Update-grub script listing not consistent with GRUB menu

Support
1

Some context :
This System is BIOS based only , has several HDDs and SSDs with multiple distros but the this specific device has the Manjaro GRUB “master” bootblock.

( In an old tread () I though that the problem were related to the btrfs fylesystem and some Open Suse TumbleWeed UEFI boot detail.
I got manual fix solution and moved on … )

Although recently caling update-grub shows :

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-7.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-7.1-x86_64.img
Found linux image: /boot/vmlinuz-6.18-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.18-x86_64.img
Found linux image: /boot/vmlinuz-6.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.1-x86_64.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
mount: /var/lib/os-prober/mount: fsconfig() failed: No such file or directory.
       dmesg(1) may have more information after failed mount system call.
Found Windows 10 on /dev/sdb1
Found antiX (23) on /dev/sdc1
Found Artix Linux (rolling) on /dev/sdc10
Found AlmaLinux 9.5 (Teal Serval) on /dev/sdc12
Found openSUSE Tumbleweed on /dev/sdc13
Found Void Linux on /dev/sdc14
Found Mabox Linux (26.08) on /dev/sdc15
Found NixOS 25.11 (Xantusia) (25.11) on /dev/sdc17
Found Arch Linux (rolling) on /dev/sdc2
Found Debian GNU/Linux 13 (trixie) on /dev/sdc3
Found MX 25.2 Infinity (25.2) on /dev/sdc5
Found Oracle Linux Server 9.5 on /dev/sdc6
Found Windows 8 on /dev/sdf1
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
done

Most of the entries are working except NixOs , Void and OpenSuse
In the final grub.cfg , those entries are missing…

Although I do have 2 more partitions with BSDs but those have the zfs filesystem.
Nonetheless I know that OpenSuse is in a btrfs filesystem, all the others are in ext4 … )

So why is not os probe writing the listed enties in grub.cfg ?

Mod edit:- Please use Quote boxes only for quoted text – ALL code, commands or command output should be treated as pre-formatted text, and entered as such according to forum guidelines. See the following Mini-HowTo for clarification. :point_down:

[Mini-HowTo] Present code or command output

Note: Grave accent (or, backtick) characters are used. :eyes:

For inline code or to show a single command:

  • please follow this simple example: code here.

For multi-line command output:

  • place text beween two rows of three (```) backtick characters to form a scrollable text box, or …
  • use the </> button in the Compose window to achieve the same result.

The empty row between these rows of backtick characters is where to paste any multi-line command output (such as inxi).

An example of a pre-formatted text enclosure:

What is a Quark?

A. In Physics, an elementary particle and fundamental constituent of matter. 
B. A character from the Star Trek: "Deep Space Nine" television series.
C. A soft, creamy, usually unsalted cheese traditional to central Europe.
2

Even though you state

It appears that it is not

The update-grub script is - as I recall a copy of the script used by Ubuntu.

If you really want to run a BIOS/MBR system - you should disable EFI in the system’s firmware.

3

I know before hand that I am using “BIOS only” to boot Manjaro.
As far as I know in the BIOS I am not able to fully disable EFI …

It is exactly the opposite , I am able to disable in the BIOS old MBR / BIOS boot but not the opposite.
As seen in the os-probe list I have several HDDs with their own boot details.
My question still remains : how is os-proble not writing the grub.cfg with the correct listing ?
Namely NixOs and Void , as those are with ext4 partitions ?

4

Most likely because they are efi installations.

A bios/mbr grub cannot and will not include efi/gpt installations.

5

As a semi-offtopic: with 14 OSes, your life will probably be easier with EFI and/or Virtual machines.

6

However, the reverse is possible. A UEFI BIOS can support booting an OS that uses MBR – even on a GPT volume. Perhaps you could perform some research on this to understand how it’s achieved. To me, this seems a more likely scenario, though with so little information provided it’s difficult to confirm or deny much.

As @Teo suggests, multi-booting so many disparate operating systems is logically much easier with a UEFI-capable system; that said, there are potentially many pitfalls as well, depending on the requirements for each OS.

I currently multi-boot Manjaro, Debian, FreeBSD, MacOS and Windows – all boot strictly using UEFI – in comparison, managing these in a strictly BIOS/MBR system or in a UEFI system with a combination of technologies, i imagine would be a virtual nightmare.

This, however, doesn’t help your situation. What might help, for a start, is to provide your system information. :point_down:

[Mini-HowTo] Provide System Information

Basic details provided by *-fetch type apps might give enough information for someone wishing to buy a computer, however, for Support purposes it’s best to ask your system directly.

Output of the inxi command will generate more useful and detailed information for those who may wish to help:

Suggested inxi command (use either):
inxi -zv8 (short-form)
inxi --filter --verbosity=8 (long-form)

Command output should be presented as pre-formatted text in accordance with forum guidelines. :eyes:

Running inxi within a chroot environment

  • Add --color=0 to the long-form command, or…
  • Change the short-form command to inxi -zv8c0

Your privacy is respected

[Mini-HowTo] Present code or command output

Note: Grave accent (or, backtick) characters are used. :eyes:

For inline code or to show a single command:

  • please follow this simple example: code here.

For multi-line command output:

  • place text beween two rows of three (```) backtick characters to form a scrollable text box, or …
  • use the </> button in the Compose window to achieve the same result.

The empty row between these rows of backtick characters is where to paste any multi-line command output (such as inxi).

An example of a pre-formatted text enclosure:

What is a Quark?

A. In Physics, an elementary particle and fundamental constituent of matter. 
B. A character from the Star Trek: "Deep Space Nine" television series.
C. A soft, creamy, usually unsalted cheese traditional to central Europe.
8

Have you actually checked the /boot/grub/grub.cfg file in your Manjaro system or are you just implying it because they are not in the grub menu that is presented to you (as the title of your post says).

I don’t know if that is possible, but maybe your grub is not from Manjaro. When you install grub to the EFI or the MBR, the installer adds the path from where it has to read the grub.cfg file. If you install grub from Manjaro, it will look your Manjaro’s grub.cfg file in Manjaro partition, but if you install grub, for example, from ArchLinux, it will look for the grub.cfg file in the Arch Linux’s partition (/dev/sdc2).
Despite of that you can always run update-grub (or the corresponding command) in the different distros and they will update their local grub.cfg, even if only one of them will be actually read by the boot loader.

The thing is, is the grub menu following your Manjaro’s grub.cfg file? If not, then it is reading a different file from other distro. If it is, then the question is why is not writing the correct data to the grub.cfg file? According to your output, update-grub finds all your distros and intends to write them to the configuration file.

If my memory does not fail me (it is not what it used to be :grinning_face:), in the case of a BIOS/UEFI mismatch, the distro would not be even in the output of update-grub/os-prober.

9

Good point actually. The install-grub should have been last run on the manjaro system.
If not, update actually does not update anything.
In a bios environment, only one system is commanding the parade. Be sure it is the manjaro.

But i still think it is a mix of bios and efi systems.

10

Hope I got your intention right

Case 1 :

UEFI booting an OS on a MBR partition is possible. UEFI specs supports both MBR and GPT partitions. This is no problem in Linux, Windows refuses to boot.

Case 2 :

MBR booting OS on a GPT partition is possible, but that’s CSM not UEFI.

11

And if grub is used as the boot loader — which is what most GNU/Linux distributions will use by default — then it requires an unformatted partition of type bios_grub, marked with the boot flag, and roughly 2 MiB in size. Without it, grub will overwrite partition boundaries.

12

@libertypo

CSM is a subset of UEFI.

In order to boot as “MBR” (assuming CSM is enabled) on a disk with a GUID Partition Table (GPT) a “protective MBR” is employed and a “hybrid MBR” setup is created, much as @Aragorn described.

The OP is clearly using the CSM capability of their UEFI/BIOS for the majority of their installations; one only needs to count the partitions. :wink:

Regardless, certainly more information is needed.

That said, the issue here is that while support may be provided to help with the Manjaro installation, the other 13 operating systems I’m afraid are the OP’s responsibility.

13

inxi -Dxxx would confirm if drives are using mbr or gpt partition scheme

and this should show menuentry options in GRUB:

sudo grep ^menuentry /boot/grub/grub.cfg |cut -d "'" -f2
14

As already mentioned, a pure UEFI solution is more convenient for the OP-s trouble.

15

While this is true – and that is not disputed – I’d guess that with 14 operating systems in play it’s unlikely that the OP will consider changing the status quo;

especially not if their reason for having so many OS installed is anything other than “Because I can”.

16

No, I suppose not

If this is the motivation, it is a tad inefficient(for me at least). Unless the OP has lots of time of his disposal

17

I multi-boot several OS (each on their own disk) and occasionally management can be a chore, but with 14, it’s difficult to imagine a use case. If little else, I commend their enthusiasm.

18

Sorry for the late reply …

To clarify I do have several devices each with own bootloader whereas I select them in the UEFI / BIOS option which one I need to boot when doing a clean install …

My “problem” at this point is that probe-os lists / shows some distros but it does not put them in the grub.cfg …

calling grep ^menuentry /boot/grub/grub.cfg | cut -d "'" -f2
I have :

Manjaro Linux
Windows 10 (on /dev/sdb1)
antiX (23) (on /dev/sdc1)
Artix Linux (rolling) (on /dev/sdc10)
AlmaLinux 9.5 (Teal Serval) (on /dev/sdc12)
Void Linux (on /dev/sdc14)
Mabox Linux (26.08) (on /dev/sdc15)
Arch Linux (rolling) (on /dev/sdc2)
Debian GNU/Linux 13 (trixie) (on /dev/sdc3)
MX 25.2 Infinity (25.2) (on /dev/sdc5)
Oracle Linux Server 9.5 (on /dev/sdc6)
Windows 8 (on /dev/sdf1)

So I am missing :
OpenSuse ( btrfs filesystem , has its own grub )
Void ( unknown at this moment if it is booting via EUFI or not but it is using ext4 )
NixOs ( unknown at this moment if it is booting via EUFI or not but it is using ext4 )

Also replying to the commentl about the correct grub.cfg I can confirm the grub.cfg distro file as I double checked the grub.cfg from the correct distro file both from outside ( chroot) Manjaro as after booting the system with the correct HDD .

I do understand the comment about the UEFI boot detail ( but still have not confirmed it yet) ..

Although if I boot from the OpenSuse Grub ( via BIOS and selecting a different hdd) I am able to boot Void without any trouble .

Also to clarify I usually write the grub2 bootblock manually / forcefully from Manjaro whenever some of the distros rewrite the bootblock with their own grub…

The "inxi -Dxx -S -C -z " details :

System:
  Kernel: 7.2.0-rc7-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 16.1.1
  Desktop: Xfce v: 4.20.2 tk: Gtk v: 3.24.52 wm: xfwm4 dm: SDDM
    Distro: Manjaro base: Arch Linux

CPU:
  Info: 18-core model: Intel Xeon E5-2697 v4 bits: 64 type: MT MCP
    arch: Broadwell rev: 1 cache: L1: 1.1 MiB L2: 4.5 MiB L3: 45 MiB
  Speed (MHz): avg: 1200 min/max: 1200/3600 cores: 1: 1200 2: 1200 3: 1200
    4: 1200 5: 1200 6: 1200 7: 1200 8: 1200 9: 1200 10: 1200 11: 1200 12: 1200
    13: 1200 14: 1200 15: 1200 16: 1200 17: 1200 18: 1200 19: 1200 20: 1200
    21: 1200 22: 1200 23: 1200 24: 1200 25: 1200 26: 1200 27: 1200 28: 1200
    29: 1200 30: 1200 31: 1200 32: 1200 33: 1200 34: 1200 35: 1200 36: 1200
    bogomips: 165229
  Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx

Drives:
  Local Storage: total: 4.3 TiB used: 100.11 GiB (2.3%)
  ID-1: /dev/nvme0n1 vendor: Cusu model: CV7000 1TB size: 953.87 GiB
    speed: 63.2 Gb/s lanes: 4 serial: <filter> temp: 29.9 C
  ID-2: /dev/sda model: SSD size: 119.24 GiB speed: 6.0 Gb/s
    serial: <filter>
  ID-3: /dev/sdb vendor: OCZ model: VERTEX2 size: 55.9 GiB speed: 3.0 Gb/s
    serial: <filter>
  ID-4: /dev/sdc vendor: Western Digital model: WD10EZRX-00DC0B0
    size: 931.51 GiB speed: 6.0 Gb/s serial: <filter>
  ID-5: /dev/sdd vendor: Toshiba model: Q300 size: 447.13 GiB
    speed: 6.0 Gb/s serial: <filter>
  ID-6: /dev/sde vendor: Samsung model: HD502HJ size: 465.76 GiB
    speed: 3.0 Gb/s serial: <filter>
  ID-7: /dev/sdf vendor: Kingston model: SKC600512G size: 476.94 GiB
    speed: 6.0 Gb/s serial: <filter>
  ID-8: /dev/sdg vendor: XrayDisk model: 1TB SSD size: 953.87 GiB
    speed: 6.0 Gb/s serial: <filter>

Any further comments ?

19

This does indeed suggest that some of your systems were installed in native UEFI mode and others in legacy BIOS emulation mode.

20

It pretty much confirms it for me; @markmarques if the OpenSuse GRUB can boot VOID but not the others, this does indicate that you need to reinstall those Legacy-installed distros in (U)EFI mode.

21 

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

Will tell you if the os it is run on is in bios or efi mode. Run it from manjaro, run it from suse and you will know.