[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Get rid of /etc/mtab ?

Wichert Akkerman <wichert@wiggy.net> writes:

> Previously Goswin Brederlow wrote:
> > > * Not everymount mounts /proc
> > 
> > They don't have to use the link
> Then what's the point of this whole discussion?

To provide and support that option for people that don't want
/etc/mtab requiring / to be RW.
> > > * /proc is not mounted early in the boot sequence
> > 
> > Doesn't seem to hurt anything. Also one can provide a /proc/mtab file
> > on / for mount (and others) to fall back to until /proc is mounted.
> I doubt having /etc/mtab suddenly change in the middle of the both
> sequence when /proc is mounted is very helpful.

That already happens when / gets mounted RW the first time. Does it
not? At some time old obsolete entries must be removed from /etc/mtab,
especially after a crash. Also the /proc/mounts substitute file should
contain the same infos as /proc/mounts will after /proc is mounted.

> > > * not all mount options are listed in /proc/mounts
> > 
> > Which options are missing and where does that matter?
> See other posts. And it definitely matters (loopback devices aren't
> cleaned up for example)

Ok, got a few too look into. I knew about loopback as mentioned before
but bind and quota options are also stuff to look into then.
> > > * Using /proc/mounts in a chroot means leaking lots of information about
> > >   the host system into the chroot (the info is there anyway via /proc
> > >   but with different paths which don't exist in the chroot. Also chroots
> > >   don't always have /proc mounted but may very well mount other things)
> > 
> > Again, use /etc/mtab in a chroot.
> How would debootstrap know when to use a symlink and when not to?

I would suggest a debconf question in basefiles that decides about
/etc/mtab file or link. deboostrap would just take the default (the
old way, file) or presupply the debconf database with the right

I don't think adapting deboostrap would be a problem.


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: