Appending extra kernel boot arguments after payload is installed

[ryncsn]

Hi, I'm working on kdump-anaconda-addon, and recently, we are introducing a new crashkernel.conf file in the kernel package. This crashkernel.conf will contain the default value for crashkernel= kernel parameter, and kdump-anaconda-addon will want to read from this file and set kernel boot param for bootloader.

The problem here is that the file is only accessible after kernel package is installed, (will be installed at /usr/lib/modules/<kver>/crashkernel.conf)

Ideally, the addon should be able to insert some tasks after payload installation, and before bootloader installation, this will be the best approach for this kdump new feature.
But\ now anaconda only allow addons can to tasks in the very beginning, or at the end of the whole installation.

So currently, I can manually get the kernel list after installation finished and set the value by calling kdumpctl reset-crashkernel (this is also a new command introduced to reset the crashkernel value accordingly to crashkernel.conf):
https://github.com/ryncsn/kdump-anaconda-addon/blob/578b32e694ab51bd6f47b517127b52025fad9bcc/com_redhat_kdump/service/installation.py#L110

But even in this way, I'm not sure what is the recommended way to get the kernel version list. Above code worked, but it may only work with DNF payload. Any suggestion or help is appreciated, thanks!

[ryncsn]

Hi, we just come up with another idea. Can we assume the installer's kernel is the same version with the payload's kernel (at least in same major release)? Like, assuming anaconda installer running on Fedora 33 will not install a Fedora 34 payload, is this right?

If so the kdump-anaconda-addon can simply read crashkernel.conf from the current running kernel's module directory.

[poncovka]

In theory, yes, but I wouldn't rely on that.

[jstodola]

Well, Fedora installer can install a much newer kernel version due to updates being automatically installed, see Fedora 33:

[anaconda root@fedora ~]# uname -r
5.8.15-301.fc33.x86_64
[anaconda root@fedora ~]# grep kernel-5 /tmp/packaging.log 
21:56:04,962 INF packaging: Installed: kernel-5.12.10-200.fc33.x86_64 1623332765 14d4723d60f56f327b1b9e05b3fa47f57e877bf04f0fbdb60aa722ca2d636867
21:57:31,944 INF packaging: Verifying: kernel-5.12.10-200.fc33.x86_64 1623332765 14d4723d60f56f327b1b9e05b3fa47f57e877bf04f0fbdb60aa722ca2d636867
21:57:32,883 DDEBUG dnf: /mnt/sysroot/dnf.package.cache/kernel-5.12.10-200.fc33.x86_64.rpm removed
[anaconda root@fedora ~]#

And different kernel being installed can be expected also on RHEL if the user is installing from the CDN, where a newer kernel package might exist. (But on RHEL you can expect the same version of the kernel, like 4.18.).

So I do not think it's a good idea to rely on crashkernel.conf from the running kernel.

[poncovka]

I think we can add support for installation tasks that are run after the payload installation and before the bootloader installation. We plan to make the scheduling of the installation tasks more flexible anyway, so it would be just a temporary workaround.

These tasks will be created right before their execution and we can provide the kernel version list of the installed payload. In the future, the kernel version list will be provided by a DBus module, so it will be a temporary workaround as well. It would work the same way as the bootloader installation:

anaconda/pyanaconda/installation.py

Lines 338 to 352 in e2516cb

	# Do bootloader.
	bootloader_proxy = STORAGE.get_proxy(BOOTLOADER)
	bootloader_install = TaskQueue("Bootloader installation", N_("Installing boot loader"))
	def run_install_bootloader():
	tasks = bootloader_proxy.InstallBootloaderWithTasks(
	payload.type,
	payload.kernel_version_list
	)
	for task in tasks:
	sync_run_task(STORAGE.get_proxy(task))
	bootloader_install.append(Task("Install bootloader", run_install_bootloader))
	installation_queue.append(bootloader_install)

This should work fine for all types of payloads except for RPM OSTree, where we don't generate the kernel version list. However, I think we can change that. You solution will work only if there is an RPM database on the installed system. Also, I am not sure how kdumpctl handles an inactive and possibly missing systemd of the installed system.

Just a note, we don't plan to support imports from pyanaconda.modules except for pyanaconda.modules.common. It is not documented yet, but the implementation of our DBus modules should be considered private.

[ryncsn]

I think we can add support for installation tasks that are run after the payload installation and before the bootloader installation. We plan to make the scheduling of the installation tasks more flexible anyway, so it would be just a temporary workaround.

Right, just by briefly checking the code, it seems not hard to add such hook, will this be implemented soon?

These tasks will be created right before their execution and we can provide the kernel version list of the installed payload. In the future, the kernel version list will be provided by a DBus module, so it will be a temporary workaround as well. It would work the same way as the bootloader installation:

If addon can insert tasks between payload installation and bootloader setup, I think it can skip getting the kernel list, just fetch the latest available kernel module directory under /lib/modules/, and read the crashkernel.conf file in it, then pass it as extra bootloader argument will be fine.

anaconda/pyanaconda/installation.py

Lines 338 to 352 in e2516cb

	# Do bootloader.
	bootloader_proxy = STORAGE.get_proxy(BOOTLOADER)
	bootloader_install = TaskQueue("Bootloader installation", N_("Installing boot loader"))
	def run_install_bootloader():
	tasks = bootloader_proxy.InstallBootloaderWithTasks(
	payload.type,
	payload.kernel_version_list
	)
	for task in tasks:
	sync_run_task(STORAGE.get_proxy(task))
	bootloader_install.append(Task("Install bootloader", run_install_bootloader))
	installation_queue.append(bootloader_install)

This should work fine for all types of payloads except for RPM OSTree, where we don't generate the kernel version list. However, I think we can change that. You solution will work only if there is an RPM database on the installed system. Also, I am not sure how kdumpctl handles an inactive and possibly missing systemd of the installed system.

For CoreOS issue, it's being discussed here: coreos/rpm-ostree#2894
I think it will be implemented in a different way, and still I think the addon can just read the crashkernel.conf file and pass it to bootloader arguments.

kdumpctl is independent of systemd so that's fine.

Just a note, we don't plan to support imports from pyanaconda.modules except for pyanaconda.modules.common. It is not documented yet, but the implementation of our DBus modules should be considered private.

Thanks for the note, but I'm not sure how can I access the payload object in addon, so I simply imported the modules lib.

[jkonecny12]

Fedora CoreOS is not using Anaconda for deployment. They have Ignition so it doesn't matter here. However, it still matters for Fedora SilverBlue.

[poncovka]

The support for the new installation tasks is implemented in #3452.

[poncovka]

It will be released in anaconda-35.18-1 probably next week.