Bug 124246 - grubby fatal error: unable to find a suitable template
grubby fatal error: unable to find a suitable template
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
FutureFeature
: Reopened
: 124906 484243 497290 (view as bug list)
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2004-05-24 20:44 EDT by Stephan Borg
Modified: 2015-02-04 11:09 EST (History)
40 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 799888 (view as bug list)
Environment:
Last Closed: 2012-10-30 11:27:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/boot/grub/grub.conf (461 bytes, text/plain)
2005-03-15 03:51 EST, Daniel L. Rall
no flags Details
grub2.cfg on Fedora 16 going from 3.1.0-7.fc16.x86_64 to 3.1.1-1.fc16.x86_64 kernel (2.95 KB, text/plain)
2011-11-14 03:25 EST, Lars E. Pettersson
no flags Details

  None (edit)
Description Stephan Borg 2004-05-24 20:44:24 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:
Upgraded from FC1 to FC2
Was dual boot FC1/WinXP - grub had entry for each.
After upgrade, no entry in grub to boot FC2.
Entered linux rescue mode and did a:
rpm -Uhv --force kernel-2.6.5-1.358.i386.rpm
and got
grubby fatal error: unable to find a suitable template

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
Normal boot entry in grub.conf

Additional info:
Comment 1 Stephan Borg 2004-05-24 20:47:18 EDT
Found out that error is caused by:
new-kernel-pkg --mkinitrd --depmod --install 2.6.5-1.358
Comment 2 Arjan van de Ven 2004-05-25 06:59:35 EDT
never ever rpm -U a kernel... really.
Comment 3 Jeremy Katz 2004-08-04 15:45:39 EDT
Have you seen thsi happen again?  Can you attach your grub.conf?
Comment 4 Stephan Borg 2004-08-04 16:17:11 EDT
No I haven't. I don't upgrade many FC1 to FC2 machines, and when I did
a few it only ever happened once. I'm happy for you to close this bug
if necessary.
Comment 5 Nicholas Miell 2004-09-21 19:57:18 EDT
When upgrading from FC2 with kernel-smp-whatever-584 to FC3t2 with
kernel-smp-whatever-541, I got the following in my upgrade.log:

Upgrading mkinitrd-4.1.11-1.x86_64.
Upgrading kernel-smp-2.6.8-1.541.x86_64.
grubby fatal error: unable to find a suitable template
grubby fatal error: unable to find a suitable template
grubby: doing this would leave no kernel entries. Not writing out new
config.

The end result was that the 541 kernel was installed, but only the 584
entry was in grub.conf, and thus an unbootable system.

And why can't non-privileged users change the bugzilla version tag?
Comment 6 W. Michael Petullo 2004-12-08 23:01:33 EST
In general, grubby really needs more fine grained error messages to
replace "grubby fatal error: unable to find a suitable template." 
This error message can be the result of more than a dozen different
return statements.
Comment 7 Thomas Frayne 2005-01-17 11:20:33 EST
I got this error running in FC3 with kernel 2.6.9-1.715_FC3smp while
using synaptic to apply an upgrade to 2.6.10-1.741_FC3smp.  The
problem is repeatable, even after rebooting, but I can still boot the
old kernel.
Comment 8 Daniel L. Rall 2005-03-15 03:47:46 EST
I got hit with this apt-get'ing a kernel update.  I'm left with an old
kernel installed (which I no longer have on disk), and a newer kernel
actually on disk, but not known about by grub.

$ uname -r
2.6.8-1.521
$ rpm -q kernel
kernel-2.6.10-1.766_FC3
kernel-2.6.10-1.770_FC3
$ ls /boot/
config-2.6.10-1.766_FC3      System.map-2.6.10-1.766_FC3
config-2.6.10-1.770_FC3      System.map-2.6.10-1.770_FC3
grub/                        vmlinuz-2.6.10-1.766_FC3

I'm attaching my /boot/grub/grub.conf.  Here's what my IDE partition
setup looks like:

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1         203      102280+  83  Linux
/dev/hda2             204      156736    78892632   83  Linux
/dev/hda3          156737      158816     1048320   82  Linux swap
Comment 9 Daniel L. Rall 2005-03-15 03:51:19 EST
Created attachment 112008 [details]
/boot/grub/grub.conf
Comment 10 Daniel L. Rall 2005-03-15 03:56:52 EST
The way I'm currently getting my kernel to boot is with a series of
commands from inside the grub shell:

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  16 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2
/grub/grub
.conf"... succeeded
Done.

grub> kernel ...
...
grub> boot
...
Comment 11 Daniel L. Rall 2005-03-15 04:06:26 EST
More interesting output from the same box:

$ sudo new-kernel-pkg --mkinitrd --depmod --install 2.6.10-1.770_FC3
grubby fatal error: unable to find a suitable template
$ sudo /sbin/grub-install --recheck /dev/hda Probing devices to guess
BIOS drives. This may take a long time.
The file /boot/grub/stage1 not read correctly.
Comment 12 Daniel L. Rall 2005-03-15 14:39:17 EST
Turns out my instance of this error was caused by "installation" of a
new kernel RPM into the /boot directory I use as a mount point for my
boot partition (/dev/hda1), _while that boot partition was not
mounted_.  After I cleaned the RPM-installed cruft out of my /boot
directory, I was able to re-mount my boot parition and use the boot
loader tools as usual (grub-install, grub, grubby, etc.).  I now know
way more than I ever wanted to know about grub...reminds me of some
similar antics with lilo.  ;)


p.s.  Nicholas, you can edit the commands executed by grub at boot
time by pressing "e" from the OS boot menu.  Change the version
numbers for your actually installed kernel to boot it instead of the
one known about by the MBR.  You can even correct the MBR using the
commands I outlined at the end of comment #10.
Comment 13 Matthew Miller 2005-04-26 11:34:33 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 14 John Thacker 2006-10-25 16:31:04 EDT
*** Bug 124906 has been marked as a duplicate of this bug. ***
Comment 15 Felipe Contreras 2007-03-21 12:31:46 EDT
This is still an issue.

Remove all your kernels, then: yum install kernel.

You won't be able to install another kernel with grubby unless you manually
create an entry in grub's configuration file.
Comment 16 Felipe Contreras 2007-03-21 12:34:10 EDT
In Fedora Core 6 I mean.
Comment 17 Bug Zapper 2008-04-03 21:50:25 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 18 Felipe Contreras 2008-04-04 04:59:39 EDT
Still present.
Comment 19 petrosyan 2008-04-04 16:48:08 EDT
Felipe, please read comment number #17 again.
Unless you update Fedora's version field this bug will be closed as a 'WONTFIX'.
Comment 20 Felipe Contreras 2008-04-07 05:50:50 EDT
This is crazy, you are making it almost impossible to keep bugs open.

You tried to change the Version field from 6 to 8, but only the owner or
submitter of the bug, or a authorized user, may change that field.
Comment 21 David Kvarnberg 2008-07-03 10:34:10 EDT
I get this too, on a FC8 box. 

I've stripped down my grub.conf to this:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.24.7-92.fc8)
        root (hd0,0)
        kernel /vmlinuz-2.6.24.7-92.fc8 ro root=LABEL=root
        initrd /initrd-2.6.24.7-92.fc8.img

A kernel update (via yum) runs:
/sbin/grubby --add-kernel=/boot/vmlinuz-2.6.25.9-40.fc8 --initrd
/boot/initrd-2.6.25.9-40.fc8.img --copy-default --make-default --title Fedora
(2.6.25.9-40.fc8) --args=root=LABEL=root  --remove-kernel=TITLE=Fedora
(2.6.25.9-40.fc8)

Which produces:
grubby fatal error: unable to find a suitable template

A strace on that command indicates that the last thing grubby does is write out
a new /etc/blkid/blkid.tab
I can get grubby to create a new entry without complaining if I remove
"--copy-default" from the command above, i.e. it's not totally broken.

Using mkinitrd-6.0.19-4.fc8.x86_64 (on an x86_64 system of course)
Comment 22 George R. Kasica 2008-07-17 23:21:53 EDT
I also see this since upgrading to FC9 with yum -upgrade. I did NOT have this 
problem prior to this on FC6-8. To get a new kernal to work I have to follow 
the below process once yum installs it:

Kernel fix for all new kernels
===============================
mount -o defaults --ro -t ext3 /dev/sda3 /sysroot

NOTE: img filename will change based on kernel version

cd /boot
mkdir newinit
cd newinit
gunzip -c ../initrd-2.6.25.10-86.fc9.i686.img | cpio -idmv
vi init

Find 'mount /sysroot' near end of file and replace it with line above and save 
file

find . | cpio --quiet -c -o > ../newinitrd
cd ..
mv initrd-2.6.25.10-86.fc9.i686.img initrd-2.6.25.10-86.fc9.i686.img.bak
gzip -9 < newinitrd > initrd-2.6.25.10-86.fc9.i686.img

vi grub/grub.conf to reflect new img and kernel filenames

reboot



when updating with yum:

 Installing     : kernel                                        [187/431] 
grubby fatal error: unable to find a suitable template
Comment 23 Bug Zapper 2008-11-26 01:47:31 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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
Comment 24 George R. Kasica 2008-12-02 12:27:18 EST
Please keep this open as it also is occurring in Fedora Core 9 as well.
Comment 25 Russell Odom 2008-12-10 13:09:08 EST
I'm seeing this in F10 when doing a yum upgrade from F8.
Comment 26 Eric Paris 2009-01-30 10:22:48 EST
Moving to rawhide as I just got this error on an F11 pre alpha install and then tried to use yum to update my kernel.
Comment 27 Felipe Contreras 2009-01-31 04:56:36 EST
I don't see what's do difficult about this. Just don't use the old grub conf, have a separate template file.
Comment 28 Hans de Goede 2009-02-05 14:56:15 EST
*** Bug 484243 has been marked as a duplicate of this bug. ***
Comment 29 Need Real Name 2009-02-05 16:00:29 EST
I am seeing the same problem after upgrading a system on software RAID-1 from Fedora 8 to 10. The Fedora 10 upgrade went fine except the boot loader upgrade option didn't work (which I have seen on other systems before). I took the usual route of repeating the upgrade but selecting the third option to install a new boot loader. Now the Fedora 10 installation boots fine but when I did the first yum update the rpm failed to install the entry in grub.conf with the error

grubby fatal error unable to find a suitable template

I noticed that I had a grub,conf.rpmsave with...

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.27.5-117.fc10.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.27.5-117.fc10.x86_64 ro root=/dev/md1 nodmraid rhgb quiet
        initrd /initrd-2.6.27.5-117.fc10.x86_64.img

but that the current grub.conf has...

default=0
timeout=0
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.27.5-117.fc10.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.27.5-117.fc10.x86_64 ro root=UUID=3adeca51-506e-4b51-aea7-c0ca9525ec36 nodmraid
        initrd /initrd-2.6.27.5-117.fc10.x86_64.img

I was able to manually add the new kernel to grub.conf using /dev/md1 for
root. I am assuming that the new use of the UUID label is screwing up attempt to add the grub entry when the new kernel is installed. I would also note that this
machine was originally installed with Windows RAID drivers by the vendor so that
I have to use nodmraid to keep dmraid from getting confused by the tattooing
on the drive. Perhaps this is related and the wrong labels are being read?
Any idea on how to debug this problem further?
Comment 30 Need Real Name 2009-02-05 21:36:20 EST
In case it helps, I get the following from /sbin/blkid...

/dev/md2: TYPE="swap" 
/dev/md0: UUID="0469a110-494a-499f-9a43-d4c821658e3b" SEC_TYPE="ext2" TYPE="ext3" 
/dev/md3: UUID="c73e4943-90d4-49af-baeb-3c91222b5131" SEC_TYPE="ext2" TYPE="ext3" 
/dev/md1: UUID="3adeca51-506e-4b51-aea7-c0ca9525ec36" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdb5: UUID="c73e4943-90d4-49af-baeb-3c91222b5131" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdb3: TYPE="swap" 
/dev/sdb2: UUID="3adeca51-506e-4b51-aea7-c0ca9525ec36" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdb1: UUID="0469a110-494a-499f-9a43-d4c821658e3b" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda5: UUID="c73e4943-90d4-49af-baeb-3c91222b5131" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda3: TYPE="swap" 
/dev/sda2: UUID="3adeca51-506e-4b51-aea7-c0ca9525ec36" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda1: UUID="0469a110-494a-499f-9a43-d4c821658e3b" SEC_TYPE="ext2" TYPE="ext3" 

Is it possible that grubby doesn't understand software raid-1 partitions when defined through a UUID rather than the traditional /dev/md# in the pre-existing grub.conf?
Comment 31 Nigel Jones 2009-02-10 14:54:36 EST
I'm getting this problem too. In my case it was occuring in F10, and is still occuring in rawhide

Same as above: (from yum output)
Installing : kernel 48/178
grubby fatal error: unable to find a suitable template
Installing : kernel-PAE 49/178
grubby fatal error: unable to find a suitable template


I think my sym link is ok
sh-4.0# ls -la menu.lst
lrwxrwxrwx 1 root root 11 2008-11-06 20:04 menu.lst -> ./grub.conf

My current menu.lst is
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/rootlv
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora 11 (2.6.29-0.96.rc3.git12.fc11.i686.PAE)
root (hd0,0)
kernel /vmlinuz-2.6.29-0.96.rc3.git12.fc11.i686.PAE ro nomodeset quiet
initrd /initrd-2.6.29-0.96.rc3.git12.fc11.i686.PAE.img

I have to update menu.lst manually each time. Tedious on rawhide :-(

COuld really do at least with grubby reporting a more useful error.
Comment 32 Carl Roth 2009-04-14 11:37:01 EDT
I built grubby/mkinitrd on a F11 rawhide system and turned on the grubby debugging to try to see what's the matter.

This system is using grubby from mkinitrd-6.0.81-1.fc11.

In my case, I'm trying to upgrade kernel-PAE-2.6.29.1-70.fc11.i686, where my existing GRUB configuration entry is

  default=0
  timeout=0
  splashimage=(hd0,0)/grub/splash.xpm.gz
  hiddenmenu
  title Fedora (2.6.29.1-68.fc11.i686.PAE)
          root (hd0,0)
          kernel /vmlinuz-2.6.29.1-68.fc11.i686.PAE ro root=/dev/mapper/hitachi0-root rhgb quiet
          initrd /initrd-2.6.29.1-68.fc11.i686.PAE.img

The failure appears to be in grubby.c:1087 (suitableImage)...  The nash library extracts the correct root device (/dev/mapper/hitachi0-root), but the stat calls around line 1144 don't think that the root device corresponds to the currently-mounted root filesystem.

    dev = nashGetPathBySpec(_nash_context, dev);
    if (!dev)
        return 0;

    i = stat(dev, &sb);
    if (i)
	return 0;

    stat("/", &sb2);

    if (sb.st_rdev != sb2.st_dev)
        return 0;

On my system, the last statement triggers, and suitableImage() returns with zero (i.e. not a suitable image)

The stat calls show sb (/dev/mapper/hitachi0-root) and sb2 (/) as

(gdb) p sb
$28 = {st_dev = 15, __pad1 = 0, st_ino = 705, st_mode = 25008, st_nlink = 1, 
  st_uid = 0, st_gid = 6, st_rdev = 64769, __pad2 = 0, st_size = 0, 
  st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1239649664, 
    tv_nsec = 304070388}, st_mtim = {tv_sec = 1239649664, 
    tv_nsec = 171003997}, st_ctim = {tv_sec = 1239649664, 
    tv_nsec = 171003997}, __unused4 = 0, __unused5 = 0}

(gdb) p sb2
$27 = {st_dev = 17, __pad1 = 0, st_ino = 256, st_mode = 16877, st_nlink = 1, 
  st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 168, 
  st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1239704224, 
    tv_nsec = 37719940}, st_mtim = {tv_sec = 1239649715, 
    tv_nsec = 958735685}, st_ctim = {tv_sec = 1239649715, 
    tv_nsec = 958735685}, __unused4 = 0, __unused5 = 0}

The offending command-line is

  grubby --add-kernel=/boot/vmlinuz-2.6.29.1-70.fc11.i686.PAE --initrd /boot/initrd-2.6.29.1-70.fc11.i686.PAE.img --copy-default --make-default --title 'Fedora (2.6.29.1-70.fc11.i686.PAE)' '--args=root=/dev/mapper/hitachi0-root ' '--remove-kernel=TITLE=Fedora (2.6.29.1-70.fc11.i686.PAE)'
Comment 33 Hans de Goede 2009-04-24 03:07:23 EDT
*** Bug 497290 has been marked as a duplicate of this bug. ***
Comment 34 Phil 2009-04-25 22:36:22 EDT
As per hdegoede's request from bug #497290 I've tried to eliminate everything by doing the following:

* creating a new grub.conf and typing a minimal setup.
* deleted the section that boots my windows install
* one by one deleting all boot sections until there are none left
* removing commands until the file is empty and trying different combinations
* ununhiding the menu
* modifying /etc/sysconfig/grub - previously this file referenced /dev/nvidia_abcdefgh instead of the actual dmraid device /dev/mapper/nvi... - to be either the propper dmfakeraid device or the actual block device of /dev/sda
* moving /etc/sysconfig/kernel to a temporary file - i.e. out of the way


To possibly help here's my current hardware setup:

Core2 E6750
6GB RAM
Asus Striker Extreme with nVidia 680i chipset
2x Raptors in fakeraid0
2x 750's in fakeraidJBOD
/ is BTRFS and part of an LVM


This is a completely fresh install and is the second complete install of the beta where this has happened.  I will be doing another reinstall in 2 days when the preview is released and will comment if the problem persists.
Comment 35 Tomasz Torcz 2009-05-06 04:29:44 EDT
Guys, I'm still getting this error on up-to-date fedora rawhide (soon to be 11). The common point is btrfs / on my machines.
Comment 36 Rolf Fokkens 2009-05-09 07:39:30 EDT
Same here: kernel upgrade results in " grubby fatal error: unable to find a suitable template".

initrd is created, but grub.conf is not changed. After changing grub.conf by hand, the system can reliably boot the new kernel.

Like the previous comments: root filesystem is btrfs.

This f11 installation is a virtual kvm based installation. For interrested people who want to reproduce this I could download the ~ 2GB image somewehere.
Comment 37 Eric Paris 2009-05-26 11:20:34 EDT
Did a little poking today,  btrfs_getattr has a line like:

static int btrfs_getattr(struct vfsmount *mnt,
                         struct dentry *dentry, struct kstat *stat)
{
        struct inode *inode = dentry->d_inode;
        generic_fillattr(inode, stat);
        stat->dev = BTRFS_I(inode)->root->anon_super.s_dev;

So btrfs (unlike every other fs in kernel) sets the dev themselves rather than using the dev from generic_fillattr.

I'm guessing (but haven't verified) that this is the reason the ->dev found when poking the block device is different than the dev btrfs is reporting and thus the rejection...

I just ask an upstream btrfs maintainer why they do this....
Comment 38 Bug Zapper 2009-06-09 05:06:33 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 39 sangu 2009-07-05 10:06:46 EDT
in rawhide < mkinitrd-6.0.90-1.fc12.x86_64 >
$ yum update kernel
[...]
get_netlink_msg returned Success
WARNING:  is a not a block device, skipping
get_netlink_msg returned No such file or directory
grubby fatal error: unable to find a suitable template
[...]
Comment 40 leigh scott 2009-07-16 10:18:46 EDT
Well with the attention this bug has received :-( I might as well get used to editing grub.conf by hand every kernel update.


    Installing     : kernel-2.6.31-0.67.rc2.git9.fc12.x86_64              295/826 
get_netlink_msg returned No such file or directory
get_netlink_msg returned No such file or directory
get_netlink_msg returned Success
WARNING:  is a not a block device, skipping
get_netlink_msg returned No such file or directory
grubby fatal error: unable to find a suitable template
  Updating       : python-2.6-10.fc12.x86_64
Comment 41 Eric Sandeen 2009-07-16 17:13:16 EDT
I'm hitting this in rawhide.  It looks like getpathbyspec() is fubar.

(disclaimer: despite owning blkid for 3 years I managed to never -really- look at it until it was dispatched to util-linux-ng \o/ !)

Anyway, getpathbyspec() is doing:

    if (!strncmp(device, "LABEL=", 6))
        return blkid_get_tag_value(blkid, "LABEL", device+6);
    else if (!strncmp(device, "UUID=", 5))
        return blkid_get_tag_value(blkid, "UUID", device+5);

but blkid_get_tag_value() returns the value of the tag specified in the 2nd arg for the device in the 3rd arg.  But we're passing in the UUID or the LABEL value itself in the 3rd arg.  So then blkid is going off trying to access "899c0289-ec5b-4143-8856-fc9eb0b8f798" and read it.

Replacing the above with:

Index: grubby-7.0/grubby.c
===================================================================
--- grubby-7.0.orig/grubby.c
+++ grubby-7.0/grubby.c
@@ -427,11 +427,7 @@ static char * getpathbyspec(char *device
     if (!blkid)
         blkid_get_cache(&blkid, NULL);
 
-    if (!strncmp(device, "LABEL=", 6))
-        return blkid_get_tag_value(blkid, "LABEL", device+6);
-    else if (!strncmp(device, "UUID=", 5))
-        return blkid_get_tag_value(blkid, "UUID", device+5);
-    return device;
+    return blkid_get_devname(blkid, device, NULL);
 }
 
 static enum lineType_e getTypeByKeyword(char * keyword, 

seems to work for me; blkid_get_devname(cache, token, <value>) returns the name of the device matching the token TOKEN=value string, or the device itself if "token" isn't a name, value pair.

Probably requires more testing, etc etc.
Comment 42 leigh scott 2009-07-16 19:35:30 EDT
(In reply to comment #41)

> seems to work for me; blkid_get_devname(cache, token, <value>) returns the name
> of the device matching the token TOKEN=value string, or the device itself if
> "token" isn't a name, value pair.
> 
> Probably requires more testing, etc etc.  

Thanks, I will give it a go and report back.


Here are some grubby rpm's with the patch.



http://leigh123linux.fedorapeople.org/pub/rpm/devel/



http://koji.fedoraproject.org/koji/taskinfo?taskID=1480779
Comment 43 leigh scott 2009-07-17 07:59:14 EDT
(In reply to comment #41)

> Probably requires more testing, etc etc. 


It fixes the problem here.


Transaction Test Succeeded
Running Transaction
  Installing     : kernel-2.6.31-0.69.rc3.fc12.x86_64                       1/1 
get_netlink_msg returned No such file or directory
get_netlink_msg returned No such file or directory
get_netlink_msg returned Success
WARNING:  is a not a block device, skipping
get_netlink_msg returned No such file or directory
Running DKMS auto installation service for kernel 2.6.31-0.69.rc3.fc12.x86_64

nvidia (185.18.14-2.1.fc12): Installing module.
......

Installed:
  kernel.x86_64 0:2.6.31-0.69.rc3.fc12                                          

Complete!
 



Thanks


Leigh
Comment 44 Jeremy Katz 2009-07-17 10:03:12 EDT
Thanks for the patch Eric -- applied and built
Comment 45 Eric Sandeen 2009-07-17 11:01:47 EDT
(In reply to comment #43)

...

> It fixes the problem here.

...

>   Installing     : kernel-2.6.31-0.69.rc3.fc12.x86_64      1/1 
...
> WARNING:  is a not a block device, skipping

^^^ hmm is that new?

-Eric
Comment 46 leigh scott 2009-07-17 11:45:25 EDT
(In reply to comment #45)
> (In reply to comment #43)
> 
> ...
> 
> > It fixes the problem here.
> 
> ...
> 
> >   Installing     : kernel-2.6.31-0.69.rc3.fc12.x86_64      1/1 
> ...
> > WARNING:  is a not a block device, skipping
> 
> ^^^ hmm is that new?
> 
> -Eric  

No, I was getting the "WARNING:  is a not a block device, skipping" before the grubby patch as well.
Comment 47 Tomasz Torcz 2009-08-20 09:01:14 EDT
Problem still persist in current rawhide:

(yum upgrade):

  Instalowanie   : kernel-2.6.31-0.162.rc6.git2.fc12.x86_64                                                                                                      4/8 
grubby fatal error: unable to find a suitable template


grubby-7.0.2-1.fc12.x86_64
dracut-0.9-1.fc12.noarch

mount output:
/dev/sda2 on / type btrfs (rw)


blkid output:
/dev/sda1: UUID="57f8b94e-dc62-42bf-96fd-b17c40bc0b53" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda2: LABEL="lnx_test" UUID="0af52868-6378-4511-ac3f-8076caca907d" TYPE="btrfs" UUID_SUB="c1cbea8e-f38d-4f2e-abef-3da6a9239346"


fstab:
UUID=0af52868-6378-4511-ac3f-8076caca907d /                       btrfs   defaults        1 1

grub/menu.lst:
title Fedora (2.6.31-0.125.4.2.rc5.git2.fc12.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.31-0.125.4.2.rc5.git2.fc12.x86_64 ro root=UUID=0af52868-6378-4511-ac3f-8076caca907d fastboot
	initrd /initrd-2.6.31-0.125.4.2.rc5.git2.fc12.x86_64.img
Comment 48 Eric Sandeen 2009-08-20 11:00:15 EDT
Seems like we could use more debugging output when this happens; there is likely more than one root cause.

-Eric
Comment 49 Jason Farrell 2009-10-21 00:41:20 EDT
I can confirm that this bug is still present in the f12 beta with grubby-7.0.8-1.fc12.i686 and using a btrfs root.

To Reproduce:
1) install the F12 beta to two VMs where one is ext4 and the other btrfs (icantbelieveitsnotbtr).
2) run "grubby --default-kernel" (or attempt to update the kernel and note that grub.conf isn't updated) to see if it's working right.

Actual results:
returns the kernel path of the default on ext4, but nothing if btrfs.
/boot/vmlinuz-2.6.31.1-56.fc12.i686.PAE

Expected:
should work everywhere.
Comment 50 Eric Sandeen 2009-10-21 11:58:13 EDT
I assume you have a supported fs for /boot on the btrfs install, and not btrfs?
Comment 51 Jason Farrell 2009-10-21 12:03:48 EDT
Yes. A completely default install, save for a btrfs root.

I opened bug 530108 to replace this old (closed) bug.
Comment 52 Tomasz Torcz 2009-10-21 12:42:55 EDT
I am using ext3 /boot and btrfs /. Anyway, F12 GRUB supports btrfs IIRC.
Comment 53 Eric Paris 2009-10-21 13:59:13 EDT
comment #32 and comment #37 together show the problem with a btrfs root.  These have been pasted in the new clean bug 530108 which I think would be the best place to get grubby (or btrfs) fixed....
Comment 54 Pavel Alexeev 2010-11-26 10:01:36 EST
I do not use btrfs, but LVM2.

Install new kernel-PAE from rawhide leading to me empty grub.conf and emit this message:
grubby fatal error: unable to find a suitable template.

I've manually fill grub.conf to fix boot, but reinstalling kernel still produce it error and do not add new kernel automatically to boot variants.
Comment 55 Jeff Raber 2010-12-03 18:16:26 EST
Please update the version on this bug.  There should not be open bugs for version < 13

Regards.
Comment 56 Pavel Alexeev 2010-12-04 01:43:42 EST
Sorry. It is on Fedora 14 up to date.
Comment 57 Aurelien Gouny 2011-02-24 21:52:44 EST
Bug is present on RHEL 6.0 as well, during kickstarting if customer rus "yum -y update" in post-scripts the new kernel package gets installed but not listed in grub.conf, same error message.
Comment 58 Charles R. Anderson 2011-04-15 13:41:28 EDT
(In reply to comment #57)
> Bug is present on RHEL 6.0 as well, during kickstarting if customer rus "yum -y
> update" in post-scripts the new kernel package gets installed but not listed in
> grub.conf, same error message.

I'm see this here as well.
Comment 59 Kenaniah Cerny 2011-07-08 18:32:33 EDT
(In reply to comment #57)
> Bug is present on RHEL 6.0 as well, during kickstarting if customer rus "yum -y
> update" in post-scripts the new kernel package gets installed but not listed in
> grub.conf, same error message.

Also verified. On my kickstarted RHEL 6.0 boxes that run "yum -y update" as a post script, the current kernel booted into is 2.6.32-71.24.1.el6.x86_64, but "rpm -q kernel" shows:

kernel-2.6.32-71.24.1.el6.x86_64
kernel-2.6.32-131.2.1.el6.x86_64
kernel-2.6.32-131.4.1.el6.x86_64
Comment 60 Rudd-O DragonFear 2011-07-18 14:17:03 EDT
I still see the problem:

-----------------------------------------------

[root@paola rudd-o]# blkid
/dev/sdb2: UUID="719e9278-0405-449e-b593-3228865f7b56" TYPE="swap" 
/dev/sda1: UUID="876e520c-f5a2-40c3-b35c-6152059b74d1" TYPE="ext2" 
/dev/sda2: UUID="07853650-9a6f-440a-b910-11cea7ca535b" TYPE="swap" 
/dev/sda3: LABEL="chest" UUID="12749222135303718268" UUID_SUB="4472025104474190775" TYPE="zfs_member" 
/dev/sdb3: LABEL="chest" UUID="12749222135303718268" UUID_SUB="3837049215699864745" TYPE="zfs_member" 
/dev/sdc1: UUID="f1264391-d00a-4848-8cff-7a32caea08e0" TYPE="ext4" 
/dev/sdc2: LABEL="transport" UUID="4839362822860547935" UUID_SUB="3710354366241419289" TYPE="zfs_member" 

-----------------------------------------------

:-\
Comment 61 Rudd-O DragonFear 2011-07-18 14:29:36 EDT
fedora 15 on here
Comment 62 devurandom 2011-09-18 04:12:58 EDT
Confirming for SL 6.1 and OpenVZ kernel:
  Installing : vzkernel-2.6.32-042stab037.1.x86_64
grubby fatal error: unable to find a suitable template
Comment 63 Slawomir Czarko 2011-10-06 15:37:38 EDT
Got it on Fedora 15 when installing kernel-2.6.40.6-0.fc15.i686
Comment 64 kevin martin 2011-10-31 17:41:52 EDT
Still happens with latest rawhide and grub2:

Running Transaction
  Updating   : kernel-debuginfo-common-x86_64-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                    1/19 
  Updating   : kernel-tools-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                      2/19 
  Updating   : kernel-tools-devel-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                3/19 
  Updating   : kernel-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                  4/19 
  Installing : kernel-debug-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                            5/19 
  Updating   : kernel-tools-debuginfo-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                            6/19 
  Installing : kernel-debug-devel-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                7/19 
  Updating   : kernel-headers-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                    8/19 
  Installing : kernel-devel-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                      9/19 
  Installing : kernel-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                           10/19 
grubby fatal error: unable to find a suitable template
  Installing : kernel-debug-3.2.0-0.rc0.git1.0.fc17.x86_64                                                                                     11/19 
grubby fatal error: unable to find a suitable template
  Cleanup    : kernel-tools-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64                                                                          12/19 
  Cleanup    : kernel-tools-devel-3.1.0-0.rc10.git0.1.fc17.x86_64                                                                              13/19 
  Cleanup    : kernel-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64                                                                                14/19 
  Cleanup    : kernel-debuginfo-common-x86_64-3.1.0-0.rc10.git0.1.fc17.x86_64                                                                  15/19 
  Cleanup    : kernel-3.1.0-0.rc9.git0.1.fc17.x86_64                                                                                           16/19 
grubby fatal error: unable to find a suitable template
grubby: doing this would leave no kernel entries. Not writing out new config.
  Cleanup    : kernel-headers-3.1.0-0.rc10.git0.1.fc17.x86_64                                                                                  17/19 
  Cleanup    : kernel-devel-3.1.0-0.rc9.git0.1.fc17.x86_64                                                                                     18/19 
  Cleanup    : kernel-tools-3.1.0-0.rc10.git0.1.fc17.x86_64                                                                                    19/19 
  Verifying  : kernel-tools-debuginfo-3.1.0-0.rc10.git0.1.fc17.x86_64                                                                          19/19 
VerifyTransaction time: 2.557
Transaction time: 598.320

Removed:
  kernel.x86_64 0:3.1.0-0.rc9.git0.1.fc17                                kernel-devel.x86_64 0:3.1.0-0.rc9.git0.1.fc17                               

Installed:
  kernel.x86_64 0:3.2.0-0.rc0.git1.0.fc17                                     kernel-debug.x86_64 0:3.2.0-0.rc0.git1.0.fc17                          
  kernel-debug-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17                     kernel-debug-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17                    
  kernel-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17                              

Updated:
  kernel-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17                     kernel-debuginfo-common-x86_64.x86_64 0:3.2.0-0.rc0.git1.0.fc17              
  kernel-headers.x86_64 0:3.2.0-0.rc0.git1.0.fc17                       kernel-tools.x86_64 0:3.2.0-0.rc0.git1.0.fc17                                
  kernel-tools-debuginfo.x86_64 0:3.2.0-0.rc0.git1.0.fc17               kernel-tools-devel.x86_64 0:3.2.0-0.rc0.git1.0.fc17  

This happens to be a home compiled kernel (to get rid of the debug code so I could install akmod-nvidia driver (since there's an unresolved error with nouveau) so this was a "yum localinstall kernel*rpm".  This bug has been open since 2004?
Comment 65 kevin martin 2011-10-31 17:44:04 EDT
Interestingly enough, it appears that it *did*, in fact, write out a new grub2/grub.cfg for the new kernel:

#
# 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="1"
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 {
true
}

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

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64.debug)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo 'Loading Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)'
	linux	/vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64.debug root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	echo 'Loading initial ramdisk ...'
	initrd /initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.debug.img
}
menuentry 'Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo 'Loading Fedora (3.2.0-0.rc0.git1.0.fc17.x86_64)'
	linux	/vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	echo 'Loading initial ramdisk ...'
	initrd /initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc9.git0.3.fc17.x86_64' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo	'Loading Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 ...'
	linux	/vmlinuz-3.1.0-0.rc9.git0.3.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.0-0.rc9.git0.3.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 (recovery mode)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo	'Loading Linux 3.1.0-0.rc9.git0.3.fc17.x86_64 ...'
	linux	/vmlinuz-3.1.0-0.rc9.git0.3.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro single nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.0-0.rc9.git0.3.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc10.git0.1.fc17.x86_64' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo	'Loading Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 ...'
	linux	/vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.0-0.rc10.git0.1.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 (recovery mode)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo	'Loading Linux 3.1.0-0.rc10.git0.1.fc17.x86_64 ...'
	linux	/vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro single nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.1.0-0.rc10.git0.1.fc17.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 7 (loader) (on /dev/sda1)" --class windows --class os {
	insmod part_msdos
	insmod ntfs
	set root='(hd0,msdos1)'
	search --no-floppy --fs-uuid --set=root 0A889E4D889E36E3
	chainloader +1
}
menuentry "Windows 7 (loader) (on /dev/sda2)" --class windows --class os {
	insmod part_msdos
	insmod ntfs
	set root='(hd0,msdos2)'
	search --no-floppy --fs-uuid --set=root B020C5A420C571C0
	chainloader +1
}
menuentry "Windows Recovery Environment (loader) (on /dev/sda3)" --class windows --class os {
	insmod part_msdos
	insmod ntfs
	set root='(hd0,msdos3)'
	search --no-floppy --fs-uuid --set=root F43CED0D3CECCBA4
	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 ###
### END /etc/grub.d/90_persistent ###
Comment 66 Lars E. Pettersson 2011-11-14 03:23:03 EST
Just did an update of Fedora 16 on a x86_64 machine and got the same message:

  Updating   : kernel-tools-3.1.1-1.fc16.x86_64                           13/26 
  Installing : kernel-3.1.1-1.fc16.x86_64                                 14/26 
grubby fatal error: unable to find a suitable template
  Cleanup    : kernel-headers-3.1.0-7.fc16.x86_64                         15/26 

(no further errors showed up)

This was the first kernel update on my Fedora 16 installation, updated from kernel 3.1.0-7.fc16.x86_64 to 3.1.1-1.fc16.x86_64 using the following grub packages:

# rpm -qa grub*
grub-efi-0.97-84.fc16.x86_64
grub2-1.99-12.fc16.x86_64
grubby-8.3-1.fc16.x86_64
#

And the following templates (verified OK with rpm -V)

# ll /etc/grub.d/
total 80
-rwxr-xr-x. 1 root root 6709 Oct 27 03:19 00_header
-rwxr-xr-x. 1 root root 5959 Oct 27 03:19 10_linux
-rwxr-xr-x. 1 root root 5875 Oct 27 03:19 20_linux_xen
-rwxr-xr-x. 1 root root 5960 Oct 27 03:19 30_os-prober
-rwxr-xr-x. 1 root root  214 Oct 27 03:19 40_custom
-rwxr-xr-x. 1 root root   95 Oct 27 03:19 41_custom
-rwxr-xr-x. 1 root root 1259 Oct 27 03:19 90_persistent
-rw-r--r--. 1 root root  483 Oct 27 03:19 README
#

The only strange thing noted in /etc/grub2.cfg was the lack of the recovery mode entry:

# grep menuentry /etc/grub2.cfg 
menuentry 'Fedora (3.1.1-1.fc16.x86_64)' --class gnu-linux --class gnu --class os {
menuentry 'Linux, with Linux 3.1.0-7.fc16.x86_64' --class gnu-linux --class gnu --class os {
menuentry 'Linux, with Linux 3.1.0-7.fc16.x86_64 (recovery mode)' --class gnu-linux --class gnu --class os {
menuentry "Microsoft Windows XP Professional (on /dev/sda2)" --class windows --class os {

(/etc/grub2.cfg will be attached)
Comment 67 Lars E. Pettersson 2011-11-14 03:25:32 EST
Created attachment 533458 [details]
grub2.cfg on Fedora 16 going from 3.1.0-7.fc16.x86_64 to 3.1.1-1.fc16.x86_64 kernel
Comment 68 Tomasz Torcz 2011-11-14 03:55:40 EST
This error can have various cases. Originally it was caused by some funky use of device pointers in btrfs.

What you are seeing right know probably is not an error. grubby updates all grub config file it finds - /boot/grub/menu.lst and /boot/grub2/grub.cfg. After going to F16 with grub2, you probably have grub1 config empty. The error emitted is from parsing empty grub1 config. As you shown, grub2 config file is updated correctly.
If you delete grub1 config file, warning should go away.
Comment 69 Robert Hinson 2011-11-14 06:54:24 EST
It isn't a 64 bit issue either.

  Installing : kernel-PAE-3.1.1-1.fc16.i686                               19/35
grubby fatal error: unable to find a suitable template
Comment 70 Lars E. Pettersson 2011-11-15 02:43:12 EST
Tomasz, you are quite correct. On another computer I removed (moved) /boot/grub and /etc/grub.conf before doing the update of the kernel, and did not get the error message. I.e. my problem was caused by old configuration files laying around when using grub2. So in my case, just an annoying error message, and not a real error/problem.
Comment 71 Sergio Monteiro Basto 2011-11-16 20:27:56 EST
from bug #730357
just edit /etc/default/grub
and put something like:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.lvm.lv=VolGroup/lv_swap quiet
SYSFONT=latarcyrheb-sun16 rd.lvm.lv=VolGroup/lv_root rd.luks=0 
KEYTABLE=pt-latin1 LANG=en_US.UTF-8"

will fix the problem of grub2.

btw in grub (1) you just need have a 
valid kernel entry on /boot/grub/grub.conf IIRC. 

but you should close this bug and move on
Comment 72 Pascal Schott 2011-11-20 03:18:41 EST
I experience this bug width grub legacy on Fedora 16 "preupgraded" from Fedora 14. My /boot/grub/grub.conf contains the following :

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /, eg.
#          root (hd0,6)
#          kernel /boot/vmlinuz-version ro root=root=UUID=eaee1e77-52cd-493a-b53
8-80eee09f03c2
#          initrd /boot/initramfs-version.img
#boot=/dev/sda7

default=0
timeout=10
splashimage=(hd0,6)/boot/grub/splash.xpm.gz
hiddenmenu

title Fedora (3.1.0-7.fc16.i686)
root (hd0,6)
kernel /boot/vmlinuz-3.1.0-7.fc16.i686 ro root=UUID=eaee1e77-52cd-493a-b538-80ee
e09f03c2  LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr
 rhgb quiet
initrd /boot/initramfs-3.1.0-7.fc16.i686.img
title Fedora (3.1.1-2.fc16.i686)
root (hd0,6)
kernel /boot/vmlinuz-3.1.1-2.fc16.i686 ro root=UUID=eaee1e77-52cd-493a-b538-80ee
e09f03c2  LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr
 rhgb quiet
initrd /boot/initramfs-3.1.1-2.fc16.i686.img
Comment 73 Edouard Bourguignon 2011-11-25 02:40:15 EST
Same here, here is my grub.conf:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,2)
#          kernel /vmlinuz-version ro root=/dev/sda7
#          initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,2)/grub/splash.xpm.gz
hiddenmenu
title Fedora (3.1.2-1.fc16.x86_64)
	root (hd0,2)
	kernel /vmlinuz-3.1.2-1.fc16.x86_64 ro root=UUID=9853f256-cc2a-42c4-8d14-8adcd3d54121 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rhgb quiet acpi_osi=Linux usbcore.autosuspend=1 pcie_aspm=force
	initrd /initramfs-3.1.2-1.fc16.x86_64.img
title Fedora (3.1.1-1.fc16.x86_64)
	root (hd0,2)
	kernel /vmlinuz-3.1.1-1.fc16.x86_64 ro root=UUID=9853f256-cc2a-42c4-8d14-8adcd3d54121 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rhgb quiet acpi_osi=Linux usbcore.autosuspend=1 pcie_aspm=force
	initrd /initramfs-3.1.1-1.fc16.x86_64.img
Comment 74 Sergio Monteiro Basto 2011-11-25 04:37:45 EST
(In reply to comment #73)
> Same here, here is my grub.conf:
> 
> # grub.conf generated by anaconda
> #
> # Note that you do not have to rerun grub after making changes to this file
> # NOTICE:  You have a /boot partition.  This means that
> #          all kernel and initrd paths are relative to /boot/, eg.
> #          root (hd0,2)
> #          kernel /vmlinuz-version ro root=/dev/sda7
> #          initrd /initrd-[generic-]version.img
> #boot=/dev/sda
> default=0
> timeout=5
> splashimage=(hd0,2)/grub/splash.xpm.gz
> hiddenmenu
> title Fedora (3.1.2-1.fc16.x86_64)
>  root (hd0,2)
>  kernel /vmlinuz-3.1.2-1.fc16.x86_64 ro
> root=UUID=9853f256-cc2a-42c4-8d14-8adcd3d54121 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> KEYTABLE=fr-latin9 rhgb quiet acpi_osi=Linux usbcore.autosuspend=1
> pcie_aspm=force
>  initrd /initramfs-3.1.2-1.fc16.x86_64.img
> title Fedora (3.1.1-1.fc16.x86_64)
>  root (hd0,2)
>  kernel /vmlinuz-3.1.1-1.fc16.x86_64 ro
> root=UUID=9853f256-cc2a-42c4-8d14-8adcd3d54121 rd_NO_LUKS rd_NO_LVM rd_NO_MD
> rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> KEYTABLE=fr-latin9 rhgb quiet acpi_osi=Linux usbcore.autosuspend=1
> pcie_aspm=force
>  initrd /initramfs-3.1.1-1.fc16.x86_64.img

and /etc/grub2.cfg 
and /etc/default/grub 
and rpm -q grubby
F16 move to grub2
Comment 75 Edouard Bourguignon 2011-11-26 05:33:47 EST
/etc/grub2.conf:

/etc/default/grub:
GRUB_CMDLINE_LINUX="quiet rhgb"

rpm -q grubby:
grubby-8.3-1.fc16.x86_64
Comment 76 josip@icase.edu 2011-11-26 14:58:42 EST
(In reply to comment #72)
> I experience this bug width grub legacy on Fedora 16 "preupgraded" from Fedora
> 14. [...]

Same here, "preupgraded" from Fedora 15.  The "preupgrade" process didn't update grub.conf so it would presumably be stuck in preupgrade on subsequent reboot.  Removing/reinstalling the kernel produced the error message:

"grubby fatal error: unable to find a suitable template"

which may be the cause of preupgrade problem.
Comment 77 josip@icase.edu 2011-11-26 15:20:26 EST
(In reply to comment #76)
> (In reply to comment #72)
> > I experience this bug width grub legacy on Fedora 16 "preupgraded" from Fedora
> > 14. [...]
> 
> Same here, "preupgraded" from Fedora 15.  The "preupgrade" process didn't
> update grub.conf so it would presumably be stuck in preupgrade on subsequent
> reboot.  Removing/reinstalling the kernel produced the error message:
> 
> "grubby fatal error: unable to find a suitable template"
> 
> which may be the cause of preupgrade problem.

Yes, F16 uses grub2, but settings for grub2 are not updated on installing Memtest86+ (see bug 729197), and "yum install kernel-PAE-3.1.2-1.fc16.i686" produces the above message under current Fedora 16 + grub2 installation.  This shows that grub2 specific installation steps are broken in a number of F16 RPMs.
Comment 78 John Ellson 2011-12-02 08:52:55 EST
I still got this error with fc17 this morning:
   kernel-3.2.0-0.rc3.git0.1.fc17.i686
   grubby-8.3-1.fc17.i686
   
Finally, after spending too long reading this tome, I found comment #68,
removed /boot/grub2/grub.cfg, reinstalled the kernel, and the problem seems to have cleared.

Why after *7 years* are the grubby error messages not improved?    How hard can it be for grubby to report that "/boot/grub2/grub.cfg is empty".   Or if it is benign, why not just remove it without generating an error?
Comment 79 pnelsonsr 2011-12-07 16:31:39 EST
Per comment #68, the grub.conf file doesn't need to be empty but also have a missing kernel, say from a f15 install.
Comment 80 kevin martin 2011-12-07 16:45:40 EST
FWIW, I'm no longer seeing the grubby fatal message in rawhide; the only problem I'm seeing with grub2 at this point is that the echo "Loading" line isn't getting updated with the latest kernel info.   For example, I updated today and my grub2/grub.cfg file shows this:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (3.2.0-0.rc4.git4.2.fc17.x86_64)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo 'Loading Fedora (3.2.0-0.rc0.git3.0.fc17.x86_64)'
	linux	/vmlinuz-3.2.0-0.rc4.git4.2.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro log_buf_len=16M  nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	echo 'Loading initial ramdisk ...'
	initrd /initramfs-3.2.0-0.rc4.git4.2.fc17.x86_64.img
}
menuentry 'Fedora (3.2.0-0.rc4.git2.1.fc17.x86_64)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo 'Loading Fedora (3.2.0-0.rc0.git3.0.fc17.x86_64)'
	linux	/vmlinuz-3.2.0-0.rc4.git2.1.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro log_buf_len=16M  nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	echo 'Loading initial ramdisk ...'
	initrd /initramfs-3.2.0-0.rc4.git2.1.fc17.x86_64.img
}
menuentry 'Fedora (3.2.0-0.rc4.git0.2.fc17.x86_64)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo 'Loading Fedora (3.2.0-0.rc0.git3.0.fc17.x86_64)'
	linux	/vmlinuz-3.2.0-0.rc4.git0.2.fc17.x86_64 root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro log_buf_len=16M  nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
	echo 'Loading initial ramdisk ...'
	initrd /initramfs-3.2.0-0.rc4.git0.2.fc17.x86_64.img
}
menuentry 'Linux, with Linux 3.2.0-0.rc0.git1.0.fc17.x86_64.debug' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo	'Loading Linux 3.2.0-0.rc0.git1.0.fc17.x86_64.debug ...'
	linux	/vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64.debug root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M  rdblacklist.nouveau=1
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.debug.img
}
menuentry 'Linux, with Linux 3.2.0-0.rc0.git1.0.fc17.x86_64.debug (recovery mode)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set=root 5fa84efc-2093-49a8-a997-98bb79a345e3
	echo	'Loading Linux 3.2.0-0.rc0.git1.0.fc17.x86_64.debug ...'
	linux	/vmlinuz-3.2.0-0.rc0.git1.0.fc17.x86_64.debug root=UUID=abf1eb35-0fe0-4e2c-8ee5-c6542ace2c85 ro single nouveau.noaccel=1 nouveau.vram_pushbuf=1 nouveau.vram_notify=1 log_buf_len=16M
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.2.0-0.rc0.git1.0.fc17.x86_64.debug.img
}
menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {
	insmod part_msdos
	insmod ntfs
	set root='(hd0,msdos1)'
	search --no-floppy --fs-uuid --set=root 0A889E4D889E36E3
	chainloader +1
}
menuentry "Windows 7 (loader) (on /dev/sda2)" --class windows --class os {
	insmod part_msdos
	insmod ntfs
	set root='(hd0,msdos2)'
	search --no-floppy --fs-uuid --set=root B020C5A420C571C0
	chainloader +1
}
menuentry "Windows Recovery Environment (loader) (on /dev/sda3)" --class windows --class os {
	insmod part_msdos
	insmod ntfs
	set root='(hd0,msdos3)'
	search --no-floppy --fs-uuid --set=root F43CED0D3CECCBA4
	drivemap -s (hd0) ${root}
	chainloader +1
}
### END /etc/grub.d/30_os-prober ###
Comment 81 Amazed 2011-12-17 23:41:36 EST
I am getting this message with FC 16 when attempting to up-date from kernel-3.1.5-2.fc16.i686 and kernel-PAE-3.1.5-2.fc16.i686 to kernel-3.1.5-6.fc16.i686 and kernel-PAE-3.1.5-6.fc16.i686.  After install, the system crashes when it attempts to boot the new default (PAE-3.1.5-6).

Removing memtest86+ and deleting /boot/grub2/grub.cfg and /etc/grub.d/40_custom failed to prevent this problem when installation was again attempted.

Removing all kernels and reinstalling did not resolve the error.
Comment 82 Amazed 2011-12-17 23:57:59 EST
I further deleted /boot/grub/grub.cfg, and this seems to have allowed things to install properly.
Comment 83 Need Real Name 2011-12-18 11:39:59 EST
Same thing here 
kernel-3.1.5-1.fc16.x86_64
kernel-3.1.5-2.fc16.x86_64
kernel-3.1.5-6.fc16.x86_64

yum -y update
.....
  Installing : json-c-0.9-2.fc15.x86_64                                   21/69 
  Installing : libreport-plugin-bodhi-2.0.8-3.fc16.x86_64                 22/69 
  Installing : kernel-3.1.5-6.fc16.x86_64                                 23/69 
grubby fatal error: unable to find a suitable template
.........

 Cleanup    : kernel-3.1.4-1.fc16.x86_64                                 64/69 
grubby fatal error: unable to find a suitable template
grubby: doing this would leave no kernel entries. Not writing out new config.
Comment 84 Need Real Name 2011-12-18 11:43:24 EST
cat /etc/grub.conf 
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda2
#          initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=10
#splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title Fedora (3.1.5-6.fc16.x86_64)
	root (hd0,0)
	kernel /vmlinuz-3.1.5-6.fc16.x86_64 ro root=UUID=89be489d-85de-42ba-b932-0a12e0aba9d0 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset nomodeset drm.debug=0x04
	initrd /initramfs-3.1.5-6.fc16.x86_64.img
title Fedora (3.1.5-2.fc16.x86_64)
	root (hd0,0)
	kernel /vmlinuz-3.1.5-2.fc16.x86_64 ro root=UUID=89be489d-85de-42ba-b932-0a12e0aba9d0 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset nomodeset drm.debug=0x04
	initrd /initramfs-3.1.5-2.fc16.x86_64.img
title Fedora (3.1.5-1.fc16.x86_64)
	root (hd0,0)
	kernel /vmlinuz-3.1.5-1.fc16.x86_64 ro root=UUID=89be489d-85de-42ba-b932-0a12e0aba9d0 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset nomodeset drm.debug=0x04
	initrd /initramfs-3.1.5-1.fc16.x86_64.img
Comment 85 Need Real Name 2011-12-18 11:44:28 EST
 rpm -q grubby --last
grubby-8.4-1.fc16                             Thu 15 Dec 2011 07:09:34 AM EST
(compiled from rawhide when trying to prevent the warning)
Comment 86 Need Real Name 2011-12-18 12:03:16 EST
diag:
/sbin/new-kernel-pkg -v  --mkinitrd  --dracut --depmod --update  3.1.5-6.fc16.x86_64

initrdfile is /boot/initramfs-3.1.5-6.fc16.x86_64.img
running depmod for 3.1.5-6.fc16.x86_64
creating initrd: /sbin/dracut  -f /boot/initramfs-3.1.5-6.fc16.x86_64.img 3.1.5-6.fc16.x86_64
found /boot/initramfs-3.1.5-6.fc16.x86_64.img and using it with grubby
updating 3.1.5-6.fc16.x86_64 from /boot/grub/grub.conf
updating 3.1.5-6.fc16.x86_64 from /boot/grub2/grub.cfg
grubby fatal error: unable to find a suitable template
grubby: doing this would leave no kernel entries. Not writing out new config.
/etc/grub2-efi.cfg does not exist, not running grubby
/etc/lilo.conf does not exist, not running grubby
 does not exist, not setting up 
/etc/extlinux.conf does not exist, not running grubby

The file 
ls -l /boot/grub2/grub.cfg
-rw-r--r--. 1 root root 0 Oct 26 21:19 /boot/grub2/grub.cfg

is empty. Should it just be removed or grub.conf should be removed?

ls -l /boot/grub/grub.conf 
-rw-------. 1 root root 1372 Dec 18 12:00 /boot/grub/grub.conf

the grub.conf is above
Comment 87 Rudd-O DragonFear 2012-01-31 20:35:59 EST
This problem transform itself into a different beast in GRUB2/F16:

https://bugzilla.redhat.com/show_bug.cgi?id=723626
Comment 88 Amazed 2012-01-31 20:53:21 EST
Rudd-O DragonFear—

The symptoms reported here (bug 124246) are present in grub2 on Fedora Core 16.  On what basis are you claiming that the symptoms that you reported as bug 723626 are to be regarded as a transformation of this bug?
Comment 89 josip@icase.edu 2012-08-02 09:05:37 EDT
I still see this problem (FC16).  Eight years without resolution is kind of long....
Comment 90 Eric Sandeen 2012-08-02 12:55:51 EDT
IMHO grubby just needs better error reporting (maybe a verbose switch) to explain why it failed, rather than issuing the fairly useless message it issues today.
Comment 91 Fedora End Of Life 2012-08-16 17:42:33 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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" (top right of this page) 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
Comment 92 Amazed 2012-08-16 21:56:52 EDT
After 8 years, is the original reporter even around to clone the bug?  He may well have died of old age.
Comment 93 Amazed 2012-08-16 23:03:39 EDT
Please refer to comment #20 (2008-04-07 05:50:50 EDT).

[1] This bug is so old that it would be grossly unreasonable to expect the original reporter to clone it.

[2] From comments, we see that the bug was biting with FC 16, which has not reached its EoL.

An ordinary user could open a new bug report, but that would obscure how long this bug has gone without being addressed.

Just as Bug Zapper changed the version number on at least one earlier occasion,  Fedora End Of Life should change the version number now.
Comment 94 Rob Riggs 2012-08-25 08:24:24 EDT
I have this problem now on F17 after upgrading from F15.  Platform is x86_64.

Does this now belong to the dracut or grubby package?  I don't think the current component is accurate anymore.
Comment 95 Amazed 2012-08-25 17:16:17 EDT
Since the bug is (finally!) assigned to someone, that person can sort-out which component is principally at issue.
Comment 96 Sergio Monteiro Basto 2012-08-25 21:33:17 EDT
The initial comments of this report , doesn't have nothing with grub2 , which is the real problem now.
So my advice is close this bug as EOL . 
a follow bug #730357
in meantime I'm out of this report.
Comment 97 Amazed 2012-08-26 01:52:40 EDT
(In reply to comment #96)

> The initial comments of this report , doesn't have nothing with grub2 ,

grub2 is plainly a version of grub.  The bug is plainly the same bug, whatever the component is principally at issue.

> So my advice is close this bug as EOL . 

This bug is biting with FC 17 (see comment #94) which, far from being past EoL, is the most recent "stable" release.

> a follow bug #730357

Better to mark bug #730357 as a duplicate of this bug.  Let's not pretend that it this is a new bug; it is over 8 years old.  Wiping the slate for a bug that went so long without being worked does not seem like a good idea.
Comment 98 Mads Kiilerich 2012-08-26 10:32:20 EDT
This bug has nothing to do with the initrd component.

The error message is a generic error message that grubby will use whenever shit happens. The message is thus a _symptom_ of some problem, but all the "me too"'s here will probably have different root causes and different solutions.

3 main places this message is seen:

* When installing a new system from scratch and kernel installation can't clone any existing boot loader entry because they haven't been created yet - bug 730357 started with that.

* When the system have some of /etc/grub.cfg and /etc/grub2.conf and /etc/grub2-efi.conf pointing to an invalid and unused configuration. Grubby will complain that it was fatal for _one_ of the boot loader configurations, but it doesn't matter at all as long the right boot loader is handled correctly ... and it usually is. Just uninstall the boot loaders you don't use and/or remove the unused symlinks.

* When not using an initrd and grubby gets confused by inconsistencies in the system - Bug 833011.

I suggest leaving this bug closed.

If you see this symptom for other reasons than the one mentioned above then better file a separate bug so we don't get the different cases mixed up.
Comment 99 Amazed 2012-08-28 08:03:25 EDT
If the bug here were fixed, then we could be assured that the component were properly identified and that this bug were not the same bug as others are reporting elsewhere.  Otherwise, it would seem that the report were being closed as perverse response to the the opacity of the error message.
Comment 100 josip@icase.edu 2012-09-23 10:04:50 EDT
Grubby must provide enough information to help a Linux administrator identify the source of the problem.  Just giving up with a generic message is unacceptable because if the problem can't be tracked to a more precise source, it can't be fixed -- as evidenced by 8+ years of complaints.

I vote to keep this bug open and to FIX the uninformative grubby message(s).
Comment 101 Eric Sandeen 2012-09-23 11:01:02 EDT
Shouldn't this be against the grubby component now?

Also, I had forgotten that as of 

* Tue Dec 20 2011 Peter Jones <pjones@redhat.com> - 8.7-1
- Add a --debug to try to help diagnose "No suitable template". (sandeen,pjones)

you guys could try --debug to see what has really gone wrong, and report new info if it helps.

You'll get such info as:

"marked to skip" or ""no line found" or "line has only %d elements" or ""access to %s failed" or many others.

It's entirely possible that the failure is due to some system change or misconfiguration, and not a bug in grubby at all.

Peter, maybe a hint in the standard output would be good:

   "No suitable template found; rerun with --debug for more info."

I'll send a patch ;)
Comment 102 Eric Sandeen 2012-09-23 11:35:07 EDT
And, if the new info reported doesn't point to a problem with mkinitrd/grubby but some other problem, and grubby is just the messenger, I'd really suggest not adding that info to this poor old bug.
Comment 103 Mads Kiilerich 2012-09-23 18:50:08 EDT
(In reply to comment #101)

This old messy closed-but-resurrected bug is perhaps not the best place to discuss any specific problem or improvements to the situation in general, but:

I doubt many users would know where to add that --debug option; they just run rpm/yum/somefancygui and install a new kernel. Even the current error message would make a lot more sense if the user knew which command was being run.

Some option in /etc/sysconfig/kernel that makes new-kernel-pkg show what it is doing and turn on debugging would perhaps be a prerequisite for making an actual improvement.

A remaining problem would be that half of grubby runs in posttrans where all output is sent to /dev/null. It would perhaps be better to log with syslog.
Comment 104 Benjamin Kosnik 2012-10-29 01:25:28 EDT
Seeing this now on F17/x86_64 with efi:

 Installing : kernel-3.6.3-1.fc17.x86_64                                 32/64 
grubby: error creating /boot/efi/EFI/redhat/grub.conf-: Read-only file system
  Cleanup    : 1:xscreensaver-5.19-3.fc17.x86_64                          33/64 
  Cleanup    : 2:perl-DateTime-0.70-3.fc17.x86_64                         34/64 
  Cleanup    : perl-DateTime-TimeZone-1.49-1.fc17.noarch                  35/64 
  Cleanup    : openldap-devel-2.4.32-3.fc17.x86_64                        36/64 
  Cleanup    : akonadi-mysql-1.8.0-1.fc17.x86_64                          37/64 
  Cleanup    : 1:xscreensaver-extras-5.19-3.fc17.x86_64                   38/64 
  Cleanup    : 1:xscreensaver-gl-extras-5.19-3.fc17.x86_64                39/64 
  Cleanup    : imsettings-gnome-1.2.9-1.fc17.x86_64                       40/64 
  Cleanup    : imsettings-1.2.9-1.fc17.x86_64                             41/64 
  Cleanup    : imsettings-qt-1.2.9-1.fc17.x86_64                          42/64 
  Cleanup    : 1:xscreensaver-extras-base-5.19-3.fc17.x86_64              43/64 
  Cleanup    : 1:xscreensaver-gl-base-5.19-3.fc17.x86_64                  44/64 
  Cleanup    : openldap-clients-2.4.32-3.fc17.x86_64                      45/64 
  Cleanup    : openldap-2.4.32-3.fc17.x86_64                              46/64 
  Cleanup    : nss-tools-3.13.5-1.fc17.x86_64                             47/64 
  Cleanup    : nss-3.13.5-1.fc17.x86_64                                   48/64 
  Cleanup    : nss-sysinit-3.13.5-1.fc17.x86_64                           49/64 
  Cleanup    : nss-softokn-3.13.5-1.fc17.x86_64                           50/64 
  Cleanup    : 2:vim-enhanced-7.3.638-2.fc17.x86_64                       51/64 
  Cleanup    : kernel-devel-3.5.3-1.fc17.x86_64                           52/64 
  Cleanup    : kernel-headers-3.6.2-4.fc17.x86_64                         53/64 
  Cleanup    : kernel-3.5.3-1.fc17.x86_64                                 54/64 
grubby fatal error: unable to find a suitable template
grubby: error creating /boot/efi/EFI/redhat/grub.conf-: Read-only file system
  Cleanup    : 2:vim-common-7.3.638-2.fc17.x86_64
Comment 105 Mads Kiilerich 2012-10-29 09:48:24 EDT
(In reply to comment #104)

In this case grubby explained clearly what the problem was.

Please file a new bug report. Especially if there is some good reason your /boot/efi is read-only.

This is a consequence of the (in my opinion very unfortunate) design decision that the EFI boot loader uses a grub.cfg that isn't /boot/grub2/grub.cfg.
Comment 106 Peter Jones 2012-10-30 11:27:04 EDT
This seems to have absolutely nothing to do with the original problem.  Please open a new bug.

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