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.