From 8fcbb4d265f6f7948081ecd88cccbb1d6548c449 Mon Sep 17 00:00:00 2001 From: Hari Bathini Date: Tue, 19 May 2020 20:19:15 +0530 Subject: [PATCH] fadump: update fadump-howto.txt with some more troubleshooting help On journaling filesystems like XFS, bootloader is likely to pick up older initrd (without vmcore capture scripts) if system crashes right after initrd update, as the bootloader (read GRUB) may not replay filesystem log before reading the initrd from disk. Added steps to workaround that problem. Signed-off-by: Hari Bathini Acked-by: Pingfan Liu --- fadump-howto.txt | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/fadump-howto.txt b/fadump-howto.txt index 89675a1..c891e37 100644 --- a/fadump-howto.txt +++ b/fadump-howto.txt @@ -129,8 +129,24 @@ Then, start up kdump as well: This should turn on the firmware assisted functionality in kernel by echo'ing 1 to /sys/kernel/fadump_registered, leaving the system ready -to capture a vmcore upon crashing. To test this out, you can force-crash -your system by echo'ing a c into /proc/sysrq-trigger: +to capture a vmcore upon crashing. For journaling filesystems like XFS an +additional step is required to ensure bootloader does not pick the +older initrd (without vmcore capture scripts): + + * If /boot is a separate partition, run the below commands as the root user, + or as a user with CAP_SYS_ADMIN rights: + + # fsfreeze -f + # fsfreeze -u + + * If /boot is not a separate partition, reboot the system. + +After reboot check if the kdump service is up and running with: + + # systemctl status kdump.service + +To test out whether FADump is configured properly, you can force-crash your +system by echo'ing a 'c' into /proc/sysrq-trigger: # echo c > /proc/sysrq-trigger