rpms/kexec-tools
7
0
Fork 0
Code Issues Pull Requests Releases Activity

fadump: update fadump-howto.txt with some more troubleshooting help

Browse Source 
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 <hbathini@linux.ibm.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
This commit is contained in:
Hari Bathini 2020-05-19 20:19:15 +05:30 committed by Kairui Song
parent 47bdeee35d
commit 8fcbb4d265
1 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
fadump-howto.txt
View File

@ -129,8 +129,24 @@ Then, start up kdump as well:
This should turn on the firmware assisted functionality in kernel by This should turn on the firmware assisted functionality in kernel by
echo'ing 1 to /sys/kernel/fadump_registered, leaving the system ready 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 to capture a vmcore upon crashing. For journaling filesystems like XFS an
your system by echo'ing a c into /proc/sysrq-trigger: 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 # echo c > /proc/sysrq-trigger