Ross Boylan wrote: > Bob Proulx wrote: > > This nfs startup part is a part that seems to have suffered from the > > transition from boot time scripts to event driven scripts. This kind > > of thing use to work in the previous init script way. I don't know > > the best design to make this work in the general case for the new > > event driven way. But at least in my testing it was sufficient to add > > this mount line to /etc/rc.local in order to mount additional nfs > > mount points at boot time. > > Do you think this is something that merits a bug/wish report? Against > what package? That is the problem. There isn't really a package associated with nfs diskless clients. It isn't a "thing" as a "configuration". And so I don't know if there is a single canonical owner for it. It would need some discussion to determine the best place for this. Perhaps others will have more insight into this topic. The topic comes up for discussion periodically. Usually we tinker with things until we scratch our particular itch and then the topic is forgotten until the next time it comes up. There are so very few people using nfs diskless. > > File /etc/rc.local: > > mount -a -t nfs > > Thanks; I can never remember where the "do this after startup" stuff > goes. I did this and it worked. And if you switch over to the "auto" and "manual" settings then this isn't needed anymore. :-) > I tried Michael's suggestion to use _netdev, before changing rc.local, > but it didn't help. The man says its for things that have to happen > after network access is available. What that actually does is in the /e/n/if-up.d/mountnfs script it mounts nfs types first and then mounts _netdev types second. So that it can apply the layers in the right specially specified order. But since the problem was that /e/n/if-up.d/mountnfs isn't called unless the interface is brought up then it isn't called to mount _netdev devices either. > On the one hand, network access is always available in a diskless > setup; on the other hand, the regular startup sequence never gets an > indication that the network has come up, which I guess means neither > _netdev not nfs mounts fire. Yes, exactly. > > In my setup when I added that then everything seemed to work just > > fine. Because nfsdiskless isn't one of the really standard > > configurations, you need to set it up manually, I think that is > > probably a good enough solution for the moment. Give it a go. > > Definitely. It was really annoying have to do the mount manually every > time, and if my daughter starts the machine she can't do it, and so > can't use myth. Yep. > Why I need the nfs mount for myth I don't know; the system is a client, > getting recordings from the server (the same machine serving NFS). So > it seems to me it should only matter if the myth server can see the > files. But it doesn's work that way. I am not familiar with MythTV at all and so can only speculate from the reported behavior that it must be wanting something down that directory path. :-) > Thanks also to Roger for his suggestions about tempfs; I'm going to look > into them. I got them from something I copied from the net, and so they > may well be inappropriate for the latest Debian. Initially I create nfs clients using debootstrap. By default the /etc/fstab will be empty. So instead of starting with a running system and trying to push it into an nfs client I started with a very small empty system and grew it into what I needed. So for you I recommend removing all of the core system mount points (including the tmpfs items that Roger recommended) and starting off empty too. However if you want /media/* mount points then of course you would want those to be available. But probably not: > none /media tmpfs defaults 0 0 But rather something like the new default entries like these. This is from my systems: proc /proc proc defaults 0 0 /dev/cdrom /media/cdrom0 udf,iso9660 user,noauto 0 0 And I also have /tmp, /var/tmp, /var/log, and /media, on tmpfs partitions for the nfs diskless clients. And by not showing my entries for those I avoid needing to list their correction mount options. I will leave that for Roger. :-) Bob
Attachment:
signature.asc
Description: Digital signature