Kali Linux is a Debian-based operating system for security testing and digital forensics. It groups command-line utilities, graphical analysis programs and curated package collections around controlled technical work. Kali Linux can run from removable media, install on a physical computer or operate inside a virtual machine. It does not perform an assessment by itself; the user still chooses a target, a method and an authorized scope.
Images serve different jobs
The main Installer image places Kali Linux on a disk and carries enough packages to complete setup without an Internet connection. It does not open into the full live desktop. The Live image takes the opposite route: it starts a working desktop from USB and lets the user test hardware or work without touching the installed operating system.
The NetInstaller downloads its packages during setup. That keeps the image small and selects current repository packages, but a failed connection can stop the installation. Choosing an image by download size alone can therefore produce the wrong boot behavior at the moment it matters.
Live changes disappear
A standard Kali Linux live session keeps its working changes in memory. Files saved only inside that temporary system, installed packages and changed settings disappear after shutdown. This behavior keeps the USB image clean between sessions, but it can surprise someone who expects a live desktop to behave like an installed system.
Persistence needs an additional partition and configuration on the USB drive. Once configured, it can retain selected files and settings across boots. Persistence also creates a lasting store on a device that may travel between computers, so the user must decide what should survive and protect the removable drive accordingly.
Services start cautiously
Kali Linux blocks externally listening network services from starting automatically under its default policy. Installing a package that contains a server does not necessarily leave that server active after the next restart. The policy limits unexpected exposure when the system joins an untrusted network.
A lab that depends on SSH, a database listener or another daemon may therefore fail until the user starts the service. Making the service persistent requires a separate enable action. This is a deliberate difference from a general server installation, where packages often activate their daemons during setup.
Updates need context
Kali Linux follows a rolling repository. Package versions move continuously instead of waiting for a new fixed operating-system release. The package manager needs a fresh view of the repositories before an install or system update, so refreshing the package lists is the first step when it reports that a package cannot be found.
A normal upgrade may hold packages back during a repository transition. A full upgrade can resolve those dependency changes by adding or removing packages as needed. That command deserves attention because it may alter more of the system than a routine update. An expired signing key can also stop repository access until the current key reaches the system.
Hardware still decides
The live desktop can confirm whether graphics, storage and network hardware work before installation. A successful boot does not guarantee that every wireless adapter supports the monitoring mode needed by a particular task. Virtual machines add another boundary because the guest normally sees virtual hardware rather than the host’s physical wireless device.
Passing a USB adapter into the guest can expose the required hardware, but the host must release that device first. A laptop can also need different firmware than the live image carries. Kali Linux includes broad hardware support, yet the assessment workflow still depends on the exact adapter and driver.
Install logs matter
An installation can fail because the downloaded image is corrupt, the target lacks space or the storage layout conflicts with the chosen setup. Repeating the same steps does not repair a damaged image. Verifying the download and writing it again to the USB drive can separate media trouble from an installer problem.
The installer can save debug logs after a failure. Those logs record the step that stopped and can be copied from the temporary environment. Keeping them is more useful than photographing only the final red screen, which rarely identifies the package, disk or configuration that caused the failure.
