Bug 657257 - Grubby fails when updating kernel in kickstart %post
Grubby fails when updating kernel in kickstart %post
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.0
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Chris Lumens
Release Test Team
:
: 659062 (view as bug list)
Depends On:
Blocks: 494837
  Show dependency treegraph
 
Reported: 2010-11-25 05:35 EST by Trond H. Amundsen
Modified: 2011-08-31 15:08 EDT (History)
20 users (show)

See Also:
Fixed In Version: anaconda-13.21.106-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 08:35:14 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)
Example kickstart file, slightly edited for security reasons (2.73 KB, text/plain)
2010-11-25 05:35 EST, Trond H. Amundsen
no flags Details
Log from %post (13.34 KB, text/plain)
2010-11-25 05:36 EST, Trond H. Amundsen
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 43389 None None None Never

  None (edit)
Description Trond H. Amundsen 2010-11-25 05:35:08 EST
Created attachment 462868 [details]
Example kickstart file, slightly edited for security reasons

Description of problem:
When installing a system via kickstart, registering a system with RHN in %post and running yum to update does not work for the kernel. The updated kernel is installed, but grub.conf is not updated. Grubby fails during kernel installation with the following error message:

  grubby fatal error: unable to find a suitable template

Version-Release number of selected component (if applicable):
grubby-7.0.15-2.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install via kickstart
2. In %post, register system with rhnreg_ks and run 'yum -y update'
  
Actual results:
New kernel is installed, but grub.conf is not updated.

Expected results:
grub.conf updated, new kernel is used after boot.

Additional info:
Reinstalling the new kernel after boot works. An example kickstart file is attached. The log from %post is also attached.
Comment 1 Trond H. Amundsen 2010-11-25 05:36:19 EST
Created attachment 462869 [details]
Log from %post
Comment 3 Stephen Murray 2010-11-29 14:47:04 EST
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.
Comment 4 Stephen Murray 2010-12-03 14:16:05 EST
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.
Comment 5 Tim Gollschewsky 2010-12-05 23:18:32 EST
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
Comment 6 Mike Leech 2010-12-13 10:22:24 EST
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?
Comment 7 Trond H. Amundsen 2010-12-13 11:13:19 EST
(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.
Comment 8 Werner Maes 2011-01-06 05:20:08 EST
Is there a new bug number for this bug after it has been moved to anaconda?
Comment 9 Gary Smith 2011-01-07 05:37:57 EST
(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.
Comment 10 Werner Maes 2011-01-07 08:05:07 EST
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
Comment 11 Chris Lumens 2011-01-10 10:03:08 EST
This is fixed by 4759b074637085af5a587ca74ad1fbc45500278f on master, so it should be a simple matter of cherry-picking the patch.
Comment 12 Gary Smith 2011-01-27 11:03:38 EST
*** Bug 659062 has been marked as a duplicate of this bug. ***
Comment 15 RHEL Product and Program Management 2011-03-16 09:30:35 EDT
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.
Comment 17 Pavel Holica 2011-04-04 09:47:28 EDT
Reproduced on RHEL6.0 GA x86_64 Server.
Verified fix on RHEL6.0 20110330.2 x86_64 Server.
Comment 18 Pavel Holica 2011-04-04 09:53:29 EDT
Sorry, verified on RHEL6.1 20110330.2 x86_64 Server :)
Comment 19 errata-xmlrpc 2011-05-19 08:35:14 EDT
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

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