Description of problem: I thought nothing should be depending on /dev/root these days anywho when you boot with no initramfs grub2 errors out when generating config file with /sbin/grub2-probe: error: cannot stat `/dev/root'. Note his might also be causing "grubby fatal error: unable to find a suitable template" when installing kernel Installing : kernel-3.1.0-0.rc5.git0.0.fc16.x86_64 94/189 grubby fatal error: unable to find a suitable template Version-Release number of selected component (if applicable): grub2-1.99-5.fc16.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot with no initramfs 2. run grub2-mkconfig -o /boot/grub2/grub.cfg 3. Actual results: /sbin/grub2-probe: error: cannot stat `/dev/root'. Expected results: Grub config to be generated Additional info:
There was a bit of discussion about this on bug 627587 in debian bugzilla where the maintainer mentioned he backported r3318 from upstream.
Throwing this on the Beta blocker bug list since users arent able to boot into a newly installed kernel. Given how flaky experience I have had with grub2 I'm also proposing we form somekind of criteria surrounding it as in grub entries must be able to be generated correctly and grub.cfg updated accordingly at update/install time.
I think our current criteria cover any significant problems grub2 could cause. Remember, the criteria are generic descriptions of desired function, not detailed definitions of the desired capabilities of specific packages. It sounds like what you actually want is more package-specific test cases for grub2, which would certainly be good.
Discussed in the 2011-09-12 Fedora QA meeting. It's unclear on how a normal user would hit this since a regular kernel update would contain an initramfs. Johann, could you elaborate a bit more on how a regular user would hit this bug?
First of all why did you not ping me on that meeting? Secondly in alpha I hit this ( and now again after I did fresh re-install of alpha at that time ) "grubby fatal error: unable to find a suitable template" one time I was left with unbootable systemd after grub2 update which forced me to use rescue cd/usb having to chroot several partition and reinstall grub2 ( which generated a config completely different then what we use by default ) and now when I update /sbin/grub2-probe: error: cannot stat `/dev/root'. wtf Fyi /dev/root is a pretty broken concept today, it should not be created, and should be avoided in any tool and that tool be fixed if it's using it We are definetly not off to a good start here and we have to prevent this from happening in the future since this can literally break novice end users system. Grub2 also create rescue mode which is a blatant security risk ( reboot/poweroff/poweron machine select grub rescue voila your are in )
The /sbin/grub2-probe: error: cannot stat `/dev/root' error will be hit by regular users who have configure the system to boot without initramfs. Are you going to argue here that booting without initramfs is not a valid user configuration? If so by all means enlighten me why it is not...
Discussed (again) during the 2011-09-12 Fedora QA meeting. This is certainly a bug but it seems to be a rather uncommon configuration and thus, was rejected as a blocker bug for Fedora 16 beta. However, it does prevent boot on kernel update for some systems and thus was accepted as NTH for Fedora 16 beta. If this turns out to be a more common configuration than we currently understand, please re-propose as a blocker and it will be re-evaluated.
"Grub2 also create rescue mode which is a blatant security risk (reboot/poweroff/poweron machine select grub rescue voila your are in )" off topic, but it's no more of a security risk than has ever been the case. 'edit the first entry and add single' has always been possible.
(In reply to comment #8) > "Grub2 also create rescue mode which is a blatant security risk > (reboot/poweroff/poweron machine select grub rescue voila your are in )" > > off topic, but it's no more of a security risk than has ever been the case. > 'edit the first entry and add single' has always been possible. You seem to have forgot that user could actually prevent that by setting boot loader password at install time which serves no purpose anymore if we continue to have and create rescue option in the boot loader menu...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to comment #4) > Discussed in the 2011-09-12 Fedora QA meeting. > > It's unclear on how a normal user would hit this since a regular kernel update > would contain an initramfs. > > Johann, could you elaborate a bit more on how a regular user would hit this > bug? I can elaborate. Something broke my dracut last month and I didn't have time to troubleshoot so I just removed the initramfs entries and changed my grub defaults. Though if it weren't for this grub2 bug, I'd have no motivation to figure out what's going on with dracut, I suppose.
*** Bug 755719 has been marked as a duplicate of this bug. ***
Is anyone still working on this?
Nobody has been working on this.
Its quite easy to fix at least in my case. Used dracut to create the initramfs Edited /boot/grub2/grub,cfg to use the initramfs created. Rebooted using this kernel Ran grub2-mkconfig -o /boot/grub2/grub.cfg and a new grub.cfg was created. I just had one kernel, and if if you have more than one you should probably make an initramfs for each of them.
I have initramfs but don't want to use it (system boots up just fine without it, and faster, too)
I just got hit by this bug running F16, upgraded from F14. Checking, only my old F14 kernels have an initrd. I used tee to keep a record of the update and there's no mention of initrd in it, so if there was an error, I'm not sure ATM where to find it. Clearly, the current kernel, 3.1.2-1.fc16.i686, boots fine without an initrd and grub.cfg was properly created in order to use it. I'll find instructions on creating a new initrd (I've seen them, and I know it's not hard, I just need a template to work from.) and try again, but I did want to report that this is still happening.
>I have initramfs but don't want to use it (system boots up just fine without it, and faster, too) In my case, it is MUCH faster. The system boots about 10 seconds faster without initrd. We should fix this bug ASAP.
I get this after upgrading FC14 to FC16, and trying to update grub to grub2. [root@bookcase opt]# ls /dev/root ls: cannot access /dev/root: No such file or directory [root@bookcase opt]# /sbin/grub2-mkconfig -o /boot/grub2/grub.cfg /sbin/grub2-probe: error: cannot stat `/dev/root'. [root@bookcase opt] I'm not sure how to check if I booted with initramfs or not, but the (grub1) section used is: title Fedora 16 root (hd0,0) kernel /vmlinuz-3.1.8-2.fc16.x86_64 root=/dev/sda3 boot initrd /initramfs-3.1.8-2.fc16.x86_64.img I had to add this by hand (looks like https://fedoraproject.org/wiki/Common_F16_bugs#Upgrade_from_Fedora_14_or_15_to_Fedora_16_with_preupgrade_leaves_bootloader_in_previous_configuration). This was a direct upgrade using yum, with no reported errors. I tried to use 'preupgrade' but apparently 100-odd meg free in /boot isn't enough these days.
Is this still an issue with f17 ... from a technical point of view? I guess the meta issue is if Fedora supports booting without initramfs or not. That should probably be discussed and decided elsewhere.
Fedora supports booting without initramfs.img that technically got supported when ever it was introduced into the kernel. This is still an issue on F16 as in before installing/updating any kernel I need to do... 1. ln -s /dev/sda4 /dev/root 2. install/update kernel 3. grub2-mkconfig -o /boot/grub2/grub.cfg" to generate correct grub entries ( the update procedure does not use grub2-mkconfig to generate the grub2 menu ) and hoping that any grub2 update has not overwritten my changes. ( which most likely is a packing bug as in grub2 config files are not marked as config files in it's spec file. Honestly been to lazy to file a bug about it and it might have been fixed already ). In any case I'm in the middle of backing up then wipe this laptop and jump on the F17 train since I need to be on F17 to participate in JBoss testing tomorrow. Hopefully Anaconda has finally been fixed to support install off USB key since this laptop does not have CD/DVD drive. And hopefully Anaconda checks for network repos before it wipes my data to ensure that it wont leave me with no os and no boot-able system encase it cant install off an USB key but somehow my gut feeling tells me that will not be the case. In essence I'm about to find out just how beefy this miracle actually is...
*** Bug 789696 has been marked as a duplicate of this bug. ***
*** Bug 816998 has been marked as a duplicate of this bug. ***
*** Bug 817179 has been marked as a duplicate of this bug. ***
r3318+r3327 upstream together solve this issue. Since both are already in fedora, I think we can close this bug.
(In reply to comment #25) You're right, I stopped experiencing this bug several months ago.
Thanks.
I'm still hitting this bug. Fully updated F16 x86 [root@mireille ~]# grub2-mkconfig /sbin/grub2-probe: error: cannot stat `/dev/root'.
(In reply to comment #28) > I'm still hitting this bug. Fully updated F16 x86 Please state your grub2 version. f16 is probably not nextrelease.
# grub2-mkconfig --version grub2-mkconfig (GRUB) 2.00~beta4 # rpm -q grub2 grub2-2.0-0.25.beta4.fc17.x86_64 # grub2-mkconfig -o /boot/grub2/grub.cfg /usr/sbin/grub2-probe: error: failed to get canonical path of /dev/root. Doesn't seem to be fixed in current version in Fedora 17 (although I think the error message is slightly different to previous versions)
(In reply to comment #21) > Fedora supports booting without initramfs.img that technically got supported > when ever it was introduced into the kernel. > > This is still an issue on F16 as in before installing/updating any kernel I > need to do... > > 1. ln -s /dev/sda4 /dev/root > 2. install/update kernel > 3. grub2-mkconfig -o /boot/grub2/grub.cfg" to generate correct grub entries > ( the update procedure does not use grub2-mkconfig to generate the grub2 > menu ) and hoping that any grub2 update has not overwritten my changes. ( > which most likely is a packing bug as in grub2 config files are not marked > as config files in it's spec file. Honestly been to lazy to file a bug about > it and it might have been fixed already ). Same issue in rawhide grub2-2.0-0.31.beta5. The above ln -s fixed this
what does grub2-probe -v -v -t drive / say?
OK, re-opening then.
# grub2-mkconfig --version grub2-mkconfig (GRUB) 1.99 # rpm -q grub2 grub2-1.99-13.fc16.3.i686 # grub2-mkconfig /sbin/grub2-probe: error: cannot stat `/dev/root'.
# grub2-mkconfig --version grub2-mkconfig (GRUB) 1.99 This is not fedora 17, for sure.
As I said, I'm on F16 :) Will probably upgrade soon, but others are having the problem on F17 anyway
# grub2-probe -v -v -t drive / grub2-probe: info: Cannot stat `/dev/sdb', skipping. grub2-probe: error: failed to get canonical path of /dev/root. This is a surprise to me. As far as I know, there is no /dev/sdb in my system.
Created attachment 588635 [details] Possible fix Please try this patch
Applied patch to grub2-2.0-0.25.beta4.fc17.src.rpm Worked perfectly, thank you very much.
The patch is included in the unofficial beta6 scratch build on http://koji.fedoraproject.org/koji/taskinfo?taskID=4121699
Note that there seems to be some packaging conflict taking place with grub2-tools which seem to be introduced with. "* Mon May 21 2012 Peter Jones <pjones> - 2.0-0.28.beta5 - Name grub.efi something that's arch-appropriate (kiilerix, pjones) - use EFI/$SOMETHING_DISTRO_BASED/ not always EFI/redhat/grub2-efi/ . - move common stuff to -tools (kiilerix) - spec file cleanups (kiilerix)" Basically when you try to install grub2 it now depends on grub2-tools being install and when installing grub2-tools you get file conflicts... Transaction Check Error: file /etc/grub.d/10_linux from install of grub2-tools-1:2.0-0.32.beta6.fc17.x86_64 conflicts with file from package grub2-1:2.0-0.26.beta4.fc17.x86_64 ...
(In reply to comment #41) > Note that there seems to be some packaging conflict taking place with > grub2-tools which seem to be introduced with. grub2 has been split up to make grub2-efi work. Just install/upgrade the two packages at once if you want to test it. It is just an unofficial scratch build - I don't know when/if it will be pushed to f17.
This happens with 2.0-0.28> version of grub2 and normal install/update/upgrade fail due to the file conflict that happen between grub2-tools and grub2 versions <2.0-0.28 so the "update" will fail for novice end users... Anywho With grub2-1:2.0-0.26.beta4.fc17.x86_64 # grub2-probe -v -v -t drive / grub2-probe: info: Cannot stat `/dev/sdb', skipping. grub2-probe: error: failed to get canonical path of /dev/root. With grub2-2.0-0.32.beta6.fc17.x86_64 grub2-probe: info: Cannot stat `/dev/sdb', skipping. grub2-probe: warning: the device.map entry `hd0,gpt2' is invalid. Ignoring it. Please correct or delete your device.map. .... There is bunch of bad magic reported... grub-core/partmap/apple.c:123: bad magic (found 0x5256; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0xeb63; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x5256; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x5256; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0xeb63; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x5256; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x5256; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0xeb63; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x5256; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 grub-core/partmap/apple.c:123: bad magic (found 0x0; wanted 0x4552 So grub2-probe: error: failed to get canonical path of /dev/root but the /dev/sdb error is still present along with 2 new errors "invalid device map entry" and "bad magic". Installing the latest kernel grubby fails to add an entry to /boot/grub2/grub.cfg with that kernel Running Transaction Installing : kernel-3.5.0-0.rc0.git12.1.fc18.x86_64 1/2 grubby fatal error: unable to find a suitable template ( grubby probably still depends on the presence of /dev/root ) Running grub2-mkconfig -o /boot/grub2/grub.cfg does update the /boot/grub2/grub.cfg file with that kernel without the presence of /dev/root so this seems to be fixed in grub2 but the bug is still present in grubby On another note I got grub-efi-0.97-93.fc17.x86_64 installed from the default install instead of grub2-efi is that to be expected?
Ok so I think I have figure out why we see this... grub2-probe: info: Cannot stat `/dev/sdb', skipping. I'm pretty sure this is an anaconda bug as in if you are installing from a usb stick anaconda adds it when it generates the device map ( if I'm not mistaken anaconda should not be generating device.map et all in F17+ ) This probably is another anaconda bug not sure what triggers it thou... grub2-probe: warning: the device.map entry `hd0,gpt2' is invalid. Ignoring it. Please correct or delete your device.map. ( that entry points to /dev/sda2 which is /boot ) To workaround this issue simply comment out the relevant line(s) from /boot/grub2/device.map or just delete that file if you are on F17+ since grub should just automatically detect this if i'm not mistaken...
I've hit this on FC17 x86_64 as well I stopped loading the initramfs because this is a laptop and after the last kernel update (3.4.3) grub didn't find the root. I've added my dmesg, mount and df -h
Created attachment 593709 [details] dmesg output dmesg output from grub boot line: linux /vmlinuz-3.4.3-1.fc17.x86_64 root=/dev/sda3 rootfstype=ext4
Created attachment 593710 [details] mount output before root / would show up as /dev/sda3 but now it doesn't
booted with an initramfs and now grub2-mkconfig works previous grub2 command: linux /vmlinuz-3.4.3-1.fc17.x86_64 root=/dev/sda3 rootfstype=ext4 boot system boots fine new grub2 commands: linux /vmlinuz-3.4.3-1.fc17.x86_64 root=/dev/sda3 rootfstype=ext4 initrd /initramfs-3.4.3-1.fc17.x86_64.img boot system still boots fine (about same amount of time actually) but now grub2-mkconfig worked
(In reply to comment #45) > I've hit this on FC17 x86_64 as well Yes, as discussed here it is a known problem that has been fixed upstream. Or is there anything special that makes your case different ... but still this issue? Please report which grub2 version you are using and test with the packages from comment 40 (or an official unreleased build from http://koji.fedoraproject.org/koji/packageinfo?packageID=6684 or a later unofficial snapshot from http://koji.fedoraproject.org/koji/taskinfo?taskID=4152623 ) > I stopped loading the initramfs because this is a laptop Fedora always uses initramfs. If you for some reason want to try to live without and be a bit on your own then go ahead. But doing it "because this is a laptop" seems like a strange argument.
Please confirm: Has this issue been resolved with the beta6 update to f17? Will grub2-mkconfig on a system without /dev/root generate a working grub.cfg? But presumably one which uses initrd and thus will have /dev/root?
I just booted without an initramfs and ran grub2-mkconfig successfully as root and with sudo
initrd /initramfs-3.5.0-1.fc18.x86_64.img(In reply to comment #50) > Please confirm: Has this issue been resolved with the beta6 update to f17? It has been fixed > > Will grub2-mkconfig on a system without /dev/root generate a working > grub.cfg? Yes grub2-mkconfig on a system without /dev/root correctly generates working grub.cfg > But presumably one which uses initrd and thus will have /dev/root? Unless grub has been hacked not to do as in so yes it will generate an initrd /initramfs line in grub.cfg for every kernel.
bug still active on Fedora 17 3.5.1-1.fc17.x86_64... disk layout /dev/sda1 /boot /dev/sda2 / Have disable the initramfs,because the kernel can boot from an ext4 partition without it. As per instruction found at Fedora 17 Boot Optimization (from 15 to 2.5 seconds) http://www.harald-hoyer.de/personal/blog/fedora-17-boot-optimization-from-15-to-3-seconds A normal yum update that involves a new kernel update fails to properly update the grub entries ... Installing : kernel-3.5.2-1.fc17.x86_64 grubby fatal error: unable to find a suitable template The current workaround of grub2-mkconfig works and added the correct entries however it also add the initrd and rescue mode to all possible versions of kernel installed/upgraded in time. grub2 should be patched to scan if the system is running without initramfs support.
(In reply to comment #53) To disable rescue mode: /etc/defaults/grub should have a line `GRUB_DISABLE_RECOVERY="true"' N.B.: when updating/upgrading, yum creates a bunch of files with .rpmnew and .rpmsave extensions -- this is so that you can merge your changes to the default config files with the newly installed versions. I recommend running "rpmconf -a" after every big update What updates grub.cfg on `yum update' is grubby -- that's a separate utility; feel free to file a new bug against it.
(In reply to comment #53) > bug still active on Fedora 17 3.5.1-1.fc17.x86_64... What you see is another bug - probably Bug 833011.