On 04/10/14 at 10:05am, Vivek Goyal wrote:
On Thu, Apr 10, 2014 at 01:30:48PM +0800, WANG Chao wrote:
> > dracut-pre-pivot.service has After= dependency on sysroot.mount.
> > After=initrd.target initrd-parse-etc.service sysroot.mount
> > So if sysroot.mount fails, dracut-pre-pivot should still be started? Are you
> > sure that it does not get started if sysroot.mount fails.
> dracut-pre-pivot still gets started because dracut-pre-pivot.service
> doesn't "Requires=" sysroot.mount. So no matter if sysroot.mount
> or not, as long as it's started, dracut-pre-pivot will run.
If dracut-pre-pivot will run even if sysroot.mount fails, why did we
introduce "nofail" to begin with. (For non-root targets).
Sorry, I made a mistake here last time.
W/o "nofail", sysroot.mount failure causes initrd-root-fs.target never
get reached (or active). initrd.target isn't reached because of its
dependency on initrd-root-fs.target. dracut-pre-pivot.service runs
"After" initrd.target. So when initrd.target isn't reached,
dracut-pre-pivot appears like spin itself waiting for initrd.target. And
that's when a so-called "hang" happens.
I don't see any Requires= dependencies in dracut-pre-pivit.service.
Everything is Wants= and there are some ordering directieves with After=.
Exactly. "After" enforces that dracut-pre-pivot should wait until
those specific targets are reached or mount or service units get
That means even if file system mounting failed, dracut-pre-pivot should
run. That means kdump should get control.
dracut-pre-pivot would wait because it runs "After" these targets, which
are not reached because of a "fail" mode sysroot.mount failure.
If that's the case, why did we introduce "nofail" and why do we think
that removing "nofail" will hang if failure happens.
Given the fact that currently emergency shell does not do anything in
second kernel, I think kdump should still run even if failure happens. Can
we test it.
I've tested "fail" mode before and I did it again today. It did hang
dracut-initqueue: Warning: Could not boot.
dracut-initqueue: Warning: Not dropping to emergency shell, because
[ OK ] Started dracut initqueue hook.
[ OK ] Reached target Remote File Systems (Pre).
[ OK ] Reached target Remote File Systems.
[FAILED] Failed to mount /sysroot.
See 'systemctl status sysroot.mount' for details.
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
You can see initrd-root-fs.target ("Initrd Root File System") is not
active because it "Requires" sysroot.mount and sysroot.mount fails.
While in "nofail" mode, initrd-root-fs.target only "Wants"
sysroot.mount. "Wants" is weaker than "Requires" and it means
initrd-root-fs.target would want sysroot.mount to get started but do not
really care if sysroot.mount succeeds or not.
And that's the reason why in sysroot.mount failure case,
dracut-pre-pivot can get started in "nofail" mode and can not in
Given the current situation, I think even without "nofail", kdump.sh
should be reached. If that's the case, we don't have a problem at all?
> > I think we will have to keep our default actions simple and minimal. Boot
> > path is complicated and now dracut and systemd control it completely. We
> > will not have too much of flexibility w.r.t error handling.
> I think it's a good idea directly jumping to our kdump.sh. We can extend
> current kdump.sh. Do some reasonable checking, if the error is trivial
> and dump target is ready, then we dump. Otherwise do default action.
> What do you think?
Yep. Either we can create a seaparate kdump handler or service
(kdump-error-handler.service) and that service can take care of calling
kdump.sh or hook this into emergency handler and force it to call
kdump-error-handler.sh which in turn can call kdump.sh.
To be honest, I'm a bit confused. Are you saying that we can do either
of the following?
- create kdump handler or service, replacing the current dracut/systemd
- hook into current dracut/systemd error handler or service, and call our
handler which in turn would call kdump.sh
Personally I like the first idea, a new kdump handler or service can
give us more flexable way to control the context. Hooking seems hacky.
Anyway, this isn't decided yet. I'll try both ways.
So how about starting simple. Can you write a patch where emergency shell
first checks if kdump error handler is present and calls it (instead of
returning and not doing anything). If that works, we can just post a
dracut patch and we will not need anything from systemd?
I'll dive deeper and give it a try.