The issue is in /boot/efi/EFI/fedora/grub.cfg  line :  search --no-floppy --fs-uuid  --set=dev None

If /boot is on  root btrfs subvolume   $dev is empty.
search --no-floppy --fs-uuid  --label "my btrfs partition" --set=dev None    set $dev to "my btrfs partition" and solves the problem.

Sorry for my english.

There were two Btrfs regressions resulting from https://fedoraproject.org/wiki/Changes/UnifyGrubConfig feature that were being tracked in bug 1928599, summarized in https://bugzilla.redhat.com/show_bug.cgi?id=1928588#c12

Since the 'GRUB directory relative path' part is now fixed, I've closed that bug. Renaming this bug so it's clearly about the second problem that remains.

*sigh* c2 has a typo for the bug I referenced, the long URL with strikeout is correct.

Proposed as a Blocker for 34-final by Fedora user chrismurphy using the blocker tracking app because:

 Final criteria say the installer must create+install whatever it lets the user configure. And Basic says the result has to boot. Options are (a) fix the bug (b) revert the change (c) flip the anaconda switch that disallows /boot on Btrfs.

https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Disk_layouts
The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. 

https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior
A system installed with a release-blocking desktop must boot ...

Proposing as a Beta FE per https://bugzilla.redhat.com/show_bug.cgi?id=1928588#c17 . Since that bug was accepted and this one has the same impact, we should probably accept this too.

(In reply to edpil02 from comment #1)
> The issue is in /boot/efi/EFI/fedora/grub.cfg  line :  search --no-floppy
> --fs-uuid  --set=dev None
> 
> If /boot is on  root btrfs subvolume   $dev is empty.
> search --no-floppy --fs-uuid  --label "my btrfs partition" --set=dev None   
> set $dev to "my btrfs partition" and solves the problem.
> 

I'll take a look to this issue.

I've opened https://github.com/rhinstaller/anaconda/pull/3227 but it may be that it's just
papering over a bug in blivet. Someone more familiar with anaconda and blivet could review
that and let me know if blivet should be changed instead to also set the format.uuid field.

Discussed during the 2021-03-08 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException (Beta)" and an "AcceptedBlocker (Final)" was made as it is a noticeable issue that cannot be fixed with an update and seems like a clear violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" combined with the Basic "installed system must boot" criteria.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-08/f34-blocker-review.2021-03-08-17.00.txt

FEDORA-2021-0be5f28658 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0be5f28658

FEDORA-2021-0be5f28658 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-0be5f28658`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0be5f28658

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-0be5f28658 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

I tried a fresh rawhide install with  /boot btrfs.
I got a anaconda error : "Cant find stage2 UUID ..  exit or continue"   

/boot/efi/EFI/fedora/grub.cfg  file was empty. I had to edit it manually to boot.

I just tested Fedora-Workstation-Live-x86_64-Rawhide-20210314.n.0.iso and it installs and reboots OK with /boot on Btrfs. @edpil02 if you can reproduce the problem with a recent ISO, could you file a new bug and attach each log file in /tmp/ separately? Thanks.

*** Bug 1939036 has been marked as a duplicate of this bug. ***

I just ran into this with Fedora-Workstation-Live-x86_64-34_Beta-1.2.iso (that's the one from yesterday). See Bug 1939036; only spotted this one right after submitting it, sorry. :-/

Should this bug be reopened or is the anaconda in that build still to old?

Beta 1.2 should have the fix, and I can't reproduce the problem. We need the logs from the failed installation: anaconda.log, storage.log, program.log. Those are in /tmp/ in the install environment, and they're in /var/log/anaconda/ if you've already rebooted. Also useful to attach the /etc/fstab, and 'journalctl -b 0 > journal.log'. Ideally we'd find someone to reproduce the problem with boot parameter 'udev.log_priority=debug' and attach that journalctl output.

I'm confused. Beta 1.2 has anaconda-34.24.5-4.fc34 and the fix is in anaconda-34.24.5-5.fc34. I'm not sure why it didn't get pulled into RC2, it has an approved FE. I must have tested by manually updating to -5 once I booted the Live. Thorsten, disregard c16. Can you retest by booting the Live and then updating Anaconda?

sudo dnf update anaconda --exclude=device-mapper-multipath,libconfig,lldpad,fcoe-utils

(In reply to Chris Murphy from comment #17)
> Thorsten, disregard c16. Can you retest by booting the Live
> and then updating Anaconda?

I'm a bit busy, but if it's important I can do that. Is it okay to do it in a VM with a similar layout or do I have to use the machine which I prepared for other uses?

I'd say test it under the same conditions as you discovered the problem. I wouldn't bother (re)testing in a VM because that's consistently working correctly with anaconda-34.24.5-5.fc34. In the meantime I'll close this out again as fixed, since I've confirmed the fix on two baremetal systems as well as qemu-kvm.

The fixed anaconda didn't make it into Beta RC2 unfortunately, because an older anaconda was left in the candidate compose side tag, and builds from that side tag override even *newer* stable builds when running the compose, apparently. So even though we pushed -5 stable before running the compose, it wound up including -4 from the side tag :( Sorry about that. We can't respin just for that as this is an FE issue, not a blocker.

Draft for CommonBugs:

On computers with UEFI firmware and when using /boot on Btrfs, boot will fail following the installation. This is not a default configuration, you need to use Custom or Advanced-Custom UI to specifically place /boot on Btrfs. Ideally, you should fix the problem after installation, but before rebooting. Otherwise you'll need to reboot from install media, and mount the EFI System partition.

##Discover the FS UUID for the Btrfs /boot volume
lsblk -f

##Edit the forwarding grub.cfg on the EFI System partition
nano /mnt/sysimage/boot/efi/EFI/fedora/grub.cfg

##Modify the first line, replacing 'None' with the FS UUID for the Btrfs file system used for boot. Save the file. Now you can safely reboot.

##Example:

Malformed line:
search --no-floppy --fs-uuid --set=dev None

Corrected line:
search --no-floppy --fs-uuid --set=dev 404e2120-46cb-4933-8380-941bb2c403d7

anaconda-34.24.5-5.fc34 made it into RC3 which is the release version for beta. Removing CommonBugs.