Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux-meta (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1918085
Title:
Package linux-crashdump in 20.04 configures kernel cmdline crashkernel
incorrectly causing lock-up on kernel dump
Status in linux-meta package in Ubuntu:
Confirmed
Bug description:
Package linux-crashdump in 20.04 configures kernel cmdline crashkernel
incorrectly causing lock-up on kernel dump.
It is very simple to replicate. I was testing using QEmu
virtualisation software, where I had QEmu running a 20.04 install
within another 20.04 install.
Within the virtualisation install, simply install the package
"linux-crashdump":
$ sudo apt install linux-crashdump
Answering Yes and Yes to the two questions asked:
|------------------------| Configuring kexec-tools |------------------------|
| |
| |
| If you choose this option, a system reboot will trigger a restart into a |
| kernel loaded by kexec instead of going through the full system boot |
| loader process. |
| |
| Should kexec-tools handle reboots (sysvinit only)? |
| |
| <Yes> <No> |
| |
|---------------------------------------------------------------------------|
|------------------------| Configuring kdump-tools |------------------------|
| |
| |
| If you choose this option, the kdump-tools mechanism will be enabled. A |
| reboot is still required in order to enable the crashkernel kernel |
| parameter. |
| |
| Should kdump-tools be enabled be default? |
| |
| <Yes> <No> |
| |
|---------------------------------------------------------------------------|
Check the kernel command-line Grub configured by package install:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.4.0-66-lowlatency root=/dev/mapper/rootlvm-rootpart ro
crashkernel=512M-:192M
As you can see "crashkernel=512M-:192M" is definitely a syntax error.
Furthermore, when I test with this default configuration by forcing a crash:
Enable dump then reboot testing with the following command:
sudo sysctl -w kernel.sysrq=1
Once this is done, you must become root, as just using sudo will not be
sufficient. As the root user, you will have to issue the command echo c >
/proc/sysrq-trigger.
Once the "echo c > /proc/sysrq-trigger" command is issued as root, the
virtual host being tested locks-up at 100% CPU indefinitely. Forcing
shutdown and reboot shows no crash file in /var/crash folder however I
can only see files "kexec_cmd" and "kdump_lock".
To manually fix this issue I changed to "crashkernel=512M-:192M" to
"crashkernel=384M-:512M" by editing (i.e. make the small number/larger number
order correct):
$ sudo vim /etc/default/grub.d/kdump-tools.cfg
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT
crashkernel=384M-:512M"
After reboot and retest of the forced crash commands, the kdump works and all
the needed files are present after self-reboot:
$ ls /var/crash/
202103081345 kdump_lock kexec_cmd
linux-image-5.4.0-66-lowlatency-202103081345.crash
$ ls /var/crash/202103081345/
dmesg.202103081345 dump.202103081345
In summary the problem is that the default kernel command-line
configured by default "crashkernel=512M-:192M" is faulty in some way
or other and causes the kernel to lock-up at 100% CPU indefinitely
when kdump is triggered.
This can be manually fixed giving a workaround but future user will
suffer until the default installation configuration is fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1918085/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
