<div dir="ltr"><div dir="ltr">On Mon, Mar 16, 2020 at 11:52 AM Thomas Blume <<a href="mailto:Thomas.Blume@suse.com">Thomas.Blume@suse.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 13 Mar 2020, Alexander E. Patrakov wrote:<br>
<br>
> On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>> wrote:<br>
><br>
>> And what is the "official" way to prevent various units required by root<br>
>> mount from being stopped during shutdown? There could be arbitrarily<br>
>> deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...).<br>
><br>
> <a href="https://systemd.io/ROOT_STORAGE_DAEMONS/" rel="noreferrer" target="_blank">https://systemd.io/ROOT_STORAGE_DAEMONS/</a><br>
<br>
So, that means that the iscsi unit files in the running system are not<br>
designated and supported for system root, right?<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>(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.)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What about the network.service?<br>
I guess this should be also unsupported for the network device providing system<br>
root?<br></blockquote><div><br></div><div>network.service is a distro-specific addition. I don't know what it supports on your system.</div><div><br></div><div>But in general, network configuration tools often have an option to leave an interface configured upon exit. For example systemd-network has KeepConfiguration=.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Finally, can I also conclude that the _netdev parameter as an ordering<br>
constraint for the network block device is also not supported for system root?<br></blockquote><div><br></div><div>Same comment as above... how is systemd supposed to put other units before the rootfs, if they're started *from* the rootfs?</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>