Being the clever-clogs that I am, I have managed to clobber the contents of /etc/mnttab.
It started when I tried to unmount all the volumes in a prticular veritas disk group and neglected to include a suitable grep in my command line, thus attempting to unmount _all_ the filesystems on the server (for loop).
They all came back with a fs busy message so I was presuming no harm done. However, a df to check all was in order came back with no results, likewise running mount.
When I went to look in the mnttab itself I find it's zero length !?!
Everything appears ok in that the filesystems are still actually mounted and read/write.
If I try a mount or umount I get the message
"mount: Inappropriate ioctl for device"
I suspect a reboot would sort me out but that's a big hammer and I'd rather get to the bottom of it.
What have I done and how in the world do I fix it?
Running solaris 10 on a T2000, fairly recent patches applied. Bugger all running aside from base OS and SAN kit.
The umount failed (no surprise, the first thing it does is looks at the mnttab) but the mount worked perfectly - I now have a fully populated mnttab again.
That one's a completly new idea to me - I'd never heard of the mntfs filesystem type before (or the bizaare idea of having the mnttab as a virtual filesystem). Solaris is a strange animal for sure.
I'd be keen to hear anyone's theory as to how I broke it in the first place though... :o
Yeah I had that as my backup plan but I had a little time as it was still working (sort of) so I figured I'd try and find a cleaner fix
Interesting that the system call didn't update the mnttab in the old days, I could see that creating a bit of a potential mess. I've done very little work with sol7, went straight from 2.6 to 8 with the memorable exception of trying to run some NIS+ servers on 7 (shudder).
Since posting the above I've found another side-effect of using this solution - it appears that if you have a filesystem not mounted that is in the vfstab, the above command will tell the mnttab that it is mounted - resulting in confusion.
I fixed it but "unmounting" all of these volumes then mounting them for real.
Solaris has a lot of screwy pseudo filesystems these days. Used to be we would write pseudo device drivers to sneek code into the kernel. I'm disappointed with the Solaris mntfs, it's not as robust as I would have hoped. There always was a problem with /etc/mnttab. The system calls never updated it, instead they update tables in the kernel. This is one of several reasons why a user was supposed to always use the mount command and not just the sytem call. After a reboot, /etc/mnttab would often have garbage entries. The setmnt command was used to initialize it. I had hoped the the mntfs stuff would, in effect, make the kernel tables and /etc/mnttab different views of the same thing, but it seems this is not the case. It seems to be just a special purpose memory based filesystem. I guess it will self-reset at reboot. And you can update /etc/mnttab while / is mounted read-only. Maybe it has some some code to keep all of the other screwball filesystems invisible. But I'm disappointed that it can get out of sync with what is really mounted.
As for your problem, my best guess is that you umounted /etc/mnttab, an operation which ideally would have been disallowed. But I guess it has to be allowed to fix /etc/mnttab when it breaks.
I think you've got it, it's in the output from df so my poorly filtered script would have grabbed it and issued a 'umount /etc/mnttab'. Will add that little gem to my bag of tricks
- I'd never heard of the mntfs filesystem type before (or the bizaare idea of having the mnttab as a virtual filesystem). Solaris is a strange animal for sure.
