On 14/06/19 1:16 PM, Kairui Song wrote:
On Wed, Jun 12, 2019 at 2:01 AM Hari Bathini <hbathini@linux.ibm.com> wrote:
In FADump mode, when the dump targer is '/home', regular boot is failing
with logs like below:

           Starting Reload Configuration from the Real Root...
  [    3.289716] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
  [FAILED] Failed to mount /kdumproot/home.
  See 'systemctl status kdumproot-home.mount' for details.
  [DEPEND] Dependency failed for Local File Systems.
  [  OK  ] Stopped dracut pre-udev hook.
  [  OK  ] Stopped dracut initqueue hook.
           Starting Kdump Emergency...
  [  OK  ] Stopped dracut cmdline hook.
  [  OK  ] Stopped dracut ask for additional cmdline parameters.
           Starting Setup Virtual Console...
           Starting Create Volatile Files and Directories...
  [  OK  ] Started Cleanup squashfs mounts when switch root.
  [  OK  ] Started Kdump Emergency.

and eventually ending up in emergency mode. 'kdumproot/home' seems to
be mounted successfully though. 'Reload from real root' is altering the
dependency graph leading to this mess. Updated kdump-capture.service
unit file to run before initrd-parse-etc.service to avoid running into
such problems. While here, dropped the deprecated 'OnFailureIsolate'
in favour of 'OnFailureJobMode'. Tested this change successfully in both
KDump and FADump modes with different dump methods (local, ssh, nfs).

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
 dracut-kdump-capture.service |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/dracut-kdump-capture.service b/dracut-kdump-capture.service
index 57139c9..df4a437 100644
--- a/dracut-kdump-capture.service
+++ b/dracut-kdump-capture.service
@@ -7,12 +7,11 @@

 [Unit]
 Description=Kdump Vmcore Save Service
-After=initrd.target initrd-parse-etc.service sysroot.mount
-After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.service
-Before=initrd-cleanup.service
+After=initrd-root-fs.target remote-fs.target
+Before=initrd-parse-etc.service
 ConditionPathExists=/etc/initrd-release
 OnFailure=emergency.target
-OnFailureIsolate=yes
+OnFailureJobMode=isolate

 [Service]
 Environment=DRACUT_SYSTEMD=1

Hi Hari,
Hi Kairui,

Thanks for the review.

I still don't understand how this fixed the issue, and I can't
repdocue it eigher (by generating a fadump initrd on my VM).
All I can say is, I faced issues with mount and initrd-parse-etc.service previously as well.
FWIW, I have seen failure on a system with the below configuration: 

	# lsblk
	NAME                       MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
	sda                          8:0    0   100G  0 disk 
	├─sda1                       8:1    0     4M  0 part 
	├─sda2                       8:2    0     1G  0 part /boot
	└─sda3                       8:3    0    99G  0 part 
	  ├─rhel_ltczep2--lp1-root 253:0    0    50G  0 lvm  /
	  └─rhel_ltczep2--lp1-home 253:2    0 158.4G  0 lvm  /home
	sdb                          8:16   0    50G  0 disk 
	└─sdb1                       8:17   0    50G  0 part 
	  └─rhel_ltczep2--lp1-home 253:2    0 158.4G  0 lvm  /home
	sdc                          8:32   0    50G  0 disk 
	└─sdc1                       8:33   0    50G  0 part 
	  └─rhel_ltczep2--lp1-home 253:2    0 158.4G  0 lvm  /home
	sdd                          8:48   1  14.4G  0 disk 
	└─sdd1                       8:49   1  14.4G  0 part 
	  ├─rhel_ltczep2--lp1-swap 253:1    0     5G  0 lvm  [SWAP]
	  └─rhel_ltczep2--lp1-home 253:2    0 158.4G  0 lvm  /home


System is hung when "systemd.journald.forward_to_console=1" parameter is passed
to the kernel. So, attaching the console log on the failing system with parameters 
"systemd.log_target=console systemd.log_level=debug" passed to the kernel...

The VM I use is a default install which use LVM, not sure if this is
related. /home is on a dedicated disk. I did found some other issue
with fadump initrd with /home as target:

[FAILED] Failed unmounting /kdumproot/home.
[  OK  ] Stopped File System Check on /dev/mapper/rhel-swap.
[  OK  ] Stopped udev Kernel Device Manager.
[  OK  ] Stopped dracut pre-udev hook.
[  OK  ] Stopped dracut cmdline hook.

But then everything goes on well.
It give more log with "systemd.log_target=console
systemd.journald.forward_to_console=1" appended to kernel cmdline:
kdumproot-home.mount: Failed to execute command: No such file or
directory
kdumproot-home.mount: Failed at step EXEC spawning /usr/bin/umount: No
such file or directory

And could be fixed by:
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 2998c72..5222040 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -30,7 +30,7 @@ depends() {
         done
     }

-    if is_squash_available; then
+    if is_squash_available && ! is_fadump_capable; then
         _dep="$_dep squash"
     else
         dwarning "Required modules to build a squashed kdump image is missing!"
This patch helps with the unmount issue (seen even with the patch I proposed)..

- Hari