So ...
It's a bug in the grub installer?

Best,

A.

Installed grub version is 2.06-8

Having no boot options generates panic for many folks, even though fixing it is usually relatively easy.

This has been so since the Beowulf release:

Could this be a bug?

The grub installer seems to ignore the new su behaviour as described in https://files.devuan.org/devuan_beowulf … _notes.txt.

Not running an efi box, so can't say much more about this.

Best,

A.

The "missing grub binaries" were just a path issue, had to do "su -" to get proper roots path, sudo and su aren't getting full path as usually seen, possibly intentional?

In the 2/2023 Daedalus /etc/default/grub "GRUB_DISABLE_OS_PROBER=false" line is simply commented out .

MiyoLinux wrote:

    ... open and edit the following file...
    /etc/default/grub
    ...and add the following line...

    GRUB_DISABLE_OS_PROBER=false

    Save and close the file, then open a terminal and run an...

    update-grub

Ran into same issue, installed Daedalus from the live iso from Feb 2023...Grub entries for windows, Mint LMDE5 and Mageia disappeared upon Daedalus Kernel updates (obviously works somehow), although I initially booted Daedalus by running install-grub in Mageia, which has no issues with os-prober and dutifully created new entries for me.
The initial "grub install" in the Devuan live installer didn't actually install grub, which was more or less expected from the installers text.

LMDE also had no issues finding and creating entries for Daedalus. (in fact, both LDME5 and Mageia create UEFI boot menu entries as well as grub entries, including for Devuan)

poking around, the grub installation "appears" broken, as the usual grub binaries and scripts are mia-- i.e no "grub-install" "grub-mkconfig" etc.
I supposes its also possible they decided to rename everything without telling anyone, will have to figure out whats actually installed.
(I had the same gripe with grub2 that everyone had with systemd--- way too much code for a simple task. IIRC grub2 is larger that msdos 5)

Also tried grub2-install and other name variants, and needless to say grub-configurator didnt work due to no grub-install or grub-mkconfig.

Perhaps we should point out to the grub devs that grub also has "attack vector" issues, esp as it can boot non-signed images.
Anything that operates on bare metal has ~same potential issues.
 
Perhaps Poettering can contribute a bootloader extension to systemd that Microsoft will approve of? Wouldn't that be great ;-/

Have uncommented the disable comment for osprober in /etc/default/grub will try that edit prior to install this time to see if it works.

https://www.gnu.org/software/grub/manua … figuration

It is disabled by default since automatic and silent execution of os-prober, and creating boot entries based on that data, is a potential attack vector.

It seems to me that there's a simple solution that will solve this problem -- ask the user to confirm that the information obtained from os-prober is correct. Or write the info to the appropriate config file, but commented out, along with a comment above it explaining why it's commented out and the importance of verifying that the information is correct before uncommenting it.

The only systems that are using version 2.06 are Devuan Ceres and Debian Sid. Everything else is using a lower version number (for now). So, it shouldn't affect you as far as I can tell.

Thank-you. I need to upgrade that system soon, and having the multi-boot menu break is a problem that I don't need.

What about a Jessie system that was upgraded to Stretch? Would the upgrade remove the working multi-boot menu?

I just checked package versions of both Devuan and Debian.

The only systems that are using version 2.06 are Devuan Ceres and Debian Sid. Everything else is using a lower version number (for now). So, it shouldn't affect you as far as I can tell.

Just tried it on my Chimaera box (Arch and Beowulf in parallel installations): Adding that line to /etc/default/grub does not make any difference on efi installations.

rolfie

Works fine on my efi rig running either Daedalus or Ceres. Is it even an issue in Chimaera?

My experience is that os-prober never worked on efi systems. Valid for Stretch/ASCII, Buster/Beowulf, Bullseye/Chimaera.

What about a Jessie system that was upgraded to Stretch? Would the upgrade remove the working multi-boot menu?

Probably better off using grub2 to chainload other linux/unix OS's rather than rely on os-prober.

https://www.gnu.org/software/grub/manua … ading.html

https://wiki.debian.org/DualBoot/Windows10

https://wiki.gentoo.org/wiki/GRUB2/Chainloading

That may be the ticket. That's what I had to do when adding OpenBSD or NetBSD.

Just tried it on my Chimaera box (Arch and Beowulf in parallel installations): Adding that line to /etc/default/grub does not make any difference on efi installations.

rolfie

I don't use EFI.

I wonder why it doesn't work?

https://www.gnu.org/software/grub/manua … ading.html

https://wiki.debian.org/DualBoot/Windows10

https://wiki.gentoo.org/wiki/GRUB2/Chainloading

rolfie