Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Philipp Matthias Hahn <pmhahn@debian.org> writes:

> Hi!
>
> On Sat, Aug 12, 2006 at 09:34:52PM +0200, Goswin von Brederlow wrote:
>> Peter Samuelson <peter@p12n.org> writes:
>> 
>> > [Goswin von Brederlow]
>> >> Instead move the things in etc that need writing to other places:
>> >> 
>> >> 1) link /etc/mtab to /proc/mounts and create a dummy /proc/mounts on /
>> >>    for when /proc isn't mounted (works with quota in current kernels).
>> >
>> > Does the wrong thing with (a) user and (b) loop mounts.  [I just tested
>> > 2.6.16-1-k7.]  /etc/mtab needs to keep enough state for umount to know
>> > (a) who mounted something, so the same user can unmount it, and (b)
>> > that a loop device was set up automatically via 'mount -o loop', rather
>> > than done separately, so that umount can 'losetup -d /dev/loopN'.  This
>> > is information which cannot, at present, be put in /proc/mounts.
>> 
>> Yes. If you need that feature help patching the kernel (like the new
>> quota support in /proc/mounts) or link it to somewhere else.
>
> Which doesn't work because of linux-utils-2.12r/mount/fstab.c:55
> int
> mtab_is_writable() {
> 	static int ret = -1;
>
> 	/* Should we write to /etc/mtab upon an update?
> 	   Probably not if it is a symlink to /proc/mounts, since that
> 	   would create a file /proc/mounts in case the proc filesystem
> 	   is not mounted. */
> 	if (mtab_is_a_symlink())
> 		return 0;
> ...
>
> The path to mtab is also hardcoded in
> /usr/include/paths.h:54:#define _PATH_MOUNTED   "/etc/mtab"
> which is no fun to change "on-the-fly".
>
> BYtE
> Philipp

A patch for this was in the BTS that would follow the symlink but not
fail if the destination is unwritable (the /proc/mounts case).

I can't believe that is still not fixed or got lost again.

MfG
        Goswin