[ale] /etc/mtab

[David Tomaschik]

Oddly enough, /proc/mounts doesn't retain all the information that mtab
does.  For example, the kernel is oblivious to certain mount options
that are only used by the mount.* program (e.g., credentials for CIFS). 
I'm not sure how much of this still applies, but there's an extensive
LKML thread[1] that documents this and the reasons for NOT making it a
symlink to /proc/mounts.

David
[1] http://lkml.org/lkml/2003/2/19/43


On 05/05/2010 06:47 PM, Michael Trausch wrote:
>
> Yes, I actually wonder myself why the file exists at all. Seems silly
> on Linux systems; I would think that it should just be a symlink to
> /proc/mounts in any case, because it is really the kernel's job to
> track mounts and show state.
>
> It has always bugged me that its there. It bugs me even more than on a
> system that only boots ro, with init=/bin/bash, it reads /etc/mtab
> which is almost always inaccurate at that point.
>
> --
> Sent from my ADP1 running Android 2.1
>
>> On May 5, 2010 4:10 PM, "Jim Kinney" <jim.kinney at gmail.com
>> <mailto:jim.kinney at gmail.com>> wrote:
>>
>> If /var is not mounted, LOTS of stuff is not working so I'm in
>> runlevel 1 at that point :-)
>>
>> I'd even settle for a spot in /tmp.
>>
>> But not /etc. mtab is not used to configure anything. It is the
>> report of a state. So the /proc/mounts (linked to /proc/self/mounts)
>> is the only place it should exist from my thinking.
>>
>> Must be an _old_ carry over from way before /proc days.
>>
>>
>>
>> On Wed, May 5, 2010 at 3:46 PM, Dennis Ruzeski <denniruz at gmail.com
>> <mailto:denniruz at gmail.com>> wrote:
>> >
>> > So if /var was unmo...
>>
>> -- 
>> -- 
>>
>> James P. Kinney III
>> Actively in pursuit of Life, Liberty and Happiness
>> Doing pretty well on all 3 p...
>>
>>

-- 
David Tomaschik, RHCE
Moderator, LinuxQuestions.org
http://www.tuxteam.com
david at tuxteam.com [GPG: 0x6D428695]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100505/cfd3f1d0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20100505/cfd3f1d0/attachment.bin