Tech Log Entry — Kali Linux Live USB Drive Build (with Encrypted Persistence)

Tech Log Entry — Kali Linux Live USB Drive Build

(with Encrypted Persistence)

Part 1 of 2: ISO Acquisition, USB Write, Partition Layout, LUKS Encryption, and Persistence Boot

Dates: June 29–30, 2026

Summary

Successfully built a bootable Kali Linux 2026.2 Live USB thumb drive (32 GB, USB 3.0) with an encrypted persistence partition using LUKS. The build was performed entirely via CLI on a Linux Mint laptop (laptop #2). The process covered ISO acquisition via torrent, SHA256 checksum verification, raw disk write using dd, three-partition layout using fdisk, LUKS2 encryption using cryptsetup, ext4 filesystem creation labeled 'persistence', and persistence.conf configuration. After a multi-boot troubleshooting sequence to resolve a non-obvious two-prompt boot pattern, the encrypted persistence partition was confirmed fully operational across multiple reboots.

Background and Context

This project is part of an ongoing homelab and CompTIA Network+ study program. The goal was to produce a portable, self-contained network analysis toolkit that can be carried and used on personal machines (laptop #1 and laptop #2) as well as compatible public machines such as library computers and hotel business center computers.

The host machine for the build was laptop #2 (Dell Latitude E7440, Linux Mint), referred to throughout as the build machine. The target device was a 32 GB USB 3.0 metal waterproof thumb drive plugged directly into one of the laptop's USB 3.0 SuperSpeed ports.

Kali Linux was chosen because it is the industry-standard penetration testing and network analysis distribution, with a large ecosystem of pre-packaged security and monitoring tools and extensive documentation. The Live USB with encrypted persistence model was chosen to avoid permanently installing Kali on any machine, while still retaining installed tools and configurations across sessions (as was done previously with Linux Tails).

Hardware and Environment

Item	Detail
Build machine	Laptop #2 — Dell Latitude E7440, Linux Mint, UEFI (Secure Boot disabled), USB 3.0 ports
USB drive	32 GB USB 3.0 metal waterproof thumb drive, directly connected to USB 3.0 SS port
Kali version	Kali Linux 2026.2 Live amd64
Boot mode	Legacy BIOS mode (F12 boot menu on Dell)
Network	ProtonVPN active during ISO download

Steps in Process

Step 1: ISO Acquisition

The Kali Live ISO was not available via direct wget from the primary CDN URL — a 404 error was returned. The Kali website was confirmed to be serving only torrent links for the Live image on the main downloads page. The torrent method was used as the officially recommended alternative.

• Installed transmission-cli on Linux Mint: sudo apt install transmission-cli

• Downloaded Kali 2026.2 Live amd64 ISO via torrent using transmission-cli

• Noted 'got unrequested piece' messages from one peer IP during download — Transmission correctly flagged and discarded these packets; no impact on file integrity

• Stopped seeding (Ctrl+C) after Transmission entered seeding state, confirming download completion

Step 2: SHA256 Checksum Verification

The official SHA256 checksum for kali-linux-2026.2-live-amd64.iso was obtained from the Kali downloads page:

49e90e694d1b3dedd47f94afbe99dfdd5afb41c8462b638bbd332929769c773a

Verification command:

sha256sum ~/Downloads/kali-linux-2026.2-live-amd64.iso

Result: exact match confirmed. ISO verified as authentic and uncorrupted before proceeding.

Step 3: USB Drive Identification

lsblk was run before and after inserting the USB drive to identify the correct device node by comparing outputs. The USB drive was confirmed as /dev/sdb (29.3 GiB, one existing partition sdb1). Given the finality of using the “dd” command, deliberate examination and preparation of the USB drive was called for.  The device was confirmed empty of any content to retain before proceeding.

Step 4: Writing the ISO with dd

Command used:

sudo dd if=~/Downloads/kali-linux-2026.2-live-amd64.iso of=/dev/sdb bs=4M status=progress oflag=sync

Result: 5.2 GiB written in 127 seconds at 43.5 MB/s. No errors reported. oflag=sync ensured full buffer flush before the command returned.

Step 5: Partition Layout Inspection

sudo fdisk -l /dev/sdb confirmed the ISO created two partitions:

• sdb1: 5.1 GB — Hidden HPFS/NTFS — main Kali live system

• sdb2: 4.1 MB — FAT12 — EFI/boot support partition

Unallocated space from sector 10804064 to 61439999 (~24 GB) was available for the persistence partition.

Step 6: Creating the Persistence Partition

The existing sdb1 was unmounted (sudo umount /dev/sdb1) before partition work. fdisk was used interactively to create a new primary partition 3 in the unallocated space:

• Partition number: 3

• First sector: 10804064 (immediately after sdb2)

• Last sector: default (61439999 — all remaining space)

• Type: Linux (83) — assigned automatically

• Size confirmed: 24.1 GiB

The partition table was written with the 'w' command. The kernel acknowledged the new table via ioctl().

Step 7: LUKS Encryption

Command used:

sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb3

'YES' entered in all caps to confirm. A strong 6-word mixed-case passphrase was created and entered twice. Output confirmed: 'Key slot 0 created. Command successful.' The passphrase was written down and stored in two separate physically secure locations (same as with the Linux Tails USB drive).

Step 8: Opening and Formatting the Encrypted Partition

The LUKS container was opened:

sudo cryptsetup luksOpen /dev/sdb3 kali_persistence

Confirmed present in /dev/mapper/ as kali_persistence. Formatted as ext4 with the required label:

sudo mkfs.ext4 -L persistence /dev/mapper/kali_persistence

Filesystem created with 6,325,396 blocks. Label 'persistence' confirmed — Kali's live-boot system uses this label to identify the persistence partition at boot time.

Step 9: Persistence Configuration File

Mount point created and partition mounted:

sudo mkdir -p /mnt/kali_persistence

sudo mount /dev/mapper/kali_persistence /mnt/kali_persistence

persistence.conf created:

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

Verified with cat: output confirmed '/ union'. This single line instructs Kali's live-boot overlay system to persist the entire filesystem, meaning all installed packages, configuration changes, and saved files survive reboots.

Step 10: Cleanup and Ejection

Unmounted the persistence partition, closed the LUKS container, confirmed kali_persistence was absent from /dev/mapper/, and ejected the drive:

sudo umount /dev/mapper/kali_persistence

sudo cryptsetup luksClose kali_persistence

sudo eject /dev/sdb

Problems Encountered and Solutions

Problem 1: Direct ISO Download Returned 404 and DNS Errors

Initial wget attempts to download the ISO directly from cdimage.kali.org failed — first with a DNS resolution error (no network connection to CDN), then with a 404 error after VPN was enabled. Investigation confirmed Kali 2026.2 Live ISO is not available as a direct download from the primary CDN; only torrent links are served for the Live image.

• Did not work: Direct wget to cdimage.kali.org/kali-2026.2/kali-linux-2026.2-live-amd64.iso

• Worked: torrent download via transmission-cli (sudo apt install transmission-cli; transmission-cli [torrent URL])

Problem 2: Encrypted Persistence Not Engaging on Boot

After a successful first boot (confirming persistence worked), subsequent reboots failed to prompt for the /dev/sdb3 LUKS passphrase. Tools installed in the persistence session were absent, and mount | grep sdb3 returned nothing, confirming persistence was not mounted.

Extensive diagnostics were performed to identify the cause:

• fdisk -l /dev/sdb confirmed partition table intact (sdb1, sdb2, sdb3 all present)

• cryptsetup luksDump /dev/sdb3 confirmed LUKS2 header valid

• blkid /dev/sdb3 confirmed TYPE=crypto_LUKS and correct UUID

• Manually opening the partition confirmed LABEL=persistence and / union in persistence.conf

• Confirmed installed tools present in /mnt/check/rw/ overlay directories

• cat /proc/cmdline confirmed all kernel boot parameters correct: persistent=cryptsetup, persistence-encryption=luks, persistence all present

After exhausting technical causes, the root cause was identified as a user interface issue during the boot sequence: the /dev/sda4 prompt (for the Linux Mint internal encrypted drive) generates two separate prompts requiring two separate 'n' responses before the /dev/sdb3 prompt appears. Missing the second prompt caused the boot sequence to wait indefinitely, appearing as if persistence detection had failed.

• Did not work: Attempting to fix via partition table, LUKS header, label, persistence.conf, or kernel boot parameter changes — all were already correct

• Worked: Careful observation of the full boot prompt sequence; entering 'n' twice (once at the initial sda4 prompt, once at the 'error decrypting... retry? Y/n' prompt) before the sdb3 prompt appears

Lessons Learned

• Verify the download method before starting. Official CDN direct links can become unavailable between documentation updates and actual release. Always check the current downloads page for the authoritative method.

• SHA256 verification is non-negotiable before writing to disk. Corrupted or tampered ISOs produce subtle, hard-to-diagnose problems later. Verify before every dd write.

• When persistence fails to engage, check the simplest explanation first — user interaction — before assuming technical failure. The partition, LUKS header, label, and kernel parameters were all correct; the issue was a two-step boot prompt that was easy to miss.  Consider using clearer visual differentiation of prompts (both “sda4” and “sdb3” have 4 characters, both starting with “sd”).

• dd provides no confirmation prompt. The combination of lsblk before and after insertion, plus fdisk -l to confirm device size, is the minimum safe identification procedure before running dd.

• Physical custody of encrypted USB drives is a security control. A drive containing an encrypted persistence partition with installed tools and potentially captured network data should be treated like a hardware security key — not loaned, not left unattended.

Things to Watch Out for in Future

• Boot prompt sequence on any target machine: the two-prompt sda4 sequence is specific to machines with LUKS-encrypted internal drives. On machines without internal encryption, only the sdb3 prompt will appear. On public machines, no internal encryption prompt is expected.

• Secure Boot on public machines: many library and hotel computers have Secure Boot enabled and/or USB booting disabled in BIOS, preventing the Kali USB from booting. This is expected and not a malfunction — success rate on unknown public machines is variable.

• The USB drive is in Legacy BIOS boot mode on the Dell E7440. UEFI boot was available but not configured during this build. If used on machines that require UEFI boot, a different boot menu entry or configuration may be needed.

• The persistence partition is 24.1 GB. Disk usage should be monitored periodically, especially after large tool installations or if packet captures are saved to the persistence partition.

Networking studies note This project directly addresses multiple CompTIA Network+ domain areas: • Network Security: LUKS encryption at rest, passphrase management, encrypted partition creation and management, and the distinction between encryption in transit (handled by VPN during download) and encryption at rest (LUKS persistence partition). • Network Troubleshooting: The structured approach to diagnosing persistence failure — checking partition table, LUKS header, filesystem label, kernel boot parameters, and overlay directory contents before identifying the root cause — mirrors the CompTIA troubleshooting methodology: identify the problem, establish a theory, test the theory, implement the solution, verify. • Network Tools: Hands-on use of dd (raw disk I/O), fdisk (partition management), cryptsetup (LUKS encryption), mkfs.ext4 (filesystem creation), lsblk and blkid (device identification), and sha256sum (integrity verification) — all relevant to network operations and security tooling. • Portable Security Toolkit Concepts: Live USB systems, persistence overlays, and encrypted portable environments are used in professional network security, penetration testing, and incident response contexts.

Next Steps / To-Do (from Part 1)

• Proceed to tool installation into the persistence partition (covered in Part 2)

• Consider configuring UEFI boot support on the USB drive in a future session for compatibility with machines that do not support Legacy BIOS boot

• Establish a periodic check of persistence partition disk usage