Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.
Hello Powersj,
I followed the instructions on Ubuntu 20.04LTS running on a EFI only system with secure boot enabled and I canât seem to active kdump. I get the following error:
#kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x64000000
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-5.4.0-66-lowlatency
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-5.4.0-66-lowlatency
current state: Not ready to kdump
kexec command:
no kexec command recorded
#kdump-config load
* Creating symlink /var/lib/kdump/vmlinuz
* Creating symlink /var/lib/kdump/initrd.img
kexec_file_load failed: Operation not permitted
* failed to load kdump kernel
#cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.4.0-66-lowlatency root=/dev/mapper/vgdata-lvroot ro console=tty0 console=ttyS6,115200n8 rootdelay=5 net.ifnames=0 ipv6.disable=1 crashkernel=512M-:192M
Any suggestions?
Bonjour Powersj, je nâarrive plus Ă demarer le linux ni le Windows. Quand jâallume lâordinateur la console apparaĂźt et on me demande de tĂ©lĂ©charger dâabord le kernel. Cependant je ne sais pas comment procĂ©der Ă partir de la console
Vu que les commande sudo ne sont pas trouvable
Hi haimiko, sorry you hear you had trouble with kdump and secure boot. Hopefully youâve long since resolved the issue. If you did, and you have some copyedit suggestions to improve this document, please follow up with the suggested text. Unfortunately this Discourse document is not a great way to do troubleshooting of usage issues, so if you happen to still be looking for help Iâd recommend other technical support channels.
The kernel crash dump guide needs updates
Here is a link to each of the events that can cause a kernel disruption
https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
echo 1 > /proc/sys/kernel/hung_task_panic # panic when hung task is detected
echo 1 > /proc/sys/kernel/panic_on_io_nmi # panic on NMIs from I/O
echo 1 > /proc/sys/kernel/panic_on_oops # panic on oops or kernel bug detection
echo 1 > /proc/sys/kernel/panic_on_unrecovered_nmi # panic on NMIs from memory or unknown
echo 1 > /proc/sys/kernel/softlockup_panic # panic when soft lockups are detected
echo 1 > /proc/sys/vm/panic_on_oom # panic when out-of-memory happens
Changes under the default prompts after installing linux-crashdump.
During the installation, you will be prompted with the following dialogs.
âyou can select noâ for kexec-tools handling reboots. In fact it recommended to select no as this is the current default and
this step is unrelated to kernel panics and kernel crash dump collection and it applies to all
reboots. 'Yesis not actually required; This does change reboot behavior for the system not to actually reboot in the traditional fashion (soft power cycle) which might have issues (eg, some devices might not correctly handle a software-only re-initialization, instead of an actual soft power cycle), so
Nois a valid and safe choice, while
Yes` may be seen as a reboot time âoptimizationâ if the system/devices handle it well.
âYesâ should be selected here as well, to enable kdump-tools.
Remove the âas wellâ, per the above.
You can also edit /etc/default/kexec and set parameters directly:
this needs to be updated to say /etc/default/kdump-tools
If you enable kdump-tools after a reboot, you will only need to issue the kdump-config load command to activate the kdump mechanism.
I donât believe this is a correct statement
âIf you enable kdump-tools after a reboot with the crashkernel= parameter in place, you will only needâŠâ, since without the memory reservation for the crash kernel to be kexecâed on, thereâs little that kdump-tools itself can do about it.
Begin: Saving vmcore from kernel crash âŠ
This log line is out of date.
needs to say this
Started Kernel crash dump capture service
Troubleshooting -
If you are trying to crashdump on a cloud like AWS please add the following lines
to /etc/sysctl.conf and put at bottom of file.
kernel.sysctl=1
kernel.unknown_nmi_panic=1
yeah, i agree with @hypothetical-lemon this looks out of date a lot.
Is there server technical author to improve this?
Thanks for this heads up. I took a note internally to discuss with the team how to handle this topic.
Also, how to crash dump in the cloud like AWS is slightly different from doing it in say Azure.
Could you additionally clarify the statement:
Starting with 16.04, the kernel crash dump mechanism is enabled by default.
This (to me) implies that linux-crashdump is installed in 16.04 and beyond by default, but this isnât the case on my 22.04 jammy stock image, nor is it the case on public cloud images (Iâm not sure it is anywhere). Does this mean something else maybe?
Hi! As a possible point of improvement, I think it would be helpful to try to answer the question of how much disk space should be available on a system to house a full crash dump. Ostensibly that answer would be âas much RAM as is on the systemâ, but thereâs also the defaults that are used for consideration (#MAKEDUMP_ARGS="-c -d 31"
- compression and in-use-only pages).
It might also be useful to make mention of the ability to add NFS/FTP/SSH info into /etc/default/kdump-tools
for saving dumps to remote locations!
Hi @foxmulder2004 - since this moved (as the header says) but your suggestion is good I converted it into an issue tracker entry at: