It's not ideal, but what I did when I had two disks and two operating
systems was I installed two grubs, one for each OS, one on each MBR. I
then used the BIOS menu to choose which disk to boot. This means each OS updates its own grub instance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mark Fletcher composed on 2023-12-18 20:36 (UTC):

Can anyone explain why, and how I can fix this in a way that will
still work the next time the bookworm kernel gets an update?

I can't answer why Grub scripts to what the do, because I don't really use them,
and don't need to understand much about them. Grub config files in /boot/grub/ are
akin to scripts, but they are really simple, mainly just command scripts. The usual one is grub.cfg, the one os-prober feeds from other Linux installations. A
less common one is custom.cfg. To use it requires the admin build it. When it exists, grub-mkconfig incorporates its use by/in grub.cfg. It actually gets called
by default from /etc/grub.d/41_custom, which adds the stanzas from it to the Grub
boot menu - after those that it has generated itself. I copy it to /etc/grub.d/07_custom, and empty 41_custom. That causes my custom stanzas to appear first in Grub's boot menu. /etc/grub.d/40_custom acts, and a copy of it as
06_custom would act, in similar fashion, except that the admin's custom stanzas are put into it by the admin instead of into a custom.cfg file.

Thus, you, as admin, construct working stanzas however you like, with or without
UUIDS, with or without device names, with or without volume LABELS, however you like boot to go, and they don't get changed, except by the admin - you. This is easy, because you as admin can use the kernel (and initrd) symlinks Debian puts in
/, or anywhere you'd like symlinks to them to go, for distros that don't automatically create them for you. There's no need for maintenance when new kernels are installed in the case of Debian and other distros that automatically
generate new symlinks. For those that don't, creating them is trivial.

<https://forums.opensuse.org/t/how-to-have-a-custom-uefi-grub-menu-for-a-multiboot-system/133541/2>
is a thread that goes through my UEFI system setups.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mark Fletcher composed on 2023-12-20 00:28 (UTC):

I am curious to know from Debian
GRUBbers (as it were) if the behaviour I am describing in this thread
is expected...

I suspect few if any regulars here spend much time with Slackware. I think a more
conventional approach would be to reconfigure Slackware to boot by UUID, with the
result that Debian's os-prober should pick it up in the more reliable fashion. I
don't have a bootloader installed on my only Slackware, and have no more familiarity with ELILO than that it seems to be the Slack user favorite bootloader. Whether or how well it or its Grub might pick up Debian, or any proclivity it may have to usurp boot control from Debian or include stanza(s) for
Debian, I have no basis for guessing.

If you can keep your Slack kernel (& initrd if using one) generically symlinked without much trouble, a stanza you put in /etc/grub.d/41_custom should be able to
boot Slack from Debian's Grub using your custom stanza containing root=LABEL= or
root=UUID= without trouble. Same would go for using 07_custom, or custom.cfg with
06_custom, to move your custom stanza to the Debian Grub menu's top.

Multiboot is as much art as science. Like anything in Gnu/Linux, there are multiple ways to decouple felines from their skins.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue 19 Dec 2023 at 21:40:19 (-0500), Felix Miata wrote:

Mark Fletcher composed on 2023-12-20 00:28 (UTC):

I am curious to know from Debian
GRUBbers (as it were) if the behaviour I am describing in this thread
is expected...

I suspect few if any regulars here spend much time with Slackware. I think a more
conventional approach would be to reconfigure Slackware to boot by UUID, with the
result that Debian's os-prober should pick it up in the more reliable fashion. I
don't have a bootloader installed on my only Slackware, and have no more familiarity with ELILO than that it seems to be the Slack user favorite bootloader. Whether or how well it or its Grub might pick up Debian, or any proclivity it may have to usurp boot control from Debian or include stanza(s) for
Debian, I have no basis for guessing.

I can't see anywhere where the OP claims to have set up LFS for
booting itself, as opposed to being booted from a Debian Grub.
It only says "I have been able to get a grub.cfg including the
LFS system …", which seems to imply LFS has only been set up
as a "foreign" system by a Debian system.

When os-prober runs on my system, a lot of stuff gets logged in
messages, syslog and user.log. The lines that contain the string
"result:" (without the quotes) are interesting. It's evident from
those that have six fields following result: have had their root=
field copied from the foreign system's grub.cfg. (In my case,
"foreign" means a Debian system of the previous release.)

When os-prober writes several clauses into my new grub.cfg's
"### BEGIN /etc/grub.d/30_os-prober ###" section, the references
to the partition are constructed using UUIDs (not PARTUUIDs, because
there's an initrd). However, the kernel command line reads
"root=LABEL=toto04", so that string wasn't constructed by os-prober,
but copied from the foreign grub.cfg¹.

That suggests to me the probability that whereas +Grub constructs+
the root= strings for the "### BEGIN /etc/grub.d/10_linux ###"
section, +os-prober copies+ the root= strings into the
"### BEGIN /etc/grub.d/30_os-prober ###" section instead.

If you can keep your Slack kernel (& initrd if using one) generically symlinked
without much trouble, a stanza you put in /etc/grub.d/41_custom should be able to
boot Slack from Debian's Grub using your custom stanza containing root=LABEL= or
root=UUID= without trouble. Same would go for using 07_custom, or custom.cfg with
06_custom, to move your custom stanza to the Debian Grub menu's top.

In case it's not clear, "generically symlinked" means that
/vmlinuz is a symlink pointing to the most recent linux-image.
(Similarly for initrd.) I added the following to
/etc/grub.d/07_custom:

menuentry 'My bullseye' $menuentry_id_option 'custom' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --set=root --label noah03
echo 'Load /vmlinuz …'
linux /vmlinuz root=LABEL=noah03 ro systemd.show_status=true quiet
echo 'Load initial ramdisk /initrd.img …'
initrd /initrd.img
}

¹ After installing a system, upgrading the kernel, or upgrading
Grub, I run a script that converts /all/ the UUIDs in grub.cfg
into LABELs, in this little dance:
cp grub.cfg → grub.cfg-uuids
cp grub.cfg-edited → grub.cfg-old
< grub.cfg filter-script > grub.cfg-edited
cp grub.cfg-edited → grub.cfg

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Wright composed on 2023-12-20 00:00 (UTC-0600):

In case it's not clear, "generically symlinked" means that
/vmlinuz is a symlink pointing to the most recent linux-image.
(Similarly for initrd.) I added the following to
/etc/grub.d/07_custom:

menuentry 'My bullseye' $menuentry_id_option 'custom' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --set=root --label noah03
echo 'Load /vmlinuz …'
linux /vmlinuz root=LABEL=noah03 ro systemd.show_status=true quiet
echo 'Load initial ramdisk /initrd.img …'
initrd /initrd.img
}

A bit less is needed here in custom.cfg:
menuentry "Debian 13 Trixie defkernel 3 on P10" {
load_video
set gfxpayload=keep
search --no-floppy --set=root --hint-baremetal=ahci0,gpt10 --label zd8p10deb13
linux /vmlinuz root=LABEL=zd8p10deb13 noresume consoleblank=0 preempt=full mitigations=off
initrd /initrd.img
}
menuentry "Slackware 15.0 GUI on P25"{
load_video
set gfxpayload=keep
search --no-floppy --set=root --hint-efi=hd0,gpt25 --label zd8p25slack
linux /boot/vmlinuz rw root=LABEL=zd8p25slack noresume consoleblank=0 mitigations=off
initrd /boot/initrd.gz
}
# lsblk -f | egrep 'fat|slack|deb13'
├─sda1 vfat FAT32 ZD8P01ESP 20A0-2A08
├─sda10 ext4 1.0 zd8p10deb13 e37c3e3c...
├─sda25 ext4 1.0 zd8p25slack 6664eb9b...
# grep RETT /etc/os-release
PRETTY_NAME="openSUSE Tumbleweed"
# rpmqa grub2-2.1
grub2-2.12~rc1-12.1.x86_64
#
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday 19 December 2023 09:40:19 pm Felix Miata wrote:

I suspect few if any regulars here spend much time with Slackware.

I, for one, have been running Slackware since 1999. It's what's running in this virtualbox where I do my email, and it's also what's running on my file server...

--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mark Fletcher composed on 2023-12-21 21:30 (UTC):

Felix Miata wrote:

I suspect few if any regulars here spend much time with Slackware.

I am genuinely confused about how Slackware came into the picture
here... my foreign OS is LFS, nothing to do with slackware as far as I know...

Pure unadulterated word dyslexia here. My brain routinely fails to register any difference between LFS and Slackware, both of which in my mind rely more heavily
on the brains of its admins than those of Debian's or its derivatives'. LFS I've
never attempted to use. Slackware I have. Sorry for causing confusion here.

I appreciate your initial help which I still think is my best hope of
a solution

Boot setup are rather simple here. I don't "edit" content of any files in /etc/grub.d/ in the usual sense of the word. What I do is copy 40_custom to 06_custom, and copy 41_custom to 07_custom on my Tumbleweed installation. Then I
remove the content from 40_custom and 41_custom to make them inert rather than having the package system recreate them and bloat grub.cfg as a result. I manually
maintain one file: /boot/grub2/custom.cfg on my Tumbleweed / filesystem. That would correspond to a Debian LVM user, such as you, maintaining /grub/custom.cfg
on his /boot filesystem.

Admins are 100% responsible for the content of (*/gru*/)custom.cfg. Because of my
particular handling of /etc/grub.d/, the stanzas in custom.cfg head the selection
list presented by Grub on boot. Those generated by Grub's scripts are rarely utilized here. Any selected stanza from custom.cfg that fails to boot something can only be due to my own fault.

Tumbleweed is the only distro installed here where the ESP is routinely mounted to
/boot/efi/. Only one bootloader is needed per typical Gnu/Linux-only multiboot PC.

From one PC here currently booted:

# grep vmlinuz /boot/grub2/custom.cfg | wc -l
21
# grep root= /boot/grub2/custom.cfg | wc -l
21
# grep root=LABEL /boot/grub2/custom.cfg | wc -l
21
#

There need be no difference from my configuration an any Debian user's, other than
the name of the directory containing custom.cfg.

For those who don't know the why of /boot/grub2/ instead of /boot/grub/ (on openSUSE at least), grub2 is used instead of grub in /boot/ as a historical continuation of the multiple releases period when both Grub Legacy and Grub2 could
be simultaneously installed on the same installation without need for any filename
customization in Grub as installed. IIRC, one could be setup on MBR, the other on
a partition, possibly more for developer convenience than any expectation users would want both at once.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Dec 21, 2023 at 07:33:13PM -0500, Felix Miata wrote:

From one PC here currently booted:

# grep vmlinuz /boot/grub2/custom.cfg | wc -l
21
# grep root= /boot/grub2/custom.cfg | wc -l
21
# grep root=LABEL /boot/grub2/custom.cfg | wc -l
21

Just for the record, grep -c (count matching lines) exists.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu 21 Dec 2023 at 21:38:46 (+0000), Mark Fletcher wrote:

On Wed, 20 Dec 2023 at 06:01, David Wright <deblis@lionunicorn.co.uk> wrote:

I can't see anywhere where the OP claims to have set up LFS for
booting itself, as opposed to being booted from a Debian Grub.
It only says "I have been able to get a grub.cfg including the
LFS system …", which seems to imply LFS has only been set up
as a "foreign" system by a Debian system.

Yes, that's exactly it. My very first attempt involved using Debian's
/boot partition as the /boot partition for LFS as well, so installing
LFS's kernel (6.4.12 IIRC) alongside Debian's, but I quickly learned
the folly of that when I saw the mess update-grub made of that...

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

I've already posted my (slightly overlong) /etc/grub.d/07_custom;
I can boot the installer with:

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Install Debian via HTTP" {
search --no-floppy --label --set=root noah03
linux /boot/vmlinuz priority=low
initrd /boot/initrd.gz
}
#
### END /etc/grub.d/40_custom ###

So I rebuilt my LFS (was happy to do so, this is a learning exercise)
with its own /boot partition, which gets me closer to the solution I
want which is one Grub, Debian's grub, with Debian as the first and
default boot choice, but LFS available as an alternative. And the only remaining problem is the Debian GRUB's insistence on using /dev/sdX2
(for the root partition is the second partition on the disk) in the
"linux" command line parameter.

I've never run LFS; what does the menuentry in grub.cfg look like?

When os-prober runs on my system, a lot of stuff gets logged in
messages, syslog and user.log. The lines that contain the string
"result:" (without the quotes) are interesting. It's evident from
those that have six fields following result: have had their root=
field copied from the foreign system's grub.cfg. (In my case,
"foreign" means a Debian system of the previous release.)

When os-prober writes several clauses into my new grub.cfg's
"### BEGIN /etc/grub.d/30_os-prober ###" section, the references
to the partition are constructed using UUIDs (not PARTUUIDs, because there's an initrd). However, the kernel command line reads "root=LABEL=toto04", so that string wasn't constructed by os-prober,
but copied from the foreign grub.cfg.

That suggests to me the probability that whereas +Grub constructs+
the root= strings for the "### BEGIN /etc/grub.d/10_linux ###"
section, +os-prober copies+ the root= strings into the
"### BEGIN /etc/grub.d/30_os-prober ###" section instead.

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*)

Interesting -- but there is no grub.cfg on the LFS system because grub
has never been installed there. There is a /boot partition but no /boot/grub/grub.cfg <suddenly doubts self, and goes to check --
indeed, there isn't>.
So, nothing to copy from in this case.

That's why I was interested in the zgrep output: I've never had
a system with "foreign" systems that lack grub.cfg (except for
Windows, which is handled differently). I've always set up Grub
on any system I've installed.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mark Fletcher <mark27q1@gmail.com> writes

The question is, what values are config_directory and prefix set to?

Grub sets config_directory to point to the directory where it's reading
it's config from. In other words, /boot.

But why not just use 40_custom? It copies whatever is in the file (after
the header) to your grub.cfg. Don't need to figure out what file goes in
what directory. It also keeps configuration in /etc instead of moving it
to /boot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mark Fletcher composed on 2023-12-22 06:43 (UTC):

I have just discovered that I
had a typo in my custom.cfg file, and when I fixed it, it worked.

:-D

Thanks all for your help with this.

:-D
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Reg. Linux User #211409 multibooting for >3 decades

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri 22 Dec 2023 at 11:24:22 (+0000), Mark Fletcher wrote:

On Fri, 22 Dec 2023 at 01:21, David Wright <deblis@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)