On Fri, Mar 13, 2020 at 10:03 AM Thomas Blume <Thomas.Blume@xxxxxxxx> 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
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
