Kali Linux Live USB Persistence: How the Overlay Works and When It Fails

The Problem: A Kali Live USB Forgets Everything

Booting Kali Linux from a USB stick gives you a clean, forensically sound environment every time. That same cleanliness becomes a problem when you need to keep installed tools, configuration files, or evidence notes across reboots. The solution is the Live USB persistence feature, which layers a writable partition over the read-only live image. If it is configured correctly, changes to directories listed in persistence.conf survive a restart. If it is configured incorrectly, the system silently boots without persistence and you lose work.

How Persistence Works: An Overlay, Not an Installation

A standard Kali Live USB boots a compressed, read-only squashfs image. Persistence does not modify that image. Instead, the boot process looks for a separate writable area—either an ext4 partition labeled persistence or a file named persistence.img—and mounts it at /live/persistence/overlay. The kernel then uses overlayfs, a union filesystem, to present the read-only base and the writable overlay as a single directory tree.

When you write to a persistent directory, overlayfs stores the new data in the overlay. When you read a file you have not changed, overlayfs serves it from the original squashfs image. The base image remains untouched, which is why the same USB stick can boot a pristine Kali session later.

A Working Configuration

The most reliable setup uses a dedicated ext4 partition on the same USB stick, separate from the Kali live image partition. The partition must carry the label persistence and contain a file named persistence.conf.

Partition layout example

On a 32 GB USB drive, a common split is roughly 8 GB for the live image and the remainder for persistence. The persistence partition should be marked bootable (the boot flag) so the firmware and bootloader recognize it correctly.

The persistence.conf file

Create this file in the root of the persistence partition. Each line names a directory whose contents should be written to the overlay:

/home
/etc
/usr/local

Only list directories you actually need to preserve. Listing / or overly broad paths increases the chance of overlay conflicts and fills the fixed-size partition faster.

Creating the partition from a running Kali session

If you are preparing the USB from an existing Kali installation, run these commands as root. Replace /dev/sdX2 with the actual device node for your second partition—check with lsblk before proceeding.

# mkfs.ext4 -L persistence /dev/sdX2
# mkdir -p /mnt/persist
# mount /dev/sdX2 /mnt/persist
# printf '/home\n/etc\n/usr/local\n' > /mnt/persist/persistence.conf
# umount /mnt/persist

Risk: Running mkfs.ext4 on the wrong device node destroys data. Verify the target with lsblk -f and confirm the partition is not currently mounted.

Verifying Persistence Is Active

Boot the USB stick and watch the initial boot messages. A correctly configured system prints a line indicating that persistence has been enabled. After logging in, confirm the overlay is mounted read-write:

$ mount | grep /live/persistence/overlay

Expected output shows the overlay device mounted at /live/persistence/overlay with the rw option. If the directory is absent or mounted read-only, persistence did not activate.

A quick functional test

Create a marker file in a persistent directory, reboot, and check that it remains:

$ touch /home/user/persistence_test
$ sudo reboot

After the system restarts, ls /home/user/persistence_test should return the filename. If the file is gone, the overlay was not mounted or the directory was not listed in persistence.conf.

Limits and Common Mistakes

The overlay is a fixed size

The persistence partition does not grow. Check available space before large operations:

$ df -h /home

If the overlay fills, writes to persistent directories fail or the filesystem remounts read-only. Kernel upgrades and large tool installations consume space quickly; a persistence partition that is too small will become unusable after routine updates.

FAT32 and NTFS will not work

The persistence filesystem must be ext4. FAT32 and NTFS lack Unix file permissions and ownership, so the live system cannot safely store /home or /etc data there. If you created the stick with a third-party tool, check that the persistence partition is genuinely ext4 and not a FAT32 data partition.

Missing persistence.conf or wrong label

The boot process scans for the exact label persistence. A partition named kali_persistence or writable is ignored. Likewise, an ext4 partition without persistence.conf in its root will not be used as an overlay.

Editing /etc while services run

Because /etc can be persistent, configuration changes are written to the overlay immediately. However, running daemons may have already read the old configuration into memory. After editing service configuration, restart the affected service or reboot to avoid an inconsistent state.

Sharing the USB drive

Using the same stick for multiple live distributions or installer images risks overwriting the persistence partition. If a second tool repartitions the drive, the persistence label and its data are lost. Keep persistence on its own partition and back up critical files elsewhere.

Encryption requires manual setup

An unencrypted persistence partition is readable by anyone with physical access to the USB stick. The standard creation tools do not encrypt it. To protect the data, manually create a LUKS-encrypted ext4 container, label it persistence, and reference it in persistence.conf. The boot process will prompt for the passphrase before mounting the overlay.

Practical Check Before You Rely on It

Do not assume persistence is working because you created a partition. Boot the stick, run mount | grep /live/persistence/overlay, create a test file, and reboot once. If the file survives and the overlay is mounted rw, the configuration is sound. If not, re-check the partition label, the filesystem type, and the contents of persistence.conf before storing anything important on the drive.