Description of problem: grub2-mkconfig produces two errors, seem to be bogus Version-Release number of selected component (if applicable): grub2-2.00-9.fc18.x86_64 Fedora-18-Beta-TC5-x86_64-Live-Desktop.iso How reproducible: Always, at least with a btrfs raid0 volume. Steps to Reproduce: 1. Install, creating btrfs subvol for boot, root, home; on two disks (raid0) 2. Comment out theme line in /etc/default/grub 3. grub2-mkconfig -o /boot/grub2/grub.cfg Actual results: Generating grub.cfg ... /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1 /dev/sdb1. Check your device.map. Found linux image: /boot/vmlinuz-3.6.1-1.fc18.x86_64 Found initrd image: /boot/initramfs-3.6.1-1.fc18.x86_64.img /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1 /dev/sdb1. Check your device.map. No volume groups found done Expected results: minus errors and comment to check device.map Additional info: The device.map doesn't look wrong. # this device map was generated by anaconda (hd0) /dev/sda (hd1) /dev/sdb The resulting grub.cfg works. core.img has the right prefix for the boot subvol. Regression: Single disk btrfs volume, also with boot, root, home subvols, the error does not occur. Seems restricted to multiple device btrfs volumes.
OK so the resulting grub.cfg's are different but only the menuentry line appears affected. In the single disk btrfs case, the menuentry line includes the root UUID. Whereas in the 2 disk raid0 btrfs case, the menuentry line contains /dev/sda1 /dev/sdb1 instead; although the proper UUID appears within the entry on the search and linux lines. Weird. Appears benign. Attaching the two grub.cfg.
Created attachment 630354 [details] btrfs single disk grub.cfg
Created attachment 630355 [details] btrfs raid0 2-disk grub.cfg
Created attachment 630624 [details] bash -x grub2-mkconfig I think this may be related. grub2-probe --target=device / returns this: + GRUB_DEVICE='/dev/sda1 /dev/sdb1' Speculate that the CR in between these is tripping up grub2-probe later on when it's trying to figure out what to put in the menuentry, a /dev device or UUID? Pretty sure for anything else, / would return just a single device? Whereas with btrfs volumes, / isn't mapped to something like /dev/md0, but rather each constituent physical device. I think 4 devices returned for raid10 volume containing / is a realistic scenario in the near term.
I tried F18b TC7 and tried to: 1mb biosboot the rest a btrfs for /boot, swap, /. I just created a mount point for / with the desired size. Anaconda complained that /boot must be not a subvolume. Does actually grub2 support btrfs subvolumes? (in this case, it was a single disks setup).
Sorry, this was for another bug-report.
Yes Chris, this is a dup of my report although is was not obvious at first. Even more important is that there was some critical info here which says my initial patch which removed some double quotes so that the list of devices was on a single line is the correct fix. This is the same as line 133 in grub2-mkconfig. *** This bug has been marked as a duplicate of bug 890955 ***