Making Kali Linux Live USB Persistent: How It Works and How to Verify It
Learn how Kali’s persistence layer stores changes across reboots, what you need to set it up, and a quick way to confirm it’s working.
17 Apr 2026, 11:02 UTC

Why Persistence Matters on a Kali Live USB
When you boot Kali from a USB stick, the core system lives in a read‑only squashfs image. Any tool you install, configuration you tweak, or capture you save disappears on power‑off unless you rebuild the USB. Persistence solves this by giving the live system a writable layer that survives reboots while keeping the original image untouched and verifiable.
How the Persistence Layer Works
Kali uses an overlay filesystem (overlayfs on modern kernels, aufs on older ones). At boot, the system mounts two layers:
- The immutable squashfs image as the lower layer.
- A writable ext4 partition or file labeled
persistenceas the upper layer.
Overlayfs merges them into a single unified view. Files you create or modify are written to the upper layer; reads first check the upper layer, then fall back to the lower layer. Because the lower layer never changes, you can still verify the ISO’s integrity with the built‑in checksum.
Setting Up a Persistence Partition (Quick Checklist)
If you already have a Kali live USB, add a second partition (or a persistence file) and follow these steps:
- Boot from another Linux environment and identify the USB device (e.g.,
/dev/sdb). - Create a second partition, format it as ext4, and label it
persistence:sudo mkfs.ext4 -L persistence /dev/sdb2 - Mount the new partition and add a
persistence.conffile with the line:echo '/ union' | sudo tee /mnt/persistence/persistence.conf - Unmount safely:
sudo umount /mnt/persistence
When you boot the USB, choose the “Live system with persistence” entry from the boot menu.
Verifying That Persistence Is Active
You can confirm persistence without altering the base image:
- Boot Kali with the persistence option.
- Create a test file in a location that is not part of the read‑only image, for example:
touch /tmp/persistence_test - Reboot, again selecting the persistence entry.
- After login, check for the file:
If the file appears, the writable layer survived the reboot.ls -l /tmp/persistence_test - Optionally, verify the overlay is in use:
You should see a line showing the persistence partition mounted as the upper layer.mount | grep overlay
Trade‑offs and Limitations
- Size limits. The persistence partition must be large enough for all expected changes. If it fills, further writes fail and can cause instability.
- Unclean removal. Pulling the USB while the overlay is active can corrupt the persistence layer. Always shut down cleanly or unmount the partition before removal.
- Performance. Every read/write passes through overlayfs, which adds a tiny overhead compared to a native install. For most penetration‑testing tasks this is negligible.
Actionable Next Steps
If you frequently need extra tools or custom scripts on engagements, allocate a persistence partition of at least 4 GB (more if you plan to store large captures). After setting it up, run the verification steps above each time you prepare a new USB to ensure the layer is healthy. Remember to label the partition exactly persistence and include the / union line in persistence.conf; any deviation will cause the system to fall back to a non‑persistent live session.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.