How do you actually get a Linux system onto a computer and then add the software you need? This is the very first thing any IT pro needs to know: you cannot manage servers without knowing where the operating system came from or how to install the tools that make the server useful. For the CompTIA Linux+ XK0-006 exam, objective 1.2 demands you understand the different installation methods, how to handle packages (the bits of software), and how to keep everything up to date. If you cannot install Linux and manage packages, you cannot even begin the rest of the journey, so this chapter is your foundation.
Jump to a section
A simple way to picture Installing Linux and Package Management
Have you ever moved into a new flat and needed to set up your kitchen from scratch?
You start with an empty room — that's a bare-metal server with no operating system. You decide what kind of kitchen you want. A tiny apartment kitchen with a microwave and a kettle? That's a minimal Linux installation like Alpine or a core Debian netinstall. A professional chef's kitchen with a six-burner range, double oven, and industrial fridge? That's a full desktop distribution like Ubuntu Desktop or Fedora Workstation. The choice of distribution is like deciding whether you'll cook from a box or from scratch, whether you need a grill or a sous-vide machine.
Now you run the installer — the delivery and assembly crew. They unpack the cabinets (the kernel), connect the gas line (device drivers), and install the sink (the package manager). Once the kitchen is assembled, you need to stock it. Package management is like going to the supermarket. The manager is your package manager — apt, dnf, or zypper. You hand it a shopping list: "I need MySQL, Python3, and a web browser." The manager finds the exact items on the right shelf (the repository), checks the ingredients list (dependencies), and puts everything in your trolley. If you want peanut butter, the manager also grabs the bread because the recipe said so. That's resolving dependencies. Yum installs the bottle of ketchup and the chips you said you wanted — and the napkins you didn't, because the app needs them.
And if you mess up — install too many apps or the wrong packages — it's like having a messy, cluttered kitchen. You use apt remove or dnf erase to throw things in the bin. The package manager cleans up the trash, wipes the counter, and tidies the cupboard. It keeps your kitchen organised, so you can find your skillet (your web server) and your spatula (your SSH client) without digging through a heap of old takeaways.
Installing Linux is the process of putting the Linux operating system onto a computer's hard drive or solid-state drive so it can boot and run. Before installation, that computer might have nothing on it (a bare-metal machine) or it might have another operating system like Windows. Linux distributions—often called distros—are complete bundles of the Linux kernel (the core of the OS), system tools, a package manager, and often a graphical desktop environment. Different distros suit different needs: Ubuntu is beginner-friendly, CentOS Stream (or Rocky Linux) is common on servers, and Debian is rock-solid. The exam expects you to recognise that installation is not a single, monolithic step; it involves choosing a distro, selecting installation media (DVD, USB drive, network installer), partitioning the disk (splitting the hard drive into sections for system files, user data, swap space), and finally setting up user accounts and networking.
Once Linux is installed, you need software. In the old world, you might download a .exe file from a website—that is a standalone installer. Linux does something more organised. Software on Linux is distributed as packages. A package is a compressed archive that contains the software files plus metadata: the name, version, dependencies (other packages it needs to work), and installation scripts. The key tool that handles packages is called a package manager. Package managers are like automated shop assistants: they know what is available, they track what is already installed, and they understand the relationships between packages.
There are two great families you must know for XK0-006:
dpkg and apt (used by Debian, Ubuntu, Linux Mint, and their derivatives)
rpm (Red Hat Package Manager) and yum/dnf (used by Red Hat Enterprise Linux, Fedora, CentOS, Rocky Linux)
The lower-level tools (dpkg and rpm) handle individual .deb or .rpm files. You can install a specific .deb file with dpkg -i package.deb, but that tool does not automatically fetch missing dependencies. The higher-level tools—apt (apt-get or apt) and dnf (or yum)—work with online repositories. A repository is a centralised collection of packages, hosted on a server. When you run apt update, your system contacts the repository, downloads the latest list of available packages, and caches it locally. When you run apt install package, apt reads that list, finds the package, calculates the dependency tree, downloads all needed packages, and installs them in the correct order. This is a huge leap over the old way of hunting down individual installers.
Package management also includes updating and removing. Running apt upgrade or dnf upgrade updates every installed package to the latest version in the repository. This is essential for security patches and bug fixes. Removing a package with apt remove or dnf remove deletes the software files but often leaves configuration files behind; apt purge or dnf erase removes them completely. Package management tools also allow you to hold a package at a specific version (pin it) if an update would break your system.
Understanding repositories is especially important. Official repositories are vetted by the distribution maintainers, so packages are tested, stable, and secure. Third-party repositories (like EPEL for Red Hat or PPAs for Ubuntu) add extra packages not in the official set, but they come with risk—they might not be as rigorously tested. The exam will test your knowledge of when to use which tool and how to add, remove, and trust repositories.
Finally, there are alternative installation methods. You can install Linux via a PXE (Preboot eXecution Environment) network boot, which is common in data centres where hundreds of servers boot over the network without any physical media. You can also use virtualisation (installing Linux inside a virtual machine on top of Windows or macOS) or containerisation (using tools like Docker, which run isolated user-space instances sharing the host kernel). The exam wants you to know the difference between bare-metal, virtual machine, and containerised installations.
In summary, installing Linux and managing packages is fundamentally about control and consistency. You control exactly which version of an OS runs on your hardware, and you control exactly which software components get installed and when they get updated. Without package management, servers would be chaotic, insecure, and impossible to maintain at scale.
Select a Distribution
The very first step is deciding which Linux distribution (or distro) you need. For the exam, you should understand the difference between community distributions (Debian, Fedora, Arch) and enterprise distributions (Ubuntu LTS, Red Hat Enterprise Linux, SUSE Linux Enterprise Server). The choice affects everything that follows — the package manager, the default software, and the support cycle. In a real job, your company often standardises on one distribution to reduce complexity.
Obtain the Installation Media
You download the ISO file for your chosen distribution. An ISO file is a disc image — a complete copy of what would go on a DVD or USB drive. You then write that ISO to a bootable USB stick (using tools like Rufus or dd) or burn it to a DVD. Without this step, the computer has nothing to boot from. For the exam, know that you can also perform a network installation (PXE) which does not require physical media.
Boot the Installer
You plug in the USB stick or insert the DVD and restart the computer. You may need to change the BIOS/UEFI boot order so the computer boots from your media first, not the hard drive. The installer program then loads. At this point, you might see a boot menu with options like "Try Ubuntu" (for a live session) or "Install Ubuntu" (to start installation). The exam tests that you understand the difference between a live session (runs from media, no permanent changes) and an actual installation.
Partition the Disk
The installer asks you how to split the hard drive. This is called partitioning. A typical Linux system uses at least two partitions: one for the root filesystem (/) where system files live, and one for swap space (used as virtual memory when RAM is full). In a production server, you might have separate partitions for /home (user data), /var (log files), and /boot (kernel and bootloaders). The exam expects you to know terms like filesystem, mount point, and swap.
Configure the System and Install
You set your time zone, keyboard layout, user account (username and password), and optionally enable full disk encryption. The installer then copies all the necessary files from the ISO to the hard drive partitions. This takes several minutes. Once complete, the installer installs the bootloader (usually GRUB) so the computer can boot Linux on its own. You reboot, remove the installation media, and log in for the first time.
Update the System and Install Packages
After the first login, the system is already functional but likely outdated. You run your package manager: sudo apt update followed by sudo apt upgrade (Debian/Ubuntu) or sudo dnf upgrade (Red Hat). This installs security patches and bug fixes. Then you install the specific software you need: a web server (Apache), a database (MySQL), or development tools. You add any necessary repositories (e.g., EPEL for Red Hat) if the software is not in the default list.
An IT professional managing servers in a business context rarely installs a single operating system. They automate it. Here is a realistic scenario: you work for a mid-sized e-commerce company called "ShopFlow." They run thirty web servers that power their online store, all using the same distribution: CentOS Stream 9 (which uses RPM packages). Your manager asks you to deploy a new application called "InventoryTracker" to all thirty servers.
First, you log into a test sandbox. You install the application manually on one server:
- sudo dnf install inventory-tracker You quickly notice that dnf automatically installs three dependencies: python3-requests, libxml2, and sqlite. The install completes in seconds. You test the app; it works. Now you need to replicate this on all thirty production servers. You would never log into each server and type the same command thirty times—that would take hours and risk human error (forgetting a step on server 14). Instead, you use configuration management tools like Ansible or Puppet. You write a playbook that says:
- name: Install InventoryTracker dnf: name: inventory-tracker state: latest
Ansible connects to each server via SSH and runs the command. It checks if the package is already installed. If it is missing, it installs it. If it is already present at the latest version, it does nothing—that is called idempotency, a key principle of automated configuration management.
But what if your company uses a Debian-based server with Ubuntu LTS? The tool changes. You would use apt instead of dnf. The same Ansible playbook would say:
- name: Install InventoryTracker apt: name: inventory-tracker state: latest
Ansible handles the abstraction. But you, the IT pro, need to know which package manager is used on which distribution. If a colleague asks, "Is this server using yum or apt?", you should immediately check /etc/os-release or use commands like which yum or which apt.
Now imagine InventoryTracker has a major security vulnerability. A patch is released. The security team sends an alert. Your job is to update all servers. With package management, it is as simple as:
sudo dnf update inventory-tracker
You can push this via Ansible to all thirty servers at once. Without package management, you would have to manually locate the updated installer, upload it to each server, and run the installer—a fragile, error-prone process.
Finally, consider a scenario where a developer asks for a specific, unusual library: libfoo version 1.2, not the current 2.0 in the repository. You cannot just apt install libfoo=2.0 because that is not the version they need. You need to add a third-party repository (a PPA on Ubuntu or a custom repository on CentOS) or download the .deb/.rpm file directly and install it with dpkg -i or rpm -ivh, manually resolving dependencies. This is not ideal but sometimes necessary. The IT pro must know how to add a repository (apt-add-repository, or creating a .repo file in /etc/yum.repos.d/) and how to validate the source's authenticity using GPG keys.
In a production environment, package management is not just convenience—it is security compliance. Auditors will ask: "Can you prove all servers are running the same approved versions?" Your package manager log and automation tool output provide that proof.
The XK0-006 exam tests your understanding of installation and package management in several distinct ways. First, they will ask you to identify the correct package manager for a given distribution. This is a common early-exam trap—they will list four options: apt, dnf, yum, and pacman. They expect you to know that apt is for Debian/Ubuntu, dnf is the modern tool for Red Hat-based systems (replacing yum, though yum is still used on older systems), and pacman is for Arch Linux (which is not on the exam). They also test dpkg and rpm as low-level tools.
Another frequent question type: troubleshooting a failed package installation. The scenario might say: "A user runs apt install mysql-server and gets an error about unmet dependencies." The correct answer is usually to run apt-get -f install to fix broken dependencies, or to manually satisfy the dependency by installing the required package first. Traps include suggesting dpkg --force-all (dangerous) or deleting the package database.
They will also test repository management. A common question: "How do you add a new repository in Ubuntu?" The answer is either by editing /etc/apt/sources.list or adding a .list file to /etc/apt/sources.list.d/. For Red Hat, the answer is placing a .repo file in /etc/yum.repos.d/ or using dnf config-manager --add-repo.
Concepts they love to test:
- The difference between apt update and apt upgrade - apt update refreshes the local package index from repositories (does not install anything) - apt upgrade actually installs the newer versions of packages - The difference between rpm -i, rpm -e, and rpm -q - -i installs, -e erases, -q queries for information - The function of dpkg --configure -a (used after a partial upgrade to fix unconfigured packages) - What happens when you run yum clean all (clears cached metadata and packages) - How to hold a package at a specific version using apt-mark hold or dnf versionlock - How to verify a package's signature with rpm -K or dpkg --verify
Traps to watch for:
The exam might mix up distributions. They might ask about apt on a CentOS system or dnf on Ubuntu. The correct answer is always to match the tool to the distro.
They might present a question about yum vs dnf and expect you to know that dnf is the successor but yum is still present on RHEL 7 and earlier.
They may test the order of operations: before installing, must run apt update so the system knows what is available.
Questions about removing packages: apt remove leaves config files, apt purge removes config files too. The exam might ask which command fully cleans up an application.
Dependency resolution: they will present a situation where installing package A requires package B and C. Which command installs them all automatically? The answer: apt install A or dnf install A.
Key definitions to memorise:
Package: a compressed archive containing software and metadata.
Repository: a storage location (server) from which packages are downloaded.
Dependency: a package required by another package to function.
dpkg: low-level Debian package manager.
rpm: low-level Red Hat package manager.
apt: high-level tool that resolves dependencies using dpkg.
dnf: high-level tool that resolves dependencies using rpm.
Finally, the exam will test alternative installation methods. You might be asked: "Which method would you use to install Linux on 200 identical servers without physical media?" The correct answer is PXE network booting. Or: "What is the purpose of a virtual machine installer?" The answer is to run a guest OS on top of a host OS, isolating it from the host.
By understanding these patterns, you can confidently tackle the installation and package management questions on XK0-006.
Installing Linux means choosing a distribution, creating installation media, partitioning the disk, and running the installer — it is not a single click.
A package manager (like apt or dnf) resolves dependencies automatically, a task that was previously done manually and error-prone.
Packages have a lifecycle: you install them, update them, and remove them, and each command has a specific word (install, remove, purge, update, upgrade).
A repository is the trusted source where a package manager looks for packages; you must add a repository correctly to install software not in the default list.
Debian-based systems use dpkg and apt; Red Hat-based systems use rpm and dnf (or yum on older versions) — never mix them.
Updating the package index (apt update) is a separate step from upgrading software (apt upgrade) — skip the first and your system does not know what is new.
Automated configuration management tools (Ansible, Puppet) rely on package managers to ensure thousands of servers have identical, consistent software.
Removing a package with remove leaves configuration files behind; purge removes configuration, too — use purge to fully clean an application.
These come up on the exam all the time. Here's how to tell them apart.
dpkg
Low-level Debian package manager that works with .deb files directly
Does not handle dependencies automatically
Used when you need to install a specific .deb file from a local source
apt
High-level tool that resolves dependencies using dpkg under the hood
Automatically downloads and installs all required dependencies from repositories
Used for most day-to-day package operations (install, upgrade, remove)
rpm
Low-level Red Hat package manager for .rpm files
Does not resolve dependencies automatically
Useful for querying package information or installing a specific .rpm file
dnf
High-level tool that resolves dependencies using rpm under the hood
Automatically downloads and installs dependencies from repositories
Replaces yum with better performance and modern features
apt remove
Removes the software binaries but leaves configuration files intact
Useful if you plan to reinstall the same software later and want to keep settings
Does not free up space taken by configuration files in /etc
apt purge
Removes the software binaries and also deletes configuration files
Useful when you want a completely clean uninstall of an application
Frees up more disk space and removes leftover settings
apt update
Only refreshes the local package index from repositories
Does not install, upgrade, or remove any packages
Must be run before upgrade to ensure the system knows the latest available versions
apt upgrade
Actually installs newer versions of all upgradable packages
Changes the system by modifying installed software
Relies on an up-to-date index (so update comes first)
Bare-metal installation
OS installed directly on physical hardware
Has direct access to all hardware resources (CPU, RAM, disk)
Best performance but harder to snapshot or migrate
Virtual machine installation
OS runs as a guest on top of a host OS using a hypervisor (like VirtualBox, VMware, KVM)
Hardware is emulated or paravirtualised, so there is a performance overhead
Easy to snapshot, clone, and migrate between hosts
Mistake
You can install any Linux software by downloading an .exe file from a website.
Correct
Linux does not use .exe files. Software is distributed as packages (.deb or .rpm) through repositories, managed by tools like apt or dnf.
Newcomers from Windows assume the same executable-installer model, leading them to try to run Windows binaries on Linux or waste time searching for Linux 'installers' instead of using package commands.
Mistake
Running apt update is the same as running apt upgrade – both update your system.
Correct
apt update only refreshes the local package index from the repository; it does not install anything. apt upgrade actually installs the newer versions of packages.
The word 'update' sounds like it should update software, so beginners skip the critical first step and wonder why no new packages appear. They also confuse the two commands commonly.
Mistake
All Linux distributions use the exact same package management commands, like apt.
Correct
Different distributions use different package managers: Debian/Ubuntu use apt and dpkg, Red Hat/CentOS/Fedora use dnf/yum and rpm, SUSE uses zypper and rpm.
Beginners often learn one distribution (often Ubuntu) and then try the same commands on a Red Hat server, getting 'command not found' errors. They mistakenly think Linux is universal in this way.
Mistake
If a package fails to install due to a missing dependency, you should just force the installation with dpkg --force-all.
Correct
Forcing may break the system. The correct approach is to install the missing dependency first, or run apt-get -f install to fix broken dependencies automatically.
When frustrated, beginners look for the quickest 'force' solution they can find online, not realising that dependencies exist for a reason. They end up with a partially working system.
Mistake
Removing a package with apt remove completely deletes all traces of the application, including its configuration.
Correct
apt remove deletes the software files but leaves configuration files behind, which can clutter the system or cause conflicts if you reinstall. apt purge removes everything, including configuration.
Users see 'remove' and think it means total removal, not realising that configuration is kept by design (so you can reinstall without reconfiguring). They later find leftover dotfiles and settings.
Mistake
You can safely download and install individual .deb or .rpm files from random websites without any risk.
Correct
It is risky because the package may not have been signed, may be malicious, or may conflict with your system. Official repositories are vetted and signed. Always use the package manager with official repos first.
The habit of 'just download and double-click' from Windows carries over. Beginners do not understand that package signing, dependency resolution, and repository trust are essential security mechanisms.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
apt is a newer, more user-friendly command that combines the most common functions of apt-get and apt-cache. It has nicer output and progress bars, but apt-get is still fully functional. Both use the same underlying tools (dpkg) and repositories.
No. .deb files are for Debian-based systems. Red Hat-based systems use .rpm files. Trying to install a .deb file on Red Hat will fail. You must convert the package (with tools like alien) or, better, find an .rpm version or use a repository.
It means you cannot install a package because it needs software A, which needs software B, which conflicts with software C already installed. Package managers like apt and dnf solve this automatically, but before they existed, administrators had to manually resolve these chains — a nightmare known as 'dependency hell'.
Use the command sudo dnf install /path/to/package.rpm (or sudo yum localinstall for older systems). Alternatively, sudo rpm -ivh /path/to/package.rpm works but does not resolve dependencies automatically, so dnf is recommended.
Your local package index is stale or empty. The system may tell you the package does not exist (because it has no up-to-date list), or it may install an old version from a cached index. Always run apt update first to refresh the list of available packages and versions.
RHEL 9 uses dnf as the default high-level package manager. While yum is still available (as a symlink to dnf), the recommended and primary tool is dnf.
You've finished Installing Linux and Package Management. Continue through the XK0-006 study guide to build a complete picture of the exam.
Done with this chapter?