Bug 756559

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.

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).

> 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.

:) 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..

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

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.

(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.

*** Bug 733108 has been marked as a duplicate of this bug. ***

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

(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.

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

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

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

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.

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