Bug 125156 - grubby: Unable to find a suitable template
grubby: Unable to find a suitable template
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-03 03:42 EDT by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-17 10:20:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2004-06-03 03:42:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040518 Firefox/0.8

Description of problem:
Grubby has never worked for me, so I started wondering why. It always
says: Unable to find a suitable template.

That's because it's trying to --copy-default, and fails here:

if (access(fullName, R_OK)) return 0;
in function suitableImage in grubby.c
...which happens because fullName looks like this:

/boot(hd0,0)/vmlinuz-2.6.6-1.403

which I assume access does not like.

And here's the config entry I have for the default kernel:

title Fedora Linux (2.6.6 Vanilla 403)
     root (hd0,6)
     kernel (hd0,0)/vmlinuz-2.6.6-1.403 ro selinux=0 enforcing=0
root=/dev/hda7 rootflags=quota
     initrd (hd0,0)/initrd-2.6.6-1.403.img

It seems that grubby should resolve the device reference, mount it if
not mounted, and not append /boot prefix everywhere..




Version-Release number of selected component (if applicable):
mkinitrd-3.5.23-1

How reproducible:
Always

Steps to Reproduce:
1. Put device reference in default kernel path line
2. Run grubby
3.
    

Additional info:
Comment 1 Ivan Gyurdiev 2004-07-20 23:10:47 EDT
This is still broken and has been about 50 days since filed. Why?
It doesn't seem hard to fix...

Comment 2 Jeremy Katz 2004-07-26 23:34:27 EDT
Accepting patches :)

This isn't the default way we configure things and my todo list is on
the long side.  I'll hopefully get to it before FC3 is released, but
it's not something I can really promise.
Comment 3 Jeremy Katz 2004-08-04 15:44:48 EDT
Should be fixed in mkinitrd-4.0.2
Comment 4 Walter Moar 2004-08-09 16:53:36 EDT
Great to hear that this has been resolved. Will there be a new RPM (or
a patch) for those of us on RHEL using mkinitrd-3.5.13-1?
Comment 5 Ivan Gyurdiev 2004-08-09 17:24:25 EDT
Still doesn't work AFAICS. 
RPM is mkinitrd-4.0.2-1

[root@cobra tmp]# /sbin/grubby --default-kernel
[root@cobra tmp]# 

(btw this should print out a warning rather than just exit)

with this entry:

title Fedora Core (2.6.7-1.503)
     root (hd0,6)
     kernel (hd0,0)/vmlinuz-2.6.7-1.503 ro root=/dev/hda7
rootflags=quota selinux=1 enforcing=0
     initrd (hd0,0)/initrd-2.6.7-1.503.img

while it works fine with this entry:

[root@cobra tmp]# /sbin/grubby --default-kernel
/boot/vmlinuz-2.6.7-1.503
[root@cobra tmp]#

title Fedora Core (2.6.7-1.503)
     root (hd0,0)
     kernel /vmlinuz-2.6.7-1.503 ro root=/dev/hda7 rootflags=quota
selinux=1 enforcing=0
     initrd /initrd-2.6.7-1.503.img
                                                                     
                                                       ==============
Comment 6 Ivan Gyurdiev 2004-08-09 17:32:32 EDT
By the way I realize now that the root directive is for internal grub
use and not for setting the root fs, so I can use that to make it
work, but that doesn't mean it's right the way it is... but I can see
why it's low priority for you.

I tried looking at the code some time ago but the bootPrefix stuff
didn't make sense to me - it just gets ignored by most of the functions. 

Comment 7 Jeremy Katz 2004-08-10 14:27:30 EDT
Added handling for --default-kernel bit.
Comment 8 Ivan Gyurdiev 2004-08-12 14:02:34 EDT
That's good, but it still doesn't work.
You can't --remove-kernel by path when prefixed with the device label.
You can only remove it by "TITLE=". Since you can remove kernels by
path when not prefixed, this is a bug.




Comment 9 Ivan Gyurdiev 2004-08-17 10:20:17 EDT
Ok I'm happy (for now). 
Fixed.


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