Re: [PATCH] fadump: update fadump-howto.txt with some more troubleshooting help

[piliu]

On 05/19/2020 10:49 PM, Hari Bathini wrote:
>  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(a)linux.ibm.com&gt;
>  ---
>   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
>   
>   
It is a pity that we have no elegant solution from xfs side for a long
time and only can work around with this.

Acked-by: Pingfan Liu <piliu(a)redhat.com&gt;