Bug 737370 - /sbin/grub2-probe: error: cannot stat `/dev/root' when no initramfs
/sbin/grub2-probe: error: cannot stat `/dev/root' when no initramfs
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
AcceptedNTH
: Reopened
: 755719 789696 816998 817179 (view as bug list)
Depends On:
Blocks: F16Beta-accepted/F16BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2011-09-11 12:26 EDT by Jóhann B. Guðmundsson
Modified: 2012-09-27 02:43 EDT (History)
30 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-30 13:11:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Possible fix (790 bytes, patch)
2012-06-02 04:16 EDT, Vladimir Serbinenko
no flags Details | Diff
dmesg output (74.14 KB, text/plain)
2012-06-22 07:23 EDT, Timothy Davis
no flags Details
mount output (2.19 KB, text/plain)
2012-06-22 07:24 EDT, Timothy Davis
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2011-09-11 12:26:54 EDT
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:
Comment 1 Jóhann B. Guðmundsson 2011-09-11 13:04:32 EDT
There was a bit of discussion about this on bug 627587 in debian bugzilla where the maintainer mentioned he backported r3318 from upstream.
Comment 2 Jóhann B. Guðmundsson 2011-09-12 05:36:08 EDT
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.
Comment 3 Adam Williamson 2011-09-12 11:24:47 EDT
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.
Comment 4 Tim Flink 2011-09-12 11:35:36 EDT
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?
Comment 5 Jóhann B. Guðmundsson 2011-09-12 11:41:53 EDT
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 )
Comment 6 Jóhann B. Guðmundsson 2011-09-12 11:43:35 EDT
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...
Comment 7 Tim Flink 2011-09-12 12:07:17 EDT
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.
Comment 8 Adam Williamson 2011-09-12 18:52:19 EDT
"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.
Comment 9 Jóhann B. Guðmundsson 2011-09-12 20:16:16 EDT
(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...
Comment 10 Fedora Admin XMLRPC Client 2011-09-16 15:08:30 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Derek Linz 2011-09-26 06:14:28 EDT
(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.
Comment 12 Mads Kiilerich 2011-11-22 18:30:51 EST
*** Bug 755719 has been marked as a duplicate of this bug. ***
Comment 13 Konstantin Svist 2011-11-30 14:10:27 EST
Is anyone still working on this?
Comment 14 Mads Kiilerich 2011-11-30 14:36:16 EST
Nobody has been working on this.
Comment 15 Kjell.Randa@broadpark.no 2011-11-30 17:42:18 EST
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.
Comment 16 Konstantin Svist 2011-11-30 18:19:48 EST
I have initramfs but don't want to use it (system boots up just fine without it, and faster, too)
Comment 17 Joe Zeff 2011-12-19 23:55:40 EST
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.
Comment 18 Nikita S Pichugin 2011-12-25 05:05:10 EST
>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.
Comment 19 Tom Chiverton 2012-01-15 11:08:59 EST
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.
Comment 20 Mads Kiilerich 2012-04-16 14:07:10 EDT
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.
Comment 21 Jóhann B. Guðmundsson 2012-04-16 15:58:53 EDT
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...
Comment 22 Mads Kiilerich 2012-04-17 15:16:21 EDT
*** Bug 789696 has been marked as a duplicate of this bug. ***
Comment 23 Mads Kiilerich 2012-04-27 10:38:56 EDT
*** Bug 816998 has been marked as a duplicate of this bug. ***
Comment 24 Mads Kiilerich 2012-04-27 18:59:07 EDT
*** Bug 817179 has been marked as a duplicate of this bug. ***
Comment 25 Vladimir Serbinenko 2012-06-01 13:25:50 EDT
r3318+r3327 upstream together solve this issue. Since both are already in fedora, I think we can close this bug.
Comment 26 Artem S. Tashkinov 2012-06-01 13:30:19 EDT
(In reply to comment #25)

You're right, I stopped experiencing this bug several months ago.
Comment 27 Adam Williamson 2012-06-01 13:39:21 EDT
Thanks.
Comment 28 Konstantin Svist 2012-06-01 14:16:27 EDT
I'm still hitting this bug. Fully updated F16 x86

[root@mireille ~]# grub2-mkconfig 
/sbin/grub2-probe: error: cannot stat `/dev/root'.
Comment 29 Mads Kiilerich 2012-06-01 14:17:47 EDT
(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.
Comment 30 Kaare Fiedler Christiansen 2012-06-01 14:40:28 EDT
# 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)
Comment 31 Brendan Jones 2012-06-01 15:03:24 EDT
(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
Comment 32 Vladimir Serbinenko 2012-06-01 15:13:27 EDT
what does grub2-probe -v -v -t drive / say?
Comment 33 Adam Williamson 2012-06-01 15:16:13 EDT
OK, re-opening then.
Comment 34 Konstantin Svist 2012-06-01 15:24:56 EDT
# 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'.
Comment 35 Vladimir Serbinenko 2012-06-01 15:47:14 EDT
# grub2-mkconfig --version
grub2-mkconfig (GRUB) 1.99
This is not fedora 17, for sure.
Comment 36 Konstantin Svist 2012-06-01 15:53:08 EDT
As I said, I'm on F16 :)
Will probably upgrade soon, but others are having the problem on F17 anyway
Comment 37 Kaare Fiedler Christiansen 2012-06-01 16:18:10 EDT
# 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.
Comment 38 Vladimir Serbinenko 2012-06-02 04:16:55 EDT
Created attachment 588635 [details]
Possible fix

Please try this patch
Comment 39 Kaare Fiedler Christiansen 2012-06-02 11:41:35 EDT
Applied patch to grub2-2.0-0.25.beta4.fc17.src.rpm

Worked perfectly, thank you very much.
Comment 40 Mads Kiilerich 2012-06-02 15:07:22 EDT
The patch is included in the unofficial beta6 scratch build on http://koji.fedoraproject.org/koji/taskinfo?taskID=4121699
Comment 41 Jóhann B. Guðmundsson 2012-06-02 17:23:18 EDT
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@redhat.com> - 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
...
Comment 42 Mads Kiilerich 2012-06-02 18:38:07 EDT
(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.
Comment 43 Jóhann B. Guðmundsson 2012-06-02 19:44:23 EDT
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?
Comment 44 Jóhann B. Guðmundsson 2012-06-02 22:59:06 EDT
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...
Comment 45 Timothy Davis 2012-06-22 07:21:18 EDT
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
Comment 46 Timothy Davis 2012-06-22 07:23:44 EDT
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
Comment 47 Timothy Davis 2012-06-22 07:24:42 EDT
Created attachment 593710 [details]
mount output

before root / would show up as /dev/sda3 but now it doesn't
Comment 48 Timothy Davis 2012-06-22 07:32:23 EDT
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
Comment 49 Mads Kiilerich 2012-06-22 07:44:10 EDT
(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.
Comment 50 Mads Kiilerich 2012-07-30 12:27:56 EDT
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?
Comment 51 Timothy Davis 2012-07-30 12:50:36 EDT
I just booted without an initramfs and ran grub2-mkconfig successfully as root and with sudo
Comment 52 Jóhann B. Guðmundsson 2012-07-30 13:07:37 EDT
 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.
Comment 53 monts 2012-08-17 16:45:53 EDT
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.
Comment 54 Konstantin Svist 2012-08-17 17:24:53 EDT
(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.
Comment 55 Mads Kiilerich 2012-08-19 09:57:29 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.