Roger Leigh wrote: > This is an area which could use quite a bit of work. Unfortunately, > as you point out there isn't a single place to fix things--it > touches a whole host of packages, from the initramfs to the > initscripts, to udev and networking. It does touch many things. The configuration is varied. But just to clarify and simplify a little, there isn't anything that needs to be done for the initramfs or udev. The stock everything there is okay. I did make modifications to the init process. (It is so very nice that they are simple scripts so that I could understand them and modify them as needed. /me looks around the room shyly.) > Some things which need addressing: > - use of tmpfses for non-writable locations like /media: we should > be doing this by default; introducing /run/media on the /run > tmpfs was one thing looked at for wheezy; but it didn't get done > for reasons I can't recall offhand. Something to revisit for > jessie. This not just specific to nfsroot, r/o root also needs it. I am not sure it is good to always include that as a ram file system. I have often and I am sure others have too made custom directories there and custom entries in /etc/fstab. Of course on a diskless thin client these things either need to be avoided or codified in a system script but it definitely is an area where one size does not fit everyone. > - ASYNCMOUNTNFS in /etc/default/rcS (see rcS(5)). The fact this > option exists indicates a problem. The basic NFS mounting at > boot should Just Work in all situations, without gross hacks > like this. Apparently I have successfully avoided needing to know about that setting. This is my first encounter with it. I have no idea what that does and will need to research it. Usually when an nfs mount is listed in /etc/fstab it is because the function of the machine is impossible without it. Such as an nfs mounted $HOME directory. If the machine boots and presents a login screen but does not have a home directory available for the user to log in then it is useless to the user. Therefore even if it must wait synchronously for the event to finish that is okay. People don't use nfs diskles machines expecting speed daemon performance. Of course there are other lazy mounting strategies such as autofs and amd but those are not configured through hard mounts in /etc/fstab. > - There are currently two places where NFS filesystem mounting > can be triggered: /etc/network/if-up.d/mountnfs (triggered by > ipup/udev) and /etc/init.d/mountnfs.sh. There should ideally > be just a single script, which should cater for all cases; the > other script can just run the other. The transition from configure at boot time to configure when the interface comes online is also a problem for devices that are configured before system boot time and therefore escape both systems. Pehraps both of the above should call a 3rd independent common script that could also be called in this last case too. > - NetworkManager from what I've observed from other bugs reports > is hopelessly broken with NFS mounting at boot. I haven't researched it the combination. > While I've looked at this peripherally as an initscripts maintainer, > and sponsor for ifupdown, I don't personally have the NFS expertise > to fully understand all of the disparate and incompatible use cases > to be able to engineer a proper solution. We've fixed a few specific > individual issues, but not really tackled the big problem. > > Help understanding what the problems are and how best to address them > would be very much appreciated if anyone wishes to help here. We > really need someone intimately familiar with NFS, and how the boot > scripts work, or who could take the time to become familiar with them. I think that at the start this is a configuration issue. And as such it is a knowledge and documentation issue. Quite a few of us have knowledge of various parts in detail but it isn't all in one place. At least not that I know about. Therefore I think the place to start would be to try to document the recipe fully. Along the way we would have gathered all of the details into one place. Along the way of building the documentation we would discover the corner cases that make that hard and can enumerate them. Let's also not forget about the LTSP and others that have tackled these issues already. I will just trail off there and let things hang at this point. Certainly I would be willing to help in this effort and would actively like to be involved if something started happening with it. Bob
Attachment:
signature.asc
Description: Digital signature