Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 83512 - kernel update failure message (grubby: no template)
Summary: kernel update failure message (grubby: no template)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd
Version: 8.0
Hardware: i686
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-05 03:04 UTC by bill parducci
Modified: 2007-04-18 16:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-11 03:50:55 UTC


Attachments (Terms of Use)

Description bill parducci 2003-02-05 03:04:31 UTC
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 09:11:46 UTC
grubby is part of mkinitrd... changing component

Comment 2 Jeremy Katz 2003-02-19 07:02:54 UTC
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 14:31:42 UTC
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 05:24:01 UTC
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 17:46:47 UTC
Reassigning

Comment 6 Stephen E Clark 2003-05-21 12:50:05 UTC
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-04 03:12:59 UTC
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-11 03:50:55 UTC
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.