Bug 657257

Created attachment 462869 [details]
Log from %post

I see the same error behaviour during %post in kickstart. 

  Installing     : kernel-2.6.32-71.7.1.el6.i686                          35/82 
  grubby fatal error: unable to find a suitable template

The kernel is installed, but /boot/grub/grub.conf is not updated.

Following kickstart, the server boots using the original kernel that is installed from the base DVD.

Once rebooted after kickstart, I can delete the new kernel (rpm -e) and run "yum update" to have the new kernel reinstalled. grubby does not complain, /boot/grub/grub.conf is updated correctly.

I added a "sleep 1200" to my %post to allow me to poke around a bit. 

I tried running "yum -y update kernel" instead of "yum -y update". Same error.

I downloaded the kernel and kernel-firmware rpm's, did not run yum at all, did not register the server with RHN, instead ran "rpm -ivh". Same error

Displaying some grubby info shows the following during %post:

/sbin/grubby --default-kernel

..... no output from this ......


/sbin/grubby --info=$(/sbin/grubby --default-kernel)

..... no output from this ......

When I run the same commands following reboot, I get this:

[root@sjm2 ~]# /sbin/grubby --default-kernel
/boot/vmlinuz-2.6.32-71.el6.i686

[root@sjm2 ~]# /sbin/grubby --info=$(/sbin/grubby --default-kernel)
boot=/dev/sda
index=0
kernel=/vmlinuz-2.6.32-71.el6.i686
args="ro rd_LVM_LV=vg00/rootlv rd_LVM_LV=vg00/swap01lv rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rhgb quiet"
root=/dev/mapper/vg00-rootlv
initrd=/boot/initramfs-2.6.32-71.el6.i686.img
[root@sjm2 ~]# 


These (and others) are part of the scripts in the kernel rpm.

Following reboot, I can run either "yum" or "rpm -i" and they both work perfectly.

Looks like grubby tries to access /dev/root during the kickstart.

If you strace the grubby command (while it's kickstarting) you can see it opens /etc/mtab, and then tries to access /dev/root:

...
open("/etc/grub.conf", O_RDONLY) = 3
read(3, "# grub.conf generated by anaconda\n#\n# Note that you do not have to rerun grub after making changes to this file\n# NOTICE: You have a /boot partition. This means that\n# all kernel and initrd paths are relative to /boot/, eg.\n# root (hd0,0)\n# kernel /vmlinuz-version ro root=/dev/mapper/rootvg-lv_root\n# initrd /initrd-[generic-]version.img\n#boot=/dev/sda\ndefault=0\ntimeout=5\nsplashimage=(hd0,0)/grub/splash.xpm.gz\nhiddenmenu\ntitle Red Hat Enterprise Linux (2.6.32"..., 1024) = 821
read(3, "", 1024) = 0
close(3) = 0
access("/boot/vmlinuz-2.6.32-71.el6.x86_64", R_OK) = 0
getuid() = 0
geteuid() = 0
getgid() = 0
getegid() = 0
prctl(PR_GET_DUMPABLE) = 1
getuid() = 0
geteuid() = 0
getgid() = 0
getegid() = 0
prctl(PR_GET_DUMPABLE) = 1
open("/etc/blkid.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/blkid/blkid.tab", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/mtab", O_RDONLY) = 3
read(3, "/dev/root / ext4 ro 0 0\n", 65535) = 24
close(3) = 0
access("/dev/root", F_OK) = -1 ENOENT (No such file or directory)
access("/boot/vmlinuz-2.6.32-71.el6.x86_64", R_OK) = 0
open("/etc/mtab", O_RDONLY) = 3
read(3, "/dev/root / ext4 ro 0 0\n", 65535) = 24
close(3) = 0
access("/dev/root", F_OK) = -1 ENOENT (No such file or directory)
write(2, "grubby fatal error: unable to find a suitable template\n", 55grubby fatal error: unable to find a suitable template
) = 55
exit_group(1) = ?


Problem is, /dev/root doesn't exist at this point:


[root@midtst1 ~]# cat /etc/mtab
/dev/root / ext4 ro 0 0
tmpfs /dev/shm tmpfs rw,rootcontext="system_u:object_r:tmpfs_t:s0" 0 0
[root@midtst1 ~]# ls -l /dev/root
ls: cannot access /dev/root: No such file or directory

Taken from FC13 bugzilla entry:
https://bugzilla.redhat.com/show_bug.cgi?id=568539


"We are working around this problem by adding the following to the beginning of
our postinstall script; this should probably allow things to work for most
other installations too without the need to patch grubby:

ln -s `awk '{ if ($2 == "/") print $1; }' /etc/fstab` /dev/root

Probably somebody should file a bug report against anaconda as well as against
grubby, since anaconda is producing a postinstall environment in which
presumably (though I'm away from our test system right now so can't verify for
sure) /mnt/sysimage/etc/mtab shows "/" mounted from /dev/root, but
/mnt/sysimage/dev/root does not exist. So after the chroot, / appears to be
mounted from /dev/root but /dev/root does not exist.

I'd imagine the right thing for anaconda to do is populate the necessary nodes
in /mnt/sysimage/dev before moving to the postinstall phase."


This worked for me. Maybe this bug should be moved to anaconda?

(In reply to comment #6)
> 
> ln -s `awk '{ if ($2 == "/") print $1; }' /etc/fstab` /dev/root

Thank you. Confirmed that this works.

> Maybe this bug should be moved to anaconda?

Yes, it seems clear that the bug lies with anaconda and not grubby. I'm moving it to anaconda.

Is there a new bug number for this bug after it has been moved to anaconda?

(In reply to comment #8)
> Is there a new bug number for this bug after it has been moved to anaconda?

No, the bugzilla id remains the same, but the Component was changed to anaconda.

This patch works for me (it is more general that the proposed solution)

echo "patch rhel6"
mp=$(grep -w "/" /etc/fstab | sed -e 's/ .*//')
if echo "$mp" | grep "^UUID="
then
    uuid=$(echo "$mp" |sed 's/UUID=//')
    rootdisk=$(blkid -U $uuid)
    ln -vs $rootdisk /dev/root
fi

This is fixed by 4759b074637085af5a587ca74ad1fbc45500278f on master, so it should be a simple matter of cherry-picking the patch.

*** Bug 659062 has been marked as a duplicate of this bug. ***

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Reproduced on RHEL6.0 GA x86_64 Server.
Verified fix on RHEL6.0 20110330.2 x86_64 Server.

Sorry, verified on RHEL6.1 20110330.2 x86_64 Server :)

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0530.html