Bug#551555: mountnfs.sh: start should declare dependency on name resolver
[2019-01-11 20:35] Petter Reinholdtsen > [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.
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
[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. > 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. -- Happy hacking Petter Reinholdtsen
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
[2019-01-08 16:32] Petter Reinholdtsen > [Dmitry Bogatov] > >> 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. > > > > 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? > > 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. 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. > 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/. 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.
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
[Dmitry Bogatov] >> 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. > > 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? 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/. -- Happy hacking Petter Reinholdtsen
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
control: tags -1 +moreinfo [2009-10-19 08:02] Petter Reinholdtsen > [Ben Finney] > > 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. > > 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. 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?
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
On Sun, Jul 01, 2012 at 02:22:49AM +0200, Rudy Zijlstra wrote: Anything happening on this bug? 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 -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
[Ben Finney] 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. 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, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
On 19-Oct-2009, Petter Reinholdtsen wrote: [Ben Finney] The init script should have a ???Required-Start??? field declaring a dependency on the name resolver service. I agree. Which name resolver service did you have in mind. In my case ‘bind9’, but any name resolver would (I guess) meet the requirement. 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. I guess this bug report can be the focus of fixing that, then. -- \ “Our task must be to free ourselves from our prison by widening | `\our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
Package: initscripts Version: 2.87dsf-6 Severity: normal 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. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (900, 'stable') Architecture: powerpc (ppc64) Kernel: Linux 2.6.30-2-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initscripts depends on: ii coreutils 7.4-2 The GNU core utilities ii debianutils 3.2.1 Miscellaneous utilities specific t ii libc6 2.9-25 GNU C Library: Shared libraries ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip ii mount 2.16.1-4 Tools for mounting and manipulatin ii sysv-rc 2.87dsf-6 System-V-like runlevel change mech ii sysvinit-utils2.87dsf-6 System-V-like utilities Versions of packages initscripts recommends: ii e2fsprogs 1.41.9-1 ext2/ext3/ext4 file system utiliti ii psmisc22.8-1 utilities that use the proc file s initscripts suggests no packages. -- no debconf information -- \“Technology is neither good nor bad; nor is it neutral.” | `\ —Melvin Kranzberg's First Law of Technology | _o__) | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
