Cost: $0. Tools: your Ubuntu VMA software-based emulation of a complete computer that runs its own operating system and applications, isolated from the host hardware. Read more →, the verified Ubuntu ISOA single file that holds an exact copy of an optical disc's contents, used to distribute operating system installers and boot virtual machines. Read more → from Phase 1.
Take a snapshotA saved, point-in-time state of a virtual machine or storage volume that you can roll back to if a change goes wrong. Read more → named before-phase-4 first. Roll back only if truly stuck, and log why.
The five breaks
Do them one at a time. Fix each without reinstalling. Use the six-step method (lesson 4.5) for every one.
- Bad fstabThe /etc/fstab file that tells Linux which filesystems to mount at boot, where to mount them, and with what options. Read more → line. Add a line with a fake UUIDUniversally Unique Identifier: a 128-bit value used to label things, like disks and partitions, so each one can be identified reliably no matter the order it is detected. Read more →, reboot, recover (lesson 4.4).
- Full disk.
fallocateuntildf -h /reads 100%, trysudo apt updateand record the error, then find and free the space. - Lost sudoA Linux command that runs a single command with administrator (root) privileges, after checking that your account is allowed to do so. Read more →.
sudo gpasswd -d $USER sudo, log out and back in, confirm sudo fails, recover via GRUBGRand Unified Bootloader: the bootloader most Linux distributions use to show a boot menu, load the kernel and initramfs, and pass kernel parameters. Read more → recovery mode. - Stopped network.
sudo systemctl stop NetworkManager(desktop) orsudo ip link set enp0s3 down(use your interface name). Diagnose withip -br link,ping -c 2 1.1.1.1,journalctl -u NetworkManager, then fix. - Broken GRUB default. Back up
/etc/default/grub, setGRUB_DEFAULT=9(an entry that does not exist) andGRUB_TIMEOUT=0, runsudo update-grub, and reboot. Note what happens: GRUB 2.14 quietly falls back to the first entry and Ubuntu boots normally, so a wrong default is a silent problem, not a dead machine. Practice getting the menu anyway with Esc (UEFI) or Shift (BIOS), then restore the backup and runupdate-grubagain. Write the behavior you saw in your log.
Bonus (hard): with the snapshot taken, run sudo rm /boot/efi/EFI/ubuntu/grubx64.efi /boot/efi/EFI/ubuntu/shimx64.efi, reboot, and repair from the ISO with chroot (lesson 4.3). What you see varies by firmware: the fallback loader in /EFI/BOOT/ may still boot, or you may land in the firmware menu. Either way, finish the chroot repair and confirm efibootmgr lists Ubuntu again.
Worked troubleshooting: you deleted the big file and the disk is still full
Use this when break 2 does not behave the way you expect.
Symptom. You removed the big file, but df -h still shows the disk nearly full.
Hypothesis. A running process still has the deleted file open, so Linux cannot free the space yet.
Test. On the course VM, a small test filesystem showed this after rm:
df -h /mnt/small
lsof +L1
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 15M 13M 1.2M 92% /mnt/small
python3 2302 student 3r REG 7,0 12582912 0 13 /mnt/small/log.bin (deleted)
The file is gone from ls but still listed as (deleted) and held by PID 2302.
Fix. Stop or restart the process holding it. After the process stopped, df showed 152K used and 2%.
Why it worked. A file’s space is released when the last name and the last open handle are gone. rm removed the name; stopping the process closed the handle. Log this one in six-step format too, because it is a classic real-world surprise.
Proof (~/course-notes/phase-4-break-fix/)
break-fix-log.md: one section per break, in six-step format, with exact errors and commands.recovery-cheatsheet.md: your own one-page list of recovery commands from this phase.- Commit:
git commit -m "phase 4: break-fix log".
Done when
All five breaks are fixed without a reinstall or snapshot rollback, and each one has a full log entry.