Bug#551555: mountnfs.sh: start should declare dependency on name resolver

[Dmitry Bogatov]

[2019-01-11 20:35] Petter Reinholdtsen <pere at hungry.com>
> [Dmitry Bogatov]
> >> No objections, but note there used to be several scripts in rcS.d/
> >> depending on /usr/ being mounted, and these need to be moved from S to
> >> (2 3 4 5) first.
> >
> > As far as I can tell, we can assume /usr being mounted (if it is
> > separate from /) at time /sbin/init is launched.
> 
> Even on diskless workstations and thin clients using LTSP?  It is the
> use case I know about, but it is years since I tracked its status, so I
> do not know if it is still an issue there.

According to description of LTSP, it all depends on initramfs provided.
So, again, if you insist that / and /usr both remote and separate, you'd
have to slightly adjust your initramfs.

 1. Thin-clients boot via a protocol called PXE (Pre-eXecution Environment)
 2. PXE requests an IP address from a local DHCP server.
 3. The DHCP server passes additional parameters to the thin-client and downloads a Linux initramfs filesystem image
    via TFTP into a RAM disk on the client itself.
 4. The thin-client then boots the downloaded Linux initramfs image, detects hardware, and connects to the LTSP
    server's X session (normally handled by ldm).

> > Another issue is that definition of $remote_fs is *all* file systems are
> > mounted. And there is some scripts, which 'Default-Start: S', depending
> > on $remote_fs.  Seems to get this issue resolved, we need to get
> > following list of packages to get rid of dependency on $remote_fs or
> > move to (2 3 4 5) runlevels. Correct?
> 
> I can not confirm the list, but yes, every script in rcS.d/ depending on
> $remote_fs will have to move to (2 3 4 5).  Traditionally (as in
> Solaris/SysV systems) mounting /usr/ was done in rc[2345].d/, but this
> was for some strange reason never done in Debian.  I tried to move
> $remote_fs there, but ran out of steem before I managed to convince
> enough maintainers to do the switch.

Okay. I will initate discussion on debian-devel@ in preparation of mass
bug filling.