Bug 756559 - grub2 not booting into new kernel after yum update
Summary: grub2 not booting into new kernel after yum update
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grubby
Version: 16
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 733108 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-23 23:07 UTC by monts
Modified: 2012-04-25 20:20 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-25 20:19:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description monts 2011-11-23 23:07:41 UTC
Description of problem: Did a fresh custom install of Fedora 16 verified ISO and after doing a media check..with the following disk layout /boot / (/home /data were not formatted simpley remounted) 

I did a custom install with manually selecting the partitions and asked NOT to use GPT labeling. In my case only the original label lets me boot into the system... since then have upgraded two new kernels the labels are created but when I use them it drops me to a system rescue shell ... 

After a fresh install I got an error could not complete fsck. Next tried a init 5 some error about not able to connect to udev and load the libext2fs.so.2 lib booted into rescue mode via Fedora dvd checked the /etc/fstab 
 
 # /etc/fstab
 # Created by anaconda on Sat Nov 19 03:53:28 2011
 #
 UUID=someid / ext4 defaults 1 1
 UUID=someid /boot ext4 defaults 1 2
 UUID=someid /home ext4 defaults 1 2
 
 was changed to following 
 UUID=someid / ext4 defaults 0 0
 UUID=someid /boot ext4 defaults 0 0
 UUID=someid /home ext4 defaults 0 0
 
 saved and rebooted was able to boot up normally :) ... the initial selinux policy was applied and attributes changed ... logged in as root .. disabled unnecessary services and cosmetic tweaks applied (no system files were edited or altered). 
 Did a yum install yum-plugin-fastestmirror .... then did a yum update ... installed various updates new kernel and KDE 4.7.3 among other updates ... reboot !!!!
 
 Oh the horror !!! :x same error every-time being dumped into a recovery mode console .. init or even reboot does not work . 
I get the following error e2fsck returned with 127 could not load the share library libext2fs.so.2 

Was looking around and found this in the install.log file 
  
 04:13:13 Installing rootfiles-8.1-7.fc15.noarch
 04:13:13 Installing words-3.0-17.fc15.noarch
 grubby fatal error: unable to find a suitable template
 grubby: doing this would leave no kernel entries. Not writing out new config.
 * FINISHED INSTALLING PACKAGES *

I have even compile a custom kernel 3.1.2 as I need support for mounting the ntfs dynamic volume. Stock Fedora kernel does not support for mounting dynamic ntfs volumes. After doing a make install the entries were made in grub2 conf file. Selecting the same gives the same error and dumps into rescue mode. 

How reproducible:

selcting any of the linux entires other that the orignal always dumps into a rescue mode shell cannot boot into system.

Steps to Reproduce:
1. Fresh install of Fedora 16 using custom disk layout non GPT lables.
2. Did yum update (new kernel was installed) grub2 config does not gets updated properly.
3. always get dumped into rescue mode.
4. forced to use old kernel to boot/use system.
  
Actual results:
selcting any other entry then the orignal from the grub2 menu results in boot fail.

Expected results:
should be able to boot into any of the kernel esp the custom compiled 3.2.x Needed to mount ntfs dynamic volume. 

Additional info:
 
uname -a
Linux 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

The disk layout and hdd

fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
60 heads, 12 sectors/track, 2713229 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: id

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              12  1953523119   976761554   42  SFS

^^ the above is a 1TB dynamic nfts volume used as backup/data drive.

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: id

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *          63      614462      307200   83  Linux
/dev/sdb2          616448   164456447    81920000   83  Linux
/dev/sdb3       164456448   693493759   264518656   83  Linux
/dev/sdb4       693493920   976773119   141639600    5  Extended
/dev/sdb5       693493983   976768064   141637041   83  Linux

^^ the above is a 500gb hdd has Fedora 16 using custome disk layout using non GPT lables
/boot etx4 >> /dev/sdb1
/ etx4  >> /dev/sdb2
/data xfs >> /dev/sdb3
/home ext4 >> /dev/sdb5 

Disk /dev/sdc: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: id

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048      718847      358400    7  HPFS/NTFS/exFAT
/dev/sdc2          718848   488394751   243837952    7  HPFS/NTFS/exFAT

^^ the above is a 250gb drive used to test Windows 8 dev build

Was suggested to enable UEFI emulation in the BIOS.. that did not help.
the current grub2 conf file ...

Version-Release number of selected component (if applicable):
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default="${saved_entry}"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  insmod vbe
  insmod vga
  insmod video_bochs
  insmod video_cirrus
}

set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora Linux, with Linux 3.1.2' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.2 ...'
	linux	/vmlinuz-3.1.2 root=UUID=someid
 ro rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8 
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.2.img
}
menuentry 'Fedora Linux, with Linux 3.1.2 (recovery mode)' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.2 ...'
	linux	/vmlinuz-3.1.2 root=UUID=someid
 ro single rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.2.img
}
menuentry 'Fedora Linux, with Linux 3.1.1-2.fc16.x86_64' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.1-2.fc16.x86_64 ...'
	linux	/vmlinuz-3.1.1-2.fc16.x86_64 root=UUID=someid
 ro rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8 
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.1-2.fc16.x86_64.img
}
menuentry 'Fedora Linux, with Linux 3.1.1-2.fc16.x86_64 (recovery mode)' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.1-2.fc16.x86_64 ...'
	linux	/vmlinuz-3.1.1-2.fc16.x86_64 root=UUID=someid
 ro single rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.1-2.fc16.x86_64.img
}
menuentry 'Fedora Linux, with Linux 3.1.1-1.fc16.x86_64' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.1-1.fc16.x86_64 ...'
	linux	/vmlinuz-3.1.1-1.fc16.x86_64 root=UUID=someid
 ro rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8 
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.1-1.fc16.x86_64.img
}
menuentry 'Fedora Linux, with Linux 3.1.1-1.fc16.x86_64 (recovery mode)' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.1-1.fc16.x86_64 ...'
	linux	/vmlinuz-3.1.1-1.fc16.x86_64 root=UUID=someid
 ro single rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.1-1.fc16.x86_64.img
}
menuentry 'Fedora Linux, with Linux 3.1.0-7.fc16.x86_64' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.0-7.fc16.x86_64 ...'
	linux	/vmlinuz-3.1.0-7.fc16.x86_64 root=UUID=someid
 ro rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8 
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.0-7.fc16.x86_64.img
}
menuentry 'Fedora Linux, with Linux 3.1.0-7.fc16.x86_64 (recovery mode)' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	echo	'Loading Linux 3.1.0-7.fc16.x86_64 ...'
	linux	/vmlinuz-3.1.0-7.fc16.x86_64 root=UUID=someid
 ro single rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.0-7.fc16.x86_64.img
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Windows Recovery Environment (loader) (on /dev/sdc1)" --class windows --class os {
	insmod part_msdos
	insmod ntfs
	set root='(/dev/sdc,msdos1)'
	search --no-floppy --fs-uuid --set=root someid
	drivemap -s (hd0) ${root}
	chainloader +1
}
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
### BEGIN /etc/grub.d/90_persistent ###

All in all this has really made for a very bad experince using Fedora 16. I need all the help and info to fix this. Need to move critcal data from /home and /data volumes to  backup drive. Thanks

Comment 1 Mads Kiilerich 2011-11-25 16:39:56 UTC
This is a bug tracker. It is better to use some forum or mailing list if you need help.

If you have fsck errors then you can't trust anything on the disks. It is not interesting to investigate any following errors before that has been resolved.

The libext2fs errors also indicate that something is seriously wrong.

I don't see any indication of anything related to grubby, grub2 or the kernel update.

I suggest you try to install again - perhaps after making a thorough low level check of your hard drive. That will probably tell you something new.

Comment 2 monts 2011-11-25 17:42:58 UTC
Well just because I wrote want some help give the typical RTFM treatment. Very nice indeed thanks. I do know this is bug tracker. Before taking out the pitchforks and knives take the time to re read my post several times.

 There are no physical errors on the disk... no errors in dmesg ... clean mount via various live cd and the system is fully usable and does boots normally with the original entry created after the clean install.

I did write that very clearly. 
"Actual results:
selecting any other entry then the original from the grub2 menu results in boot
fail."

Was looking around and found this in the install.log file 

 04:13:13 Installing rootfiles-8.1-7.fc15.noarch
 04:13:13 Installing words-3.0-17.fc15.noarch
 grubby fatal error: unable to find a suitable template
 grubby: doing this would leave no kernel entries. Not writing out new config.
 * FINISHED INSTALLING PACKAGES *

^^ hmm not a grubby issue very nice.

Just because I mentioned windows and ntfs maybe ... using R-Linux under windows *gaps* I have taken the required backup. 
"The libext2fs errors also indicate that something is seriously wrong." 
sure sure and still a windows fs driver for Linux fs can read data from the volumes. 

Why would I do a reinstall a working system and waste valuable time/bandwidth  effort. I am not an expert like ppl out here but have been using this distro since RH 8 > Fedora Core > Fedora. I do know my way around.

Lets start afresh. It is a issue that is why I have reported this. Sorry for being a bit sarcastic :P

let me know what more can be done at my end. If this can be solved via some trick with grub2(really do not know much abt it, but hey can always read n learn).

Comment 3 Mads Kiilerich 2011-11-25 18:20:07 UTC
> Was looking around and found this in the install.log file 
> 
>  04:13:13 Installing rootfiles-8.1-7.fc15.noarch
>  04:13:13 Installing words-3.0-17.fc15.noarch
>  grubby fatal error: unable to find a suitable template
>  grubby: doing this would leave no kernel entries. Not writing out new config.
>  * FINISHED INSTALLING PACKAGES *

https://bugzilla.redhat.com/show_bug.cgi?id=730357

> Why would I do a reinstall a working system and waste valuable time/bandwidth 
> effort.

That should be to get a scenario where you can focus on one issue at a time. Where you can file one issue without mentioning 7 other. A setup where you don't have file system errors. A setup where everything is as it is in Fedora and works for many other users.

You have obviously tried so hard to fix various issues that I don't know how much of your system that is standard Fedora.

Most of the kernels that doesn't work for you is apparently your own. (And NTFS works just fine with ntfs-3g without compiling any custom kernel.)

The grub.cfg you showed has been created by grub2-mkconfig - grubby haven't touched it at all.

Comment 4 monts 2011-11-25 19:00:33 UTC
:) The only reason I did a custom kernel compile, the backup ntfs drive is dynamic volume (SFS) which is not supported in the stock Fedora kernel.
This was also mentioned before. It needs # CONFIG_LDM_PARTITION enabled which is not on by default. Really do not have any pressing need to use a custom kernel. 

There is no self compiled black magic involved. The system has pretty much standard settings...

Linux 3.1.0-7.fc16.x86_64 (installed via Fedora 16 dvd boots normally)

Linux 3.1.0-7.fc16.x86_64 (installed via a standard yum update gives error)

Linux 3.1.1-1.fc16.x86_64 (installed via a standard yum update gives error)

Linux 3.1.1-2.fc16.x86_64 (installed via a standard yum update gives error)

Linux 3.1.2 (self compiled and installed via make install just to enable #CONFIG_LDM_PARTITION gives error)

hehe even windows boots normally via the menu.

The grub.cfg you showed has been created by grub2-mkconfig - grubby haven't
touched it at all.
*true* coz after a bit of googleling I did so via grub2-mkconfig -o /boot/grub2/grub.cfg 

This at least added the windows entry. Now I do not have to keep changing the boot order in the BIOS every time I need windows ;)

So indeed grubby has not touched the config (that is what I have been trying to tell)... now the question is WHY and how to fix this. This is the *only* issue. I do feel we are getting somewhere indeed..

Comment 5 monts 2011-11-28 07:39:15 UTC
Just did a yum update and as a result this added a new entry 

Fedora (3.1.2-1.fc16.x86_64) still the same error.

Tried to do a # grub2-script-check -v it simply hangs and nothing happens.

This is my current /etc/default/grub If it helps in anyways.

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0  KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8"

This is my current /boot/grub2/grubenv

# GRUB Environment Block
saved_entry=Fedora Linux, with Linux 3.1.0-7.fc16.x86_64

Comment 6 Bill Gianopoulos 2011-12-08 00:42:04 UTC
If there is some overriding issue with this patch, could we at least put in a patch to just not insert the "echo Loading ...." line at all?  This way just makes it look like the incorrect kernel is being booted which is just not a very good thing at all.

Comment 7 Bill Gianopoulos 2011-12-08 00:44:45 UTC
(In reply to comment #6)
> If there is some overriding issue with this patch, could we at least put in a
> patch to just not insert the "echo Loading ...." line at all?  This way just
> makes it look like the incorrect kernel is being booted which is just not a
> very good thing at all.

Opps. Sorry this comment was meant for a different bug.

Comment 8 Brian Lane 2012-01-23 16:39:20 UTC
*** Bug 733108 has been marked as a duplicate of this bug. ***

Comment 9 aaronsloman 2012-03-22 17:27:34 UTC
I've seen exactly this problem using  yum update in Fedora 16, most recently 3.3.0-2.fc16.i686
Someone else has reported the same symptoms in bug #751875

After a lot of experimentation I can describe what seems to be the problem (though I don't know how to fix it).

My boot partition is /dev/sda6

Fedora 15 was originally installed on /dev/sda12
Fedora 16 was later installed on /dev/sda12, but I wanted to leave the option
to boot into F15, so I left /boot/grub/grub.conf When I installed F16 the entries for F15 were copied into /boot/grub2/grub.cfg, though later removed them after moving permanently to F16.

However, I found that yum update always inserts the wrong linux partition uuid into grub.cfg whenever I update the kernel: it inserts the partition that was appropriate for F15 root, not the one for F16 root. Fort example, when I upgraded to kernel 3.3.0-2.fc16.i686 the upgrade process inserted a line starting:
linux   /vmlinuz-3.3.0-2.fc16.i686 root=UUID=837e4096-5725-403f-bcf2-c1a8c503669e
  
even though the running kernel had this (which I had had to edit by hand to get the right UUID):

linux   /vmlinuz-3.1.7-1.fc16.i686 root=UUID=29cae70a-ba5d-4178-8d93-30208331e510

Whenever this happens I cannot boot the new kernel until I have edited the line in grub.cfg (while running the old kernel).

I think I have had this problem consistently since installing F16. It has been extremely annoying, and I have spent a lot of time searching for a solution. I have not found one though I have found many web pages reporting similar complaints (e.g. from Ubuntu as well as fedora users).

I tried editing /etc/grubd/10_linux (which is a very obscure shell script that no user should have to edit). I tried inserting a definition for GRUB_DEVICE_UUID, but that made no difference to yum install: it still got the device wrong.

Strangely if I run grub2-mkconfig > /tmp/grub.cfg then the entries for F16 kernels are correct in the section starting

### BEGIN /etc/grub.d/10_linux ###

but seriously wrong in the section starting 

### BEGIN /etc/grub.d/30_os-prober ###

e.g. It wrongly labels a Fedora 16 kernel as Fedora 15 and inserts the wrong partition for it:

menuentry "Fedora release 15 (Lovelock) (on /dev/sda12)" --class gnu-linux --class gnu --class os {
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos6)'
        search --no-floppy --fs-uuid --set=root edcc4306-8eab-4f2e-990e-57520dfa2ab5
        linux /vmlinuz-3.3.0-2.fc16.i686 root=/dev/sda12
        initrd /initramfs-3.3.0-2.fc16.i686.img
}

That should be release 16 on /dev/sda13 and root=/dev/sda13

I conclude that grub2 is so buggy as to be unfit for production use and whatever 'yum update' is doing in Fedora 16 is also seriously buggy, though the output is different from that of grub2-mkconfig which gets *some* parts right that yum update gets wrong.

It's likely that this bug is only manifested in cases where a new release (in my case fedora 16) is installed on a machine that previously contained other releases using the same boot partition.

I am merely a user, and would not be able to work on fixing the code. I hope this helps those who can fix it to identify the bugs.

[I have been installing new kernels because of bugs in pm-hibernate as reported in bug #781749 Having to edit grub.cfg after each yum update is a serious inconvenience. I suspect some users think the installation has failed completely because they cannot boot the new version at all or the boot causes serious errors because it uses the wrong root partition -- which is what originally happened to me.]

Aaron Sloman
http://www.cs.bham.ac.uk/~axs

Comment 10 aaronsloman 2012-03-22 17:30:32 UTC
(In reply to comment #9)

Sorry: correcting serious typo in above:

> Fedora 15 was originally installed on /dev/sda12
> Fedora 16 was later installed on /dev/sda12, 

The latter should have been /dev/sda13

Very sorry for any confusion.

Comment 11 Jim Swain 2012-03-25 03:29:57 UTC
Linux linuxnew 3.3.0-4.fc16.i686.PAE #1 SMP Tue Mar 20 18:24:16 UTC 2012 i686 i686 i386 GNU/Linux

With an installation of f16 (Verne) as an in-place update to f14:

.  On yum install of a new kernel, there is an error thrown 'grubby cannot find suitable template'; however, it does update grub.cfg (with correct reference to the default stanza for the hardware environment), but does not remove existing stanzas for items not in /boot

.  Following this error, executing # grub-mkconfig -o /boot/grub2/grub.cfg, corrects everything in the grub.cfg with regard to contents of /boot

Comment 12 Jim Swain 2012-03-25 03:37:16 UTC
Linux linuxnew 3.3.0-4.fc16.i686.PAE #1 SMP Tue Mar 20 18:24:16 UTC 2012 i686 i686 i386 GNU/Linux

With an installation of f16 (Verne) as an in-place update to f14:

.  On yum install of a new kernel, there is an error thrown 'grubby cannot find suitable template'; however, it does update grub.cfg (with correct reference to the default stanza for the hardware environment), but does not remove existing stanzas for items not in /boot

.  Following this error, executing # grub-mkconfig -o /boot/grub2/grub.cfg, corrects everything in the grub.cfg with regard to contents of /boot

Comment 13 aaronsloman 2012-04-03 23:35:05 UTC
A new entry in bug #751875 (comment 8) reveals that the wrong boot partition uuid can be copied from /etc/fstab to grub.cfg by grubby.

The error in fstab does not affect booting because fstab cannot be read before the root partition has been mounted. But copying an error from there to grub.cfg can be fatal, so grubby should be fixed.

grub2-mkconfig does not fall into that trap

Comment 14 Mads Kiilerich 2012-04-24 18:54:57 UTC
monts, do that explain your problem?

Otherwise please post the unedited output of blkid and the content of /etc/fstab and /boot/grub2/grub.cfg.

Comment 15 monts 2012-04-25 20:19:25 UTC
Well I am kinda late but should have closed the bug from my end. Nothing really worked as such back then... and I had to do a painful sector by sector copy recovery of my data which really took a long time. 

Once that was done and the data verified the entire hdd was low level formatted (just to make sure) and reinstalled using the same dvd, hardware combo.. and lo it worked .. even did a yum update few days back pulled almost 1gb of patches.. seems to work fine.. had to move on as that was a production install.. so I guess I really cannot shed more light as to what went wrong was it the hardware/setup or just a mystery bug etc.. 

Monts


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