Description of problem: When modifying the shipped overcloud image using virt-customize, we encountered issues booting up this image during provisioning. For example, we are injecting repositories and updating RPMs. Version-Release number of selected component (if applicable): Compose: RHOS-17.1-RHEL-9-20230511.n.1 rhosp-director-images-base-17.1-20230509.1.el9ost.noarch rhosp-director-images-metadata-17.1-20230509.1.el9ost.noarch rhosp-director-images-ipa-x86_64-17.1-20230509.1.el9ost.noarch rhosp-director-images-x86_64-17.1-20230509.1.el9ost.noarch rhosp-director-images-17.1-20230509.1.el9ost.noarch rhosp-director-images-minimal-17.1-20230509.1.el9ost.noarch rhosp-director-images-uefi-x86_64-17.1-20230509.1.el9ost.noarch How reproducible: 100% Steps to Reproduce: 1. Modify overcloud image with `virt-customize` (or other guestfish tools) 2. Start provisioning. Actual results: RHEL failing to boot properly on baremetal node. Expected results: RHEL boots properly on baremetal node. Additional info:
Created attachment 1965033 [details] fail boot
Created attachment 1965034 [details] fail boot
I believe a kernel was updated in the overcloud image in the attached pictures containing the failure.
It looks like the initramfs for the updated kernel is not present in /boot (ccamposr found this). It looks like the virt-customize doesn't install the kernel-core package when performing the update. A workaround for this can be explicitly installing the kernel-rt with virt-customize.
(In reply to Ricardo Diaz from comment #4) > It looks like the initramfs for the updated kernel is not present in /boot > (ccamposr found this). It looks like the virt-customize doesn't > install the kernel-core package when performing the update. A workaround for > this can be explicitly installing the kernel-rt with virt-customize. I believe that might be intentional on part of RHEL. Regardless of that intent, this doesn't seem to be an actual bug as the issue is the image being created by user invoked virt-customize action. As such, I think this can be closed as not a bug. Please advise.
Hey Julia, Sounds logical to me that this is most likely the behavior of RHEL RPMs. Let me follow up on this tomorrow with the folks who commented on this, and we will close this bug if needed.
Could you please provide the exact commands you ran to customise the image? A possible outcome from this bug is documentation which ensures the kernel doesn't get updated during these customise steps.
Hi Steve, this command: virt-customize -a overcloud-hardened-uefi-full.qcow2 --install kernel-core --selinux-relabel
Ricardo has provided the command.
Setting NEEDINFO to request the full documented steps followed to do this, so we can reproduce it.