Installing Linux

No objective asks you to perform an installation, but the objectives do name its parts. Objective 4.1 lists unattended deployment, Kickstart and cloud-init; 1.1 lists PXE and the boot process; 1.3 is the partitioning and filesystem decisions you make while installing; 3.6 covers verifying what you installed. So this is not off-syllabus material, it is the one task those objectives are scattered across. CompTIA gives installation a whole chapter with two labs for the same reason. The decisions you make here are cheap now and expensive or impossible later.

Why this matters

Installation is where you make choices you will live with for the machine's whole life. Filesystem type, partition layout, whether /var is separate, whether the disk is encrypted — all are cheap now and expensive or impossible later. Choosing xfs and later needing to shrink it means a rebuild.

It is also placed late in this course deliberately, following CompTIA's own sequencing: you learn to operate a system before you learn to build one, because the install decisions only make sense once you understand what they affect.

The lesson

Physical and virtual deployments

Physical — boot from USB or over the network, install to local disks. You care about firmware mode (UEFI or legacy), RAID controller configuration, and driver availability for the network and storage controllers.

Virtual — create the VM, attach the ISO, install. Most decisions are already made for you by the hypervisor, and the ones that remain are about resources and device types (VirtIO, from the virtualisation lesson).

Cloud — usually neither. You launch a pre-built image and configure it with cloud-init at first boot. Nobody installs an operating system to start an EC2 instance, and the "installation" skill that matters there is image building.

Choosing a distribution

Decide on support model rather than preference:

RHEL family (RHEL, Rocky, AlmaLinux, CentOS Stream) — ten-year lifecycle, slow-moving packages, backported fixes, and the family most enterprise software is certified against. dnf, SELinux, xfs by default.

Debian family (Debian, Ubuntu LTS) — five years for Ubuntu LTS, newer packages, very large repositories. apt, AppArmor, ext4 by default.

The practical questions: what does your application vendor support, what does your team already know, and how long must this machine live without a rebuild. Novelty is rarely the right criterion for a server.

Preparing installation media

# find the target device FIRST, and be certain
lsblk
sudo dd if=Rocky-9.4-x86_64-dvd.iso of=/dev/sdb bs=4M status=progress oflag=sync
sync

dd will overwrite whatever you point it at. Write to /dev/sda instead of /dev/sdb and you have destroyed the machine you are working on, with no prompt and no undo. Run lsblk immediately before, confirm the size matches the USB stick, and read the command twice.

Safer alternatives that do the same job with a confirmation step: Fedora Media Writer, Rufus on Windows, or Ventoy, which lets you keep several ISOs on one stick and choose at boot.

Verifying the image checksum

Do this before writing, not after.

sha256sum Rocky-9.4-x86_64-dvd.iso
sha256sum -c CHECKSUM                     # compare against the published file

gpg --verify CHECKSUM.gpg CHECKSUM        # verify the checksum file's SIGNATURE

A checksum alone proves the download was not corrupted in transit. It does not prove the image is genuine — anyone who could replace the ISO on a mirror could replace the checksum file beside it. Verifying the checksum file's GPG signature against the distribution's published key is what proves origin.

This is the same distinction as in the source-build lesson, and it matters more here: you are about to boot this image and hand it your disks.

Booting the installer

• Choose the boot device in firmware, or use the one-time boot menu (F12, F11, Esc — it varies).
• Match firmware mode to intent. Installing in legacy BIOS mode when you meant UEFI produces a system that boots but cannot use Secure Boot, and converting afterwards means reinstalling the bootloader and repartitioning. ls /sys/firmware/efi in the installer's shell confirms which mode you are in.
• Secure Boot may need to be temporarily disabled for distributions without a signed shim — most mainstream ones are signed and need no change.

Partitioning during installation

The layout you will be offered by default is one big root plus swap, and it is fine for a laptop. For a server, separating filesystems buys containment:

Separating /var is the one that repays itself. Runaway logging fills /var and the system keeps running; fill / and it stops, often in ways that make recovery awkward.

The counter-argument is real: fixed partitions can be sized wrongly and you may end up with space in the wrong place. Use LVM and that objection mostly disappears — you can grow any volume later from free extents, which is why LVM is the default in most server installers.

Filesystem and mount point choices

xfs — RHEL's default. Excellent at scale, grows online, and cannot be shrunk. Choose it when sizing is confident.

ext4 — Debian's default. Mature, and it can be shrunk offline. Choose it when sizing is uncertain.

btrfs — snapshots and checksumming built in, more moving parts.

Set noatime on data-heavy filesystems, and noexec,nosuid,nodev on /tmp and /var/tmp, at install time — retrofitting means an fstab edit and a remount you have to remember.

Encryption is an install-time decision. Enabling LUKS during installation is a checkbox; adding it afterwards means backing up, reformatting and restoring. Do it on anything portable, and on anything you will eventually decommission — which, as the destruction lesson argued, is every disk.

Swap sizing

The old rule of twice RAM is long obsolete. Current practice:

Hibernation is the reason for the second column — suspending to disk writes the whole of RAM into swap, so swap must be at least as large as RAM. Servers do not hibernate, so they take the smaller figure.

Some swap is better than none even with plenty of RAM: it lets the kernel evict genuinely idle pages and keep more cache. Tune the tendency rather than removing it:

sysctl vm.swappiness            # 60 default; 10 is common on servers
echo "vm.swappiness = 10" > /etc/sysctl.d/99-swap.conf

A machine swapping heavily is a machine that needs more RAM. Swap is a safety margin, not capacity.

Bootloader placement

GRUB2 goes to the EFI System Partition on UEFI systems, or the MBR of the boot disk on legacy ones. The installer normally gets this right; the case to watch is multiple disks, where the bootloader must land on the disk the firmware actually boots from. Install it elsewhere and the machine completes its installation and then will not boot.

Set a GRUB password where physical access is a concern — otherwise anyone at the console can edit the kernel line to init=/bin/bash and have root without a password, exactly as the boot lesson described.

Network configuration during install

Configure it during installation rather than afterwards. The installer needs the network for updates and for any network-based package source, and getting it right at that point avoids a machine you then have to reach some other way.

Set the hostname here too. It is used in certificates, logs and monitoring, and changing it later means chasing every place it was recorded.

Servers want static addressing, or a DHCP reservation. A server whose address changes is a server whose DNS, firewall rules and monitoring all quietly become wrong.

Creating the first user

Create a normal user and add it to wheel or sudo. Leave the root password unset where the installer allows it, so sudo is the only escalation route — which is the account-hardening position arrived at by default.

Add your SSH public key during installation if the installer supports it; the machine is then reachable with key authentication from first boot, and password authentication can be disabled immediately.

Post-installation steps

A short standard sequence, worth doing every time:

dnf update -y                          # or: apt update && apt upgrade -y
systemctl enable --now chronyd         # TIME FIRST
timedatectl set-timezone Etc/UTC
hostnamectl set-hostname web01

# SSH: keys only
ssh-copy-id user@newhost               # from your workstation, first
# then on the host:
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sshd -t && systemctl reload sshd

firewall-cmd --permanent --add-service=ssh && firewall-cmd --reload
getenforce                             # confirm SELinux is Enforcing
aide --init                            # integrity baseline, BEFORE exposure

Two of those are ordered deliberately. Time first, because Kerberos, TLS and log correlation all depend on it and skew produces failures that look like anything but a clock. The AIDE baseline before the machine is exposed, because a baseline taken later may enshrine a compromise as normal.

Confirm you can log in with a key in a second session before disabling password authentication in the first.

Unattended installation with Kickstart

Installing by hand does not scale and is not reproducible. Kickstart (RHEL family) answers every installer question from a file:

# ks.cfg
lang en_GB.UTF-8
keyboard uk
timezone Etc/UTC --utc
rootpw --lock
user --name=admin --groups=wheel --password=<hash> --iscrypted
network --bootproto=dhcp --hostname=web01
bootloader --location=mbr
clearpart --all --initlabel
autopart --type=lvm --fstype=xfs
firewall --enabled --service=ssh
selinux --enforcing
%packages
@^minimal-environment
chrony
%end
%post
dnf -y update
%end

# pass it at boot
inst.ks=http://provisioning/ks.cfg

The installed system also writes /root/anaconda-ks.cfg — the Kickstart equivalent of what you just did by hand. Install one machine interactively, then take that file as the starting point for your template. It is far easier than writing one from scratch.

Debian's equivalent is preseed; Ubuntu Server now uses autoinstall YAML. Combined with PXE from the boot lesson — DHCP points at TFTP, TFTP serves the installer, the installer fetches the Kickstart file — you have unattended provisioning of bare metal at any scale.

What to take away

• Verify the ISO's signature, not just its checksum.
• dd to the wrong device destroys the machine you are using. lsblk first.
• Match UEFI or legacy at install time; converting later is a reinstall.
• Separate /var so logs cannot fill root, and use LVM so sizing mistakes are recoverable.
• xfs cannot be shrunk; ext4 can. Decide before you commit.
• Encryption is cheap at install and expensive afterwards.
• Swap sizing: hibernation needs swap ≥ RAM; servers do not hibernate.
• Configure time, hostname and network during installation.
• Take the integrity baseline before the machine is exposed.
• Keep /root/anaconda-ks.cfg from the first manual install — it is your Kickstart starting point.