> Date: 18 May 1996 11:36:43 +0200
> From: Andreas Koppenhoefer
<koppenas@koppenas.dialup.informatik.uni-stuttgart.de>
> To: submit-linux-dev-kernel@ratatosk.yggdrasil.com,
> Dan Merillat <harik@ao.net>
> Cc: mjb@sophos.com, harik@ao.net
> Newsgroups: linux.dev.kernel
> Subject: Re: Cleaning up the config files in /etc (Re: As 2.0 looms) (fwd)
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> >>>>> "DM" == Dan Merillat <harik@ao.net> writes:
> In article <Pine.LNX.3.91.960506181639.20497G-100000@eola.ao.net> Dan Merillat <harik@ao.net> writes:
>
> DM>
> DM> On Thu, 2 May 1996, Matthew J Brown wrote:
> DM>
> >> /etc/mtab should not exist (save as a symlink to /proc/mounts).
> >> /proc/mounts should be updated so it contains all the information
> >> /etc/mtab contains.
> >>
> >> There should be no need for /etc/mtab, because it contains no info the
> >> kernel doesn't already have.
> DM>
> DM> Also very true.
> DM>
> >> /etc/mtab is also a special case because it *can't* move to /var.
> >> Why? because /var could be a seperate partition!
> DM>
> DM> Why not? What difference does that make? It _HAS_ to move, because it
> DM> is a changing file, and all changing files have to be out of /etc.
> DM> /var is the place for any file that will be modified at runtime. Logs,
> DM> PIDS, whatever. /, /etc/ and /usr/ are supposed to be able to be mounted
> DM> read-only. And, on my system, that's my goal. I want to get my system
>
> Mounting /usr read-only is good. But / and /etc is very unusual!
> Mounting / read-only is typically used for booting and running fsck,
> but gets usually remounted rw as soon as fsck finished. Typically /etc
> and / are on the same partition.
No. / and /etc is a GOOD thing. Unusual, yes, but good. The goal is
that I will have 3 read-write areas, /tmp, /home and /var. That way
NO_ONE can modify my setup. (I have /, and /usr on a drive that can be
hardwired read-only.) This is a security issue, 99% of linux users
shoudln't care about it. The only thing that really bugs me is that mtab
should be in /var/run. It is something generated at run-time, so that is
where it belongs. Only static config files belong in /etc (as per the
FSSTND) I'd also like /etc/ to be a hierarchy, but that's just me. (and
my current config, anyway)
Besides: NFS-root, if you use the same one for multiple systems, it could
get hairy if it is writable. (I know that is inefficient, and probably
non-nessisary now that drive prices are so low. But it is still
possible, and perhaps useful in some applications.)
> DM> up to the point where I can leave those mounted read-only and not have
> DM> any dire concequences.
> /etc/mtab is required to be in /etc, because usually mounting is done
> as follows:
>
> 1. mount -n -o remount,rw /
No, it isn't. That's where you got it wrong.
My order of operations is:
1) Root is mounted (kernel)
2) mount -n /var -o rw
3) mount -o remount /var
4) rm -f /var/run/* (to clean out old pid's, etc.)
4) mount -o remount / (still read-only)
then mount the rest of the system.
Of course, this only worked once mtab and the locks were in /var/run.
> umount needs information about which fs is mounted how and where. It
> must read these info from some file like /etc/mtab or /proc/... But
> maybe /proc is not mounted! Therefore umount must check for existence of
Perhaps var is not mounted! But what then? Well, /var is marked noauto,
so I have to explicitly mount/unmount it. And, hidden neatly under /var
is a copy of the mtab forged to show that / is the only FS mounted!
So, all I have to do upon shutdown is:
umount -a
umount /var
and flip the machine off.
> IMHO the only way to solve this problem is adding some system call to
> query information about mounted filesystems and use these instead of
> /etc/mtab or /proc/mounts. This may work like libc's
> opendir()/readdir()/closedir().
Much better then depending on /proc. It would be a VERY nice system call
to have. Perhaps returning a linked-list of a mtab structure? (one for
each mounted FS)
I'd mess with that if I had the need right now. Just moving mtab to var
has solved a lot of problems.
--Dan