Bug 2029801

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/

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.