Why do this?

Well... I have a HP Victus 15L Desktop computer. Yes, I know, I know. Boo, hiss, HP bad. However, I also have a laptop from HP. It runs off of an Intel N200 CPU with 4GB of memory. It's fine. Good enough for communication. Not so much for work.

And thus, the HP Victus 15L. This computer was given to me after it was determined that fixing it would either take too much time, or cost more money than could be afforded. When I was told of the issues that surrounded this computer, I naturally asked if I could take a crack at it.

Turns out, it took the form of Windows not fully and properly booting off of the installed NVMe. It'd get to the Windows 10 logo and hard-lock at that point. OK, so it doesn't boot off of it. Why not try a Linux LiveUSB?, I thought to myself. So I grabbed a Debian KDE ISO and wrote it to a USB stick I had that was of sufficient size. It successfully booted in normal mode.

But it didn't even get far enough to the live environment, often rebooting just after EFI had loaded off of the USB stick. I tried the recovery mode option, which did allow it to get further. Alas, still, the desktop would instantly reboot. Eventually, I discovered that the specific kernel parameters, processor.max_cstate=1 and idle=nomwait would allow it to get to the live environment.

Success! Or so I thought. While in recovery mode, the desktop would limp along with just a singular core available to it. Over the course of a month or so, I eventually discovered with the assistance of others that maxcpus=2 was about as stable as it was going to get whilst running off of the LiveUSB. isolcpus= didn't even work, but I did discover that the Ryzen 5700G had the 10th, 13th and 15th cores hard-lock the desktop instantly when trying to wake the processors up after removing nosmp from the kernel parameters.

It was sufficiently functional enough, but even with enabling the other cores, the desktop would continue to reboot. Sometimes instantly. Sometimes after about 10-20 minutes, but it'd still reboot. Settling at maxcpus=2 allowed the desktop to run quite stably.

After all that work, I also wanted to keep data and not have to re-transfer all the things I'd need to do the usual day-to-day work stuff. I used to have a stick with Debian set up with persistence a fair few years ago and I decided it was time to do that.

So... USB Persistence?

So, I tried this with Debian 12 and 13 with this guide. Unfortunately, while the guide did allow me to successfully write the LiveUSB, it wasn't sufficient to produce a valid LiveUSB to boot. It'd drop me to grub >. Ooooh, scary! But I knew my way around it. This guide has you walk through the usage of fdisk and doesn't tell you how to actually get the 3rd partition set up correctly. It simply has you produce an invalid LiveUSB.

TELL ME THE SOLUTION ALREADY!

sudo fdisk /dev/sdb <<<$'n\np\n\n\n\nw', substituting /dev/sdb for whatever your actual disk identifier is, if you follow the above guide.

That's it. That's the trick. And yes, it works with UEFI with the above fdisk one-liner.

Why not replace the desktop? Or the CPU? The board?

Money. Have you seen the prices for replacement hardware in the year of our laird, 2026? This computer was functional enough for my needs. Eventually though, I'll replace the CPU or motherboard. I have replacement hardware, but they're unfortunately not close enough at hand as I'd been visiting my friends in Atlanta and South Carolina after FurryWeekend Atlanta and MegaPlex 2026.

But replace it, I will. Just need to confirm which one is the bad part and replace it. But given that HP has refused to correct the infamous C-state issue for these computers, it may be best to just scavenge the NVMe, RAM and GPU from this deskop.

The Guide in full

You will need a USB drive that's at least 8GB or larger, these days. The larger, the better. In my case, I had a 250GB PNY SSD in a SATA to USB enclosure. Plug the drive in, wait for it to show up and ignore the prompt to mount it. We'll want to go to the Terminal or the shell of your choice.

Download the ISO and modify it.

Depending on your preferred LiveUSB OS, here's how:

LANG=C sed 's/splash quiet/persistence /;s/quiet splash/persistence /' \
    </home/keiro/debian-live-13.6.0-amd64-kde.iso \
    >/home/keiro/debian-live-13.6.0-amd64-kde.iso-persist.iso

Identify the drive

Determine what your drive's identifier is.

lsblk -o NAME,SIZE,MODEL,MOUNTPOINT

You should get output something very much like this, as an example:

user@debian ➜  ~ lsblk -o NAME,SIZE,MODEL,MOUNTPOINT
NAME     SIZE MODEL               MOUNTPOINT
loop0    3.2G                     /run/live/rootfs/filesystem.squashfs
sda    232.9G PNY CS900 250GB SSD 
├─sda1   3.9G                     /run/live/medium
├─sda2   3.3M                     
└─sda3   229G                     /run/live/persistence/sda3

Naturally, you'll want to substitute /dev/sd[x] with whatever your USB's identifier is. In my case, it was /dev/sdb. Yes, the output looks different here, due to running in LiveUSB persistence mode.

Wipe the Drive

sudo wipefs -a /dev/sd[x] -- be sure to get this right!

Once done, let's create the MBR/UEFI partition.

sudo dd if=/dev/zero of=/dev/sdb bs=1M count=200

wipefs will format the drive. Meanwhile, dd zeros the first 200 MB, covering the MBR, GPT header, and any EFI data in the early sectors.

Verify sync

Before running dd, confirm that sync resolves to the system binary and not a shell alias:

type sync

The output should be sync is /usr/bin/sync. If it returns an alias definition instead, unalias it with unalias sync, or substitute /usr/bin/sync explicitly at the end of the dd command.

Write the ISO to your USB

sudo dd if=/path/to/debian-live-13.6.0-amd64-kde.iso of=/dev/sdb bs=4M status=progress && sync

status=progress shows the running transfer rate. sync flushes the write cache on completion—don’t remove the drive before it returns. It'll take a bit.

Boot off of the USB

Before adding the persistence partition, confirm the ISO write produced a bootable drive. Boot the computer and ensure you choose to boot off of the LiveUSB via whatever your motherboard's boot selector path. If it reaches the Debian live menu and boots cleanly, you have a known working LiveUSB. If it doesn’t boot at this stage, go back and redo the steps carefully.

Let's Make the Magic Happen

Following the above steps and writing the LiveUSB will leave you with free disk space after the ISO has been written. Debian uses a isohybrid layout—a hybrid MBR/GPT partition table that supports both BIOS and UEFI boot paths. Adding a partition requires an explicit start sector; without it, fdisk’s default placement can conflict with the hybrid structure in strange ways. So let's take that out of the equation and run:

sudo fdisk /dev/sdb <<<$'n\np\n\n\n\nw'

After fdisk writes the new partition table, the running kernel may not immediately recognize the change. partprobe signals the kernel to re-read the partition table on the device without requiring a reboot:

sudo partprobe /dev/sdb

Once it completes, confirm the new partition is visible:

lsblk /dev/sdb

Your new partition will appear beneath the device in the output. Note its full identifier—for example, sdb3 in my case, as you’ll need it in the next few steps. If it doesn’t appear immediately, wait a moment and run lsblk again before proceeding.

Format the Partition

Format the new partition as ext4 with the label persistence. The Debian live system identifies the persistence partition by this label at boot:

sudo mkfs.ext4 -L persistence /dev/sdb

Create the Persistence Configuration

Mount the partition:

sudo mount /dev/sdb /mnt

Create the configuration file:

sudo echo "/ union" | sudo tee /mnt/persistence.conf

The / union directive instructs the live system to mount the entire filesystem as a union overlay. Changes made during a session are written to the persistence partition rather than discarded on shutdown.

Sync the data:

sudo sync

Unmount the partition:

sudo umount /mnt

Finally, let's BOOT!

Boot from the USB, since we already modified the LiveUSB to include the persistence parameter to boot from.

The first boot with persistence active will be slower than a standard live session—the system is running entirely from the USB drive, and the persistence overlay adds a layer of I/O. This is normal.

Verify Persistence

After booting, confirm the persistence partition is mounted:

lsblk -f

The output should show something very much like this:

user@debian ➜  ~ lsblk -f
NAME   FSTYPE   FSVER            LABEL                  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0  squashfs 4.0                                                                                0   100% /run/live/rootfs/filesystem.squashfs
sda    iso9660  Joliet Extension d-live 13.6.0 kd amd64 2026-07-11-09-02-23-00                              
├─sda1 iso9660  Joliet Extension d-live 13.6.0 kd amd64 2026-07-11-09-02-23-00                     0   100% /run/live/medium
├─sda2 vfat     FAT12                                   6A52-069F                                           
└─sda3 ext4     1.0              persistence            612e6ba2-bc3f-4956-8c18-1947ffb6df81  209.7G     1% /run/live/persistence/sda3

Create a test file:

touch ~/persistence-test.txt

Reboot with persistence enabled. If the file is present after reboot, persistence is working.