DISK PARTITIONING & Arch Installation

SSH LOGIN SLIDE

Students connect to the lab server using SSH.
Command (red, shown on slide): ssh aghos@oos.wimic.agh.edu.pl

Remind students:
- They need a terminal (Linux/macOS: built-in; Windows: PuTTY or Windows Terminal)
- The username is aghos — same for everyone
- No password is set for this user

AGHOS BOOT MENU

After SSH login, students see a simple numbered menu.
Pressing 1 starts a QEMU virtual machine session booted from the AGHOS ISO.
The boot output is forwarded over serial → terminal, so they see it in their SSH window.
This is where the hands-on work happens — inside the VM.

LANGUAGE SELECTION

After the AGHOS GRUB menu loads, students choose a keyboard/language layout.
Most students should pick English (US).
This is a standard live-system locale selection — nothing unusual here.

LOGIN AS AGHOS

Inside the booted VM, students log in as user aghos with no password.
Then they escalate to root with: sudo su

Important note: first boot may take a while — the system image is pulled over the network. This is normal.

TECHNICAL BACKGROUND — HOW THE LAB INFRASTRUCTURE WORKS

This is an optional deep-dive slide for curious students. Not required to follow the lab.

Key points to mention:
- Each student gets their own isolated QEMU session — changes do not affect others
- AGHOS GRUB auto-detects headless mode and routes output to serial → terminal
- To end the session: shutdown -h now (not exit — exit only logs out of the shell)
- Option 2 at login = plain host shell (no VM)
- disk.img (100 GB) = the virtual hard drive visible as /dev/vda inside QEMU
- If disk.img is too large to download, students can create a smaller image and copy data to it

CREATING A VIRTUAL DISK FILE — fallocate vs dd

Two methods shown side by side:
  Method A: fallocate -l 30G disk.img  — fast, allocates space without writing zeros (recommended)
  Method B: dd if=/dev/zero of=disk.img bs=1M count=2048  — slower, fills with zeros

Key flags to explain:
  fallocate -l = length (supports K, M, G, T)
  dd: if=input source, of=output file, bs=block size, count=number of blocks

Why 2 GB? Large enough to hold a real OS. Students can use 500M for quick practice.
Always check free space first: df -h

DRIVES OVERVIEW — The lab machine has 3 drives

Drive layout:
  /dev/nvme0n1 — 1 TB, very fast NVMe SSD
  /dev/nvme1n1 — 1 TB, very fast NVMe SSD
  /dev/sda     — 10 TB, slow but spacious SATA HDD

This slide sets up the scenario for the upcoming multi-drive mount exercise.

PARTITION PLANNING — Drive 1 (NVMe SSD)

  p1 → /boot   (EFI system partition, FAT32)
  p2 → /        (root filesystem, ext4)
  p3 → /var     (variable data — logs, databases)
  p4 → /home    (user home directories)

Discuss WHY we separate /var and /home:
- /var can grow quickly (logs, package cache) — isolating it prevents it from filling root
- /home on its own partition = user data survives OS reinstall

Drive 2: dedicated to fast game storage — games benefit from fast NVMe I/O.
Drive 3: slow but spacious SATA — media files (videos, photos) don't need fast random I/O.

PARTITION ASSIGNMENT SUMMARY & 3D DRIVE VIEW

Each bar labelled with its intended mount point.
This is the planning phase — no commands yet, just the target layout.

3D view: drives rotated 90° for clearer perspective. Labels: Drive 1 (left), Drive 2 (centre), Drive 3 (right).

MOUNTING PLAN — Assigning partitions to directories

Same live system tree, now annotated with the partition assignment plan.
Key point: "It's just a plan for now — no mounts have happened yet."

MOUNT COMMAND ANATOMY

Breakdown: mount [device] [mountpoint]
  command:    mount
  device:     /dev/nvme0n1p2
  mountpoint: /mnt

Simple, but important. Every subsequent mount follows the same pattern.

STEP-BY-STEP MOUNTING

Step 1: Mount root first — /mnt is the anchor point.
Step 2: Create dirs INSIDE the mounted root. If you create them before mounting, they will be inside the live system, not the new root.
Step 3: Mount boot (EFI), var, home from Drive 1.
Step 4: Create games/media dirs inside the now-mounted /home, then mount Drive 2 and Drive 3.

Common mistake: forgetting to create the target directory before mounting.
Also: note the different devices — nvme1n1p1 (fast NVMe) vs sda1 (spacious SATA).

LAB 4.1 — Steps 1–3: disk file, partitions, filesystems

Step 1: fallocate -l 4G arch.img  (creates a 4 GB raw image file)
Step 2: losetup -P --find --show arch.img  (attaches as /dev/loop0, -P scans for partition nodes)
        parted creates GPT + EFI partition (512M, FAT32) + root partition (rest, ext4)
Step 3: mkfs.vfat -F 32 /dev/loop0p1  (EFI must be FAT32!)
        mkfs.ext4 /dev/loop0p2         (root filesystem)
        lsblk -f /dev/loop0            (verify)

Common mistake: students try to format /dev/loop0 directly instead of /dev/loop0p1 or p2.

LAB 4.2 — Step 4: Mounting partitions

CRITICAL ORDER: mount root FIRST, then create /mnt/boot, then mount EFI inside it.
  sudo mount /dev/loop0p2 /mnt            ← root first
  sudo mkdir -p /mnt/boot                 ← create dir inside mounted root
  sudo mount /dev/loop0p1 /mnt/boot       ← EFI inside

Verify with:  findmnt /mnt  and  df -h /mnt /mnt/boot

Warning: if you create /mnt/boot before mounting loop0p2, it will be inside the live system, not the new root.

LAB 4.2b — Mounting a partition inside a user home directory and configuring /etc/fstab

Key teaching points:
- The mountpoint directory MUST exist before mounting — always create it with mkdir -p first
- Always test-mount manually before editing fstab, to verify the partition and filesystem are healthy
- Use UUID (not /dev/sdXN) in fstab — device names can change between reboots if drives are reordered
- The nofail option is critical for extra drives in /home — without it, a missing drive will drop the system into emergency mode at boot
- Always run: sudo mount -a   after editing fstab to catch typos BEFORE the next reboot

fstab field explanation:
  1. device    — UUID=... (from blkid) or /dev/sdXN
  2. mountpoint — absolute path, must exist
  3. fstype    — ext4, vfat, btrfs, ntfs-3g, etc.
  4. options   — comma-separated flags (defaults,nofail,noatime...)
  5. dump      — always 0 (legacy, ignored)
  6. pass      — 0=skip fsck, 1=check root first, 2=check after root

LAB 4.3 — Step 5: pacstrap

pacstrap downloads and installs Arch base packages directly into /mnt (the new root):
  sudo pacstrap -K /mnt base linux linux-firmware
  -K = initialise a fresh pacman keyring in /mnt

Recommended extras: vim nano grub efibootmgr networkmanager

This step requires internet. If it fails:
  - Check: ping archlinux.org
  - Update mirrors: reflector --save /etc/pacman.d/mirrorlist

LAB 4.4 — Steps 6–7: genfstab and arch-chroot

genfstab -U /mnt >> /mnt/etc/fstab
  Generates the filesystem table using UUIDs. ALWAYS verify the output with: cat /mnt/etc/fstab

arch-chroot /mnt
  Smarter than plain chroot — auto-binds /proc, /sys, /dev, /run into the new root.
  After this you are INSIDE the new system!

Inside chroot: set timezone, hostname, root password, enable NetworkManager.
These are the minimum steps for a bootable system.

LAB 4.5 — Step 8: GRUB bootloader

grub-install flags:
  --target=x86_64-efi       EFI mode (use i386-pc for legacy BIOS)
  --efi-directory=/boot     where the EFI partition is mounted
  --bootloader-id=ARCH      label shown in UEFI firmware menu
  --removable               writes to /boot/EFI/BOOT/BOOTX64.EFI (fallback path)

IMPORTANT: --removable is ESSENTIAL for loop device installs.
Without it, GRUB registers itself with the HOST machine's UEFI firmware.

Then: grub-mkconfig -o /boot/grub/grub.cfg  (generates the menu)

LAB 4.6 — Finish installation and test with QEMU

Inside chroot: set locale and LANG, then exit.

Back on host — unmount in REVERSE ORDER (innermost first!):
  umount /mnt/boot   ← boot first
  umount /mnt        ← root last
  losetup -d /dev/loop0

Test with QEMU (optional) or verify by re-mounting and checking /mnt/boot contents.

SUMMARY — Complete command reference (3 pages in PPTX)

Page 1: loop device, partitioning, filesystem, mounting commands — cheat sheet for the lab.
Page 2: minimal pacstrap package set (base linux linux-firmware grub efibootmgr net-tools dhclient nano mc)
Page 3: extended full KDE desktop install — shown as a real-world example. Students do NOT need to run all of this for the lab.

REFERENCE — Common errors and fixes

Six error cards, each with cause and fix:
  1. losetup: /dev/loop0 is busy → umount first, then losetup -d
  2. mount: /dev/loop0p1 does not exist → use losetup -P to scan partition nodes
  3. mkfs: disk.img contains a filesystem → format the partition (p1/p2), not the raw image
  4. grub-install: EFI variables not supported → add --removable flag
  5. pacstrap: failed to retrieve files → check internet, update mirrors with reflector
  6. umount: target is busy → kill blocking processes with fuser -km /mnt or lsof +D /mnt