TL;DR cockpit-bootloader detects changes made by kdump-commandline.service as manual changes.
I've recently been helping a friend get a crashkernel working on their system, and a leftover from that is that I still have the kdump packages installed and the services enabled. The kdump-commandline service changes the command line in order to allocate appropriate space for the crash kernel. Here you can see it detecting that the value I manually changed (I was testing cockpit-bootloader and this was a harmless change), was incorrect, and fixing it:
> systemctl status kdump-commandline.service
○ kdump-commandline.service - Check and update kdump options on the kernel command line
Loaded: loaded (/usr/lib/systemd/system/kdump-commandline.service; enabled; preset: disabled)
Active: inactive (dead) since Sat 2026-01-31 22:56:34 AEDT; 6min ago
Duration: 1.833s
Invocation: aa321ed48b1e47b5851ee58176f44f15
Process: 1985 ExecStart=/usr/sbin/kdumptool commandline -c -U (code=exited, status=0/SUCCESS)
Main PID: 1985 (code=exited, status=0/SUCCESS)
Mem peak: 33M
CPU: 1.182s
Jan 31 22:56:32 Pallas kdumptool[1985]: Kdump expects these crashkernel= values on the kernel command line:
Jan 31 22:56:32 Pallas kdumptool[1985]: crashkernel=72M,low crashkernel=387M,high
Jan 31 22:56:32 Pallas kdumptool[1985]: (based on the output of 'kdumptool calibrate')
Jan 31 22:56:32 Pallas kdumptool[1985]: /proc/cmdline contains:
Jan 31 22:56:32 Pallas kdumptool[1985]: crashkernel=72M,low crashkernel=512M,high
Jan 31 22:56:32 Pallas kdumptool[1985]: Kdump may not work correctly
Jan 31 22:56:34 Pallas kdumptool[1985]: Updated the command line options in the bootloader.
Jan 31 22:56:34 Pallas kdumptool[1985]: Changes will take effect on next boot.
Jan 31 22:56:34 Pallas systemd[1]: kdump-commandline.service: Deactivated successfully.
Jan 31 22:56:34 Pallas systemd[1]: kdump-commandline.service: Consumed 1.182s CPU time, 33M memory peak.
cockpit-bootloader does not like this:
Grub2 config doesn't match the selected snapshot.
This is caused by manual configuration changes.
Chanes made to grub config
@@ -8,7 +8,7 @@
GRUB_HIDDEN_TIMEOUT=1
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=0
-GRUB_CMDLINE_LINUX_DEFAULT="quiet security=selinux selinux=1 preempt=full rcu_nocbs=0-N rcu_nocb_poll threadirqs psi=1 pci=realloc,pcie_bus_perf pcie_aspm.policy=performance iwlmvm.power_scheme=1 nvidia.NVreg_EnableResizableBar=1 nvidia.NVreg_UsePageAttributeTable=1 nvidia.NVreg_RegistryDwords=“RMIntrLockingMode=1\\;RmEnableAggressiveVblank=1” crashkernel=72M,low crashkernel=512M,high mitigations=off rd.driver.blacklist=nouveau"
+GRUB_CMDLINE_LINUX_DEFAULT="quiet security=selinux selinux=1 preempt=full rcu_nocbs=0-N rcu_nocb_poll threadirqs psi=1 pci=realloc,pcie_bus_perf pcie_aspm.policy=performance iwlmvm.power_scheme=1 nvidia.NVreg_EnableResizableBar=1 nvidia.NVreg_UsePageAttributeTable=1 nvidia.NVreg_RegistryDwords=“RMIntrLockingMode=1\\;RmEnableAggressiveVblank=1” crashkernel=72M,low crashkernel=387M,high mitigations=off rd.driver.blacklist=nouveau"
GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX_RECOVERY="security=selinux selinux=1"
PS "Chan(g?)es made to grub" :)
TL;DR cockpit-bootloader detects changes made by kdump-commandline.service as manual changes.
I've recently been helping a friend get a crashkernel working on their system, and a leftover from that is that I still have the kdump packages installed and the services enabled. The kdump-commandline service changes the command line in order to allocate appropriate space for the crash kernel. Here you can see it detecting that the value I manually changed (I was testing cockpit-bootloader and this was a harmless change), was incorrect, and fixing it:
cockpit-bootloader does not like this:
PS "Chan(g?)es made to grub" :)