On Fri, 22 Dec 2023 at 01:21, David Wright <deb...@lionunicorn.co.uk> wrote:
>
> What sort of mess? I would have thought Grub would ignore excess
> kernels dropped into /boot. I have a laptop here that has two
> bookworm netinst ISOs (release candidates) and a kernel and initrd
> (hd-media) for booting the ISOs, and they've been ignored through
> at least two kernel upgrades:
>
> 4096 Oct 9 22:49 /grub
> 83 Aug 16 15:52 System.map-5.10.0-25-686
> 83 Sep 28 23:25 System.map-5.10.0-26-686
> 245147 Aug 16 15:52 config-5.10.0-25-686
> 245200 Sep 28 23:25 config-5.10.0-26-686
> 703594k Apr 24 2023 debian-bookworm-DI-rc1-i386-netinst.iso
> 704643k Apr 28 2023 debian-bookworm-DI-rc2-i386-netinst.iso
> 19920k Apr 27 2023 initrd.gz
> 33580k Oct 7 12:36 initrd.img-5.10.0-25-686
> 33588k Nov 27 18:46 initrd.img-5.10.0-26-686
> 5548224 Apr 8 2023 vmlinuz
> 4988160 Aug 16 15:52 vmlinuz-5.10.0-25-686
> 4990880 Sep 28 23:25 vmlinuz-5.10.0-26-686
It saw a Debian kernel (6.1.something) on <debian boot partition>/ and
a LFS kernel (6.4.12 IIRC) on <the same Debian boot partition>/. It
also saw candidate root filesystems on <debian lvm root> and <LFS root
partition>. And it proceeded to cartesian join them, so I got LFS
kernel with debian root filesystem, Debian kernel with Debian root
filesystem, LFS kernel with LFS root filesystem (specified by
/dev/sdc2 which the very next time it booted that disk was /dev/sda2)
and Debian kernel with LFS root filesystem (again specified by device
name). Obviously, only 2 of those are things I'd ever want to boot.
And, once I saw what it had done, I kinda slapped my forehead and
thought well yeah, how was it supposed to know not to do that...
>
> I've never run LFS; what does the menuentry in grub.cfg look like?
>
menuentry 'Linux From Scratch (12.0-systemd) (on /dev/sdc2)' --class linuxfromsc
ratch --class gnu-linux --class gnu {
insmod part_gpt
insmod ext2
set root='hd2,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-ef
i=hd2,gpt1 --hint-baremetal=ahci2,gpt1 <fs UUID elided>
else
search --no-floppy --fs-uuid --set=root <fs UUID elided>
957b66
fi
linux /vmlinuz-6.4.12-lfs-12.0-systemd root=PARTUUID=<partUUID elided>
}
That is AFTER my edits to replace root=/dev/sdc2 in the linux command
line with the PARTUUID. The FS UUIDs I elided above were put there by
GRUB. Again, Debian GRUB created this when I ran it with os_prober
turned ON. I grabbed this and copied it to custom.cfg, made the edit
to add the PARTUUID, then ran update-grub again with os_prober turned
off.
Ah hold on. Maybe os_prober is what is generating this menuentry
stanza in the first place, and grub is just using it. If that's the
case, I was asking the wrong question in the first place. Maybe the
question isn't why isn't grub using PARTUUID= in this situation, which
the manual says it will, but rather why isn't os_prober doing so?
>
> So what does this command show, if anything:
>
> $ zgrep result: /var/log/messages*
> /var/log/messages:Dec 21 18:10:52 acer 90linux-distro: result:
> /dev/sda4:Debian GNU/Linux 12 (bookworm):Debian:linux
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result:
> /dev/sda4:/dev/sda4:Debian
> GNU/Linux:/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8
> ro quiet
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result:
> /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux
> 6.1.0-13-686:/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8
> ro quiet
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result:
> /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-13-686 (recovery
> mode):/boot/vmlinuz-6.1.0-13-686:/boot/initrd.img-6.1.0-13-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8
> ro single
> /var/log/messages:Dec 21 18:10:57 acer 40grub2: result:
> /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux
> 6.1.0-10-686:/boot/vmlinuz-6.1.0-10-686:/boot/initrd.img-6.1.0-10-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8
> ro quiet
> /var/log/messages:Dec 21 18:10:58 acer 40grub2: result:
> /dev/sda4:/dev/sda4:Debian GNU/Linux, with Linux 6.1.0-10-686 (recovery
> mode):/boot/vmlinuz-6.1.0-10-686:/boot/initrd.img-6.1.0-10-686:root=UUID=ac1b3d4f-aa95-4e12-b6e6-fd455273a3b8
> ro single
>
> (you can use messages*, syslog* or user.log*)
Interestingly, the most recent output in /var/log/messages* was from
November, ie before i started playing with this. So here is what is in
/var/log/syslog*, confining attention to the most recent date:
/var/log/user.log:2023-12-18T18:37:47.192311+00:00 phantom 40lsb:
result: /dev/sdc2:Linux From Scratch
(12.0-systemd):LinuxFromScratch:linux
/var/log/user.log:2023-12-18T18:37:49.378939+00:00 phantom
90linux-distro: result: /dev/mapper/kazuki--vg-root:Debian GNU/Linux
10 (buster):Debian:linux
/var/log/user.log:2023-12-18T18:37:49.893237+00:00 phantom 90fallback:
result:
/dev/sdc2:/dev/sdc1::/boot/vmlinuz-6.4.12-lfs-12.0-systemd::root=/dev/sdc2
/var/log/user.log:2023-12-18T18:37:51.945521+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian
GNU/Linux:/boot/vmlinuz-4.19.0-12-amd64:/boot/initrd.img-4.19.0-12-amd64:root=/dev/mapper/kazuki--vg-root
ro quiet
/var/log/user.log:2023-12-18T18:37:52.037769+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux
4.19.0-12-amd64:/boot/vmlinuz-4.19.0-12-amd64:/boot/initrd.img-4.19.0-12-amd64:root=/dev/mapper/kazuki--vg-root
ro quiet
/var/log/user.log:2023-12-18T18:37:52.125886+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux 4.19.0-12-amd64 (recovery
mode):/boot/vmlinuz-4.19.0-12-amd64:/boot/initrd.img-4.19.0-12-amd64:root=/dev/mapper/kazuki--vg-root
ro single
/var/log/user.log:2023-12-18T18:37:52.217524+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux
4.19.0-11-amd64:/boot/vmlinuz-4.19.0-11-amd64:/boot/initrd.img-4.19.0-11-amd64:root=/dev/mapper/kazuki--vg-root
ro quiet
/var/log/user.log:2023-12-18T18:37:52.304735+00:00 phantom 40grub2:
result: /dev/mapper/kazuki--vg-root:/dev/sdb1:Debian GNU/Linux, with
Linux 4.19.0-11-amd64 (recovery
mode):/boot/vmlinuz-4.19.0-11-amd64:/boot/initrd.img-4.19.0-11-amd64:root=/dev/mapper/kazuki--vg-root
ro single
(The references to "kazuki" are an old buster installation on an old
SSD that is connected to this box but that I am not using these days,
but can't quite bring myself to delete.... I don't particularly want
it in GRUB but don't mind if it gets there)
I don't know how it figured out /dev/sdc2 -- on the one hand it is
clever to have done so with no grub.cfg to tell it, on the other I
wish it were clever enough to use PARTUUID= instead, as the
grub-mkconfig manual implies it is.
That all said, the updated idea of trying 40_custom instead of
41_custom and thus avoiding the question of the config_directory
variable is what I will try next.
Mark
