Is it possible to modify the official Rocky Linux ISO to begin the kickstart installation with a more recent vmlinuz?
I need the kernel to be version 5.14.0-427.28.1 rather than the default 5.14.0-427.13.1 that ships with the ISO.
This is critical because I need the kernel running during the kickstart phase to match the version 427.28.1 as several drivers require it during my kickstart post customizations process.
Could you advise on how to customize the ISO to upgrade the kernel during kickstart, and also to update the included repositories like AppStream and BaseOS?
Tbh instead of modifying the ISO, I would create a new one, with the stuff you need.
I can recommend using the image builder for that, if you can spare another system to build images. (the setup part of the repos is even a bit simpler than when using RHEL, as in the guide, just adding the repos without the rhsm part)
That can build you customized ISOs, which immediately start the kickstart install, or even build ready to use template images, for hypervisors.
In this case it will put the latest available packages in the image.
The drivers actually work on version 5.14.0-427.13.1, but I had already created a VMDK template for all of my VMware-based VMs and deployed them with 28.1. The issue only came up with my bare-metal machines, where we use the PXE kickstart method for testing. Downgrading my whole infrastructure wasn’t something I wanted to deal with, and building a custom ISO seemed even more inconvenient.
In the end, I recreated the entire infrastructure on version 5.14.0-427.13.1. Since it’s partly automated, I didn’t mind doing it.
The drivers actually work on version 5.14.0-427.13.1, but I had already created a VMDK template for all of my VMware-based VMs and deployed them with 28.1
Always remember that there is no difference between installing (eg) 9.1 and upgrading to 9.5 or just installing 9.5 . If you’re used to other package formats and workflow, you may be surprised by the knowledge.
You’ll be updating your deployed machines immediately, as there’s no risk, there’s trivial rollbacks (backinstalls), and it’s all atomic so no half-installs of packages.
Given the requirement of long-term support that keeps things compatible, running yum-upgrade via cron is still a recipe for easy success even after they moved to using lennart’s cancerous blob for all the things – 99% safe vs 100%.