Bug 2029801
| Summary: | RFE: Allow creating kdump.img for all kernel versions | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Marko Myllynen <myllynen> |
| Component: | kexec-tools | Assignee: | Philipp Rudo <prudo> |
| Status: | NEW --- | QA Contact: | Jie Li <jieli> |
| Severity: | unspecified | Docs Contact: | Sujata Kurup <skurup> |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | frival, prudo, ruyang, skurup, xiawu |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Release Note | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Story | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Marko Myllynen
2021-12-07 10:37:55 UTC
Hi Marko, I'm currently looking into your RFE. Can you please help me to understand your use case a better so I know what needs to be done. BTW as this targets cloud environments, I'm currently assuming that the system where you create the images and the instances where the images are ran differ substantially. Especially they might want to have different settings in /etc/kdump.conf. (In reply to Marko Myllynen from comment #0) > Description of problem: > dracut allows updating the standard initramfs image for all kernels with: > > dracut -f --regenerate-all > > Currently "kdumpctl rebuild" can be used to update the kdump.img image only > for the running kernel. That's not entirely true. You can use a specific kernel by setting KDUMP_KERNELVER in /etc/sysconfig/kdump (Note: exporting KDUMP_KERNELVER before executing kdumpctl won't work as the variable will be overwritten at the beginning of kdumpctl by the value set in the config...). So in theory you could update /etc/sysconfig/kdump (and /etc/kdump.conf) and then call "kdumpctl rebuild" for every installed kernel. But that sounds unnecessarily complicated and quite error prone to me. > It would be helpful in some cases if "kdumpctl rebuild" would provide > similar functionality as dracut so to allow creating/updating the kdump.img > for all the installed kernel versions. A recent item added a --kernel=<kernel-path> option for an different subcommand, where <kernel-path> can be any path accepted by grubby (including ALL and DEFAULT). My plan is to add the same option for 'rebuild' so that a user can specify for which kernel version(s) the initrd shall be rebuild. In addition I plan to add a '--config' option that allows to specify an alternate config instead of /etc/kdump.conf. Would my plans be sufficient for your use case? > For instance, when creating a base image this could be used to create the > kdump.img during image creation time thus hopefully avoiding the need for > each instance creating the kdump.img after the initial boot. Agree, avoiding the need to rebuild the initrd for every instance what we should aim for. Thanks Philipp > Version-Release number of selected component (if applicable): > RHEL 9.0 Beta Thanks for looking into this! (In reply to Philipp Rudo from comment #2) > > I'm currently looking into your RFE. Can you please help me to understand > your use case a better so I know what needs to be done. > > BTW as this targets cloud environments, I'm currently assuming that the > system where you create the images and the instances where the images are > ran differ substantially. Especially they might want to have different > settings in /etc/kdump.conf. That's a good point that should be kept in mind, and preferably also mentioned on the man page if this feature is added. I'm currently building our local base image on VMware which is also where it will be used so here we should have pretty much identical systems in both cases. Some VMs might eventually have different amount of NICs and more disks but all the adapters and drivers should still be the same. > > Currently "kdumpctl rebuild" can be used to update the kdump.img image only > > for the running kernel. > > That's not entirely true. You can use a specific kernel by setting > KDUMP_KERNELVER in /etc/sysconfig/kdump (Note: exporting KDUMP_KERNELVER > before executing kdumpctl won't work as the variable will be overwritten at > the beginning of kdumpctl by the value set in the config...). A-ha, ok, I failed to notice that, I only tried using the environment variable and it didn't help. I've now managed to build kdump initramfs in a template preparation script for the latest kernel with: # Create kdump initramfs for the newest kernel kver_latest=$(rpm -q --qf "%{version}-%{release}.%{arch}\n" kernel | sort -V | tail -n 1) sed -i -e "s,^KDUMP_KERNELVER=.*,KDUMP_KERNELVER=$kver_latest," /etc/sysconfig/kdump kdumpctl rebuild sed -i -e 's,^KDUMP_KERNELVER=.*,KDUMP_KERNELVER="",' /etc/sysconfig/kdump But as you say this is unnecessarily complicated compared to merely providing an option to kdumpctl. > A recent item added a --kernel=<kernel-path> option for an different > subcommand, where <kernel-path> can be any path accepted by grubby > (including ALL and DEFAULT). My plan is to add the same option for 'rebuild' > so that a user can specify for which kernel version(s) the initrd shall be > rebuild. In addition I plan to add a '--config' option that allows to > specify an alternate config instead of /etc/kdump.conf. > > Would my plans be sufficient for your use case? Yes, sounds very good, --kernel=ALL or such would be as easy as it needs to be. Thanks! Draft for this feature was sent to the mailing list [1]. It became a rather large change so I'm afraid I won't be able to backport it to 8.9/9.3 in time. So deferring this RFE once more. [1] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/ENTBABCB6OJO3X4ZAP5CLJT5K5FUNYGV/ |