Bug#551555: mountnfs.sh: start should declare dependency on name resolver
Dmitry Bogatov
KAction at debian.org
Sun Jan 13 13:31:32 GMT 2019
[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.
More information about the Debian-init-diversity
mailing list