aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDanilo M. <danix@danix.xyz>2026-09-22 11:24:19 +0200
committerDanilo M. <danix@danix.xyz>2026-09-22 11:24:19 +0200
commitbc551a6c677be28c34ed19d6c1f5e8bf600a1610 (patch)
tree0fe89b03f21f715daadb575b90bc7cd96fcb73bf
parente2a9bfbc4775b48665dab40d60bb654eeeff5762 (diff)
downloadsbo-dockerbuild-bc551a6c677be28c34ed19d6c1f5e8bf600a1610.tar.gz
sbo-dockerbuild-bc551a6c677be28c34ed19d6c1f5e8bf600a1610.zip
image-builder: document the LILO re-run rule in fstab.example
The docker host boots BIOS/legacy with LILO in the MBR; GRUB is installed but only as EFI binaries the firmware never loads, so it is inert rather than competing. Worth writing down, because "two bootloaders installed" reads as ambiguous until you check which one the firmware actually uses. The part that bites is that LILO maps the kernel by physical block, so `lilo -v` has to be re-run by hand after a kernel or initrd change. Skip it and the machine looks fine until it reboots, which on a headless VM means recovering from the console. Noted next to the mount entries, and noted that editing those entries specifically does not need it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
-rw-r--r--image-builder/fstab.example23
1 files changed, 23 insertions, 0 deletions
diff --git a/image-builder/fstab.example b/image-builder/fstab.example
index 79c9473..b0ca1d9 100644
--- a/image-builder/fstab.example
+++ b/image-builder/fstab.example
@@ -43,3 +43,26 @@ UUID=0e5d008d-0ee0-41bc-9222-aedba1e088d0 /var/lib/docker ext4 defaults 0 2
# --format '{{.State.Pid}}')/mountinfo
# and check the device is the system disk, not the docker one.
/opt/registry-data /opt/sbo-testbuild/registry none bind 0 0
+
+# ---------------------------------------------------------------------------
+# Booting: LILO, and it needs re-running by hand
+# ---------------------------------------------------------------------------
+# This host boots BIOS/legacy with LILO in the MBR of /dev/sda. GRUB is also
+# installed, but only as EFI binaries under /boot/efi, and the firmware never
+# boots in EFI mode, so they are inert. There is no ambiguity about which
+# bootloader runs; there is just an unused one lying around.
+#
+# LILO maps the kernel by physical block address, so the map goes stale
+# whenever the blocks move. Run `lilo -v` after:
+#
+# * installing or replacing a kernel or initrd (the usual case)
+# * editing /etc/lilo.conf
+# * moving or defragmenting /boot
+#
+# Forgetting leaves an unbootable machine that looks fine until it reboots,
+# which on a headless VM means a console session to recover. `lilo -t -v`
+# tests without writing, and re-running `lilo -v` when nothing changed is
+# harmless, so when in doubt, run it.
+#
+# Editing the entries above does NOT need it: mounts are userspace, applied
+# long after the kernel loads, and the root device is unchanged.