[systemd-devel] _netdev for system root mount?

[Mantas Mikulėnas]

On Mon, Mar 16, 2020 at 11:52 AM Thomas Blume <Thomas.Blume at suse.com> wrote:

> On Fri, 13 Mar 2020, Alexander E. Patrakov wrote:
>
> > On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov <arvidjaar at gmail.com>
> wrote:
> >
> >> And what is the "official" way to prevent various units required by root
> >> mount from being stopped during shutdown? There could be arbitrarily
> >> deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...).
> >
> > https://systemd.io/ROOT_STORAGE_DAEMONS/
>
> So, that means that the iscsi unit files in the running system are not
> designated and supported for system root, right?
>

I've only used iSCSI for data volumes, but... how could the rootfs possibly
be dependent on a process running *from the same rootfs*? I mean, the iSCSI
or NBD daemons have to start from somewhere else *before* the rootfs is set
up and mounted, don't they?

If the rootfs is iSCSI-based or NBD-based, then I would expect the
corresponding daemons to be started from the *initramfs*, meaning they
wouldn't be managed as rootfs .service units in the first place -- and they
wouldn't be stopped along with other .service units either.

(Note that if your initramfs itself is systemd-based, then it has a
completely separate set of units, with its own boot order and everything.)


>
> What about the network.service?
> I guess this should be also unsupported for the network device providing
> system
> root?
>

network.service is a distro-specific addition. I don't know what it
supports on your system.

But in general, network configuration tools often have an option to leave
an interface configured upon exit. For example systemd-network
has KeepConfiguration=.


>
> Finally, can I also conclude that the _netdev parameter as an ordering
> constraint for the network block device is also not supported for system
> root?
>

Same comment as above... how is systemd supposed to put other units before
the rootfs, if they're started *from* the rootfs?

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