diff options
| author | Danilo M. <danix@danix.xyz> | 2026-09-22 11:24:19 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-09-22 11:24:19 +0200 |
| commit | bc551a6c677be28c34ed19d6c1f5e8bf600a1610 (patch) | |
| tree | 0fe89b03f21f715daadb575b90bc7cd96fcb73bf /image-builder | |
| parent | e2a9bfbc4775b48665dab40d60bb654eeeff5762 (diff) | |
| download | sbo-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>
Diffstat (limited to 'image-builder')
| -rw-r--r-- | image-builder/fstab.example | 23 |
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. |