[systemd-devel] _netdev for system root mount?

Mantas Mikulėnas grawity at gmail.com
Fri Mar 13 08:19:43 UTC 2020


On Fri, Mar 13, 2020 at 10:03 AM Thomas Blume <Thomas.Blume at suse.com> wrote:

> Hi,
>
> I have a SUSE SLES system where system root is provided via iscsi firmware
> (ibft).
> The installer automatically adds the _netdev parameter to the system root
> mount.
> The ordering when applying the _netdev parameter is documented as:
>
> -->
> Network mount units are ordered between remote-fs-pre.target and
> remote-fs.target, instead of local-fs-pre.target and local-fs.target. They
> also
> pull in network-online.target and are ordered after it and network.target.
> --<
>
> On system start, I can see this:
>
> -->
> Mär 12 16:38:11 install systemd[1]:
> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device:
> Dependency Before=network-online.target ignored (.device units cannot be
> del>
> Mär 12 16:38:11 install systemd[1]:
> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device:
> Dependency Before=network.target ignored (.device units cannot be delayed)
> Mär 12 16:38:11 install systemd[1]:
> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency
> Before=network-online.target ignored (.device units cannot be delayed)
> Mär 12 16:38:11 install systemd[1]:
> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency Before=network.target
> ignored (.device units cannot be delayed)
> --<
>
> Which looks like _netdev becomes almost a noop.
> The only effect I can see afterwards is that the system root mount gets
> ordered
> below remote-fs.target:
>
>
Somehow the 'cannot be delayed' message does not make sense with Before=.

But it feels like the dependency itself is backwards, too, it should be
*After=* network.target... At least I see the regular
systemd-fstab-generator adds After=, which makes more sense, but it still
triggers the same message.

I guess there's a bug in there somewhere but I'm not sure where.


>
> ● └─remote-fs.target
> ●   ├─-.mount
> ●   ├─boot-efi.mount
> ●   └─iscsi.service
>
> But this is also a noop, because system root is already mounted in the
> initrd
> and has no more relevance after switch root.
> It could be even dangerous, because on shutdown the system root mount
> might be
> attempted to stop before the system is switching back to the initrd.
>

AFAIK the root mount is never stopped (and has the 'perpetual' flag set). I
don't think it would even be *possible* to do so because pid1 itself is
being executed from there, as well as there's still other filesystems
(/run, /dev) mounted on top of it. (Which is the entire point of switching
back to the shutdown-initramfs.)

Either way – stopping a mount literally just unmounts the filesystem (which
is supposed to be a safe operation). I'd probably be more worried about
iscsi.service, since the blockdev losing connection *before* its fs is
unmounted is actually the dangerous part...

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200313/4707aceb/attachment.htm>


More information about the systemd-devel mailing list