I’m trying to fix my system after moving it from one server to another. It works perfectly with kernel booted via network, but not from the disk.
Reinstalling stock CentOS 6.6 kernel shows this error:
grubby fatal error: unable to find a suitable template
My /boot/grub/grub.conf file looks fine:
default=0
timeout=5
title linux centos6_64
kernel /vmlinuz-2.6.32-504.8.1.el6.x86_64 root=/dev/sda3 ro crashkernel=auto SYSFONT=latarcyrheb-sun16 LANG=pl_PL.UTF-8 KEYTABLE=pl
root (hd0,1)
initrd /initramfs-2.6.32-504.8.1.el6.x86_64.img
All files are in place:
ls -l /boot
razem 24645
-rw-r--r-- 1 root root 106312 01-28 22:40 config-2.6.32-504.8.1.el6.x86_64
drwxr-xr-x 3 root root 1024 2011-07-08 efi
drwxr-xr-x 2 root root 1024 03-06 13:44 grub
-rw------- 1 root root 18227613 03-06 13:44 initramfs-2.6.32-504.8.1.el6.x86_64.img
-rw-r--r-- 1 root root 200245 01-28 22:41 symvers-2.6.32-504.8.1.el6.x86_64.gz
-rw-r--r-- 1 root root 2544888 01-28 22:40 System.map-2.6.32-504.8.1.el6.x86_64
-rwxr-xr-x 1 root root 4153008 01-28 22:40 vmlinuz-2.6.32-504.8.1.el6.x86_64
ls -l /boot/grub/
razem 259
-rw-r--r-- 1 root root 15 03-02 20:55 device.map
-rw-r--r-- 1 root root 63 2011-07-08 device.map.backup
-rw-r--r-- 1 root root 13396 03-06 13:05 e2fs_stage1_5
-rw-r--r-- 1 root root 12636 03-06 13:05 fat_stage1_5
-rw-r--r-- 1 root root 11780 03-06 13:05 ffs_stage1_5
-rw------- 1 root root 242 03-06 13:44 grub.conf
-rw-r--r-- 1 root root 11772 03-06 13:05 iso9660_stage1_5
-rw-r--r-- 1 root root 13284 03-06 13:05 jfs_stage1_5
lrwxrwxrwx 1 root root 11 03-06 13:04 menu.lst -> ./grub.conf
-rw-r--r-- 1 root root 11972 03-06 13:05 minix_stage1_5
-rw-r--r-- 1 root root 14428 03-06 13:05 reiserfs_stage1_5
-rw-r--r-- 1 root root 1341 2010-11-14 splash.xpm.gz
-rw-r--r-- 1 root root 512 03-06 13:05 stage1
-rw-r--r-- 1 root root 126116 03-06 13:05 stage2
-rw-r--r-- 1 root root 12040 03-06 13:05 ufs2_stage1_5
-rw-r--r-- 1 root root 11380 03-06 13:05 vstafs_stage1_5
-rw-r--r-- 1 root root 13980 03-06 13:05 xfs_stage1_5
/etc/fstab looks fine too:
cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/sda3 / ext4 rw,noatime,nodiratime,usrjquota=aquota.user,grpjquota=aquota.group,usrquota,grpquota,jqfmt=vfsv0 0 1
/dev/sda2 /boot ext4 errors=remount-ro 0 1
/dev/sda4 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
How to resolve this ?
I’m trying to fix my system after moving it from one server to another. It works perfectly with kernel booted via network, but not from the disk.
Reinstalling stock CentOS 6.6 kernel shows this error:
grubby fatal error: unable to find a suitable template
My /boot/grub/grub.conf file looks fine:
default=0
timeout=5
title linux centos6_64
kernel /vmlinuz-2.6.32-504.8.1.el6.x86_64 root=/dev/sda3 ro crashkernel=auto SYSFONT=latarcyrheb-sun16 LANG=pl_PL.UTF-8 KEYTABLE=pl
root (hd0,1)
initrd /initramfs-2.6.32-504.8.1.el6.x86_64.img
All files are in place:
ls -l /boot
razem 24645
-rw-r--r-- 1 root root 106312 01-28 22:40 config-2.6.32-504.8.1.el6.x86_64
drwxr-xr-x 3 root root 1024 2011-07-08 efi
drwxr-xr-x 2 root root 1024 03-06 13:44 grub
-rw------- 1 root root 18227613 03-06 13:44 initramfs-2.6.32-504.8.1.el6.x86_64.img
-rw-r--r-- 1 root root 200245 01-28 22:41 symvers-2.6.32-504.8.1.el6.x86_64.gz
-rw-r--r-- 1 root root 2544888 01-28 22:40 System.map-2.6.32-504.8.1.el6.x86_64
-rwxr-xr-x 1 root root 4153008 01-28 22:40 vmlinuz-2.6.32-504.8.1.el6.x86_64
ls -l /boot/grub/
razem 259
-rw-r--r-- 1 root root 15 03-02 20:55 device.map
-rw-r--r-- 1 root root 63 2011-07-08 device.map.backup
-rw-r--r-- 1 root root 13396 03-06 13:05 e2fs_stage1_5
-rw-r--r-- 1 root root 12636 03-06 13:05 fat_stage1_5
-rw-r--r-- 1 root root 11780 03-06 13:05 ffs_stage1_5
-rw------- 1 root root 242 03-06 13:44 grub.conf
-rw-r--r-- 1 root root 11772 03-06 13:05 iso9660_stage1_5
-rw-r--r-- 1 root root 13284 03-06 13:05 jfs_stage1_5
lrwxrwxrwx 1 root root 11 03-06 13:04 menu.lst -> ./grub.conf
-rw-r--r-- 1 root root 11972 03-06 13:05 minix_stage1_5
-rw-r--r-- 1 root root 14428 03-06 13:05 reiserfs_stage1_5
-rw-r--r-- 1 root root 1341 2010-11-14 splash.xpm.gz
-rw-r--r-- 1 root root 512 03-06 13:05 stage1
-rw-r--r-- 1 root root 126116 03-06 13:05 stage2
-rw-r--r-- 1 root root 12040 03-06 13:05 ufs2_stage1_5
-rw-r--r-- 1 root root 11380 03-06 13:05 vstafs_stage1_5
-rw-r--r-- 1 root root 13980 03-06 13:05 xfs_stage1_5
/etc/fstab looks fine too:
cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/sda3 / ext4 rw,noatime,nodiratime,usrjquota=aquota.user,grpjquota=aquota.group,usrquota,grpquota,jqfmt=vfsv0 0 1
/dev/sda2 /boot ext4 errors=remount-ro 0 1
/dev/sda4 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
How to resolve this ?
-
_ck_
- Posts: 89
- Joined: 2012/08/10 23:00:35
grub2 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.
In previous CentOS I’d know how to fix this.
But lost with grub2 — any suggestions?
Code: Select all
yum update
(snip)
Updating : kernel-tools-3.10.0-123.6.3.el7.x86_64
Installing : kernel-3.10.0-123.6.3.el7.x86_64
grubby fatal error: unable to find a suitable template
Updating : kernel-headers-3.10.0-123.6.3.el7.x86_64
Cleanup : kernel-tools-3.10.0-123.4.4.el7.x86_64
Cleanup : kernel-headers-3.10.0-123.4.4.el7.x86_64
Cleanup : kernel-tools-libs-3.10.0-123.4.4.el7.x86_64
grubby fatal error: unable to find a suitable template
grubby: doing this would leave no kernel entries. Not writing out new config.
Verifying : kernel-tools-libs-3.10.0-123.6.3.el7.x86_64
(/snip)
Installed:
kernel.x86_64 0:3.10.0-123.6.3.el7
Updated:
kernel-headers.x86_64 0:3.10.0-123.6.3.el7 kernel-tools.x86_64 0:3.10.0-123.6.3.el7 kernel-tools-libs.x86_64 0:3.10.0-123.6.3.el7
After reboot it is
3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
so it updated anyway? huh?
Code: Select all
rpm -qa | grep kernel
kernel-tools-3.10.0-123.6.3.el7.x86_64
kernel-headers-3.10.0-123.6.3.el7.x86_64
kernel-3.10.0-123.4.4.el7.x86_64
kernel-tools-libs-3.10.0-123.6.3.el7.x86_64
kernel-3.10.0-123.6.3.el7.x86_64
kernel-3.10.0-123.4.2.el7.x86_64
kernel-3.10.0-123.el7.x86_64
-
gerald_clark
- Posts: 10642
- Joined: 2005/08/05 15:19:54
- Location: Northern Illinois, USA
Re: grub2 grubby fatal error: unable to find a suitable temp
Post
by gerald_clark » 2014/08/07 02:12:57
I just updated with no problem.
Is this a VM? If so what lind and what boot method was chosen?
-
TrevorH
- Site Admin
- Posts: 32532
- Joined: 2009/09/24 10:40:56
- Location: Brighton, UK
Re: grub2 grubby fatal error: unable to find a suitable temp
Post
by TrevorH » 2014/08/07 10:13:02
Post the output of ls -la /etc/grub2.cfg /boot/grub2/grub.cfg
-
toracat
- Site Admin
- Posts: 7505
- Joined: 2006/09/03 16:37:24
- Location: California, US
- Contact:
Re: grub2 grubby fatal error: unable to find a suitable temp
Post
by toracat » 2014/12/19 23:48:17
Also, do you happen to have /etc/grub.conf or /boot/grub/grub.conf ? If so, try removing them.
CentOS Forum FAQ
-
_ck_
- Posts: 89
- Joined: 2012/08/10 23:00:35
Re: grub2 grubby fatal error: unable to find a suitable temp
Post
by _ck_ » 2014/12/20 06:33:53
So, happened again but this time on production machine that now won’t restart.
viewtopic.php?f=47&t=50216
Have to wait until morning for kvm to console to find out what went horribly wrong.
I did make a softlink for grub.conf to remind me of the new setting so that probably triggered this but I find it horrifying that maybe grub2 put the system into a non-recoverable reboot state.
(also I’ve done kernel upgrades before with that softlink in place without that error)
Will post more in the morning after I can see wtf actually happened.
Really miss init.d and grub.conf, things were so «simple»
-
_ck_
- Posts: 89
- Joined: 2012/08/10 23:00:35
Re: grub2 grubby fatal error: unable to find a suitable temp
Post
by _ck_ » 2014/12/20 07:04:05
Okay I managed to get into the console and selected the older 3.10.0-123.13.1.el7.x86_64 and it booted normally.
So with grub2, how do I diagnose what went horribly wrong with the kernel update?
-
_ck_
- Posts: 89
- Joined: 2012/08/10 23:00:35
Re: grub2 grubby fatal error: unable to find a suitable temp
Post
by _ck_ » 2014/12/20 07:51:03
update-grub seems to have magically fixed it, but wish I could have learned what went wrong, I cannot find anything in the logs
I also added the GRUB_FALLBACK method halfway down this page http://labs.creativecommons.org/2012/04 … raid1.html
so hopefully grub2 can recover the next time this happens
side note — serial consoles via lan sure are handy but worry how safe they are…
Description
Rick Kasten
2014-12-30 20:21:47 UTC
Description of problem:
I updated my kernel `yum -y update kernel` and got the following output:
Running Transaction
Installing : kernel-2.6.32-504.3.3.el6.x86_64
grubby fatal error: unable to find a suitable template
Furthermore, my /boot/grub/grub.conf remains unchanged, and the command `grubby --default-kernel` results in no output. I then tried to copy the default `grubby --copy-default --add-kernel=/boot/vmlinuz-2.6.32-504.3.3.el6.x86_64 --title="CentOS (2.6.32-504.3.3.el6.x86_64)"`, and that resulted in
grubby fatal error: unable to find a suitable template
Here is my /boot/grub/grub.conf:
default=0
timeout=0
hiddenmenu
title CentOS (2.6.32-358.el6.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-358.el6.x86_64 ro root=LABEL=rootfs console=ttyS0
initrd /boot/initramfs-2.6.32-358.el6.x86_64.img
Based on that I ran the command `grubby --info=/boot/vmlinuz-2.6.32-358.el6.x86_64` and got this:
grubby: kernel not found
So I tried again with `grubby --info=/boot/boot/vmlinuz-2.6.32-358.el6.x86_64` and got this:
boot=/dev/sda
index=0
kernel=/boot/vmlinuz-2.6.32-358.el6.x86_64
args="ro console=ttyS0"
root=LABEL=rootfs
initrd=/boot/boot/initramfs-2.6.32-358.el6.x86_64.img
Note that the initrc starts with "/boot/boot/" while kernel is "/boot/". Both /boot/ and /boot/boot/ are actual directories on my system, but /boot/boot/ contains only files relevant to kernel-2.6.32-358 while /boot/ contains files relevant to all three kernels I have installed (I also have kernel-2.6.32-504.1.3 installed, but grubby must have failed on that update as well).
Finally, any attempt to manually edit /boot/grub/grub.conf has resulted in an unbootable system, so at this point, I have no way at all of upgrading my kernel.
Version-Release number of selected component (if applicable):
grubby-7.0.15-7.el6.x86_64
How reproducible:
Easily
Steps to Reproduce:
1. yum -y update kernel
Actual results:
Error message "grubby fatal error: unable to find a suitable template"
No changes to /boot/grub/grub.conf when it should be getting updated with the kernel being installed
Expected results:
Nothing (no grubby errors)
Additional info:
Comment 1
Rick Kasten
2014-12-30 20:38:31 UTC
I have discovered that I have a file /boot/initrd-2.6.32-358.el6.x86_64kdump.img but I have no corresponding file for either 504 kernel I have installed.
Comment 3
Rick Kasten
2014-12-30 21:57:36 UTC
Sorry, I figured out the /boot/boot/ stuff, and my /boot/grub/grub.conf now looks like this:
default=0
timeout=0
hiddenmenu
title CentOS (2.6.32-504.3.3.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-504.3.3.el6.x86_64 ro root=LABEL=rootfs console=ttyS0
initrd /initramfs-2.6.32-504.3.3.el6.x86_64.img
However, everything else about this remains true: installing a new kernel still results in "grubby fatal error: unable to find a suitable template", and `grubby --default-kernel` still results in no output. I have to edit my /boot/grub/grub.conf manually for any kernel update.
Comment 4
Peter Jones
2015-10-12 17:55:25 UTC
Please attach /var/log/grubby from immediately after the failure has occurred.
Comment 6
Rick Kasten
2015-11-02 23:45:15 UTC
You're getting back to me almost 10 months after I opened the bug, and you think I'm still going to have my grubby log?
Comment 7
Rick Kasten
2016-08-15 16:16:08 UTC
This ticket can be closed
Comment 11
R P Herrold
2017-09-27 17:31:42 UTC
I see action on this ticket -- I probably have the files requested in comment #4 ... checking
Comment 12
R P Herrold
2017-09-27 17:38:13 UTC
Running a kernel only update just now I do not see the 'no suitable template' message on this unit -- I know I have seen them elsewhere so I will 'walk through' active 6 units looking for it [root@blind log]# rpm -qa kernel* kernel-2.6.32-573.22.1.el6.i686 kernel-2.6.32-642.el6.i686 kernel-firmware-2.6.32-696.el6.noarch kernel-2.6.32-504.16.2.el6.i686 kernel-headers-2.6.32-696.el6.i686 kernel-2.6.32-431.11.2.el6.i686 kernel-2.6.32-696.el6.i686 [root@blind log]# yum upgrade kernel Loaded plugins: fastestmirror Setting up Upgrade Process Determining fastest mirrors * base: mirrors.lga7.us.voxel.net * extras: mirrors.gigenet.com * updates: centos.mirror.constant.com base | 3.7 kB 00:00 base/primary_db | 3.7 MB 00:02 extras | 3.3 kB 00:00 extras/primary_db | 21 kB 00:00 updates | 3.4 kB 00:00 updates/primary_db | 3.5 MB 00:00 Resolving Dependencies --> Running transaction check ---> Package kernel.i686 0:2.6.32-696.10.2.el6 will be installed --> Processing Dependency: kernel-firmware >= 2.6.32-696.10.2.el6 for package: kernel-2.6.32-696.10.2.el6.i686 --> Running transaction check ---> Package kernel-firmware.noarch 0:2.6.32-696.el6 will be updated ---> Package kernel-firmware.noarch 0:2.6.32-696.10.2.el6 will be an update --> Finished Dependency Resolution --> Running transaction check ---> Package kernel.i686 0:2.6.32-431.11.2.el6 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================= Package Arch Version Repository Size ================================================================================= Installing: kernel i686 2.6.32-696.10.2.el6 updates 30 M Removing: kernel i686 2.6.32-431.11.2.el6 @updates 89 M Updating for dependencies: kernel-firmware noarch 2.6.32-696.10.2.el6 updates 29 M Transaction Summary ================================================================================= Install 1 Package(s) Upgrade 1 Package(s) Remove 1 Package(s) Total download size: 59 M Is this ok [y/N]: y Downloading Packages: (1/2): kernel-2.6.32-696.10.2.el6.i686.rpm | 30 MB 00:04 (2/2): kernel-firmware-2.6.32-696.10.2.el6.noarch.rpm | 29 MB 00:04 --------------------------------------------------------------------------------- Total 6.3 MB/s | 59 MB 00:09 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : kernel-firmware-2.6.32-696.10.2.el6.noarch 1/4 Installing : kernel-2.6.32-696.10.2.el6.i686 2/4 Cleanup : kernel-2.6.32-431.11.2.el6.i686 3/4 warning: erase unlink of /lib/modules/2.6.32-431.11.2.el6.i686/modules.order failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-431.11.2.el6.i686/modules.networking failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-431.11.2.el6.i686/modules.modesetting failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-431.11.2.el6.i686/modules.drm failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-431.11.2.el6.i686/modules.block failed: No such file or directory Cleanup : kernel-firmware-2.6.32-696.el6.noarch 4/4 Verifying : kernel-firmware-2.6.32-696.10.2.el6.noarch 1/4 Verifying : kernel-2.6.32-696.10.2.el6.i686 2/4 Verifying : kernel-2.6.32-431.11.2.el6.i686 3/4 Verifying : kernel-firmware-2.6.32-696.el6.noarch 4/4 Removed: kernel.i686 0:2.6.32-431.11.2.el6 Installed: kernel.i686 0:2.6.32-696.10.2.el6 Dependency Updated: kernel-firmware.noarch 0:2.6.32-696.10.2.el6 Complete! [root@blind log]#
Comment 13
R P Herrold
2017-09-27 17:39:26 UTC
grubby works uneventfully, but there is no /var/log/grubby file [root@blind ~]# grubby --default-kernel /boot/vmlinuz-2.6.32-696.10.2.el6.i686 [root@blind ~]# cd /var/log [root@blind log]# ls anaconda.log dmesg messages spooler-20170910 anaconda.program.log dmesg.old messages-20170903 spooler-20170917 anaconda.storage.log dracut.log messages-20170910 spooler-20170924 anaconda.syslog dracut.log-20130101 messages-20170917 tallylog anaconda.yum.log dracut.log-20140101 messages-20170924 wtmp audit dracut.log-20150101 ntpstats wtmp-20151125 boot.log dracut.log-20160101 sa yum.log btmp lastlog secure yum.log-20140101 btmp-20170901 mail secure-20170903 yum.log-20150101 cron maillog secure-20170910 yum.log-20160101 cron-20170903 maillog-20170903 secure-20170917 yum.log-20170101 cron-20170910 maillog-20170910 secure-20170924 cron-20170917 maillog-20170917 spooler cron-20170924 maillog-20170924 spooler-20170903 [root@blind log]#
Comment 14
R P Herrold
2017-09-27 17:44:36 UTC
What CLI option or RC file setting contains an option to cause 'grubby' to emit debugging information to /var/log/grubby so I may enable it? the 'man' page lists none that I can see
Comment 15
R P Herrold
2017-09-27 18:48:55 UTC
no noise seen here either [root@sna-mirror sysconfig]# cat /etc/redhat-release CentOS release 6.9 (Final) [root@sna-mirror sysconfig]# yum clean all Loaded plugins: fastestmirror Cleaning repos: base epel extras updates Cleaning up Everything [root@sna-mirror sysconfig]# cd /var/log [root@sna-mirror log]# ls *grub* ls: cannot access *grub*: No such file or directory [root@sna-mirror log]# yum -q upgrade kernel ================================================================================= Package Arch Version Repository Size ================================================================================= Installing: kernel i686 2.6.32-696.10.3.el6 updates 30 M Removing: kernel i686 2.6.32-573.22.1.el6 @updates 92 M Updating for dependencies: kernel-firmware noarch 2.6.32-696.10.3.el6 updates 29 M Transaction Summary ================================================================================= Install 1 Package(s) Upgrade 1 Package(s) Remove 1 Package(s) Is this ok [y/N]: y warning: erase unlink of /lib/modules/2.6.32-573.22.1.el6.i686/modules.order failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-573.22.1.el6.i686/modules.networking failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-573.22.1.el6.i686/modules.modesetting failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-573.22.1.el6.i686/modules.drm failed: No such file or directory warning: erase unlink of /lib/modules/2.6.32-573.22.1.el6.i686/modules.block failed: No such file or directory [root@sna-mirror log]# ls *grub* ls: cannot access *grub*: No such file or directory [root@sna-mirror log]# date Wed Sep 27 14:38:24 EDT 2017 [root@sna-mirror log]# grubby --info=` grubby --default-kernel ` boot=/dev/xvda index=0 kernel=/boot/vmlinuz-2.6.32-696.10.3.el6.i686 args="ro rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=ttyS0 elevator=noop crashkernel=auto rhgb quiet" root=/dev/vda1 initrd=/boot/initramfs-2.6.32-696.10.3.el6.i686.img [root@sna-mirror log]# grubby --update-kernel=ALL --remove-args="quiet" [root@sna-mirror log]# grubby --update-kernel=ALL --remove-args="rhgb" [root@sna-mirror log]# grubby --info=` grubby --default-kernel ` boot=/dev/xvda index=0 kernel=/boot/vmlinuz-2.6.32-696.10.3.el6.i686 args="ro rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=ttyS0 elevator=noop crashkernel=auto" root=/dev/vda1 initrd=/boot/initramfs-2.6.32-696.10.3.el6.i686.img [root@sna-mirror log]#
Comment 16
R P Herrold
2017-09-27 18:52:14 UTC
mpetlan as you set this to 'urgent' could you also please amend the Reporter field to my email address -- my local procmail sorting will bring incoming content ot me faster if that is done ... there must be some 'behind the scenes' activity, as comments I see jump from $7 to #11 Not required, but just faster
Comment 17
Rick Kasten
2017-09-28 18:16:25 UTC
I am no longer in a position to offer assistance with my original problem.
Comment 27
Peter Jones
2018-01-30 18:27:00 UTC
Unfortunately, RHEL 6 is based on grubby 7, and the logging was not added until grubby 8. In any case, what we have to know in order to fix this is /why/ it can't find a suitable template. Basically, it's looking for an entry for the kernel which is currently set as default to boot, and then trying to find the root filesystem and similar for that. If that fails, it'll try each successive entry until it finds one that's suitable. In order, the things that will make an entry not suitable as a template are: - no kernel line (or it's malformed / doesn't have enough elements on it) - access(kernel_path, R_OK) fails - usually this means it's missing, which will happen if you "rpm -Uvh" kernel instead of "rpm -ivh" or using yum correctly. - no root= line and root= isn't on the kernel arguments line - root= can't be resolved to a device (i.e. root=/dev/sdb1 where the file doesn't exist, root=LABEL=foo where no fs is labeled "foo", or "root=UUID=abcdefg" where blkid doesn't find any fs with that label.) - we couldn't parse /etc/mtab - the UUID of the fs root= points at doesn't match the UUID of the actual filesystem we found mounted as root in /etc/mtab. Again, check what blkid says the UUID is for each. To diagnose which thing is going wrong, first a reproducible set of conditions needs to be established - this usually just means saving the grub.conf from before and after the transaction, and running the grubby invocation that failed (i.e. what new-kernel-pkg ran) on a copy of that file. If you can make a reproducible set of conditions where the failure occurs, then usually strace on the grubby invocation will show you which condition fails, and then the next step is figuring out why - it's possible it's a bug in grubby, but more often something external has broken the data needed for one of the above tests. One thing you might try, and I'm not sure it will actually work, is the test build of grubby linked below, which is the RHEL 7 grubby 8 package (which will log things to /var/log/grubby) hacked up to hopefully work on RHEL 6, where we don't have grub2. Without knowing specifically why finding a suitable template entry is failing, it's impossible to ACK this bug, as we simply do not know what's going wrong.
Comment 28
Red Hat Bugzilla Rules Engine
2018-01-30 18:28:24 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Comment 30
R P Herrold
2018-01-30 18:48:54 UTC
thank you for the pointer -- will add into my testing, and if / when I have a reproducer on RHEL 6 level code but with the later 'grubby-8', I will clone this bug and add details
Comment 31
R P Herrold
2018-01-30 19:02:21 UTC
fwiw, there is a sbin -> /usr/sbin/ path change as well
when I encounter the template issue, I'll
--nodeps through that objection
[root@blind ~]# rpm -Uvh /home/herrold/rpmbuild/RPMS/i686/grubby-8.28-23.el6.pj0.i686.rpm
error: Failed dependencies:
/sbin/new-kernel-pkg is needed by (installed) kernel-2.6.32-696.20.1.el6.i686
[root@blind ~]# rpm -qf /sbin/new-kernel-pkg
grubby-7.0.15-7.el6.i686
[root@blind ~]# rpm -qlp /home/herrold/rpmbuild/RPMS/i686/grubby-8.28-23.el6.pj0.i686.rpm | grep new-kernel-pkg
/usr/sbin/new-kernel-pkg
/usr/share/man/man8/new-kernel-pkg.8.gz
[root@blind ~]#
again, thank you
I have an appliance (read: a PC in a rackmount chassis which sits in the rack and does its job for years without anyone really paying it much attention until it dies) running CentOS 5.4. Trying to upgrade the kernel to the latest 5.x release (2.6.18 build 406) and running into this error message.
I have read https://stackoverflow.com/questions/27712084/grubby-fatal-error-unable-to-find-a-suitable-template, but that Q offered no explanation or solutions.
I have also read https://bbs.archlinux.org/viewtopic.php?id=166217 and tried that out as well… no luck either.
I REALLY do not want to have to concoct some hackish script wrapper for a kernel upgrade to do something which the tool is supposed to do so I’m hopeful there is a solution to this.
My grub file resides in /boot/grub (grub.conf). There is a symlink in /boot/grub/grub pointing to it, as there is also a symlink in /etc likewise pointing to it.
The actual grub.conf (sans comments for brevity):
default=0
timeout=5
splashimage=(hd0,2)/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-348.16.1.el5)
root (hd0,5)
kernel /vmlinuz-2.6.18-348.16.1.el5 ro root=LABEL=ROOT
initrd /initrd-2.6.18-348.16.1.el5.img
The output of the kernel rpm running the post install script, new-kernel-pkg (I added the quotes around the titles so I could rerun the command):
/sbin/grubby --add-kernel=/boot/vmlinuz-2.6.18-406.el5 --initrd /boot/initrd-2.6.18-406.el5.img --copy-default --make-default --title "CentOS (2.6.18-406.el5)" --args=root=LABEL=ROOT --remove-kernel=TITLE="CentOS (2.6.18-406.el5)"
It all looks valid to me. I just don’t understand what the grubby tool is expecting to find in the grub.conf and what mine is failing to provide to satisfy it. Anyone?
Note: If I mod the above script to add --bad-image-okay to the grubby commandline, it will work as I would expect: the new kernel is added to the grub.conf file and it’s all correct… but that option is supposed to ignore errors and the like, so, what is wrong with my config, or more accurately, what error did I tell grubby to ignore?