On 13/06/19 2:10 PM, Dave Young wrote:
Hi Hari,
On 06/13/19 at 12:53pm, Hari Bathini wrote:
> Hi Dave,
>
> Thanks for the review..
>
> On 12/06/19 11:33 AM, Dave Young wrote:
>> Hi Hari,
>> On 06/11/19 at 11:30pm, Hari Bathini 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(a)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
>> Still not get why this can solve the problem, but with above change it
>> could cause kdump fail:
>> | sysroot.mount
>> | |
>> | v
>> | initrd-root-fs.target
>> | |
>> | v
>> v initrd-parse-etc.service
>> (custom initrd |
>> services...) v
>> | (sysroot-usr.mount and
>> | various mounts marked
>> | with fstab option
>> | x-initrd.mount...)
>> | |
>> | v
>> | initrd-fs.target
>> \______________________ |
>> \|
>> v
>> initrd.target
>> |
>> v
>> initrd-cleanup.service
>>
>>
>> We can see there is sysroot-usr.mount and other mounts after
>> initrd-parse-etc.service, kdump needs to be after those mounts.
>>
>> Actually we do not care about rootfs, current kdump scripts can work
>> without root, if dump to root fs we still regard it as a normal mount.
> We are covered by systemd-fstab-generator. It generates mount units, for all entries
> in /etc/fstab, which finish before local-fs.target. Same goes for sysroot.mount
> as well with an entry for /sysroot available in /etc/fstab in KDump/FADump case.
> So, the mount(s) dump capture scripts would be looking for should be ready well
> before initrd-root-fs.target (local-fs.target/sysroot.mount)..
I'm still not sure I can get the whole process clearly, but since in
the boot process flow, it saids about "x-initrd.mount", we appended the
flag in mkdumprd like below:
# "x-initrd.mount" mount failure will trigger isolate emergency service
# W/o this, systemd won't isolate, thus we won't get to emergency.
# This is not applicable to remote fs mount, because if we use
# "x-initrd.mount", remote mount will become required by
# "initrd-root-fs.target", instead of "remote-fs.target".
That's how it is
# handled within systemd internal. We need remote mount to be required
# "remote-fs.target", because we need to bring up network before any
remote
# mount and "remote-fs.target" can be a checkpoint of that.
# If remote mount fails, dracut-initqueue will still start and once
# dracut-initqueue finishes, kdump service will start. Because remote mount
# failed, kdump service will fail and it will lead to kdump error handler.
if ! is_nfs_dump_target; then
_options="$_options,x-initrd.mount"
fi
With fstab-generator, it is no longer relevant which was nicely summarized in
commit 8fd9f017b235 (mkdumprd: remove useless "x-initrd.mount")
Another thing is we still not sure why this can fix the bug, more
digging should be neede, let's see if Kairui and Pingfan have comments.
Niether do I. Someone said we can't trust "init" to do the sane thing
anymore for a reason :)
I am sure of two things though. One, initrd-parse-etc.service can change the dependency
graph
and it has something to do with why we are failing even after the filesystem mount did
succeed. Two, stopping systemd from getting to that point till kdump-capture.service is
done with is helping...
- Hari