When mounting NFS volumes, the ‘mountnfs.sh’ script needs the name
resolver to be started in order to resolve the NFS server's name. The
init script should have a ‘Required-Start’ field declaring a
dependency on the name resolver service.

[Ben Finney]

I agree.  Which name resolver service did you have in mind.

Unfortunately $named can not be listed as a dependency for
mountnfs.sh, as it would generate a dependency loop.  First of all,
all known implementations of $named start in rc2.d, while mountnfs.sh
need to happen in rcS.d/ if /usr/ is an NFS volume.  Second,
mountnfs.sh is part of $remote_fs, which all known implementations of
$named depend on.  For this to work the mountnfs.sh script need to be
split into one part executed from rcS.d/ taking care of mounting /usr/
(and perhaps other core file ystems), and another part executed from
rcS.d/ taking care of the rest, and several scripts in unrelated
packages need to move their scripts from rcS.d/ to rc2.d - rc5.d.  Not
an easy task.

Happy hacking,

In my case ‘bind9’, but any name resolver would (I guess) meet the
requirement.

I guess this bug report can be the focus of fixing that, then.

Anything happening on this bug?

I note that wheezy still has it, and i have to manually mount my nfs
after a reboot.

cheers,


Rudy

Not that I'm aware of.

There are other NFS issues outstanding as well, which could really use
the attention of an NFS expert.

NFS mounting a separate /usr is IMO not something we should support,
given that it makes no sense (just mount the rootfs on NFS directly).
If we were to relax this existing constraint, would that make the
dependencies any easier to fix?


Regards,
Roger

control: tags -1 +moreinfo

[2009-10-19 08:02] Petter Reinholdtsen <pere@hungry.com>

Correct me if I am wrong, but on modern installations /usr is mounted by
initramfs (note usrmerge initiative), so I believe we could move
mountnfs.sh from S to (2 3 4 5) (with some modifications to not try
mount multiple times).

Objections?

[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.

Also, I do not believe any initrd will NFS mount /usr/, so the use case
described do not really match your description.  When /usr/ is NFS
mounted (for example because of size constraints), it is not possible to
merge / and /usr/.

[2019-01-08 16:32] Petter Reinholdtsen <pere@hungry.com>

As far as I can tell, we can assume /usr being mounted (if it is
separate from /) at time /sbin/init is launched.

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?

	alsa-utils
	arno-iptables-firewall
	auto6to4
	dpdk
	eeepc-acpi-scripts
	espeakup
	fcoe-utils
	ferm
	initscripts
	ipsec-tools
	lm-sensors
	netfilter-persistent
	oss4-base
	pidentd
	policycoreutils
	prads
	pyroman
	quota
	racoon
	screen
	setserial
	shorewall
	shorewall-init
	shorewall-lite
	shorewall6
	shorewall6-lite
	switchconf
	x11-common
	zfs-fuse
	zvbi

It results in 25 maintainers affected. Sounds like MBF.

True. initramfs knows only two modes of operation -- either remote root
(nfs mode) or local root (local mode). It does not know, what to do, if
root is local and /usr is remote. Given upcoming `usrmerge', I do not
consider this limitation serious.

But if for some reason you prefer to have local root and remote /usr,
you could do this -- just modify your initramfs. I just conjured
following kludge for specific case of two virtual machines, 10.0.0.2 as
nfs-server and 10.0.0.3 as local-root,remote-usr:

	ip link set up dev ens3
	ip addr add 10.0.0.3/16 dev ens3
	nfsmount 10.0.0.2:/usr /root/usr

	^^^^^^^^ This snippet is to be inserted into mountroot()
	function in /usr/share/initramfs-tools/scripts/local.

Probably, proper hook could be written and installed.

[Dmitry Bogatov]

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.

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.

[2019-01-11 20:35] Petter Reinholdtsen <pere@hungry.com>

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).

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

Control: severity -1 wishlist

I know there was some discussion about refactoring the initscripts to achieve
this. However, catering for all varieties of remote fs mount is already
difficult and I propose to downgrade this to wishlist.  Using the IP address in
/etc/fstab is probably better IMHO.

Mark