Nope, doesn’t work. I just did it, editing the kdump.conf and set it to no. Then installed kernel-ml to test it, still crashkernel enabled. Just confirming. None of what we tested so far, including this doesn’t work.
I also realised that /etc/kernel/install.d is analogous to /usr/lib/kernel/install.d - so similar to like putting your own systemd services in /etc/systemd/ instead of under /usr/lib/systemd. I even tried doing the 92-crashkernel thing there by creating a script just to exit 0 and then making it executable, and that also didn’t work. That would have at least been better than editing the one under /usr/lib/kernel/install.d anyway to try and make it a bit more of an official way of doing it.
Even using a combo of grub-mkconfig --update-bls-cmdline and grubby doesn’t work either. It’s like every single option is completely crippled.
I have kdump service disabled anyway which removed the additional files that were usually generated under /boot each time a kernel was installed. Whether that actually helps any, even when dmesg still shows crashkernel memory as being allocated I’ve no idea. But I’m OK with my VM memory usage anyway at present. Was just attempting to figure a way of fixing it to help you guys out.
I think we are missing some additional preconditions here. My tests shows that a reinstall of the current running kernel does not get the bls+crashkernel entries added. Enabling auto_reset_crashkernel introduces the crashkernel entry again when doing a reinstall. My context does not have any crashkernel entry in /etc/default/grub, /etc/grub2.cfg, /proc/cmdline, /etc/kernel/cmdline. GRUB_ENABLE_BLSCFG=true is set in /etc/default/grub.
Now try this installing a completely new kernel that isn’t on the system. I did this pulling a kernel from elrepo, the parameters appear. So, if you try this and they don’t for you, then that means something else is different on your system. Existing kernels aren’t the problem here. It’s installing new ones.
I have a Alma 9.3 that (unintentionally) has kdump enabled.
The /etc/default/grub:GRUB_CMDLINE_LINUX does not contain crashkernel.
The /etc/kernel/cmdline does not contain crashkernel.
Every bootloader-entry does have crashkernel and hence the kernel runs with it too.
I did systemctl disable kdump.service ; systemctl stop kdump.service and reboot.
The kernel still boots with crashkernel option because BLS-entry is unchanged.
Then: grub2-mkconfig --update-bls-cmdline -o /boot/grub2/grub.cfg
Now the bootloader-entries do not contain crashkernel any more.
Conclusion: the generation of bootloader-entry does not get the crashkernel option from /etc/default/grub nor from /etc/kernel/cmdline; some other source does provide that. (Similarly, the root=XXX ro is not from /etc/default/grub – but exists in /etc/kernel/cmdline.)
I have a stand alone RL9 server and also RL9 installed in a vm on a Fedora machine. Both have crashkernel on the command line but the vm does not reserve the 256 MB memory space. On the vm the kdump status is enabled and the output is that a condition is not met thus it is dead.
On the server kdump is disabled but as has been shown that has no effect on memory reservation.
When I have a clean Rocky 9 install I don’t have an /etc/kernel/cmdline file. I only get this when running the grubby commands to configure removal of crashkernel. Even without it, the grubby info command reports crashkernel as being there. I have disabled kdump service, and my /boot/grub2/grub.cfg or /etc/grub2.cfg do not contain crashkernel entries. dmesg does claim that it reserves 256mb, although I cannot verify if it does actually reserve it, or just outputs the message anyway.
Not been able to get crashkernel disabled using any of the methods here, usually up until this thread appeared I just disabled kdump and forgot about it. We could probably spend so much time on this probably far more than it’s worth tbh
That option (crashkernel) is generated by the install script, that are executed when a kernel is installed (all scripts in /usr/lib/kernel/install.d/ are executed). So, you need the additional key auto_reset_crashkernel set to no in /etc/kdump.conf to dictate to not add the mention option to new kernels.
Because of the way the option is crafted, crashkernel reserves memory up to 512MB depending on the total system memory available to the kernel. That’s what the option means. Not a good assumption if you ask me. Very confusing.
It’s a bug guys! I’m filing it. Everyone go home and have a nice break!
No idea why people are talking about other distroes here. This is def a distro-specific issue. I came to Rocky forums because it’s a Rocky problem!
I’ve had known this issue far back since CentOS 7. Devs still didn’t get rid of that stupid kernel option. So annoying. Rocky(or RHEL) nowadays run on VMs anyways. The kernel crash on CSP VMs are often due to underlying host issue, not the kernel itself. Even if it is, ain’t nobody got time for carefully pulling the dump off the vm and inspecting/investigating it. More of than not, the dump alone cannot solve all the problems. You have to use kernel module options to troubleshoot.
It’s only a coincidence that I tested using the 9.4 beta. Disabling dump on install, the beta removed the whole crashkernel option.
Would it work on RL 9.3? Removal of crashkernel did return the 256mb. But the utilities make dump --mem-usage /proc/kcore and kdumpctl showmem do return errors. Unsure what would happen on a system crash.
Well, I think it’s worth investigating it. Consider that other distroes don’t even ship with kdump enabled. Think how many PHP connections you can handle with 512MB. It’s at least 20. You can run a whole mariadb with that amount of memory. It’s ridiculous. All that much memory sitting on its arse doing nothing. Memory is expensive on cloud, you know. Every megabyte counts. Think how much work put into that memory thus saving energy.
Or maybe I’m just too paranoid because I’m from the embedded world.
My premise was that you don’t need kdump for most use cases. It’s not too late to turn it on when you start experiencing some issues. Most distroes don’t ship with it enabled anyways for that very reason.
It’s only a coincidence that I tested using the 9.4 beta. Disabling dump on install, the beta removed the whole crashkernel option.
Rocky is based on RHEL, so most bugs in Rocky are same as the RHEL has. Those have to be reported to Red Hat as “bug in RHEL (or CentOS Stream)” in order for RH to fix them. Rocky then rebuilds from fixed versions of code. (CentOS was the same way – bug for bug what RHEL had.)
It is possible for Rocky to have some bugs of its own. Errors in the build process, like some package initially missing. Those bugs Red Hat cannot fix.
