Skip to content

Installing Linux

Now that you can tell distributions apart, it's time to get one running. This page covers every common way to run Linux, how to verify an ISO so you don't boot a tampered image, how to make a bootable USB, a conceptual walkthrough of an AlmaLinux 9 install, and the first things every admin should do on a fresh server.

Tested on

AlmaLinux 9.4 installer (Anaconda). ISO verification and dd examples run on any Linux host; Rufus/balenaEtcher steps are for Windows/macOS.

Ways to run Linux

You don't always need to wipe a machine. Pick the method that matches your goal:

Method Best for Notes
Bare metal Production servers, max performance Installs directly on physical hardware.
Virtual machine (VirtualBox, KVM/QEMU, Proxmox, VMware) Learning, labs, isolation Run Linux inside your current OS. Snapshots make mistakes cheap.
Cloud instance (AWS EC2, Azure, GCP, OpenStack) Servers you don't own hardware for Launched from a prebuilt image in seconds; no ISO needed.
WSL2 (Windows Subsystem for Linux) Developers on Windows A real Linux kernel inside Windows; great for tooling, not for systemd-heavy server testing.
Live USB Trying a distro, rescue/repair Boots a full OS off the USB without touching the disk.

If you're just learning

Start with a VM (VirtualBox is free and cross-platform, or KVM/Proxmox if you're on Linux already). Snapshots let you break things and roll back instantly — the best way to learn.

Step 1 — Download and verify the ISO

Download the AlmaLinux 9 DVD ISO from an official mirror (https://almalinux.org/get-almalinux/). The same page publishes a CHECKSUM file and the project's GPG key.

Why verify? A corrupted download can fail mid-install; a maliciously modified image could backdoor every server you build. Verification catches both.

Verify the SHA-256 checksum

# Compute the checksum of what you actually downloaded
sha256sum AlmaLinux-9.4-x86_64-dvd.iso
ec7... (a long hex string)  AlmaLinux-9.4-x86_64-dvd.iso

Compare that string against the value in the official CHECKSUM file. Better, let the tool do the comparison for you:

# -c reads the CHECKSUM file and verifies any ISO it references
sha256sum -c CHECKSUM 2>/dev/null | grep OK
AlmaLinux-9.4-x86_64-dvd.iso: OK

Verify the GPG signature (proves authenticity, not just integrity)

A checksum only proves the file matches some published value. A GPG signature proves the CHECKSUM file itself came from AlmaLinux and wasn't swapped.

# Import the official AlmaLinux signing key (from the URL on their site)
sudo rpm --import https://repo.almalinux.org/almalinux/RPM-GPG-KEY-AlmaLinux-9

# Or with gpg directly, then verify the signed CHECKSUM file:
gpg --verify CHECKSUM
gpg: Good signature from "AlmaLinux OS <[email protected]>"

Warning

A Good signature line is what you want. If you see BAD signature or the key doesn't match the one published on the official site, do not use the image — stop and re-download from a trusted mirror.

Step 2 — Write a bootable USB

You'll flash the verified ISO onto a USB stick (this erases the stick).

On Linux — dd

# FIRST: find the correct device name for your USB stick
lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 465.8G  0 disk
└─sda1   8:1    0 465.8G  0 part /
sdb      8:16   1  28.7G  0 disk            <-- the USB stick
# Write the ISO to the WHOLE device (sdb), not a partition (sdb1).
# bs=4M speeds it up; status=progress shows a live counter; sync flushes at the end.
sudo dd if=AlmaLinux-9.4-x86_64-dvd.iso of=/dev/sdb bs=4M status=progress conv=fsync

Danger

dd is nicknamed "disk destroyer." It writes blindly to whatever of= points at. If you put your system disk (/dev/sda above) there, you will wipe your computer. Triple-check the device name with lsblk before pressing Enter.

On Windows or macOS

  • Rufus (Windows) — pick the ISO, pick the USB device, use "DD Image" mode if prompted, click Start.
  • balenaEtcher (Windows/macOS/Linux) — a friendly GUI: Flash from file → Select target → Flash. It validates the write automatically.

Step 3 — Conceptual install walkthrough (AlmaLinux 9 / Anaconda)

Boot the target machine from the USB (you may need to change boot order in the firmware/BIOS). AlmaLinux uses the Anaconda installer. Here's what each screen means.

Language and keyboard

Choose your install language and keyboard layout. This sets the system default locale, which you can change later.

Disk partitioning

This is the screen that matters most. You can let Anaconda do automatic partitioning, or choose Custom to lay it out yourself. A sensible server layout:

Mount point Size (example) Filesystem Purpose
/boot 1 GB xfs Kernel and bootloader files. Kept separate so the bootloader can always find it.
/boot/efi 600 MB vfat Required on UEFI systems (the EFI System Partition).
/ (root) 30–50 GB+ xfs The operating system itself.
swap 2–8 GB swap Overflow when RAM is full; supports hibernation.
/home remaining space xfs User data, kept separate so you can reinstall the OS without losing it.

ext4 vs xfs: Both are mature, journaling filesystems.

  • xfs is the AlmaLinux/RHEL default — excellent with large files and high parallelism, the standard choice for RHEL-family servers.
  • ext4 is the long-time Linux default elsewhere (Debian/Ubuntu) — rock-solid and can be shrunk, which xfs cannot.

LVM (Logical Volume Manager): Anaconda defaults to putting / and others inside LVM. LVM adds a flexible layer between partitions and filesystems so you can grow volumes, add disks, and take snapshots later without repartitioning. For servers, keep LVM enabled.

Separate /home and /var on servers

Putting /home (and often /var) on their own volumes means a runaway log file or full user partition can't fill up / and crash the whole system.

Software selection — minimal vs server-with-GUI

  • Minimal Install — no desktop, just the base system. The right choice for servers: smaller attack surface, less to patch, lower resource use. You administer it over SSH.
  • Server with GUI — adds a graphical desktop. Convenient for beginners or workstations, but usually unnecessary overhead on a server.

Choose Minimal Install for a server, then add only the packages you actually need.

Network, root password, and user

  • Enable the network interface and (optionally) set the hostname here.
  • Set a strong root password — or, better, leave root locked and create an admin user with sudo.
  • Create a regular user and tick "Make this user administrator" so it gets sudo rights.

Click Begin Installation, wait, then reboot and remove the USB.

Step 4 — Essential first-boot tasks

Never leave a fresh server in its default state. Do these immediately.

# 1. Fully update the system to pull in the latest security patches
sudo dnf upgrade --refresh -y
# Debian/Ubuntu equivalent: sudo apt update && sudo apt upgrade -y
# 2. Create a non-root sudo user (skip if you made one during install)
sudo adduser deepak
sudo passwd deepak
# On RHEL family, the 'wheel' group grants sudo:
sudo usermod -aG wheel deepak
# Debian/Ubuntu use the 'sudo' group instead: sudo usermod -aG sudo deepak

Stop logging in as root

Day-to-day work should use an unprivileged account and sudo for individual commands. It limits the blast radius of mistakes and gives you an audit trail of who ran what.

# 3. Set a meaningful hostname
sudo hostnamectl set-hostname web01.example.com
hostnamectl                      # confirm
# 4. Enable and start SSH so you can administer remotely
sudo systemctl enable --now sshd
sudo systemctl status sshd       # should show "active (running)"

# Open the firewall for SSH (firewalld is the AlmaLinux/RHEL default)
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
# Debian/Ubuntu with ufw: sudo ufw allow OpenSSH && sudo ufw enable

Harden SSH next

Once you've confirmed key-based login works, disable password and root SSH login in /etc/ssh/sshd_config (PermitRootLogin no, PasswordAuthentication no) and reload sshd. Set up SSH keys before you lock yourself out.

Verify your work

# Confirm the installed version matches what you intended
cat /etc/os-release

# Confirm the system is fully patched (should report nothing to do)
sudo dnf check-update; echo "exit code: $?"   # 0 = up to date, 100 = updates available

# Confirm your sudo user works without logging in as root
sudo -l

# Confirm SSH is running and reachable
systemctl is-active sshd
sudo firewall-cmd --list-services            # should include 'ssh'

# Review your disk layout and filesystems
lsblk -f

Summary

  • Choose a method to match the goal: VM/snapshots for learning, bare metal or cloud for production, WSL2 for Windows dev, live USB for rescue.
  • Always verify the ISO with sha256sum -c CHECKSUM (integrity) and gpg --verify CHECKSUM (authenticity) before trusting it.
  • Write the USB with dd (Linux — triple-check of= with lsblk) or Rufus/balenaEtcher (Windows/macOS).
  • A good server disk layout separates /boot, /, swap, and /home; use xfs (RHEL default) or ext4, and keep LVM for future flexibility.
  • Pick Minimal Install for servers — administer over SSH.
  • First-boot essentials: update, create a non-root sudo user, set the hostname, and enable SSH + open the firewall.
  • Next: learn where everything lives in the filesystem hierarchy.

Test yourself