Description of problem: If /boot is on Btrfs, following successful installation with no error, the reboot fails at a grub> prompt, no menu appears. Looks like preboot GRUB doesn't set dev= variable, so $prefix is missing and it can't find grub.cfg or grubenv. Version-Release number of selected component (if applicable): grub2-efi-x64-2.04-35.fc34.x86_64 How reproducible: Always if $BOOT is on Btrfs Steps to Reproduce: 1. Install, make /boot mountpoint Btrfs ## NOTE: installer additionally creates a boot subvolume which is mounted at /boot/ 2. Reboot 3. Actual results: Fail at grub> prompt. Expected results: GRUB menu, list of kernels to boot, firmware setup Additional info:
Non-working case grub> set ()/grub2= ?=0 btrfs_relative_path= btrfs_subvol= btrfs_subvolid= check_signatures=no color_highlight=black/light-gray color_normal=light-gray/black feature_200_final=y feature_all_video_module=y feature_chainloader_bpb=y feature_default_font_path=y feature_menuentry_id=y feature_menuentry_options=y feature_nativedisk_cmd=y feature_ntldr=y feature_platform_search_hint=y feature_timeout_style=y fw_path=(hd0,gpt1)/EFI/fedora grub_cpu=x86_64 grub_netfs_type=grub grub_platform=efi lang= locale_dir= net_default_ip=(null) net_default_mac=(null) net_default_server= pager=1 prefix=()/grub2 pxe_default_server= root=hd0,gpt1 secondary_locale_dir= grub>
Compared to a working case, these items seem important but missing/malformed in the Btrfs case. (hd0,gpt2)/grub2= boot=hd0,gpt1 config_directory=(hd0,gpt1)/EFI/fedora config_file=(hd0,gpt1)/EFI/fedora/grub.cfg dev=hd0,gpt2 prefix=(hd0,gpt2)/grub2
As a test, converted working ext4 $BOOT to btrfs (which does not create a 'boot' subvolume, like the installer). Updated fstab UUID. Updated /boot/grub2/grub.cfg. Reboot fails the same way. Makes me think there's something about device discovery that depends on ext4 $BOOT?
XFS $BOOT works ok. Curious.
ESP's grub.cfg is missing two parts: 1. # cat /mnt/sysroot/boot/efi/EFI/fedora/grub.cfg search --no-floppy --fs-uuid --set=dev None set prefix=($dev)/grub2 export $prefix configfile $prefix/grub.cfg [root@localhost-live ~]# 2. No reference for the 'boot' subvolume, which the installer allows to be arbitrarily named by the user. It's possible to make this subvolume the mount time default via 'btrfs subvolume set $subvolid', but I'm not sure whether the installer knows how to manipulate it. Another option is treat subvolume like a directory and just add it to the prefix path: set prefix=($dev)/boot/grub2 Tested that fixing these two things makes the system bootable.
I've proposed a pull-request for anaconda to fix this issue: https://github.com/rhinstaller/anaconda/pull/3196
Proposed as a Freeze Exception for 34-beta by Fedora user m4rtink using the blocker tracking app because: Required to fix support for GRUB directory on a btrfs subvolume.
I applied the patch in the PR to Fedora-Workstation-Live-x86_64-34-20210222.n.0.iso and it works (Custom part, switch /boot to Btrfs device).
+4 votes in https://pagure.io/fedora-qa/blocker-review/issue/244 , marking accepted.
FEDORA-2021-a432247223 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a432247223
FEDORA-2021-a432247223 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a432247223` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a432247223 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Testers: The fix in c10 and c11, fixes the problem in the ESP grub.cfg line 2 set prefix=($dev)/grub2 should be set prefix=($dev)/boot/grub2 Still needed is a fix for ESP grub.cfg line 1 search --no-floppy --fs-uuid --set=dev None should be search --no-floppy --fs-uuid --set=dev $FSUUIDforyourbootfilesystem Once the fix goes stable the bug status should probably go back to ASSIGNED.
FEDORA-2021-a432247223 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Reopening per comment 10.
Let's close this bug as fixed, and use bug 1930567 to track the remaining problem.
This is/was an accepted Beta FE, but that one is only proposed as a Final blocker. Do we not also want it as a Beta FE?
Oh yeah good point. Yes.
Hum, some mastodon feedback brought me back to this: https://fosstodon.org/@skruffl@chaos.social/111706262961652079 which links to: https://unix.stackexchange.com/questions/683025/fedora-installation-failed-to-write-boot-loader-configuration it rather seems like this use of grub2-mkrelpath is actually failing when /boot isn't a separate mount point. did anyone ever test whether this works with no /boot mount point?
Memory is a funny thing. Possibly Silverblue fails with a /boot directory on / (i.e. /boot not on its own mount point), where the conventional desktops successfully install. It's likely I filed a bug for this but I'm not finding it off hand. But I definitely haven't tested any of this recently.