From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 Description of problem: attempted to update kernel using up2date and it gave the following message: grubby fatal error: unable to find a suitable template Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: 1. up2date -u 2. 3. Actual Results: # up2date -u Fetching package list for channel: redhat-linux-i386-8.0... Fetching Obsoletes list for channel: redhat-linux-i386-8.0... Fetching rpm headers... Testing package set / solving RPM inter-dependencies... kernel-2.4.18-24.8.0.i686.r ########################## Done. Preparing ########################################### [100%] Installing... 1:kernel ########################################### [100%] grubby fatal error: unable to find a suitable template ...however, rpm db is updated: # rpm -qa |grep kernel kernel-pcmcia-cs-3.1.31-9 kernel-2.4.18-19.8.0 kernel-2.4.18-24.8.0 <+++++++ kernel-2.4.18-14 ...grub.conf is updated: # cat /etc/grub.conf default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Red Hat Linux (2.4.18-24.8.0) root (hd0,0) kernel /vmlinuz-2.4.18-24.8.0 ro root=LABEL=/tmp initrd /initrd-2.4.18-24.8.0.img [...] ...the files are where they should be: # ls -al /boot/*2.4.18-24.8.0* 42257 Jan 31 04:05 /boot/config-2.4.18-24.8.0 258856 Feb 4 17:54 /boot/initrd-2.4.18-24.8.0.img 15436 Jan 31 04:05 /boot/module-info-2.4.18-24.8.0 503847 Jan 31 04:05 /boot/System.map-2.4.18-24.8.0 3171861 Jan 31 04:05 /boot/vmlinux-2.4.18-24.8.0 1112073 Jan 31 04:05 /boot/vmlinuz-2.4.18-24.8.0 ...and finally, the machine seems to boot just fine. Expected Results: no fatal messages Additional info: either this is an erroneus error or grubby going fatal isn't a big deal :oP
grubby is part of mkinitrd... changing component
Can you attach your complete /boot/grub/grub.conf? up2date has some older code that does the updating so it usually ends up working even if grubby breaks
here is /boot/grub/grub.conf as it stands today: # 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/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Red Hat Linux (2.4.18-24.8.0) root (hd0,0) kernel /vmlinuz-2.4.18-24.8.0 ro root=LABEL=/tmp initrd /initrd-2.4.18-24.8.0.img title Red Hat Linux (2.4.18-19.8.0) root (hd0,0) kernel /vmlinuz-2.4.18-19.8.0 ro root=LABEL=/tmp initrd /initrd-2.4.18-19.8.0.img title Red Hat Linux (2.4.18-14) root (hd0,0) kernel /vmlinuz-2.4.18-14 ro root=LABEL=/tmp initrd /initrd-2.4.18-14.img
line #662 of grubby.c will cause it to fail if the default entry in lilo.conf lacks a root= directive. This line should probably be removed.
Reassigning
I was having the same problem. I discovered that besides my /boot/grub.conf file I also had a /etc/lilo.conf file. Grubby was trying to update both of them even though I had quit using lilo. It was successfully updating the /boot/grub.conf file but was unable to find a suitable template in the /etc/lilo.conf file and thus exiting with an error return.
Here's a patch to correct the problem as referenced by David Winter on 2003-03-03 00:24. The problem is readily replicated by using a LABEL for the root device instead of an explicit "root=/dev/..." key/value pair in lilo.conf. *** grubby.c-old 2003-06-03 22:05:17.000000000 -0500 --- grubby.c 2003-06-03 22:10:09.000000000 -0500 *************** *** 659,665 **** --- 659,671 ---- line = entry->lines; while (line && line->type != LT_ROOT) line = line->next; + + #ifdef WANT_GRUBBY_FAILURE_BEFORE_TRYING_LT_KERNELARGS + /* + * 3 JUN 2003: [nelsonbe] - ifdef corrects premature + * return before evaluation and possible ``else'' decision. + */ if (!line) return 0; + + #endif if (line && line->numElements >= 2) dev = line->elements[1].item;
This is fixed with newer versions of mkinitrd