Grub cannot find the other linux os installed on the hard drive

[pebcak]

@dalto

it looks like you are running rawhide

Yes, it’s Rawhide.

@dalto

Did you use automatic partitioning or manual?

Manual with two partitions only ESP and root (EXT4).

My guess is that perhaps because boot directory is under root and not on a separate partition then Arch’s os-prober is capable of detecting it. That’s why I mentioned it before in case that would indeed make a difference.

[dalto]

@pebcak

Manual with two partitions only ESP and root (EXT4).

Yes, since this is highly atypical for a Fedora install, that is probably why it is working.

[pebcak]

Having experienced the same issue as OP once before, I think I made the installation specifically “simple” like this to see if I could get the dualboot working using Arch’s grub.
It does work so I am not complaining

[dalto]

@petsam

Fedora does not use normal upstream grub, but a seriously modified, using a different method (Fedora patent, a combination of grub and systemd-boot type of configuration, if I could give a short description), which cannot provide data searched by other distros grub/os-prober.

I can’t think of any reason that Fedoras implementation of the BLS would cause this.

[culcal]

Yes, since this is highly atypical for a Fedora install, that is probably why it is working.

Haha, fedora likes to do things differently than many other distros.

In many cases I don’t think it makes a difference, but fedora just chooses to be different.
It is a fantastic distro. And compared to ubuntu and linux mint, I think fedora performs much, much better.

So far I don’t really think I can tell the difference between fedora and EOS. It seems that they are just as fast and smooth as each other.

I have a small feeling that on the fedora there are some things that look better, e.g. websites, and some applications. But it’s just a feeling. I haven’t tested it long enough to say for sure.

I have plenty of space on my hard drive to do one more EOS installation to test if another partitioning scheme will work.

I think I will be using EOS as my daily driver in the future. I have long been looking for a distro that is easy to do a minimal installation of. On fedora you have to manually install hardware suport and all xorg utils when the installation is complete.

With EOS, you can choose all these things in calamaras. It’s really nice.

[dalto]

@culcal

I have plenty of space on my hard drive to do one more EOS installation to test if another partitioning scheme will work.

Two things.

1. Changing the partition scheme on EOS won’t make any difference. You would need to change the partition scheme on Fedora.
2. I wouldn’t change any partitioning. Grub/os-prober detection is a broken mess to begin with. I think you are honestly better off adding manual boot menu entries.

[petsam]

@dalto

I can’t think of any reason

We may be talking about different things.
I am talking about this, and I would enjoy a POV that would suggest this new Fedora style is compatible with normal GRUB implementations. Here’s part of the paper:

By default the implementation looks for the “loader/entries” subdirectory relative to ($boot). That means that in Fedora’s will normally be in /boot/loader/entries/.

wiki/Changes/BootLoaderSpecByDefault

Detailed Description

The Boot Loader Specification (BLS) defines a scheme and file format to manage boot loader configuration for each boot option in a drop-in directory, without the need to manipulate bootloader configuration files. Directories of individual drop-in configuration files are standard for many purposes on Linux nowadays, so the goal is to also extend this concept for boot menu entries. This proposal does not include full implementation of that specification, which is not widely adopted, but merely refers loosely to the format and general layout of the configuration files.

This is especially important in Fedora because the same bootloader is not used in all architectures. GRUB 2 is used in most of them, but there are others such as zipl for s390x and Petitboot for ppc64le. Not all bootloaders have the same configuration file format, so there is a need for an indirection level and per bootloader specific logic to edit these configuration files, when adding or removing a boot entry.

The current component that does this work is grubby, that has support for all the different bootloader configuration file formats and manipulates them on kernel installation or uninstallation. Besides manipulating the bootloader configuration files, grubby also does other things like running dracut to create an initial ramdisk image.

Fedora already has a lot of infrastructure in place to not require modifying bootloader configuration files for boot menu entries. Fedora’s grub2 includes a “blscfg” command to load and build menus from configuration files, which the Fedora kernel packages provide, and the kernel-install script can do any additional task that is currently done by grubby. The kernel-install script has a pluggable design that uses a drop-in directory for scripts to extend its functionality, so if needed, any bootloader specific logic can be implemented as kernel-install scripts. With this setup the core bootloader configuration files can be static and not modified after installation.

The missing piece was the lack of support in our bootloaders, but our default bootloaders now have support to parse BLS-like configuration files now. So we can default to install BLS files on kernel installation and drop grubby.

Differences from BootLoaderSpec

There are a couple of differences between this implementation, the original Boot Loader Specification proposal, and Matthew Garrett’s proposed update:

• By default the implementation looks for the “loader/entries” subdirectory relative to ($boot). That means that in Fedora’s will normally be in /boot/loader/entries/. But on grub2, the subdirectory is configurable by placing a grubenv file at ($boot)/EFI/fedora/grubenv for EFI or ($boot)/grub2/grubenv for BIOS with a variable set named “blsdir”, which specifies a subdirectory relative to ($boot).
• Only the device grub is loaded from is searched for config files.
• On other machines, only the grub root device is searched
• The following keywords have not currently been implemented: multiboot, module, version, machine-id, filesystem, chainload, efi, devicetree. If encountered, they are ignored.
• On all platforms, the entries are sorted by the BLS filename using the rpmvercmp() version comparison function.
• multiple initrd entries are allowed, and will be processed in order
• On grub platforms, the following grub-specific keywords have been implemented:
  • the BLS filename is also used for menuentry’s --id parameter, so you can use it in saved_entry
  • grub_hotkey - same as grub’s “–hotkey” menuentry parameter
  • grub_users - same as grub’s “–users” menuentry parameter; used for password protection
  • grub_class - same as grub’s “–class” menuentry paramter
  • grub_arg - passes extra arguments to menuentry

So I suppose the OP error message looking for /boot/, is about the entries, and not the kernel image, or something else.

[dalto]

@petsam

We may be talking about different things.

Perhaps? We are both talking about the same BLS implementation in Fedora.

However, my point is, the Fedora grub implementation should have no impact either way on the Arch os-prober/grub ability to detect it. The kernel and initrd are still in standard locations. The grubs aren’t interacting with each other.

[culcal]

Two things.

1. Changing the partition scheme on EOS won’t make any difference. You would need to change the partition scheme on Fedora.
2. I wouldn’t change any partitioning. Grub/os-prober detection is a broken mess to begin with. I think you are honestly better off adding manual boot menu entries.

Ok, I do as you suggest.

I’ll report back with how it went. It’s probably going to take me some time. I just have to get to the bottom of what exactly I have to write on these manual boot options, in /etc/grub.d/40_custom

And whether I should make an entry for the boot options it already shows. Or only those EOS grub does not show.

It would be nice if you or someone else has time to explain it to me. I understand, of course, that it is time-consuming with all the explanations.
It seems like the arch wiki isn’t specific, or I don’t understand the explanation there.

[dalto]

@culcal

Or only those EOS grub does not show.

It depends, if you want to disable os-prober, you would need to add entries for all the other OSes(i.e. on EOS you would need to add Windows and Fedora). If you are going to leave os-prober enabled, you only need to add the missing ones.

@culcal

It would be nice if you or someone else has time to explain it to me. I understand, of course, that it is time-consuming with all the explanations.

There is a bunch of different ways to do it is part of the problem. You need to start by deciding which approach you want.

[culcal]

It depends, if you want to disable os-prober, you would need to add entries for all the other OSes(i.e. on EOS you would need to add Windows and Fedora). If you are going to leave os-prober enabled, you only need to add the missing ones.

Thanks, that was a very specific and good explanation.

One more question:
do I have to manually change /etc/grub.d/40_custom when a new kernel update comes?

[dalto]

@culcal

do I have to manually change /etc/grub.d/40_custom when a new kernel update comes?

From Fedora->EOS, no, because the kernel names don’t change.

From EOS->Fedora, yes. However, you can avoid that by chainloading Fedora’s grub. This is also simpler to implement.

[petsam]

@petsam

Only the device grub is loaded from is searched for config files.

@petsam

a variable set named “blsdir”, which specifies a subdirectory relative to ($boot).

@petsam

The following keywords have not currently been implemented: multiboot, module, version, machine-id, filesystem, chainload, efi, devicetree. If encountered, they are ignored.

@petsam

not require modifying bootloader configuration files for boot menu entries.

@petsam

Fedora’s grub2 includes a “blscfg” command to load and build menus from configuration files, which the Fedora kernel packages provide,

IIUC the situation, using EnOS grub to boot Fedora can be done with custom entry/entries in custom.cfg. But… in the long run, additional grub parameters or other (maybe insignificant) modifications to Fedora’s grub(2), will have to be added again in EnOS grub custom.cfg, whenever they happen, as the Fedora model does not ever modify grub.cfg (native entries). It’s created only once, with no parameters inline menu entries (in grub.cfg), as they are added on-the-fly by their custom grub command (blscfg). This defies the original reason to use EnOS grub to boot all systems, without having to boot the other systems, or do manual editing.

If I were to handle such a situation, I would

• BIOS system
  • use Fedora’s grub to boot other systems/EnOS , with custom.cfg, using configfile grub command
  • or, in case more than one disk were available, install grub from each OS on a different drive, and use BIOS quick boot menu to select OS.
• UEFI system
  • Use UEFI Quick boot menu, to select OS

So, the conclusion is again in agreement with @dalto

@dalto

There is a bunch of different ways to do it is part of the problem. You need to start by deciding which approach you want.

[petsam]

@dalto

you can avoid that by chainloading Fedora’s grub.

I think this is useless, as the active grub will still be from EnOS, and as described above, it misses Fedora modifications (extra command, env-vars, etc.)

[dalto]

@petsam

I think this is useless, as the active grub will still be from EnOS, and as described above, it misses Fedora modifications (extra command, env-vars, etc.)

Eh? In this case it would actually be launching Fedora’s grub so I am not following…

[petsam]

@dalto

it would actually be launching Fedora’s grub

Ehm, I thought you meant configfile… I only ever used chainloading WinOS systems. If chainloading Fedora is possible, then you are right, of course. Sorry!

---

To my excuse, if any, chainloading refers to partitions, where saying grub, I misunderstood.

[pebcak]

With the risk of going OT but a quick question: is this new method implemented already in a standard installation of Fedora or one needs to:

grub2-switch-to-blscfg

?

https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#How_To_Test

[petsam]

@pebcak

standard installation of Fedora

The documentation says the new way would be the default with new installations, so it depends when you installed Fedora. Don’t ask me which date it started .

[dalto]

@pebcak

With the risk of going OT but a quick question: is this new method implemented already in a standard installation of Fedora or one needs to:

The BLS config has been the default for a long time now(years). You don’t need to run any commands.

[pebcak]

Alright, good to know that! Thank you!