[ILUG] Curious issue with NFS mounts in dapper

[Niall O Broin]

On 6 Oct 2006, at 00:10, FRLinux wrote:

> On 10/5/06, Niall O Broin <niall at magicgoeshere.com> wrote:
>> I have a box with kubuntu dapper installed which has a strange
>> problem with NFS mounts. The problem is that the mounts don't show up
>> in df output, or in /etc/mtab (the former follows from the latter, as
>> df walks /etc/mtab). It's as if the NFS mounts are done with mount -n
>> but they're not - at least, not deliberately.
>
> Far from me trying to judge your setup, but i am rather curious as of
> which options are you using on the NFS server and also what flavour is
> the NFS server ? (kernel version might also help here)

The NFS server(s) are various Linux and Sun and the problem occurs  
with them all, so it's not a server side issue. As I said, it looks  
like the NFS mounts at startup are being done with mount -n. I have  
three dapper desktops here, and one works as I'd expect, the other  
two do not (although in fairness they only count as one, really, as  
one is a clone of the other).

OK - since i wrote the above paragraph, I now believe I have a handle  
on what's happening. Everything I read indicated that NFS mounts in  
ubuntu are done by the script /etc/network/if-up.d/mountnfs which is  
run when an interface is brought up, supposedly. I say supposedly  
because using ls -lu on that file after a boot showed that the file  
had NOT been read.

So, I moved that file out of the way, rebooted, and bingo - no NFS  
mounts, so the NFS mounts are definitely being done by that script -  
yet the atime doesn't show that. And then the lightbulb went on :-)   
The available evidence is:

1) /etc/mtab not being written
2) atime of a file not being updated when the file is accessed

so where do we look for the guilty party?

Yes, you guessed it - a non writable root filesystem. What seems to  
be happening is that when the NFS mounts are done, the root  
filesystem is mounted ro.

When a Linux box boots, generally speaking, the root filesystem is  
first mounted ro, so that various start scripts can be run, including  
one which does a filesystem check on the root filesystem (which isn't  
possible if the root filesystem is mounted rw). At some stage during  
the boot process, the root filesystem is remounted read write. On  
ubuntu (it's a standard Debian-ism) this is done by the script /etc/ 
init.d/checkroot.sh .  This script is obviously doing its thing  
because when the box has booted, the root filesystem is writable, but  
it appears that it's not while the nfs mounts are being done.

Now, it seems that I have identified the source of the problem, but  
not the reason for it. The affected boxes are not using the default  
ubuntu choice of ext3 for their root filesystems, but rather JFS  
(why? - because I'm using JFS for years and it has never given me a  
bit of bother. In fairness, nor has ext2/3 given me much bother, but  
JFS was a solid journalling solution on Linux before ext3 - so call  
it old habits dying hard). I just installed another instance and this  
time I used ext3 for the root filesystem, and the problem does NOT  
occur. But what on earth is going on here? Oh - answers along the  
lines of "Use ext3 for the root filesystem" are not helpful. I  
already know that this avoids the problem. I'm now curious about what  
causes the problem, and how to solve it.


Niall