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:
Found out that error is caused by: new-kernel-pkg --mkinitrd --depmod --install 2.6.5-1.358
never ever rpm -U a kernel... really.
Have you seen thsi happen again? Can you attach your grub.conf?
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.
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?
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.
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.
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
Created attachment 112008 [details] /boot/grub/grub.conf
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 ...
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.
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.
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.
*** Bug 124906 has been marked as a duplicate of this bug. ***
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.
In Fedora Core 6 I mean.
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
Still present.
Felipe, please read comment number #17 again. Unless you update Fedora's version field this bug will be closed as a 'WONTFIX'.
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.
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)
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
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
Please keep this open as it also is occurring in Fedora Core 9 as well.
I'm seeing this in F10 when doing a yum upgrade from F8.
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.
I don't see what's do difficult about this. Just don't use the old grub conf, have a separate template file.
*** Bug 484243 has been marked as a duplicate of this bug. ***
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?
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?
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.
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)'
*** Bug 497290 has been marked as a duplicate of this bug. ***
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.
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.
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.
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....
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
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 [...]
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
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.
(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
(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
Thanks for the patch Eric -- applied and built
(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
(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.
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
Seems like we could use more debugging output when this happens; there is likely more than one root cause. -Eric
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.
I assume you have a supported fs for /boot on the btrfs install, and not btrfs?
Yes. A completely default install, save for a btrfs root. I opened bug 530108 to replace this old (closed) bug.
I am using ext3 /boot and btrfs /. Anyway, F12 GRUB supports btrfs IIRC.
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....
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.
Please update the version on this bug. There should not be open bugs for version < 13 Regards.
Sorry. It is on Fedora 14 up to date.
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.
(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.
(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
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" ----------------------------------------------- :-\
fedora 15 on here
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
Got it on Fedora 15 when installing kernel-2.6.40.6-0.fc15.i686
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?
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 ###
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)
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
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.
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
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.
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
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
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
(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
/etc/grub2.conf: /etc/default/grub: GRUB_CMDLINE_LINUX="quiet rhgb" rpm -q grubby: grubby-8.3-1.fc16.x86_64
(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.
(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.
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?
Per comment #68, the grub.conf file doesn't need to be empty but also have a missing kernel, say from a f15 install.
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 ###
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.
I further deleted /boot/grub/grub.cfg, and this seems to have allowed things to install properly.
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.
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
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)
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
This problem transform itself into a different beast in GRUB2/F16: https://bugzilla.redhat.com/show_bug.cgi?id=723626
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?
I still see this problem (FC16). Eight years without resolution is kind of long....
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.
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
After 8 years, is the original reporter even around to clone the bug? He may well have died of old age.
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.
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.
Since the bug is (finally!) assigned to someone, that person can sort-out which component is principally at issue.
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.
(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.
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.
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.
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).
Shouldn't this be against the grubby component now? Also, I had forgotten that as of * Tue Dec 20 2011 Peter Jones <pjones> - 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 ;)
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.
(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.
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
(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.
This seems to have absolutely nothing to do with the original problem. Please open a new bug.