Fix issue with the live CD booting onto a pre-existing partition for good, use cd instead of root on the live cd grub

This commit is contained in:
markmental 2026-09-10 22:48:53 -04:00
commit a43e95b17f
2 changed files with 4 additions and 4 deletions

View file

@ -250,7 +250,7 @@ The installed GRUB menu has a 5s timeout and boots automatically.
| Symptom | Likely cause / fix |
|---------|--------------------|
| **How to tell which build a VM is actually running** | At the login prompt the build stamp is printed (`Mentalnet GNU/Linux build YYYYMMDD-HHMMSS`); inside the guest check `cat /etc/os-release` (`BUILD_ID=`) or `cat /proc/version`. Useful kernel build markers: `#3 ... 18:45:02` predates the rtl8139 fix, `#4 ... 20:24:17` is the first build with 8139cp. |
| **Booting the CD runs an older install instead of the live system** | Fixed: the live medium is identified by `/boot/grub/grub-eltorito.img` (a file only the ISO carries), so an existing Mentalnet install on disk no longer hijacks the boot. On builds older than this fix, the CD's GRUB searched for `/boot/bzImage`, found the disk first (BIOS enumerates disks before the CD) and chained into the installed system. |
| **Booting the CD runs an older install instead of the live system** | Fixed: the live CD's GRUB core hardcodes `root=(cd)` (the El Torito boot CD itself), so the boot chain never touches any attached disk and an existing Mentalnet install can no longer hijack it. On builds older than this fix, the CD's GRUB searched for `/boot/bzImage` (or a marker file), and since BIOS enumerates disks before the CD, the search landed on the installed system first. |
| **Proxmox: VM boots an older build despite uploading a new ISO** | Proxmox keeps every upload as a separate storage volume, and a VM's CD/DVD drive points at a specific **volume** — renaming or re-uploading a file never updates an existing drive (checksums of the new file do not help either). Delete the stale volume, upload the unique-named ISO from the build log, attach it in Hardware, and check Boot Order (an installed disk can also shadow the CD). |
| GRUB menu does not appear, or the machine reboots before booting, in QEMU | Try more RAM (`-m 256`). Memory pressure during development was the culprit more than once. |
| Kernel panic: `Unable to mount root fs` | The CD drive is on an unsupported controller. The kernel targets PIIX-era IDE/ATA; modern SATA-only setups are out of scope. |
@ -268,7 +268,7 @@ Everything Mentalnet-specific lives here:
| File | Purpose |
|------|---------|
| `board/mentalnet/grub-embedded.cfg` | config embedded into the GRUB core image: finds the live medium via `/boot/grub/grub-eltorito.img` (a file only the ISO carries), so the CD always boots the live system even with an installed disk attached. NB: GRUB early configs support plain commands only - no comment lines, no `\` continuations, no `\|\|` operators. |
| `board/mentalnet/grub-embedded.cfg` | config embedded into the live CD's GRUB core: hardcodes `root=(cd)` so the CD always boots the live system, even with a Mentalnet install on an attached disk (GRUB's `(cd)` device is the El Torito boot CD itself, so nothing on any disk can influence the chain). NB: GRUB early configs support plain commands only - no comment lines, no `\` continuations, no `\|\|` operators, and `search` must be avoided because it iterates devices in BIOS order (disks first). |
| `board/mentalnet/linux-slim.config` | kernel config fragment: keeps the classic PCI NICs, ATA/ATAPI, USB HID/storage, serial and VGA console; drops wireless, sound, DRM, RAID, PCMCIA, debug |
| `board/mentalnet/overlay/usr/sbin/mentalnet-install` | the hard disk installer |
| `board/mentalnet/overlay/usr/share/mentalnet/grub-disk.cfg` | boot menu template written to installed systems (`@ROOTDEV@` is replaced) |

View file

@ -1,3 +1,3 @@
search --no-floppy --file /boot/grub/grub-eltorito.img --set=root
set prefix=($root)/boot/grub
set root=(cd)
set prefix=(cd)/boot/grub
normal