From Newsgroup: alt.os.linux

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in my
menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

then the only way to do that is with a /etc/grub.d/40_Custom file but
those directives need to be hand-edited after every update in any of the systems. Thousands of users including myself have been asking for
STANDARDIZED vmlinuz and initrd links pointing to the latest kernel!!! openSuse have listened and do this but most others do not. This would
make it possible to have a simplified custom menu that uses the links
and does not have to be edited each time.

As it is, the only alternative is some cron that runs the installed
systems and verifies existing or creates standard links which can then
be used in an /etc/grub.d/40_Custom file.

4 of 6 already use dynamically regenerated either standardized or
fixed-name links that can be used.

Artix vmlinuz, vmlinuz-linux, initramfs-linux.img
Slackware vmlinuz, initrd.gz
Tumbleweed vmlinuz, initrd
Leap vmlinuz, initrd

For now I plan to create the links manually in Devuan/Debian

menuentry "12 Devuan 6.1.2 Excalibur" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 37fd95d7-fd2c-4020-ad07-66be4b0d9bd4
linux /vmlinuz root=UUID=37fd95d7-fd2c-4020-ad07-66be4b0d9bd4 ro
initrd /initrd
}





and maybe just devise a script that periodically validates them.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Thu, 24 Sep 2026 16:49:41 -0400, bad sector wrote:

then the only way to do that is with a /etc/grub.d/40_Custom file
but those directives need to be hand-edited after every update in
any of the systems.

<https://www.gnu.org/software/grub/manual/grub/grub.html> section 6.1, rCLSimple configuration handlingrCY:

`grub-mkconfig` does have some limitations. While adding extra
custom menu entries to the end of the list can be done by editing
`/etc/grub.d/40_custom` or creating `/boot/grub/custom.cfg`,
changing the order of menu entries or changing their titles may
require making complex changes to shell scripts stored in
`/etc/grub.d/`. This may be improved in the future. In the
meantime, those who feel that it would be easier to write
`grub.cfg` directly are encouraged to do so ... and to disable any
system provided by their distribution to automatically run
`grub-mkconfig`.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 9/24/26 7:39 PM, Lawrence DrCOOliveiro wrote:

On Thu, 24 Sep 2026 16:49:41 -0400, bad sector wrote:

then the only way to do that is with a /etc/grub.d/40_Custom file
but those directives need to be hand-edited after every update in
any of the systems.

<https://www.gnu.org/software/grub/manual/grub/grub.html> section 6.1, rCLSimple configuration handlingrCY:

`grub-mkconfig` does have some limitations. While adding extra
custom menu entries to the end of the list can be done by editing
`/etc/grub.d/40_custom` or creating `/boot/grub/custom.cfg`,
changing the order of menu entries or changing their titles may
require making complex changes to shell scripts stored in
`/etc/grub.d/`. This may be improved in the future. In the
meantime, those who feel that it would be easier to write
`grub.cfg` directly are encouraged to do so ... and to disable any
system provided by their distribution to automatically run
`grub-mkconfig`.

Devs want tools, users want utilities. I'm working with 40_custom but
there are issues, more about this tomorrow night. There is nothing wrong
with auto updates, most of the complaints revolve around menu
PRESENTATION and easy/simple user control of THAT.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Thu, 24 Sep 2026 23:16:17 -0400, bad sector wrote:

Devs want tools, users want utilities.

Not sure what the difference is. Sounds like yourCOre bringing across a
mindset from the world of proprietary platforms, where ordinary users
are not supposed to have access to any functionality that has to do
with rCLdevelopmentrCY.

In the open-source world, there are no hard-and-fast barriers; itrCOs
all a spectrum.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Op 25-09-2026 om 05:16 schreef bad sector:

On 9/24/26 7:39 PM, Lawrence DrCOOliveiro wrote:

On Thu, 24 Sep 2026 16:49:41 -0400, bad sector wrote:

then the only way to do that is with a /etc/grub.d/40_Custom file
but those directives need to be hand-edited after every update in
any of the systems.

<https://www.gnu.org/software/grub/manual/grub/grub.html> section 6.1,>> rCLSimple configuration handlingrCY:

-a-a-a-a `grub-mkconfig` does have some limitations. While adding extra
-a-a-a-a custom menu entries to the end of the list can be done by editing >> -a-a-a-a `/etc/grub.d/40_custom` or creating `/boot/grub/custom.cfg`,
-a-a-a-a changing the order of menu entries or changing their titles may
-a-a-a-a require making complex changes to shell scripts stored in
-a-a-a-a `/etc/grub.d/`. This may be improved in the future. In the
-a-a-a-a meantime, those who feel that it would be easier to write
-a-a-a-a `grub.cfg` directly are encouraged to do so ... and to disable any >> -a-a-a-a system provided by their distribution to automatically run
-a-a-a-a `grub-mkconfig`.

Devs want tools, users want utilities. I'm working with 40_custom but
there are issues, more about this tomorrow night. There is nothing wrong
with auto updates, most of the complaints revolve around menu
PRESENTATION and easy/simple user control of THAT.

It doesn't necessarily have to be 40_custom, if you want your entry
higher on the list you can use a lower number.
I have currently 5 custom entries, each in its own file: 14_custom
through 18_custom.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 25 Sep 2026 08:07:35 +0200, dillinger wrote:

It doesn't necessarily have to be 40_custom, if you want your entry
higher on the list you can use a lower number. I have currently 5
custom entries, each in its own file: 14_custom through 18_custom.

Note that clever little rCLtailrCY shell trick at the start. This turns
the rest of the file into a simple list of menu items to be output.
But thererCOs no reason why you have to use that trick in your custom
script.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

bad sector <forgetski@_INVALID.net> writes:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in
my menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

Booting six different Linux installs is an extremely niche use case, not supporting it automatically doesnrCOt make it a rCyPOSrCO.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 9/25/26 4:02 AM, Richard Kettlewell wrote:

bad sector <forgetski@_INVALID.net> writes:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in
my menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

Booting six different Linux installs is an extremely niche use case, not supporting it automatically doesnrCOt make it a rCyPOSrCO.

Natural stability requires three or more legs, I just brought it down
from ten and the current mix is 3 with systemd and three without to
focus on the looming gore.




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 9/24/26 7:39 PM, Lawrence DrCOOliveiro wrote:

On Thu, 24 Sep 2026 16:49:41 -0400, bad sector wrote:

then the only way to do that is with a /etc/grub.d/40_Custom file
but those directives need to be hand-edited after every update in
any of the systems.

<https://www.gnu.org/software/grub/manual/grub/grub.html> section 6.1, rCLSimple configuration handlingrCY:

`grub-mkconfig` does have some limitations. While adding extra
custom menu entries to the end of the list can be done by editing
`/etc/grub.d/40_custom` or creating `/boot/grub/custom.cfg`,
changing the order of menu entries or changing their titles may
require making complex changes to shell scripts stored in
`/etc/grub.d/`. This may be improved in the future. In the
meantime, those who feel that it would be easier to write
`grub.cfg` directly are encouraged to do so ... and to disable any
system provided by their distribution to automatically run
`grub-mkconfig`.

"...queries involving GRUB2 menu problems consistently yield millions of results, indicating it is one of the most common troubleshooting areas
in Linux administration."

I rest my case.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 9/25/26 6:47 AM, chose wrote:

On 9/25/26 4:02 AM, Richard Kettlewell wrote:

bad sector <forgetski@_INVALID.net> writes:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader.-a If all I want in
my menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

Booting six different Linux installs is an extremely niche use case, not
supporting it automatically doesnrCOt make it a rCyPOSrCO.

Natural stability requires three or more legs, I just brought it down
from ten and the current mix is 3 with systemd and three without to
focus on the looming gore.

oops, escaped with wrong handle...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 9/24/26 11:43 PM, Lawrence DrCOOliveiro wrote:

On Thu, 24 Sep 2026 23:16:17 -0400, bad sector wrote:

Devs want tools, users want utilities.

Not sure what the difference is. Sounds like yourCOre bringing across a mindset from the world of proprietary platforms, where ordinary users
are not supposed to have access to any functionality that has to do
with rCLdevelopmentrCY.

In the open-source world, there are no hard-and-fast barriers; itrCOs
all a spectrum.

What I want is

*blindfolded in 3 seconds with one hand*

usability, the way you could set up heating in your car before the
advent of the digital eye-sore filmpanels. Grub legacy had it, grub2
needs something like an easy menu building and composition interface.
Listing in partition order has to be a beginning, I think that's already
the case, after that I'd like to see variables that simply allow users
to decide what they want to see listed

$fontcolor $partition# $OS ($versioned/roll) ($latestkernel)

The other day I ended up with someting like 60 entries with Debian alone accounting for about 9.

I'm on my way to fix (problems with grub search) it but the overhead is unjustifiable.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 24/09/2026 22.49, bad sector wrote:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in my
menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

then the only way to do that is with a /etc/grub.d/40_Custom file but
those directives need to be hand-edited after every update in any of the systems.

Let each distribution to handle their own grub.cfg as they see it fit,
just don't install the grub loader on disk.

You then have one master grub stored in mbr/gpt/efi, which has only your custom configuration, it points to the grub in the partition, for example:

menuentry '11 Artix' {
insmod chain
set root=(hd0,11)
configfile /boot/grub/grub.cfg
}

This makes you to have to edit the master grub install only each time
you install a new distro. Each time a distro updates kernels it will
update it's own grub configuration.

As it is, the only alternative is some cron that runs the installed
systems and verifies existing or creates standard links which can then
be used in an /etc/grub.d/40_Custom file.

Ouch, why over complicate something that Grub already have solved...
--
//Aho
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

chose <chose@INVALID_.gov> (but really a nym-shifted bad sector) writes:

On 9/25/26 4:02 AM, Richard Kettlewell wrote:

bad sector <forgetski@_INVALID.net> writes:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in
my menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

Booting six different Linux installs is an extremely niche use case,
not supporting it automatically doesnrCOt make it a rCyPOSrCO.

Natural stability requires three or more legs, I just brought it down
from ten and the current mix is 3 with systemd and three without to
focus on the looming gore.

I have no idea what this is supposed to mean. One Linux per computer has
been perfectly adequate for me (and I suspect almost all other Linux
users) for 30 years. At any rate whatever the reasons for your choices,
the configuration is distant outlier compared to the rest of the world.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-09-25 14:39, J.O. Aho wrote:

On 24/09/2026 22.49, bad sector wrote:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in my
menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

then the only way to do that is with a /etc/grub.d/40_Custom file but
those directives need to be hand-edited after every update in any of
the systems.

Let each distribution to handle their own grub.cfg as they see it fit,
just don't install the grub loader on disk.

You then have one master grub stored in mbr/gpt/efi, which has only your custom configuration, it points to the grub in the partition, for example:

-a-a-a menuentry '11 Artix' {
-a-a-a-a-a-a insmod chain
-a-a-a-a-a-a set root=(hd0,11)
-a-a-a-a-a-a configfile /boot/grub/grub.cfg
-a-a-a }

This makes you to have to edit the master grub install only each time
you install a new distro. Each time a distro updates kernels it will
update it's own grub configuration.

Or use the UEFI system to choose what partition to boot.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 25 Sep 2026 06:53:20 -0400, bad sector wrote:

"...queries involving GRUB2 menu problems consistently yield
millions of results, indicating it is one of the most common
troubleshooting areas in Linux administration."

But rCLmillions of resultsrCY indicate that there are millions of answers
out there to your problems. If it was rCLmillions of queries without
yielding many resultsrCY, you would have a point.

So really it is you failing to educate yourself on how exactly the
GRUB configuration system works, and how flexible it really is.

I rest my case.

Try again.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 25 Sep 2026 07:14:54 -0400, bad sector wrote:

On 9/24/26 11:43 PM, Lawrence DrCOOliveiro wrote:

In the open-source world, there are no hard-and-fast barriers; itrCOs
all a spectrum.

What I want is

*blindfolded in 3 seconds with one hand*

You get the tools you need to build such a solution for free; it is up
to you to figure out how to use them. So far all yourCOve done is
complain about your impression that the GRUB configuration system
cannot do something it most certainly can do, you just canrCOt be
bothered to put in the intellectual effort to figure it out.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 9/25/26 8:39 AM, J.O. Aho wrote:

On 24/09/2026 22.49, bad sector wrote:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in my
menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

then the only way to do that is with a /etc/grub.d/40_Custom file but
those directives need to be hand-edited after every update in any of
the systems.

Let each distribution to handle their own grub.cfg as they see it fit,
just don't install the grub loader on disk.

You then have one master grub stored in mbr/gpt/efi, which has only your custom configuration, it points to the grub in the partition, for example:

-a-a-a menuentry '11 Artix' {
-a-a-a-a-a-a insmod chain
-a-a-a-a-a-a set root=(hd0,11)
-a-a-a-a-a-a configfile /boot/grub/grub.cfg
-a-a-a }

This makes you to have to edit the master grub install only each time
you install a new distro. Each time a distro updates kernels it will
update it's own grub configuration.

This looks promissing

As it is, the only alternative is some cron that runs the installed
systems and verifies existing or creates standard links which can then
be used in an /etc/grub.d/40_Custom file.

Ouch, why over complicate something that Grub already have solved...

That was before I found out that most DO use links already although not exactyly standardized, the link na]mes do not change with version. The
last 40_custom I tried worked only for Slackware because search could no
t find the (confirmed) uuid's. Haven't had time to kick it around since.




#!/bin/sh
exec tail -n +3 $0
# 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 "11 Artix (rolling)" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 97e..
linux /vmlinuz-linux root=UUID=97e.. rw
initrd /amd-ucode.img /initramfs-linux.img
}

menuentry "12 Devuan 6.1.2 Excalibur" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 37f..
linux /vmlinuz root=UUID=37f.. ro
initrd /initrd.img
}

menuentry "13 Slackware 15.0" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root ea9..
linux /vmlinuz root=UUID=ea9.. ro
initrd /initrd.gz
}

menuentry "14 Tumbleweed (rolling)" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 700..
linux /vmlinuz root=UUID=700.. ro
initrd /initrd
}

menuentry "15 Debian 13.7" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root d45..
linux /vmlinuz root=UUID=d45.. ro
initrd /initrd.img
}

menuentry "16 Leap 16.0" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 147..
linux /vmlinuz root=UUID=147.. ro
initrd /initrd
}



whether I next do

# grub2-mkconfig -o /boot/grub2/grub.cfg

OR the approved suse way of

# update-bootloader --refresh

the result is the same:

What I don't want
=================
- standard menu list of partitions as
usual with os-prober ..all of them work

What I do want
==============
- my custom list .. only two of these work
Devuan and Debian ...the other 4 cannot
find the kernel and fail the initrd call
because the kernel is needed first. Looks
like 'search' may be buggy (all the uuid's
verified).

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-Sep-25 1:59 PM, one nym, one OS, one trick pony wrote:

chose <chose@INVALID_.gov> (but really a nym-shifted bad sector) writes:

I speak 4 languages and participate in several dozen forums which
requires several handles, but unlike Pan Thunderbird doesn't let groups
to be limited to certain handles and every now and then the wrong one
gets used because (you guessed it) on several computers all running many
OS'es not all instances of Thunderbird are set up exactly the same way.

On 9/25/26 4:02 AM, Richard Kettlewell wrote:

bad sector <forgetski@_INVALID.net> writes:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in
my menu for (currently) 6 onboard OSes is the partition number and the >>>> distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

Booting six different Linux installs is an extremely niche use case,
not supporting it automatically doesnrCOt make it a rCyPOSrCO.

Natural stability requires three or more legs, I just brought it down
from ten and the current mix is 3 with systemd and three without to
focus on the looming gore.

I have no idea what this is supposed to mean. One Linux per computer has
been perfectly adequate for me (and I suspect almost all other Linux
users) for 30 years. At any rate whatever the reasons for your choices,
the configuration is distant outlier compared to the rest of the world.

Too bad that not a single one of my questions was about what anyone
thinks of multi-OS usage but about my perceived lack of simplicity in grub2.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-Sep-25 8:39 AM, J.O. Aho wrote:

On 24/09/2026 22.49, bad sector wrote:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in my
menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

then the only way to do that is with a /etc/grub.d/40_Custom file but
those directives need to be hand-edited after every update in any of
the systems.

Let each distribution to handle their own grub.cfg as they see it fit,
just don't install the grub loader on disk.

You then have one master grub stored in mbr/gpt/efi, which has only your custom configuration, it points to the grub in the partition, for example:

-a-a-a menuentry '11 Artix' {
-a-a-a-a-a-a insmod chain
-a-a-a-a-a-a set root=(hd0,11)
-a-a-a-a-a-a configfile /boot/grub/grub.cfg
-a-a-a }

This makes you to have to edit the master grub install only each time
you install a new distro. Each time a distro updates kernels it will
update it's own grub configuration.

I'll keep this for future reference, for now 'Claude' has helped out
with the TS:


... the usable 40_custom file

#!/bin/sh
exec tail -n +3 $0
# 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 "11 Artix (rolling)" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 97e..
linux /boot/vmlinuz-linux root=UUID=97e.. rw
initrd /boot/amd-ucode.img /boot/initramfs-linux.img
}

menuentry "12 Devuan 6.1.2 Excalibur" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 37f..
linux /vmlinuz root=UUID=37f.. ro
initrd /initrd.img
}

menuentry "13 Slackware 15.0" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root ea9..
linux /boot/vmlinuz-6.12.30 root=UUID=ea9.. ro
initrd /boot/initrd.gz
}

menuentry "14 Tumbleweed (rolling)" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 700..
linux /boot/vmlinuz root=UUID=700.. ro
initrd /boot/initrd
}

menuentry "15 Debian 13.7" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root d45..
linux /vmlinuz root=UUID=d45.. ro
initrd /initrd.img
}

menuentry "16 Leap 16.0" {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 147..
linux /boot/vmlinuz root=UUID=147.. ro
initrd /boot/initrd
}

...PLUS
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_SUBMENU="true"
GRUB_DISABLE_OS_PROBER="true"



...PLUS
sudo chmod -x /etc/grub.d/10_linux
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

On my x870e board invoking UEFI bios is a 500% PITA, the only way to
reliably get to it is unplugging the drive tray and booting that way,
leaving the systyem nothig but bios to launch. Admittedly the inclusion
of the UEFI menu makes it much easier and keeping THAT extra entry is a
winner for me.



....Heads-UP:

GRUB MULTI-BOOT MENUENTRY FAILS WITH "file '/vmlinuz' not found" DESPITE CORRECT UUIDs =========================================================================

SYMPTOM
-------

A hand-written GRUB 40_custom menu entry for a non-Debian-family Linux installation fails to boot with:

error: file '/vmlinuz' not found.
error: you need to load the kernel first.

This happens even when:

- search --no-floppy --fs-uuid --set=root <uuid> uses the correct,
verified filesystem UUID (confirmed with blkid / lsblk -f)
- the correct insmod modules for the partition table and filesystem
are loaded
- the target filesystem is a normal, healthy ext4 partition
- grub2-mkconfig / update-grub has been re-run after editing 40_custom

Meanwhile, Debian and Devuan entries using the identical style of
menuentry, generated the same way, boot without any problem.


ROOT CAUSE
----------

search --fs-uuid --set=root only locates the partition and sets $root.
It does NOT check whether the kernel/initrd files named in the linux
and initrd lines actually exist. That lookup happens separately, at
boot time, when GRUB tries to load those exact paths.

Debian and Devuan are unusual among mainstream distributions: their
packaging creates a generic symlink at the filesystem root, e.g.

/vmlinuz -> boot/vmlinuz-<version>
/initrd.img -> boot/initrd.img-<version>

This convention exists specifically so external bootloaders (or
manually written stanzas) can reference a short, version-independent
path.

Arch-based distributions (Artix), Slackware, and openSUSE (Tumbleweed,
Leap) do NOT create this root-level alias. Their kernels and initrds
exist only under /boot/:

/boot/vmlinuz-linux
/boot/vmlinuz-6.12.30
/boot/vmlinuz -> vmlinuz-<version>
(openSUSE, Slackware: relative symlink, but still under /boot)

A 40_custom entry written by copying the Debian-style pattern
(linux /vmlinuz ..., initrd /initrd.img ...) will therefore search the
correct partition, succeed, and then fail immediately afterward,
because no file named /vmlinuz exists at that partition's root - only
under /boot/.

THE FIX is simply prefixing the kernel/initrd paths with /boot/ (or
using the real versioned filename directly), matching whatever that
specific distribution's own filesystem layout actually is. No UUID,
search, module, or grub2-mkconfig/update-bootloader fix was required -
those were all red herrings that had to be independently ruled out
first.


WHY THIS IS EASY TO MISDIAGNOSE
--------------------------------

Several plausible-looking causes have to be excluded before the real
one is visible, and all of them feel like the right area to
investigate:

1. UUID mismatch - a natural first suspect, especially if the file
was edited or partitions were reformatted at any point. Worth
checking, but in this case the UUIDs were already correct.

2. Missing filesystem driver module (insmod ext4/btrfs/etc.) -
genuinely can cause search to fail outright, but produces a
different error (no such device), not a file-not-found on the
kernel line.

3. ext4 on-disk feature flags (metadata_csum, 64bit, etc.) - a
reasonable hypothesis when comparing distros with different
e2fsprogs versions, but a dead end here since the flags didn't
correlate with which entries failed.

4. Wrong bootloader "owns" the boot process in a multi-distro EFI
setup - worth ruling out with efibootmgr -v any time several OSes
are installed, but in this case a single GRUB (openSUSE's) was
confirmed as the sole, master bootloader for all six systems.

5. The SUSE-specific note that "update-bootloader --refresh" should
be used instead of "grub2-mkconfig" - this is true only when SUSE's
own installation owns /boot/grub2; in a shared multi-boot setup
where one distro's GRUB serves everyone, running
"grub2-mkconfig -o /boot/grub2/grub.cfg" directly is the reliable,
explicit choice, and using it side-stepped any ambiguity about
what the wrapper script does internally.

Only after all of the above were eliminated did directly listing each partition's actual /boot contents (ls -la /boot/vmlinuz* /boot/initrd*)
reveal the real, simple mismatch.


DOCUMENTATION / TOOLING GAPS THIS EXPOSES ------------------------------------------

- GRUB's own error message is misleading in context. "file
'/vmlinuz' not found" is accurate but gives no hint that the issue
is a path convention difference between distributions, not a
missing or corrupt file. Nothing in the message or in GRUB's
manual flags this distro-to-distro inconsistency.

- The Debian-family root-level /vmlinuz symlink convention is not
something other distributions replicate or warn about, and it is
easy to internalize it as "how GRUB entries work" if Debian/Devuan
is the first or main system someone writes manual entries for.

- No mainstream distribution's documentation cross-references this
explicitly (i.e. "if writing manual GRUB entries for distro X,
don't assume the Debian-style root-level vmlinuz/initrd paths").
It is scattered, implicit knowledge rather than documented
anywhere central.

- Generic multi-boot / custom GRUB entry tutorials online
overwhelmingly use Debian/Ubuntu-derived examples, which quietly
reinforces the bare /vmlinuz pattern as if it were universal.


Two separate skill levels are involved:

DIAGNOSING IT (the process this whole exchange walked through -
systematically ruling out UUIDs, modules, filesystem flags, EFI
bootloader ownership, and only then inspecting each partition's real
/boot contents) is beyond what a typical desktop Linux user would be
expected to do unassisted. It requires comfort with lsblk, tune2fs,
efibootmgr, manual mounting of foreign partitions read-only, and
interpreting GRUB's rescue-mode command line - this is
intermediate-to-advanced sysadmin territory, not something covered in
beginner distro documentation.

APPLYING THE FIX once known is straightforward and within reach of any
user already comfortable manually editing /etc/grub.d/40_custom in the
first place: it is a one-line-per-entry change (adding a /boot/ prefix
or the correct versioned filename) followed by a standard grub2-mkconfig/update-grub regeneration.

In short: writing custom multi-distro GRUB entries at all already puts
someone outside "average user" territory (most distros generate
correct boot entries automatically via os-prober or their own
installer without any manual intervention). For anyone already doing
this manually across several distributions on shared hardware, this
particular pitfall - silently mixing Debian-style bare /vmlinuz paths
into entries for non-Debian systems - is common enough, and the fix
simple enough, that it's worth checking first, before working through
the fuller diagnostic chain above.











--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-09-24 16:49, bad sector wrote:

At best it's a tool made for developers (tail wagging the dog) and
doesn't even resemble a user-oriented boot loader. If all I want in my
menu for (currently) 6 onboard OSes is the partition number and the
distro name ending with a UEFI boot

11 Artix
12 Devuan
13 Slackware
14 Tumbleweed
15 Debian
16 Leap
UEFI

then the only way to do that is with a /etc/grub.d/40_Custom file but
those directives need to be hand-edited after every update in any of the systems. Thousands of users including myself have been asking for STANDARDIZED vmlinuz and initrd links pointing to the latest kernel!!! openSuse have listened and do this but most others do not. This would
make it possible to have a simplified custom menu that uses the links
and does not have to be edited each time.

As it is, the only alternative is some cron that runs the installed
systems and verifies existing or creates standard links which can then
be used in an /etc/grub.d/40_Custom file.

I use rEFInd as the bootloader on all of my UEFI systems. Works great.
If it worked on my legacy systems, I'd replace grub2 in a heartbeat.

TJ
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-09-25 13:59, Richard Kettlewell wrote:

I have no idea what this is supposed to mean. One Linux per computer has
been perfectly adequate for me (and I suspect almost all other Linux
users) for 30 years. At any rate whatever the reasons for your choices,
the configuration is distant outlier compared to the rest of the world.

But of course there are always exceptions. My computers all have at
least 2 Mageia installs on them, and half of them have 3.

One desktop and one laptop each have systems used for production, and
the rest are used for testing purposes. As an active member of the
Mageia Quality Assurance team, I test updates to Mageia 10 before they
are sent out into the wild.

For the last three months I've also been testing updates to Mageia 9.
That goes EOL today, so I will change them to Mageia 10 soon. Later,
after some more development, they will become "Cauldron" installs,
testing our development version under daily use.

TJ
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 9/30/26 8:11 AM, TJ wrote:

On 2026-09-25 13:59, Richard Kettlewell wrote:

I have no idea what this is supposed to mean. One Linux per computer has
been perfectly adequate for me (and I suspect almost all other Linux
users) for 30 years. At any rate whatever the reasons for your choices,
the configuration is distant outlier compared to the rest of the world.

But of course there are always exceptions. My computers all have at
least 2 Mageia installs on them, and half of them have 3.

One desktop and one laptop each have systems used for production, and
the rest are used for testing purposes. As an active member of the
Mageia Quality Assurance team, I test updates to Mageia 10 before they
are sent out into the wild.

For the last three months I've also been testing updates to Mageia 9.
That goes EOL today, so I will change them to Mageia 10 soon. Later,
after some more development, they will become "Cauldron" installs,
testing our development version under daily use.

TJ

Nowadays with all the zukerboogers and gatekeepers jockeying for
monopoly and total $tranglehold on humanity we never know which OS gets 'compromized' next so as far as I'm concerned using a single whatever is imprudence cubed.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-Sep-30 8:11 AM, TJ wrote:

On 2026-09-25 13:59, Richard Kettlewell wrote:

I have no idea what this is supposed to mean. One Linux per computer has
been perfectly adequate for me (and I suspect almost all other Linux
users) for 30 years. At any rate whatever the reasons for your choices,
the configuration is distant outlier compared to the rest of the world.

But of course there are always exceptions. My computers all have at
least 2 Mageia installs on them, and half of them have 3.

One desktop and one laptop each have systems used for production, and
the rest are used for testing purposes. As an active member of the
Mageia Quality Assurance team, I test updates to Mageia 10 before they
are sent out into the wild.

For the last three months I've also been testing updates to Mageia 9.
That goes EOL today, so I will change them to Mageia 10 soon. Later,
after some more development, they will become "Cauldron" installs,
testing our development version under daily use.

Haha, haven't seen the 'Cauldron' descriptor in like decades! I started
with Slackware then moved to suse (4.4 or so) which had just forked from
it. Both have been on my machines ever since but now new suse installs
deploy only systemd-boot (don't know where this is going to end). On the hardware front I fought grub2 as long as I could but caved in when
buying new iron inevitably meant UEFI for my remaining years. So now
with an investment of hours and hours I got a decent menu out of grub2,
I'll keep rEFInd in my notes for a rainy day...


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Wed, 30 Sep 2026 19:41:37 -0400, bad sector wrote:

So now with an investment of hours and hours I got a decent menu out
of grub2,

You could have written a script to automate it for you.

You *do* know those files in /etc/grub.d are nothing more than shell
scripts, donrCOt you?
--- Synchronet 3.22a-Linux NewsLink 1.2