--- title: 'Debian and USB Persistence' url: 'https://ituralde.com/da-blog/debian-persistence' markdown: 'https://ituralde.com/da-blog/debian-persistence.md' date: '2026-10-26' description: "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 comput…" --- ## [Debian and USB Persistence](https://ituralde.com/da-blog/debian-persistence) 26th Oct 2026 # 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](https://cache.forums.debian.net/index.php?title=Debian_Live_USB_with_Persistence) 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-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! IT WILL FORMAT YOUR DRIVE OR PARTITION IF YOU DON'T! 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` The partition MUST be named persistence #### 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. --- ## Navigation - Parent: [Da Blog](https://ituralde.com/da-blog.md) - Previous: [Dealing with ADHD](https://ituralde.com/da-blog/adhd.md)