Linux Multi-boot no entry written for system using BTRFS

[benbullard79]

OpenMandriva version: Cooker and ROME Describe the bug: On a multi-boot computer with several OpenMandriva operating systems. User installs a system using btrfs. Then user installs a second system also using btrfs. The first system using btrfs will not have a boot entry created. Steps to reproduce: On a multi-boot computer with several OpenMandriva operating systems. User installs a system using btrfs. The user installs a second system also using btrfs. The first system using btrfs will not have a boot entry created. Observed behavior: The first system using btrfs will not have a boot entry created. Expected behavior: That all OMLx systems are not only recognized but have entries written to the grub.cfg file on the boot-loader system. Additional comment: I use this type of setup to test thing in OMLx on hw. Logs and screenshots if relevant Here is an example of what os-prober sees when one of the operating systems is using btrfs:

$ sudo os-prober
[sudo] password for ben79: 
/dev/nvme0n1p3:OpenMandriva Lx 23.06 (23.06):OpenMandrivaLx:linux
/dev/nvme0n1p7:OpenMandriva Lx 23.90 (Nickel) Cooker:OpenMandriva:linux:btrfs:UUID=f74ee8ae-4aa4-423b-9ad0-7fe532a76acd:subvol=@root
/dev/nvme0n1p9:OpenMandriva Lx 23.90 (23.90):OpenMandrivaLx1:linux

The /dev/nvme0n1p7 system is using btrfs.

Then it look like update-grub2 is writing entries in grub.cfg for all 4 systems present:

$ sudo update-grub2
Generating grub configuration file ...
Found theme: /boot/grub2/themes/OpenMandriva/theme.txt
Found background: /boot/grub2/themes/OpenMandriva/background.png
Found linux image: /boot/vmlinuz-6.3.5-desktop-3omv2390
Found initrd image: /boot/initrd-6.3.5-desktop-3omv2390.img
fgrep: warning: fgrep is obsolescent; using grep -F
Found linux image: /boot/vmlinuz-6.2.7-desktop-1omv2390
Found initrd image: /boot/initrd-6.2.7-desktop-1omv2390.img
fgrep: warning: fgrep is obsolescent; using grep -F
Found memtest image: /boot/memtest.bin
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.
Found OpenMandriva Lx 23.06 (23.06) on /dev/nvme0n1p3
Found OpenMandriva Lx 23.90 (Nickel) Cooker on /dev/nvme0n1p7
Found OpenMandriva Lx 23.90 (23.90) on /dev/nvme0n1p9
Adding boot menu entry for UEFI Firmware Settings ...
Adding boot menu entry for EFI firmware configuration
done

But in reality no entries are written for the system on /dev/nvme0n1p7 that is using btrfs.

grub.cfg.txt

This is a bit complicated of an issue. I do my best to describe it, if I have failed in any way please ask and I'll try to do better. Also I realize that this is not a common scenario but we have had a few users complain about this.

I believe these bug reports are relevant (Thanks [saber716rus):

https://github.com/OpenMandrivaAssociation/distribution/issues/2902

https://github.com/calamares/calamares/issues/2130

https://github.com/calamares/calamares/issues/1580

[benbullard79]

Currently the only work around I have for this is to copy the entries from the missing btrfs system to the boot-loader systems grub.cfg. I was hoping to be able to use chainloading but have not been able to figure out how to do so.

I have tried these:

menuentry "Chainload to OpenMandriva Lx 23.90 (23.90) in /dev/nvme0n1p7" {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root f74ee8ae-4aa4-423b-9ad0-7fe532a76acd
        chainloader +1
}

That results in "No valid efi file found". So I also tried:

chainloader /boot/efi/EFI/'OpenMandriva_Lx_[GRUB]'/grubx64.efi

Same error. I do not know if I am on right track with this but it seems like this just needs a way to tell it where the grubx64.efi file is.

[benbullard79]

Another way to describe this issue is that if user on Linux multi-boot computer installs OMLx with btrfs they have to use the system with btrfs as the boot-loader system. The other systems will not print entries to grub.cfg for the system using btrfs. In my case with more than one system using btrfs then you will be in a situation requiring the work around which you then have to redo for every new kernel.

[saber716rus]

first, you need to make calamaris split into sub-volumes, or write a script to split it into 2 sub-volumes and then register the mount point / on the sub-volume in fstab and bind the name @ to it. With a hamster (home), similar to @home and /home

I raised the problem in the calamaris Git a long time ago, but there is an indirect solution through configs, but this is not it. There should be a markup on the sub-volumes. https://wiki.archlinux.org/title/Btrfs

arch has a very good wiki. It describes in detail and I think a temporary solution. This is to add a script, if a btrfs partition is detected with a mount point '/', then you can use the script to make a markup on the sub-volumes and bind to fstab and then install. but there is one caveat this is a mistake https://forum.manjaro.org/t/grub-error-sparse-file-not-allowed/20267

[benbullard79]

first, you need to make calamaris split into sub-volumes, or write a script to split it into 2 sub-volumes and then register the mount point / on the sub-volume in fstab and bind the name @ to it. With a hamster (home), similar to @home and /home

Thanks for the reply and information. What I am looking for is a fix for this that works for non-technical users. I do not know if such a fix is possible. There is talk of OM making btrfs the default file system type for installation. We do have a good number of users that do multi-boot. As matters stand now if we were to switch to btrfs we would cause some users to be unhappy.

[benbullard79]

I belileve comment by saber716rus on June 9 confirms this as a bug

[saber716rus]

I belileve comment by saber716rus on June 9 confirms this as a bug

since calamares does not know how to split btrfs into sub-volumes, then you can make a bash script so that there is a breakdown into sub-volumes, especially about automatic markup on btrfs.

[benbullard79]

I belileve comment by saber716rus on June 9 confirms this as a bug

since calamares does not know how to split btrfs into sub-volumes, then you can make a bash script so that there is a breakdown into sub-volumes, especially about automatic markup on btrfs.

Thanks, I was reporting this on behalf of other users and with a view that some folks advocate for using btrfs as default for OMLx installs. I believe to use btrfs as default we have a few things like this that need to be addressed. If they can be.