On Fri 22 Dec 2023 at 11:24:22 (+0000), Mark Fletcher wrote:
> 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.
> [ … ]
> 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...
That seems to answer my question—it's something about installation
kernels that makes Grub ignore them, rather than Debian/non-Debian.
> > I've never run LFS; what does the menuentry in grub.cfg look like?
> [ … ]
> 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?
AIUI os-prober doesn't write "fancy" kernel commands lines itself:
it copies them. The scripts that write prefix30 menuentries are happy
to juggle partitions and contents because they are written with Grub's
capabilities in mind, but they can't know how those kernels will
interpret their commandline parameters beyond the most basic.
[ … ]
> 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,
It searched partitions for bootables, and found one in /dev/sdc2
(which, as you pointed out, is not a stable name), so it wrote
linux /vmlinuz-6.4.12-lfs-12.0-systemd root=/dev/sdc2
named after where it found the kernel. "root=/dev/sdc2" can be
understood by any linux kernel.
> on the other I
> wish it were clever enough to use PARTUUID= instead, as the
> grub-mkconfig manual implies it is.
Only /etc/grub.d/{10_linux,20_linux_xen} can generate PARTUUIDs;
/etc/grub.d/30_os-prober doesn't even contain the string "PARTUUID".
And I noticed:
https://www.linuxfromscratch.org/lfs/view/9.0/chapter08/grub.html
says:
"Caution
"There is a command, grub-mkconfig, that can write a configuration
file automatically. It uses a set of scripts in /etc/grub.d/ and
will destroy any customizations that you make. These scripts are
designed primarily for non-source distributions and are not
recommended for LFS. If you install a commercial Linux distribution,
there is a good chance that this program will be run. Be sure to
back up your grub.cfg file."
So it seems to be assumed that LFS sysadmins should craft their own.
> 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.
Yes, I posted a 40_custom entry, and have never seen any advantage
in trying the 41_custom method myself.
Cheers,
David.
