Description of problem: I tried to install f16 on a btrfs / with /boot being a subvolume. It seems grub2 detects this as /boot being a separate partition and creates all paths relative to /boot instead of / (e.g. grub.cfg contains "linux /vmlinuz-...." instead of "linux /boot/vmlinuz...."). This leads to grub2 falling back into rescue mode with a file not found error. Version-Release number of selected component (if applicable): 1.99-12 How reproducible: always Steps to Reproduce: 1. Install f16 to a btrfs / filesystem without a separate /boot partition 2. # mv /boot /boot.old 3. # btrfs subvolume create /boot 4. # cp -a /boot.old/* /boot/ 5. # grub2-mkconfig -o /boot/grub2/grub.cfg -- grep vmlinuz /boot/grub2/grub.cfg now shows all the paths relative to /boot already, so if you don't want an unbootable system, stop here and undo the previous steps 6. run grub2-install with apropriate paramters 8. reboot Actual results: grub2 falls back to rescue mode with a file not found error Expected results: grub2 reads grub.cfg and shows the boot menu and then boots the selected os Additional info: after recreating /boot as a normal directory and rerunning grub2-install and grub2-mkconfig everything works as expected again. Thanks Mirco
That sounds a lot like Bug 748121 - can you confirm that?
(In reply to comment #1) > That sounds a lot like Bug 748121 - can you confirm that? I'm not sure. There definetly is a difference, as Bug 748121 only deals with seperate /boot filesystems, as fas as I understand. And grub-install doesn't give any error messages in my case. But it might boil down to the same problem, I just don't know enough about grub2 to tell.
(In reply to comment #1) > That sounds a lot like Bug 748121 - can you confirm that? I think the problem is that there is no way to specify a subvolume to grub2. It doesn't look at all related to 748121 to me.
This config should work on latest F17. Can you confirm?
I have changed my setup to /boot being a normal subdir instead of a subvolume to get it to boot ;) I will test this though but its unlikely I find the time until mid of the week.
I finally got to test this, and no, unfortunately this doesn't seem to be fixed. After running grub2-mkconfig -o /boot/grub2/grub.cfg I still get entries like this: echo 'Linux 3.3.7-1.fc17.x86_64 wird geladen …' linux /vmlinuz-3.3.7-1.fc17.x86_64 root=UUID=dadb0392 ... echo 'Initiale Ramdisk wird geladen …' initrd /initramfs-3.3.7-1.fc17.x86_64.img So all paths are still relative to /boot instead of /. I didn't try rebooting since I figured it wouldn't work anyway. My grub version is 2.0-0.36.beta6.fc17 now (installed via koji).
Can you post the file /proc/self/mountinfo ? What does grub2-mkrelpath /boot say? I'm pretty sure it worked when I tested it.
Created attachment 593539 [details] /proc/self/mountinfo
grub2-mkrelpath /boot gives me an empty line when /boot is a subvolume.
Comment on attachment 593539 [details] /proc/self/mountinfo Hm, there is nothing mounted at /boot.
Indeed. And there shouldn't. All I did was: $btrfs subvolume create /boot2 $cp -r /boot/{,.vmlinuz}* /boot2/ $mv /boot /boot3 $mv /boot2 /boot before: $grub2-mkrelpath /boot /boot $ after: $grub2-mkrelpath /boot $
BtrFS is up to its dirty tricks again. It changes the device without having a mountpoint. Wonderful. Will have to look into it.
No. the whole btrfs partition is on /dev/sda5. I only created a subvolume. All data in /boot is still stored on /dev/sda5. The problem is that grub _thinks_ /boot is on a different device even though it is not.
No, it's btrfs which tells us that they're on different devices: phcoder.phnet:22:40:13:~/compile$ stat /mnt/1/boot/ Device: 1fh/31d Inode: 256 Links: 1 phcoder.phnet:22:40:15:~/compile$ stat /mnt/1 Device: 1eh/30d Inode: 256 Links: 1 It looks like btrfs devs are going to add an API to retrieve that informations, so let's wait for them.
Alright. It wasn't such a good idea to create a subvolume for /boot as that excludes /boot from yums snapshot feature so I can perfectly live without it. Thanks anyway :)
Created attachment 593598 [details] Possible patch Please test this patch
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.