Question
Kali Linux Persistence: Transitioning from Unencrypted to LUKS Encrypted Partitions
Rey Lane
0 reputation · 09 Feb 2022, 15:29 UTC
37.2K views
Loading…
0 reputation · 09 Feb 2022, 15:29 UTC
Kali Linux Live USB persistence utilizes an overlay filesystem to merge a read-only system image with a writable partition. While the system supports both unencrypted and LUKS-encrypted persistence partitions, the transition between these two states is not an automated process.
When moving from a standard persistence partition to an encrypted one, the underlying partition must be reformatted with LUKS, which destroys existing data. Because the persistence.conf file resides within the partition itself, the configuration mapping for directories like /home and /etc is lost during the encryption process.
There is uncertainty regarding the most efficient method to migrate existing persisted data into a new encrypted volume without manually recreating the overlay configuration from scratch.
persistence.conf mapping?31275 reputation · 09 Feb 2022, 20:17 UTC
No. Existing unencrypted persistence data cannot be moved to a LUKS-encrypted persistence partition without a full backup and restore of both the data and persistence.conf. LUKS formatting is destructive and persistence.conf lives on the partition being reformatted.
Overlayfs itself does not care about a UUID change. Kali live boot finds persistence by partition label persistence and, for encrypted setups, by the LUKS mapper name created at unlock. If the label is restored to persistence after reformat, the overlay will attach to the new volume. A UUID change is therefore tolerable, a missing label is not.
kalilinuxpersistence.conf is stored inside the persistence partition and defines the overlay mappings, e.g. / union, /home, /etc. It is lost on reformat unless backed up./dev/mapper/persistence and must be mounted before overlay setup. Init scripts rely on the label persistence, not a specific UUID or /dev/sdX.Boot detection is label-based, not UUID-based. The overlayfs upperdir is provided by the mounted persistence volume. Changing UUID during reformat is expected and harmless provided the partition label is set back to persistence and the boot parameter persistence is used. The seamless transition you are looking for does not exist because the configuration file is co-located with the data it configures.
lsblk -f. Mount it read-only to external safe storage:
mkdir /mnt/oldpersist /mnt/backup
mount /dev/sdX2 /mnt/oldpersist
cp -a /mnt/oldpersist /mnt/backup/persist-copy/mnt/oldpersist/persistence.conf and the whole data tree.cryptsetup luksFormat /dev/sdX2
cryptsetup open /dev/sdX2 persistence
mkfs.ext4 -L persistence /dev/mapper/persistencemount /dev/mapper/persistence /mnt/newpersist
cp -a /mnt/backup/persist-copy/* /mnt/newpersist/
# ensure persistence.conf is restored verbatimpersistence boot parameter and verify.mount | grep overlay shows a writable upperdir from /dev/mapper/persistence.blkid shows label persistence and lsblk -f shows the mapper./home or /etc, reboot, and confirm it persists.Missing diagnostic detail that changes recommendation: exact Kali release and boot media type, e.g. official ISO with persistent overlay vs Ventoy or Rufus DD mode. Persistence detection scripts and default label handling have varied across releases, which affects whether manual mount or label correction is required after encryption.
Cautions: LUKS formatting is destructive; passphrase loss makes the volume inaccessible; do not edit persistence.conf while the overlay is active; rely on label not /dev/sdX.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.