I don’t like crashkernel reserving 256MB of memory on my cloud vm. There’s no point! VMs rarely crash. It’s just a waste of precious memory.
I couldn’t find a way to prevent crashkernel args from getting to BLS entries. It seems that the devs didn’t think this through. The BLS entries are generated by installkernel. It pulls the param using an undocumented feature of kdumpctl(/usr/lib/kernel/install.d/92-crashkernel.install).
All the materials on the internet are outdated as /etc/defaults/grub has nothing to do with BLS entries anymore. I can always remove/hide 92-crashkernel.install, but there’s no guarantee that the package responsible for the file(kexec-tools) won’t get updated and dnf won’t install it again.
What am I missing here? Just posting before filing a bug report.
You didn’t understand the problem. I know how to remove args from individual BLS loaders. Future kernels installed by the package managers will still have crashkernel args.
Disabling kdump.service does not magically turn off the crashkernel cmdline or reclaim the memory reserved for crashkernel during boot time. The only way to reclaim it is reloading the kernel with crashkernel option turned off.
[ 0.162689] Reserving 256MB of memory at 512MB for crashkernel (System RAM: 16382MB)
Yes, Rocky 9 does it different by including the cmdline in each bls loader conf. I think AlmaLinux does it elegantly, too. I like the idea of BLS. The problem is that RHEL devs thought too much about customizability.
Now, wait for a kernel update and see that the crashkernel=... option appear in the new loader entry for the new version of kernel. The only way to prevent it from happening is deleting/disabling in Rocky 9 /usr/lib/kernel/install.d/92-crashkernel.install which is a cheap hack as mentioned in the original post. My question was what’s the “right way” that devs as intended and designed?
mentions using grub2-editenv, as well as the commands we already listed above which are supposed to set the defaults for existing and new kernels, and it doesn’t work.
That would seem to be the correct way, but for some bizarre reason it’s not working as intended.
IIRC, there were some “fluctuation” on whether (BLS) entry has $kernelopts on the options line or the “hardcoded” options verbatim. Was it on EL8, were I confused by EL9? I seem to recall reading bugzilla about it. (I was confused by EL9’s grub initially.)
The former does use that variable from grubenv, has thus same set of options for all entries, and install of kernel does not need to do anything to “copy” the options.
The latter allows each entry to have different options, but the install of new kernel has to copy those options from somewhere.
The EL9 does use the latter method and apparently copies options from /etc/kernel/cmdline grub2-mkconfig --update-bls-cmdline seems to update the /etc/kernel/cmdline (and BLS entries).
The --update-bls-cmdline was added in el9_3.
- reset-crashkernel-for-installed_kernel)
+ _reset-crashkernel-for-installed_kernel)
if [[ $(kdump_get_conf_val auto_reset_crashkernel) != no ]]; then
reset_crashkernel_for_installed_kernel "$2"
fi
Use auto_reset_crashkernel or just disable kdump.service like you said. AND then regenerate the BLS entries. That should do it. If not, this is clearly a bug.
This whole thing has to be documented somewhere!
What a nightmare. One hell of a rubberduck debugging we did here.
Using grubby with the --updata=ALL option should create this file:
/etc/kernel/cmdline
The “kernel-install” script reads this file to populate the kernel parameters on new kernel installs. The most important parameter that must be in this file is the “root=<path to / and subvolume or UUID and subvolume>” .
If it doesn’t then new kernels won’t boot.
Mate, you haven’t tested it yourself. Do you even see what the problem is? Have you reinstalled/upgraded the kernel to see if that worked? Well, last time I checked, it didn’t.