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.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!