See https://github.com/ostreedev/ostree/issues/3198 Basically with bootc/ostree we're moving to composefs for the root filesystem. grub2-mkconfig needs to learn in this case to read /sysroot which is where the physical root lives. This patch fixes it for me: --- /usr/sbin/grub2-mkconfig.orig 2024-08-29 20:29:13.483212450 +0000 +++ /usr/sbin/grub2-mkconfig 2024-08-29 20:28:36.605582110 +0000 @@ -138,8 +138,15 @@ exit 1 fi +# Path to the real rootfs; we may be in a container or using bootc/ostree e.g. +GRUB_PHYSICAL_FILESYSTEM=/ +GRUB_FS="$(stat -f -c %T / || echo unknown)" +if test "x${GRUB_FS} = xoverlay" && test -d /sysroot; then + GRUB_PHYSICAL_FILESYSTEM=/sysroot +fi + # Device containing our userland. Typically used for root= parameter. -GRUB_DEVICE="`${grub_probe} --target=device /`" +GRUB_DEVICE="`${grub_probe} --target=device ${GRUB_PHYSICAL_FILESYSTEM}`" GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 2> /dev/null`" || true GRUB_DEVICE_PARTUUID="`${grub_probe} --device ${GRUB_DEVICE} --target=partuuid 2> /dev/null`" || true Reproducible: Always
(In reply to Colin Walters from comment #0) > See https://github.com/ostreedev/ostree/issues/3198 > > Basically with bootc/ostree we're moving to composefs for the root > filesystem. grub2-mkconfig needs to learn in this case to read /sysroot > which is where the physical root lives. > > This patch fixes it for me: > > --- /usr/sbin/grub2-mkconfig.orig 2024-08-29 20:29:13.483212450 +0000 > +++ /usr/sbin/grub2-mkconfig 2024-08-29 20:28:36.605582110 +0000 > @@ -138,8 +138,15 @@ > exit 1 > fi > > +# Path to the real rootfs; we may be in a container or using bootc/ostree > e.g. > +GRUB_PHYSICAL_FILESYSTEM=/ > +GRUB_FS="$(stat -f -c %T / || echo unknown)" > +if test "x${GRUB_FS} = xoverlay" && test -d /sysroot; then > + GRUB_PHYSICAL_FILESYSTEM=/sysroot > +fi > + > # Device containing our userland. Typically used for root= parameter. > -GRUB_DEVICE="`${grub_probe} --target=device /`" > +GRUB_DEVICE="`${grub_probe} --target=device ${GRUB_PHYSICAL_FILESYSTEM}`" > GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid > 2> /dev/null`" || true > GRUB_DEVICE_PARTUUID="`${grub_probe} --device ${GRUB_DEVICE} > --target=partuuid 2> /dev/null`" || true > Thanks Colin for providing the solution. Are you planning to create a pull request for Fedora dist-git repository? > > > Reproducible: Always
Please make one from the patch above. I don't know how you maintain the patches in dist-git. Is there a repo somewhere? Thanks.
(In reply to Timothée Ravier from comment #2) > Please make one from the patch above. I don't know how you maintain the > patches in dist-git. Is there a repo somewhere? Thanks. Sure, I can take it. If possible, you can also create a PR from https://src.fedoraproject.org/rpms/grub2
Would someone who has connections to grub upstream (subscribed to list, etc.) be able to shepherd it there?
(In reply to Colin Walters from comment #4) > Would someone who has connections to grub upstream (subscribed to list, > etc.) be able to shepherd it there? sure, I take care of posting it and CC you.
I used `rpm-ostree usroverlay`, applied the patch and ran grub2-mkconfig, I got this result: ``` $ sudo grub2-mkconfig -o /etc/grub2-efi.cfg Generating grub configuration file ... Found Fedora Linux 40 (Toolbx Container Image) on /dev/mapper/luks-<snip> Found Ubuntu 22.04.4 LTS on /dev/mapper/luks-<snip> Adding boot menu entry for UEFI Firmware Settings ... done ``` Not sure if that's intended but apparently with this patch grub detects my containers, although I'm not very sure if it actually adds them as boot options.
Are there any updates to this upstream? I tried looking through the grub devel mailing list archives but could not find anything mentioning the patch.
(In reply to Mateus Rodrigues Costa from comment #6) > I used `rpm-ostree usroverlay`, applied the patch and ran grub2-mkconfig, I > got this result: > > ``` > $ sudo grub2-mkconfig -o /etc/grub2-efi.cfg > Generating grub configuration file ... > Found Fedora Linux 40 (Toolbx Container Image) on /dev/mapper/luks-<snip> > Found Ubuntu 22.04.4 LTS on /dev/mapper/luks-<snip> > Adding boot menu entry for UEFI Firmware Settings ... > done > ``` > > Not sure if that's intended but apparently with this patch grub detects my > containers, although I'm not very sure if it actually adds them as boot > options. I believe this is not desired. Colin, any comment on this?
> Not sure if that's intended but apparently with this patch grub detects my containers, although I'm not very sure if it actually adds them as boot options. Uhhh....wait are you using the devicemapper backend for podman? Or how did you set up that /dev/mapper/luks-<snip> ? Is there actually an overlayfs mounted on top of that?
(In reply to Colin Walters from comment #9) > > Not sure if that's intended but apparently with this patch grub detects my containers, although I'm not very sure if it actually adds them as boot options. > > Uhhh....wait are you using the devicemapper backend for podman? Or how did > you set up that /dev/mapper/luks-<snip> ? > Is there actually an overlayfs mounted on top of that? I have FDE and the btrfs storage driver for podman.
> and the btrfs storage driver for podman. Yeah...so this kind of thing is why os-prober is COMPLETELY CRAZY. Scanning all of your block devices (which in your case, some happen to be containers) to find things that look like bootable systems is just again not something we should be doing by default. There may be a way to teach os-prober to ignore the btrfs subvolumes (I think that's what they are right?) that are containers. Also honestly I don't think there's a big advantage to using the btrfs backend for podman, the overlay driver works just as well - and would avoid this issue because they don't appear as block devices.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.