Bug 83512 - kernel update failure message (grubby: no template)
kernel update failure message (grubby: no template)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd (Show other bugs)
8.0
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Jeremy Katz
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-04 22:04 EST by bill parducci
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-10 23:50:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description bill parducci 2003-02-04 22:04:31 EST
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
Comment 1 Arjan van de Ven 2003-02-05 04:11:46 EST
grubby is part of mkinitrd... changing component
Comment 2 Jeremy Katz 2003-02-19 02:02:54 EST
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
Comment 3 bill parducci 2003-02-19 09:31:42 EST
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
Comment 4 David Winter 2003-03-03 00:24:01 EST
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.
Comment 5 Jeremy Katz 2003-03-20 12:46:47 EST
Reassigning
Comment 6 Stephen E Clark 2003-05-21 08:50:05 EDT
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.
Comment 7 Bob Nelson 2003-06-03 23:12:59 EDT
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@earthlink.net] - 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;
Comment 8 Jeremy Katz 2003-06-10 23:50:55 EDT
This is fixed with newer versions of mkinitrd

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