Study guide
3.2 Booting Kali in Live Mode
Kali Linux Certified Professional KLCP
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path
2 About Kali Linux
2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies
3 Getting Started with Kali Linux
3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations
4 Linux Fundamentals
4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment
5 Permissions and Process Management
5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment
6 Installing Kali Linux
6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations
7 Configuring the Network, Users, and SSH
7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH
8 Configuring Services
8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd
9 Helping Yourself and Getting Help
9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports
10 Security Policy and Network Services
10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services
11 Firewalling and Monitoring
11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging
12 Debian Package Management: APT
12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt
13 dpkg and Advanced Package Management
13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity
14 Advanced Usage
14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption
15 Kali Linux in the Enterprise
15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking
16 Introduction to Security Assessments
16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead
3.2 Booting Kali in Live Mode
Key Takeaways Explain This Topic AI
The Kali live boot menu offers Live, Live (fail-safe), Live (forensic mode), USB persistence entries, and graphical/text installer entries
Live mode runs from the boot medium with a copy-on-write overlay in RAM — nothing on the host's internal disks is touched and all changes vanish on reboot unless persistence is configured
Forensic mode guarantees Kali never uses swap and never auto-mounts anything — neither internal drives nor removable media — preserving evidence on the host
Fail-safe mode boots with conservative kernel parameters (such as noapic and nomodeset) for hardware that crashes or hangs under the normal entry
Live USB persistence stores changes in a dedicated (optionally LUKS-encrypted) partition so files, settings, and tool updates survive reboots
Last updated: July 2026
Booting Kali in Live Mode
Writing a Kali ISO to a USB stick (with balenaEtcher, Rufus in DD mode, or dd ) gives you a portable Kali system. Boot from it and the live boot menu appears. The exam expects you to know each menu entry and, more importantly, what each one guarantees about the host machine.
The live boot menu entries
Live system (amd64) — the default. Kali loads the kernel, mounts a compressed read-only root filesystem (squashfs) directly from the boot medium, unions it with a copy-on-write overlay in RAM, and boots the full Xfce desktop without touching the host's internal disks.
Live system (amd64 fail-safe mode) — the same live system booted with conservative kernel parameters that disable problematic features (options like noapic, noapm, nodma, and nomodeset) for hardware that hangs, crashes, or shows a black screen under the normal entry.
Live system (forensic mode) — a hardened live session for incident-response and forensic work; detailed below.
Live system with USB persistence and Live system with USB encrypted persistence — live sessions that read and write a persistence partition on the USB device so your changes survive reboots.
Start installer / Start installer with speech synthesis — launch the Debian-based installer to put Kali onto a hard disk. (The installer-only ISO instead shows Graphical install / Install at the top level.)
Advanced install options — a submenu holding the graphical, text, expert, automated and rescue installer modes.
Utilities — a separate submenu holding memtest and the hardware detection tool (HDT).
What plain live mode does (and does not do)
In standard live mode the running system is assembled in memory: the read-only squashfs from the USB stick is layered with a copy-on-write overlay in RAM. Two consequences follow. First, the host's internal drives are left alone — you can poke a suspect machine, a friend's laptop, or a lab box without installing anything. Second, everything you change is discarded at shutdown : installed packages, saved files, browser history, all of it lives only in the RAM overlay. Log in with the default live credentials, user kali with password kali , and treat the session as disposable.
Forensic mode: guarantees and why they matter
Live (forensic mode) exists for one reason: when you examine a machine during an investigation, your own tooling must not contaminate the evidence. Merely mounting a filesystem read-write — or even read-only with certain options — can update metadata; letting the kernel activate a swap partition overwrites whatever sensitive data (passwords, keys, fragments of deleted files) happened to be swapped out there. Forensic mode therefore makes three concrete guarantees:
Swap is never used — the kernel will not activate any swap partition it finds, so existing swap contents are preserved.
Internal drives are not auto-mounted — Kali's automounter is effectively disabled, so nothing on the host's disks is touched unless you deliberately mount it yourself, and you would mount it read-only (for example mount -o ro /dev/sda1 /mnt/evidence ).
Removable media is not auto-mounted either — USB sticks, CDs and the like are ignored on insertion; nothing happens to any medium without direct user action.
This matters because forensic soundness is about being able to say, under scrutiny, that your examination did not alter the original evidence. Timestamps, unallocated space, and swap artifacts are exactly what an opposing analyst checks. If your job is to image or triage a drive, boot forensic mode; if you then need Kali's full write access for analysis, work on a forensic copy , never the original.
A classic exam trap: forensic mode is not a privacy or anonymity mode, and it is not persistence. It changes how the host's storage is treated, nothing more. Similarly, do not confuse forensic mode with fail-safe mode — fail-safe is about uncooperative hardware , forensic is about protecting data .
USB persistence
Standard live mode forgets everything at reboot, which is frustrating if you update tools, save wordlists, or customize your environment. Live USB persistence solves this: you partition the USB stick so that, alongside the live image, there is a partition labeled persistence containing a persistence.conf file, and the boot menu's persistence entries mount it as the writable overlay. Files you save, packages you install with apt , and configuration changes are written to that partition and restored on the next boot. The encrypted persistence variant stores the overlay inside a LUKS (Linux Unified Key Setup) encrypted container, so a lost USB stick does not leak your engagement notes, credentials, or client data — the obvious choice for real-world work.
Remember the boundary: persistence still runs Kali from the USB stick with live-mode performance characteristics. It is not a full disk installation, and the boot menu's installer entries remain the right path when you want Kali permanently on a machine.
Quick reference: which entry for which job
- Boot menu entry Writes to host disk? Changes kept after reboot? Use it when
- Live (amd64) No No Trying Kali, testing hardware compatibility
- Live (fail-safe) No No Normal live boot hangs or black-screens
- Live (forensic mode) No — and swap/auto-mount disabled No Examining a machine without altering evidence
- Live USB persistence Only to the USB's persistence partition Yes Daily portable Kali that remembers your setup
- Graphical install / Install Yes — full installation Yes (installed system) Putting Kali permanently on disk
One last practical note: live mode is also the best pre-install test . Boot the live entry on the target machine and confirm that Wi-Fi, audio, display, and suspend all work; if something fails live, it will fail installed, and you can research the fix before committing to repartitioning. The Utilities menu's hardware detection tool (HDT) helps inventory exactly which chipsets you are dealing with.