Description of problem: The summary pretty much states the problem. You get a "press any key to continue" and you can and the system boot up. This only occurs when btrfs is multi-volume AND when /boot is on that multi-volume. Version-Release number of selected component (if applicable): Fedora 19, Fedora 20, grub2-25 How reproducible: Everytime. Created a kvm-virtual with a singl volume BTRFS and then re-did it with multivolume. This is "similar" to https://bugzilla.redhat.com/show_bug.cgi?id=890955 but totally takes place at bootup time.
OK, I have narrowed the problem down to a problem in /etc/grub.d/10_linux which is not handling multi-volume correctly when the /boot is on multi-volume and puts code on two lines which should only be on one. I will take a look at the code and see if I can come up with a patch.
I will take my previous statement back. The problem in 890955 is in MANY places which just are NOT prepared for the "device" not being a (singular) device but multiple devices. In reality, BTRFS does not care about any of this. You can refer to BTRFS storage by its singular UUID or by any of its devices ... you do not need to specify all of them.
Created attachment 816402 [details] update grub-probe.c to print " " instead of "\n" for hint This does fix the problem and has been testing on both Fedora 19 (grub2-2.00-23) and Fedora 20 Beta-TC5 (grub2-2.00-25). Including this patch, there are a total of three patches to grub2 and two patches for os-prober to make btrfs work. There patches are equally applicable to both Fedora 19 and Fedora 20. See https://bugzilla.redhat.com/show_bug.cgi?id=982009 for the other two grub 2 patches.
Oops, the bugzilla report cited above is for the os-prober patches needed for btrfs to work. There is one additional patch for grub2 described in this bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=890955
This problem is corrected by upstream: commit 588744d0dc655177d5883bdcb8f72ff5160109ed It would be nice if this was fixed sooner rather than later.
I really would like to see this problem and the problem described in https://bugzilla.redhat.com/show_bug.cgi?id=890955 in the offical release of Fedora 20. These are more than a little arggravating for the use with BTRFS filesystems. I am going to address both problems here. From your prospective, I am not sure there is a good option so much as one less bad than the others. As I see it, here are the options: 1. Do nothing. Grub2 is broken with respect to /boot on btrfs and multi-device btrfs. 2. Use to two quick&dirty patches I supplied. They work for me but YMMV. 3. Use the "offical" patch commit id 588744d0dc655177d5883bdcb8f72ff5160109ed. This will cause a lot of other patches to be brought in. Something extremely undesireable at this point for Fedora 20. This is something for Fedora 21. 4. I reworked the "official" patch so that it fit on top of the current grub2-2.00-25.fc20.src.rpm This is working for me but again YMMV Bother #2 and #4 were tested on Fedora 20-Beta The patches for #2 are on this BZ and on bz 890955 I am attaching the patches for #3 and #4 here.
Created attachment 823466 [details] official patch from grub git repository
Created attachment 823467 [details] my refit of offical patch for 2.00-25.fc20
The Fedora grub2 fork is barely maintained but regularly rebased to new upstream releases. I suggest you try to upstream your patches - that is the best way to get them included in later fedora versions.
grub2 in rawhide has addressed outstanding btrfs issues by fixes from upstream