Install a new kernel in a chroot gives a grubby error

[mathog]

Is there some way for yum install to act on a kernel rpm in a disk image (chroot environment) so that grubby does not fail?

This is what I tried:

Code: Select all

ROOTDIR=/var/lib/systemimager/images/centos7.x.beowulf
mount -o bind /sys  $ROOTDIR/sys #for network
mount -o bind /proc $ROOTDIR/proc #for network
mount -o bind /dev/urandom  $ROOTDIR/dev/urandom  #for urand
chroot $ROOTDIR
HOLDDIR=/tmp/yum_rpms
mkdir $HOLDDIR
yum upgrade --downloadonly --downloaddir=$HOLDDIR
#copied all of those to /usr/common/tmp/yum_rpms from outside the chroot
yum -y install /tmp/yum_rpms/*.rpm
#warning about: /etc/nsswitch.conf.new
#grubby fatal error: unable to find a suitable template
#several of these warnings:
#  Running in chroot, ignoring request.
exit
umount $ROOTDIR/sys 
umount $ROOTDIR/proc
umount $ROOTDIR/dev/urandom

Then on one physical node did:

Code: Select all

INSTALLSTRING="--disablerepo=\\* -y install $HOLDDIR/*"
ssh  node21 "yum $INSTALLSTRING; echo ''"

Looking at /boot/grub2/grub.cfg in the two environments it was evident that the newer kernels had been installed
on the physical node, but were not installed in the chroot. /var/log/grubby.log in the chroot environment had:

Code: Select all

DBG: 25566: Wed Oct 16 14:17:36 2019: command line: --grub2 -c /boot/grub2/grub.cfg --add-kernel=/boot/vmlinuz-3.10.0-1062.1.2.el7.x86_64 --cop
y-default --title CentOS Linux (3.10.0-1062.1.2.el7.x86_64) 7 (Core) --args=root=LABEL=root  --remove-kernel=TITLE=CentOS Linux (3.10.0-1062.1.
2.el7.x86_64) 7 (Core) --make-default
DBG: Image entry failed: access to /vmlinuz-3.10.0-957.5.1.el7.x86_64 failed
DBG: menuentry 'CentOS Linux (3.10.0-957.5.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menu
entry_id_option 'gnulinux-3.10.0-957.5.1.el7.x86_64-advanced-/dev/sda3' { 
DBG:    load_video
DBG:    set gfxpayload=keep
DBG:    insmod gzio
DBG:    insmod part_msdos
DBG:    insmod xfs
DBG:    set root='hd0,msdos1'
DBG:    linux16 /vmlinuz-3.10.0-957.5.1.el7.x86_64 root=/dev/sda3 ro crashkernel=auto
DBG:    initrd16 /initramfs-3.10.0-957.5.1.el7.x86_64.img
DBG: }

and similar messages for the other kernels. The chroot's grub.cfg had today's timestamp but the newest kernel in it was 3.10.0-957.5.1.el7.x86_64. They physical node had entries for that plus two newer ones: 3.10.0-1062.1.2.el7.x86_64 and 3.10.0-957.27.2.el7.x86_64.

Possible to set up the chroot environment differently so that grubby is happy?

Does it even matter? If the image is reimaged onto a compute node grub2 will be run at the end, and since that will be physical, it should work then when it fails here.

Thanks.