On 05/13/14 at 10:50pm, Vivek Goyal wrote:
On Thu, May 08, 2014 at 07:37:13PM +0800, WANG Chao wrote:
> This patch does the following two changes in 2nd kernel:
> a). dump target is mounted under /sysroot
> b). append "x-initrd.mount" to the mount options.
> With a). we don't need to track what we've mounted in 2nd kernel. We
> can just umount recursively every mount in /sysroot by command:
> umount -R /sysroot
Why do we need to "umount" everything under /sysroot?
dump target is mounted under /sysroot/ in 2nd kernel, say
To keep error handler simple enough, I don't want to check out /etc/fstab
about where the dump target is mounted. So it makes life much easier to
have the dump target mount under /sysroot/. Before reboot or poweroff,
we can simply umount -R /sysroot to have both /sysroot and dump target
mount to be unmounted.
> It's very convenient to do so, because it's hard to track what we've
> mounted when we're in error handling path. So mount everything under
> /sysroot is reasonable and practical for us.
As I said here as well ...
> With b). the mount unit becomes required by "initrd-root-fs.target"
> rather than it used to be "local-fs.target".
> The difference between "initrd-root-fs.target" and
> the former has OnFailureIsolate=yes but the later does not. From
I don't understand why do we need this. initrd-root-fs.target should
be dependent only on root mount unit and no other mount unit. And if
one can't mount root, that's a fatal failure and launching emergency
shell in "Isolate" mode makes sense.
No, not with "x-initrd.mount":
# ls -l /run/systemd/generator/initrd-root-fs.target.wants/
lrwxrwxrwx 1 root 0 36 May 14 13:58 sysroot.mount ->
But not reaching local-fs.target should not be a fatal failure. One
should still be able to continue with boot. And to me it makes sense
that in this case emergecny shell is launched without isolating rest
of the serivces.
We must isolate to emergency in case of any error which is critical for
initrd.target. So that we can avoid any further systemd unit execution.
Because initrd-cleanup.service, as one of those units, would switch
Let's take local-fs.target for example:
local-fs.target fails and emergency.service is triggered. And
because sysinit.target "Conflicts=" with emergency.service,
sysinit.target will be stopped. basic.target "Requires=" sysinit.target,
which will in turn be stopped too. initrd.target "Requires="
basic.target, and it will be stopped too. Then initrd-cleanup.service
comes into the picture because it runs "After" initrd.target. Given the
fact that initrd.target is considered to be done from perspective of
initrd-cleanup.service, initrd-cleanup.service will be started and will
That's why we need to isolate on any error. We want systemd to stop
completely except for the emergency services.
These dependencies are complicated and some of the systemd terms are not
quite comprehensive so it's possible I made mistake here. But bottom
line is "local-fs.target" doesn't work out and systemd switch root.
"initrd-root-fs.target" (x-initrd.mount) works flawlessly.
That also means that if we fail to mount an nfs or non-root file system,
we will fall into emergency shell with sysroot mounted? That's what we
No. None of these are related...
> Takes a boolean argument. If true, the unit listed in OnFailure=
> will be enqueued in isolation mode, i.e. all units that are not its
> dependency will be stopped. If this is set, only a single unit may
> be listed in OnFailure=. Defaults to false.
> With OnFailure=emergency.target and OnFailureIsolate=yes, when error
> occurred during the boot, systemd will "isolate" to emergency.target,
> that means all the service will be stopped except the dependencies of
> emergency.target. So that systemd boot process will be interrupt and
> leave emergency.target as the only one running. Without the isolate,
> systemd will continue to boot and emergency.target will be interrupted.
What do you mean by emergency.target will be interrupted.
I explain at above why it doesn't work out if we don't isolate.