Description of problem: Built image configured with wrong kernel in the boot loader Version-Release number of selected component (if applicable): How reproducible: every time Steps to Reproduce: 1. source ~/stackrc 2. export DIB_LOCAL_IMAGE=\"/home/stack/rhel-guest-image-9.0-20211026.10.x86_64.qcow2\" 3. export DIB_YUM_REPO_CONF=\"/etc/yum.repos.d/rhos-release-\"17.0\".repo /etc/yum.repos.d/rhos-release-rhel-\"9.0\".repo /etc/yum.repos.d/rhos-release-ceph-*.repo\" 4. openstack overcloud image build --image-name overcloud-hardened-uefi-full --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-uefi-python3.yaml --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-uefi-rhel9.yaml --verbose\n" 5. try to boot image Actual results: `/boot/vmlinuz-5.14.0-1.7.1.el9.x86_64' not found. Expected results: boot loader is configured with the proper kernel installed in the image, kernel-5.14.0-1.7.1.el9.x86_64 installed Additional info: here is the logging of what kernel was actually installed 2022-06-27 14:07:14.167 | 2022-06-27 14:00:18.431 | Installing: 2022-06-27 14:07:14.168 | 2022-06-27 14:00:18.431 | kernel x86_64 5.14.0-70.13.1.el9_0 rhosp-rhel-9.0-baseos 588 k 2022-06-27 14:07:14.170 | 2022-06-27 14:00:18.431 | kernel-core x86_64 5.14.0-70.13.1.el9_0 rhosp-rhel-9.0-baseos 34 M 2022-06-27 14:07:14.172 | 2022-06-27 14:00:18.431 | kernel-modules x86_64 5.14.0-70.13.1.el9_0 rhosp-rhel-9.0-baseos 21 M
Recommend updating to latest base image first: http://download.eng.bos.redhat.com/rhel-9/nightly/RHEL-9/latest-RHEL-9.0/compose/BaseOS/x86_64/images/
OK, I'll try and replicate locally using base image rhel-guest-image-9.0-20220420.0.x86_64.qcow2
Oh I see what is happening, the path to the kernel is: /vmlinuz-5.14.0-70.13.1.el9_0.x86_64 but it should be: /boot/vmlinuz-5.14.0-70.13.1.el9_0.x86_64 The path will be different depending on whether there is a separate /boot partition or not. There is already a script[1] which fixes this for the BLS entries in the base image[1], but I think something different is happening here. My theory is that grub2-mkconfig is detecting the *build host* partition layout has a /boot partition, then generates incorrect file paths inside the chroot. That is why this might be intermittent, some hosts have a /boot partition, others not. I've actually already proposed another change for a different reason[2] which should also fix this. [1] https://opendev.org/openstack/diskimage-builder/src/branch/master/diskimage_builder/elements/rhel/post-install.d/03-reset-bls-entries#L31-L34 [2] https://review.opendev.org/c/openstack/diskimage-builder/+/846838
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543