By the end of these two weeks, every student has a working computer they assembled from components and an operating system they installed themselves. That machine is theirs. All Phase 5 and Phase 6 work happens on it.
This is the emotional midpoint of the course. The "wait, I can do that?" moment you planned from the beginning. Everything in Phases 1–3 was preparation — the filesystem knowledge, the terminal confidence, the UEFI familiarity from session 56 — all of it lands here as practical capability rather than abstract knowledge.
Two things to prepare before Phase 4 starts. First: hardware. Each student needs a compatible set of components. The bare minimum that can run Kubuntu and Ollama in Phase 6: a CPU with 4 cores, 8GB RAM minimum (16GB preferred for Ollama), 256GB NVMe SSD, a case, a motherboard with the right socket, and a PSU. Integrated graphics is sufficient. Budget: €200–350 per build depending on sourcing. Second: the Kubuntu LTS ISO and sha256sum file downloaded before session 59, and USB drives for each student.
Pacing note: the assembly session (57) and the installation session (60) almost always run long. If your 1-hour format is firm, plan to split session 57 across two days, and accept that session 60 may need the full period without a formal close. The first boot is the close.
Before touching hardware, students need a mental model of what each component does, not just what it is called. This session bridges the four-layer model from session 1 — hardware, firmware, OS, applications — with the physical reality of the components they will handle next week. By the end, every component should have a clear function in the student's mind.
Bring in physical components if possible — even a single stick of RAM, a CPU (with the socket guard on if Intel), an NVMe SSD, and a motherboard are enough to make the session concrete. If physical components are not available, high-quality photos on screen work. A disassembled PC with the side panel removed showing all components in context is ideal.
Hold up (or display) the disassembled machine. Ask: "Can anyone name every component they see?" Take all answers without correcting — write them on the board. When naming is exhausted, ask: "Can anyone explain what each one does?" The gap between the two lists is what this session fills. Most students can name components from gaming or tech interest. Almost none can explain the data flow between them.
Cover each component with a physical example or close-up photo. For each one, explain: what it does, where data goes in and out, and what happens when it fails. The failure mode is often the most memorable part.
CPU (Central Processing Unit). Executes instructions — billions per second. Modern CPUs have multiple cores, each capable of running its own thread simultaneously. The CPU fetches instructions from RAM, decodes them, executes them, and writes results back to RAM. It does not store programs — storage and RAM do that. The CPU is the fastest component but also the most dependent on everything else being ready. Failure: machine will not power on, or powers on without POST completing.
Motherboard. The backbone that every other component connects to. The CPU socket determines which CPUs are compatible. The RAM slots determine the memory type. PCIe slots host expansion cards. The chipset manages communication between components. The UEFI firmware is stored on a chip on the motherboard. Failure: nothing works — the motherboard is the integration point for all other components.
RAM (Random Access Memory). Fast, temporary working memory. Programs and their data are loaded from disk into RAM before the CPU can process them. When power is removed, RAM is wiped — this is why unsaved work is lost in a crash. More RAM allows more programs to run simultaneously without the OS having to swap to disk. Current standard: DDR5 on new builds, DDR4 on older platforms. Failure: random crashes, corrupted data, failure to boot with beep codes.
Storage (NVMe SSD / SATA SSD / HDD). Permanent storage — survives power loss. NVMe SSDs connect via PCIe M.2 slot, achieving 3–7 GB/s sequential read speeds. SATA SSDs connect via SATA cable, limited to ~550 MB/s. HDDs use spinning magnetic platters — slowest but cheapest per gigabyte. For our build: NVMe SSD for the OS. Failure: machine boots to "no bootable device," or data corruption/loss.
PSU (Power Supply Unit). Converts mains AC power to the DC voltages components require: 12V (CPU, GPU, fans), 5V (USB, some chipset components), 3.3V (RAM, some chipset). The PSU wattage must exceed total system draw. An undersized PSU causes random shutdowns under load. A failing PSU causes erratic behavior and can damage components. The PSU is the component most people buy cheap and most often regret.
CPU Cooler. CPUs generate significant heat — a modern CPU under load can exceed 100°C without cooling. The cooler draws heat from the CPU die through thermal paste into a heatsink, which a fan pushes air through. Thermal paste fills microscopic gaps between the CPU's heat spreader and the cooler's contact surface — without it, the CPU overheats in seconds. Liquid coolers replace the fan-and-heatsink with a pump, tubes, and a radiator mounted in the case. For our build: a standard air cooler is sufficient. Failure: CPU throttles to prevent damage, then shuts down if temperature exceeds threshold.
Component identification sheet. For each component, fill in the table:
Components: CPU, motherboard, RAM, NVMe SSD, PSU, CPU cooler, case fan.
Discussion question: if you had to replace one component to make a slow 5-year-old computer faster for general daily use, which would you choose and why? (RAM and SSD upgrades are usually the highest-value changes — explore why.)
The failure mode column in the exercise is the most instructive. Students who learn "bad RAM causes random crashes and data corruption — very hard to diagnose" will remember it because it is counterintuitive. Most people assume a RAM problem would cause obvious RAM-related errors. It does not — it causes random, unpredictable failures that look like software problems. Systems administrators spend hours diagnosing mysterious crashes before running memtest and finding faulty RAM. This is real diagnostic knowledge.
The discussion question about which component to upgrade will reveal students with gaming PC knowledge. Let them lead — they are usually correct that RAM (if under 16GB) and NVMe SSD (if still on an HDD) are the best value upgrades. Ask them to explain the data flow reason: an SSD makes storage access 10–50× faster, so the bottleneck shifts from disk to CPU/RAM. That reasoning is more valuable than the conclusion.
Scenario: a student ordered a CPU (Intel Core i5-13600K), a motherboard (with AM5 socket), and DDR5 RAM. Everything arrived. Nothing works. Why? The AM5 socket is AMD's — the i5 uses Intel's LGA1700. The motherboard and CPU are physically incompatible — the CPU will not even seat. This is a real, common, expensive mistake that compatibility checking prevents entirely. Compatibility is the most important hardware skill.
Compatibility works as a chain. Each decision constrains the next:
Socket types to know. Intel current: LGA1700 (12th/13th/14th gen), LGA1851 (Core Ultra). AMD current: AM5 (Ryzen 7000/8000/9000 series). These sockets are not interchangeable in any way — different pin counts, different physical layouts, different CPU shapes.
RAM compatibility. RAM type (DDR4 vs DDR5) is determined by the motherboard. DDR4 and DDR5 are not cross-compatible — the notch position on the module is different, so you cannot physically install the wrong type. RAM speed (3200 MHz, 5600 MHz, etc.) must be supported by the motherboard's XMP/EXPO profile. Installing faster RAM than the board supports does not damage anything — the RAM runs at the board's maximum supported speed instead.
PSU sizing. Find the TDP of the CPU (e.g., 65W). Add the TDP of the GPU if discrete (e.g., 150W). Add approximately 50W for the rest of the system. Multiply by 1.2 for headroom. For our integrated-GPU build: CPU TDP (65W) + system (50W) × 1.2 = ~138W. A 550W PSU is generous — but PSUs run more efficiently at 50–80% load, so not wasting wattage matters less than having headroom.
PCPartPicker. pcpartpicker.com checks compatibility automatically. It flags socket mismatches, RAM type mismatches, power budget overruns, and case clearance issues. It is not infallible — always verify against manufacturer specifications for critical choices — but it catches most common mistakes.
PCPartPicker challenge (internet required). Build a theoretical parts list for a €400 budget computer that will run Kubuntu and the Ollama AI tools in Phase 6.
Requirements: must support Kubuntu, 16GB RAM minimum, NVMe SSD (256GB minimum), no discrete GPU, zero compatibility warnings on PCPartPicker.
For each component chosen, write: name, price, why chosen, and one compatibility reason it works with the previous choice.
After building: what is the total TDP? Is the PSU correctly sized? What would you change if the budget was €300? What if it was €600?
Compare results with a partner — which build has better value? Better upgrade path? Are there any differences in RAM speed, NVMe interface, or PSU efficiency rating?
The PCPartPicker exercise is consistently one of the most engaging in Phase 4 for students with any interest in gaming or tech. Budget constraints make it feel like a puzzle. Students who come in with gaming PC knowledge will be immediately engaged — let them teach others. Students without that background often find the constraint-solving aspect satisfying once they start. The €400 budget is tight enough to require real trade-offs but realistic enough to be achievable.
The boot process connects the hardware of week 14 to the OS installation of week 15. Students who understand this sequence will not be confused when GRUB appears in session 60, when the installer asks about partitions, or when the system says "no bootable device" after a misconfigured installation. This session is the theoretical foundation for everything that happens in week 15.
Ask a student to draw the four-layer diagram from session 1 from memory. Once it is on the board: "The boot process is the moment these four layers activate in sequence. Each layer hands control to the next. Today we trace that handoff step by step." This connects back to the very first session of the course — a satisfying callback at the midpoint.
Walk through the boot sequence with each step on the whiteboard, drawn as a flowchart. Add each step as you explain it.
Key distinctions to emphasise. UEFI vs legacy BIOS: UEFI is the modern standard. It requires GPT partition tables (not MBR), supports drives over 2TB, supports secure boot, and has a graphical interface. Legacy BIOS is text-only, limited to MBR, and cannot address drives over 2TB. We use UEFI for our installation. Secure boot: a UEFI feature that verifies the bootloader is cryptographically signed before running it. Prevents tampered boot software but can cause issues with some Linux installations if not configured correctly.
The EFI System Partition (ESP). A small FAT32 partition that the UEFI firmware can read. It contains the bootloaders for all installed operating systems. GRUB lives here. The ESP is the bridge between the firmware (UEFI) and the software (GRUB → kernel). Without a correctly formatted ESP, the UEFI cannot find anything to boot.
Boot sequence flowchart. Students draw the complete boot sequence independently — without looking at the board. Each step as a box, each handoff as an arrow. For each box, write: what software is involved, where it lives physically (on a chip, in a FAT32 partition, in RAM, on the root filesystem), and what it hands control to next.
Failure analysis — answer these without looking at notes:
The failure analysis questions are the session's most valuable exercise. Students who can trace a failure backward through the boot chain understand the sequence as a dependency graph, not a list. Question 1 — deleted GRUB — is particularly instructive: the fix (boot from a live USB, chroot into the system, reinstall GRUB) is a real recovery procedure that many Linux users need at some point. You do not need to explain the fix in detail now — just tell them the fix exists and that it requires booting from external media. That preview makes the live USB in session 59 feel more meaningful.
Students enter the UEFI interface on their existing machines and learn to navigate it. When they enter UEFI on their newly assembled machine in session 58, it will not be their first time in that interface. Familiarity removes the anxiety that causes mistakes.
Ask: how many students have entered UEFI before? (Usually very few.) Ask those who have: what were you trying to do? The answer is usually "fix a boot problem" or "enable something for a game." This session is about understanding UEFI as a tool, not as an emergency measure.
How to enter UEFI: press the manufacturer-specific key during the power-on splash screen. Common keys: Del (ASUS, Gigabyte), F2 (MSI, Lenovo, Dell), F12 (boot menu on many boards). On Kubuntu: System Settings → Startup and Shutdown → click "Restart into UEFI Setup." This is the reliable method — no timing required.
UEFI navigation: arrow keys move between fields. Enter selects. F-keys perform actions (F10 = save and exit on most boards). Every change must be saved explicitly — exiting without saving discards all changes. There is usually a "Discard and Exit" and a "Save and Exit" option. Know the difference before touching anything.
The five categories that matter for our installation:
During this exercise, you are reading and observing only. Do NOT change any setting and do NOT save. If you accidentally change something, press Escape repeatedly until you reach the exit menu, then select "Discard and Exit." Never press F10 or "Save and Exit" during this exercise.
Review the three settings for next week: (1) boot order — USB first, (2) AHCI mode for storage, (3) secure boot — may need to be disabled. Write these in the handout. Preview session 57: "Next session you build the machine. Read the handout tonight. Know the assembly sequence before you touch a component."
One student will accidentally save a change during this session. It always happens. Handle it calmly: restart into UEFI again, identify what changed (compare against other students' notes), and revert it manually. This is not a crisis — it is a learning moment about why "discard and exit" exists and why UEFI changes are reversible. The student who accidentally saves something will be extremely careful for the rest of the course.
If the UEFI on any student machine is set to RAID mode rather than AHCI for storage, that explains why some machines have had unusual disk behavior in earlier phases. Mention this and explain: RAID mode in a single-drive system adds a compatibility layer that can cause issues with Linux drivers. AHCI is correct for our setup.
The physical build. Students assemble their computers following a strict sequence, checking each step before proceeding to the next. The most common build mistakes are: RAM not fully seated, CPU power connector missed, front panel connectors miswired. Each of these is prevented by following the sequence and verifying before proceeding.
Time note: this session reliably runs long for first-time builders. If your format allows, give this session 90 minutes. If constrained to 60 minutes, plan for the assembly to continue at the start of session 58, with the first power-on happening mid-session 58.
Anti-static: touch the metal case or use an anti-static strap before handling any component. Static discharge can destroy a CPU or RAM module instantly and invisibly.
No force: if a connector, screw, or component does not go in easily, stop. It is probably oriented incorrectly. Force damages connectors permanently.
CPU handling: the CPU installation is the most delicate step. The socket pins or pads are extremely fragile. Hold the CPU by its edges only, never touch the contact surface.
Ask before proceeding: if you are uncertain about any step, stop and ask. Hardware damage is usually permanent and expensive. Asking costs nothing.
Walk through each step once as a demonstration on a spare board or with clear photos before students perform it. Then students execute while you circulate and verify each step before they proceed to the next.
Follow this sequence exactly. Do not skip ahead. Check each step before proceeding.
Before any power is connected, every student must verify this checklist:
Do not proceed to session 58 until every item is verified by you personally for each student.
The three most common mistakes in first builds, in order of frequency: (1) CPU power connector not connected — machine powers on but immediately shuts down, or does not POST. Easy to miss because it is in a corner of the board and the 24-pin is more prominent. (2) RAM not fully seated — machine powers on, no display output, may beep. The click is definitive — if you did not hear it, it is not seated. (3) Front panel power button connector on wrong pins — machine will not power on when the button is pressed. Fix: short the power button pins directly with a screwdriver to test, then correct the connector position.
If a student has installed an Intel CPU and the socket has bent pins after the lever is lowered — stop. Do not continue. This is rare but serious. The socket can sometimes be repaired with a mechanical pencil lead or a similar tool, but it requires patience. If the damage is severe, the motherboard may need replacement. Document carefully and contact your hardware supplier.
No warm-up. No lecture. Connect the peripherals, press the power button, and see what happens. This is the payoff for four sessions of theory. The goal: every student's machine passes POST, shows the UEFI interface, correctly identifies the CPU and RAM, and has the boot settings configured for OS installation.
Connect in this order: monitor cable to the motherboard's video output (integrated graphics — there is no GPU). USB keyboard. Power cable to PSU. Flip the PSU rocker switch to on.
Press the power button. Observe everything.
If nothing happens (no fans, no LEDs): PSU switch may be off, or power button front panel connector is on wrong pins. Short the power button header pins directly with a screwdriver to test.
If fans spin but no display: RAM not seated, CPU power not connected, or no video cable to the correct port. Check each systematically.
If POST succeeds: UEFI splash screen or logo appears. Press the appropriate key to enter UEFI setup.
In UEFI, verify:
Save and exit (F10 or the save option). Machine reboots. It will display "no bootable device" or similar — this is correct. The machine works. There is no OS yet.
Before ending the session, confirm with each student verbally:
Any student who cannot confirm all five needs to resolve the issue before session 59. A machine that cannot detect its SSD in UEFI will not install an OS correctly.
Preview session 59: "Tomorrow you create the bootable USB and learn why partitioning matters. The day after, you install the OS. By the end of this week, you log into a machine you built from scratch."
"No bootable device" is the most important message to reframe correctly. Students who do not understand this message will think their build failed. Emphasise proactively: this message means the machine is working perfectly. It searched for an operating system and found none, because we have not installed one yet. This message is confirmation that the hardware works. Installation is the next session.
If a student's machine will not POST after checking the common causes (RAM, CPU power), systematically work through the POST sequence: does the PSU light up? Do any fans spin briefly then stop (often a power delivery issue)? Do any diagnostic LEDs illuminate on the motherboard? Most modern motherboards have POST diagnostic LEDs that indicate which component is failing — CPU, DRAM, BOOT, VGA. These LEDs are more informative than beep codes.
Ask: when the Kubuntu installer runs, what will it do to the NVMe SSD? Most students will say "erase it" or "put the OS on it." The complete answer is: it will create a partition table, create partitions, format each partition with a filesystem, install files, install GRUB to the EFI partition, and configure the bootloader. This session explains every step of that process so session 60 contains no surprises.
Partition tables. A partition table describes how a storage device is divided into regions. GPT (GUID Partition Table) is the modern standard — supports unlimited partitions (practical limit around 128), drives over 2TB, and is required for UEFI boot. MBR (Master Boot Record) is legacy — maximum 4 primary partitions, 2TB drive limit, required for some older systems. For our installation: GPT, because we are using UEFI.
What partitions we will create. Two partitions are required for a functional Kubuntu installation:
1. EFI System Partition (ESP) — 512MB, FAT32 format, mounted at /boot/efi. This is where GRUB and the UEFI boot entry live. The UEFI firmware reads this partition directly — it must be FAT32. Without it, the system cannot boot.
2. Root partition (/) — remainder of the disk, ext4 format, mounted at /. Everything else lives here: the OS files, installed applications, your home directory, your configurations. One partition for everything simplifies administration for our purposes.
Optional but common: a swap partition (or swap file) provides virtual memory — used when RAM is full. On systems with 16GB RAM, swap is rarely needed but having a 4–8GB swap prevents out-of-memory crashes on heavy workloads. For our installation, the Kubuntu installer creates a swap file automatically on the root partition — no separate swap partition needed.
Creating the bootable USB. The dd command copies the ISO to the USB drive byte-for-byte:
sudo dd if=kubuntu-lts.iso of=/dev/sdX bs=4M status=progress
if= is the input file (the ISO). of= is the output file (the USB device — must be the device, not a partition: /dev/sdb not /dev/sdb1). bs=4M sets the block size for speed. status=progress shows progress. The critical step: verify the device name with lsblk before running dd. Writing to the wrong device destroys its contents permanently and silently.
Run lsblk before and after inserting the USB drive. The device that appears after insertion is the USB drive. Confirm the device size matches the USB capacity. Only then proceed with dd. Writing to the wrong device — especially the NVMe drive — cannot be undone.
lsblk. Identify the main NVMe drive and its partitions. What filesystem is on the EFI partition? What is its size?sudo fdisk -l /dev/nvme0n1 (or your NVMe device path). Read the output — what partition table type is used? What partitions exist?sha256sum kubuntu-*.isolsblk again. Which new device appeared? Write the full device path (e.g., /dev/sdb).lsblk — the USB now shows multiple partitions. What are they?Verify every student has a completed bootable USB. Preview session 60: "Tomorrow you partition the disk, install the OS, and boot into a machine you built yourself. Decide your username and hostname tonight — you cannot change them easily afterward."
The dd verification step is the safety critical moment of this session. Every student must run lsblk, identify the USB device, and have their dd command verified before running it. Do not allow anyone to run dd before you have seen their command and confirmed the of= path. A student who runs dd against their NVMe drive loses their Phase 1–3 work. This is recoverable in theory (the data may still be on disk) but not practically within a course session.
The sha256sum verification (task 3) is a real security practice. If a student's ISO checksum does not match, the download is corrupt or was tampered with. In practice, this almost always means a corrupt download rather than tampering — but the check is the same either way. A student who installs from a corrupt ISO will encounter bizarre installation failures that are very hard to diagnose. The checksum check prevents this entirely.
No warm-up. No lecture. Insert the USB, power on, boot from it, and follow the installer. Walk students through each screen as they encounter it — explain decisions as they arise, not in advance. The payoff for everything in Phase 4.
Insert the USB drive. Power on. If the machine does not boot from USB automatically, enter the UEFI boot menu (usually F12) and select the USB device. The Kubuntu live environment loads. From the desktop, launch the installer.
Walk through each installer screen together. Explain each decision as you reach it.
Language: select your preferred language.
Keyboard layout: select and test by typing special characters.
Installation type: Normal installation. Check "Install third-party software" for broader hardware support (especially Wi-Fi drivers).
Disk setup — this is the critical screen. Choose "Manual partitioning."
Location / timezone: select your timezone.
User account:
Review and install: read the summary. Verify the partition layout. Click Install Now.
Wait approximately 10–20 minutes. The installer copies files, installs GRUB, and configures the system.
Installation complete: click "Restart Now." When prompted, remove the USB drive. The machine boots from the NVMe drive. GRUB appears (briefly or as a menu). The login screen appears.
Log in with your credentials. The desktop appears.
Open a terminal. Run each command and write the output:
uname -a — what kernel version is installed? What architecture?df -h — what partitions are mounted? What sizes match the partitions you created?free -h — how much RAM does the system report? Does it match what UEFI showed?lsblk — what is the disk layout? Can you identify the EFI and root partitions?cat /etc/os-release — what OS and version is installed?Do the numbers from df -h, free -h, and lsblk match what you saw in UEFI during session 58? They should.
You assembled a computer from components. You configured its firmware. You created a bootable installation medium. You partitioned the disk, chose the filesystem, installed the OS, and logged in for the first time. The machine running in front of you is yours — in every sense of the word. All remaining work in this course happens on this machine.
Do not rush the moment when the login screen appears. Let students sit with it for 30 seconds. Some will be surprised it worked. Some will be proud. Some will be matter-of-fact about it. All of these responses are valid. Then run the verification commands and connect the numbers back to what they saw in UEFI — the RAM amount matches, the disk size matches. The machine is working exactly as designed, and they designed it.
If any student's installation fails part-way through — which occasionally happens due to USB write errors, disk errors, or corrupt ISO — do not panic. Boot back from the USB, reformat the NVMe partition table (the installer can do this), and reinstall. A failed install followed by a successful reinstall is a better learning experience than a first-attempt success, because the student has now debugged a real OS installation failure. Name it as such.
After session 60: each student should transfer their dotfiles from Phase 3 to the new machine. Either via USB drive copy or by recreating them from their ~/dotfiles/ backup. This is the portability test from session 48 in real life — exactly the scenario that exercise was preparing for. Reference it explicitly.
Phase 4 of 6 · Linux seminar · Kubuntu LTS · Ages 15–18
Phase 5 — Solving real problems — begins next session