[gentoo-dev] rfc: converting /etc/mtab to a symlink

[gentoo-dev] rfc: converting /etc/mtab to a symlink

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

All,

from what I'm seeing, we should look into converting /etc/mtab to a
symlink to /proc/self/mounts [1].

Are there any remaining concerns about doing this?

If not, it seems like it would be pretty easy to make baselayout create
this symlink in the stages (I'm willing to do this work), but what about
on systems that are already installed? Should we send out a news item
and have everyone convert their /etc/mtab manually or find a way to
automate that?

William

[1] http://bugs.gentoo.org/show_bug.cgi?id=477498

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Matt Turner]

On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <williamh@gentoo.org> wrote:
> All,
>
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?
>
> William
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498

Is the issue with NFS user mounts resolved? (Mentioned
https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Mike Gilbert]

On Sun, Oct 13, 2013 at 5:13 PM, Matt Turner <mattst88@gentoo.org> wrote:
> On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <williamh@gentoo.org> wrote:
>> All,
>>
>> from what I'm seeing, we should look into converting /etc/mtab to a
>> symlink to /proc/self/mounts [1].
>>
>> Are there any remaining concerns about doing this?
>>
>> If not, it seems like it would be pretty easy to make baselayout create
>> this symlink in the stages (I'm willing to do this work), but what about
>> on systems that are already installed? Should we send out a news item
>> and have everyone convert their /etc/mtab manually or find a way to
>> automate that?
>>
>> William
>>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498
>
> Is the issue with NFS user mounts resolved? (Mentioned
> https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)
>

Could someone using NFS actually test and see if there are any
problems? That comment on the wiki has no details, and Google has not
been very helpful in finding an answer.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Peter Volkov]

В Вс, 13/10/2013 в 14:13 -0700, Matt Turner пишет:
> On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <williamh@gentoo.org> wrote:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].

> Is the issue with NFS user mounts resolved? (Mentioned
> https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)

Looks like Gentoo's nfs-utils package does not support this. nfs-utils
have --enable-libmount-mount so we just need to start using it.
https://bugs.gentoo.org/show_bug.cgi?id=487962

BTW, most distributions did all this changes two years ago, so all
packages have support for mtab. For exampled, I've checked two packages
that had this problem two years ago and one package unconditionally
depends on libmount (pam_mount) while another just avoids touch mtab if
it's not writable and works anyway (cifs-utils). Both packages with
required changes are in Gentoo's stable tree :)

--
Peter.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Pacho Ramos]

El lun, 14-10-2013 a las 09:58 +0400, Peter Volkov escribió:
> В Вс, 13/10/2013 в 14:13 -0700, Matt Turner пишет:
> > On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <williamh@gentoo.org> wrote:
> > > from what I'm seeing, we should look into converting /etc/mtab to a
> > > symlink to /proc/self/mounts [1].
> 
> > Is the issue with NFS user mounts resolved? (Mentioned
> > https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)
> 
> Looks like Gentoo's nfs-utils package does not support this. nfs-utils
> have --enable-libmount-mount so we just need to start using it.
> https://bugs.gentoo.org/show_bug.cgi?id=487962
> 
> BTW, most distributions did all this changes two years ago, so all
> packages have support for mtab. For exampled, I've checked two packages
> that had this problem two years ago and one package unconditionally
> depends on libmount (pam_mount) while another just avoids touch mtab if
> it's not writable and works anyway (cifs-utils). Both packages with
> required changes are in Gentoo's stable tree :)
> 
> --
> Peter.
> 
> 
> 

Thanks for finding the problem with NFS :)

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Patrick Lauer]

On 10/14/2013 03:32 AM, William Hubbs wrote:
> All,
> 
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
> 
> Are there any remaining concerns about doing this?

Apart from breaking umount -a and some other things?
None at all ;)

(The breakage is visible e.g. with umount -a tmpfs, which used to be
quite useful if you had a few chroots with /var/tmp/portage as tmpfs and
wanted to reset them. Now it'll also punt random things like /run if
you're lucky - and in the past it knocked out the OpenRC state directory
reliably)

There are pretty good historical reasons for having /etc/mtab as a file,
maybe you should do some archeology before just trying to change things.

Applications that can't handle a properly set up Linux system should be
patched to either use /proc/mounts unconditionally or randomly segfault
to emulate proper Windows best practises.

> 
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?

... you automate that, you get a few angry bugs.
Better to warn, if you absolutely have to, and let users consciously
remove features when they are ready for it.

Thanks,

Patrick

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Mike Gilbert]

On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 10/14/2013 03:32 AM, William Hubbs wrote:
>> All,
>>
>> from what I'm seeing, we should look into converting /etc/mtab to a
>> symlink to /proc/self/mounts [1].
>>
>> Are there any remaining concerns about doing this?
>
> Apart from breaking umount -a and some other things?
> None at all ;)
>
> (The breakage is visible e.g. with umount -a tmpfs, which used to be
> quite useful if you had a few chroots with /var/tmp/portage as tmpfs and
> wanted to reset them. Now it'll also punt random things like /run if
> you're lucky - and in the past it knocked out the OpenRC state directory
> reliably)
>

I don't follow this: it seems like umount -a is supposed to unmount
all filesystems. umount -a -t tmpfs would unmount all tmpfs
filesystems. /run should be included in that set, even if mtab is a
regular file.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Patrick Lauer]

On 10/14/2013 07:29 AM, Mike Gilbert wrote:
> On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>> On 10/14/2013 03:32 AM, William Hubbs wrote:
>>> All,
>>>
>>> from what I'm seeing, we should look into converting /etc/mtab to a
>>> symlink to /proc/self/mounts [1].
>>>
>>> Are there any remaining concerns about doing this?
>>
>> Apart from breaking umount -a and some other things?
>> None at all ;)
>>
>> (The breakage is visible e.g. with umount -a tmpfs, which used to be
>> quite useful if you had a few chroots with /var/tmp/portage as tmpfs and
>> wanted to reset them. Now it'll also punt random things like /run if
>> you're lucky - and in the past it knocked out the OpenRC state directory
>> reliably)
>>
> 
> I don't follow this: it seems like umount -a is supposed to unmount
> all filesystems. umount -a -t tmpfs would unmount all tmpfs
> filesystems. /run should be included in that set, even if mtab is a
> regular file.
> 

And the magic trick is to keep "system mounts" like /run out of
/etc/mtab (willful desynchronization) so that umount -a doesn't nuke
them by accident.

... why else would you keep such data in two non-synchronized locations?! :D

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Rich Freeman]

On Sun, Oct 13, 2013 at 7:38 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> And the magic trick is to keep "system mounts" like /run out of
> /etc/mtab (willful desynchronization) so that umount -a doesn't nuke
> them by accident.
>
> ... why else would you keep such data in two non-synchronized locations?! :D
>

Sounds interesting and all, but I don't think this really should be
driving our system design (the desire to have a command that is
supposed to unmount everything not actually unmount everything).  It
wouldn't take more than a few lines of bash to just write a script to
unmount the stuff you're interested in - I routinely toss in my
chroots a script to mount/unmount stuff (tmpfs, bind-mounts, proc/sys,
etc).

There could very well be other issues with changing mtab to a symlink
though, so continue to speak up if there are other things that could
go wrong.

Rich

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Mike Gilbert]

On Sun, Oct 13, 2013 at 7:38 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 10/14/2013 07:29 AM, Mike Gilbert wrote:
>> On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>>> On 10/14/2013 03:32 AM, William Hubbs wrote:
>>>> All,
>>>>
>>>> from what I'm seeing, we should look into converting /etc/mtab to a
>>>> symlink to /proc/self/mounts [1].
>>>>
>>>> Are there any remaining concerns about doing this?
>>>
>>> Apart from breaking umount -a and some other things?
>>> None at all ;)
>>>
>>> (The breakage is visible e.g. with umount -a tmpfs, which used to be
>>> quite useful if you had a few chroots with /var/tmp/portage as tmpfs and
>>> wanted to reset them. Now it'll also punt random things like /run if
>>> you're lucky - and in the past it knocked out the OpenRC state directory
>>> reliably)
>>>
>>
>> I don't follow this: it seems like umount -a is supposed to unmount
>> all filesystems. umount -a -t tmpfs would unmount all tmpfs
>> filesystems. /run should be included in that set, even if mtab is a
>> regular file.
>>
>
> And the magic trick is to keep "system mounts" like /run out of
> /etc/mtab (willful desynchronization) so that umount -a doesn't nuke
> them by accident.
>
> ... why else would you keep such data in two non-synchronized locations?! :D
>

That's certainly a neat trick. However, it seems a bit weird to use a
system-wide database for such a use case; what if multiple users are
setting up mounts like this?

I guess the key takeaway from this is that people do unconventional
things. Probably best to just change the default, and throw up a big
warning for existing users as you indicated in your original reply.

[gentoo-dev] Re: rfc: converting /etc/mtab to a symlink

[Steven J. Long]

On Mon, Oct 14, 2013 at 07:38:19AM +0800, Patrick Lauer wrote:
> On 10/14/2013 07:29 AM, Mike Gilbert wrote:
> > On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> >> On 10/14/2013 03:32 AM, William Hubbs wrote:
> >>> All,
> >>>
> >>> from what I'm seeing, we should look into converting /etc/mtab to a
> >>> symlink to /proc/self/mounts.
> >>>
> >>> Are there any remaining concerns about doing this?
> >>
> >> Apart from breaking umount -a and some other things?

What "other things"? AFAICT from the debian bug report[1] problems are far
much more likely when it's not a symlink, unless you're on kernel <2.6.26
(which is admittedly more likely for a Gentoo user, but it would not be the
mainstream Gentoo user, by any stretch of the imagination.)

> >> (The breakage is visible e.g. with umount -a tmpfs, which used to be
> >> quite useful if you had a few chroots with /var/tmp/portage as tmpfs and
> >> wanted to reset them. Now it'll also punt random things like /run if
> >> you're lucky - and in the past it knocked out the OpenRC state directory
> >> reliably)
> >>
> > 
> > I don't follow this: it seems like umount -a is supposed to unmount
> > all filesystems. umount -a -t tmpfs would unmount all tmpfs
> > filesystems. /run should be included in that set, even if mtab is a
> > regular file.
> > 
> 
> And the magic trick is to keep "system mounts" like /run out of
> /etc/mtab (willful desynchronization) so that umount -a doesn't nuke
> them by accident.
> 
> ... why else would you keep such data in two non-synchronized locations?! :D
> 

You wouldn't: the only reason I've clung to the idea of a file, are the
transitional problems mentioned in the debian bug, ie information not available
in /proc/mounts that is available in /etc/mtab. Clearly that was fixed 2 years
ago, including for NFS and smb.

Given the CLONE_NEWNS issue (which one might use in the situation you describe):
"At this point, /etc/mtab *must* be a symlink to avoid breakage.  Note that
/proc/mounts is now a symlink to /proc/self/mounts for this reason: each process
has potentially different mounts"; going forward it really does not seem like a
good idea not to default to the symlink.

I agree it should not be forced on existing installs, nor on an admin who wants
to do something funky (or is using an ancient kernel for some reason.) However
I would definitely support a news item about the default change, along with
a recommendation for existing installs also to change, unless the admin has
a reason not to.

Just as a heads-up, that the ground has changed, and the vast majority really
do not want to be running without that symlink.

And yeah, script that properly (or a new namespace if it works) you lazy git ;p

Regards,
steveL.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494001

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Mon, Oct 14, 2013 at 07:21:47AM +0800, Patrick Lauer wrote:
> On 10/14/2013 03:32 AM, William Hubbs wrote:
> > All,
> > 
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].
> > 
> > Are there any remaining concerns about doing this?
> 
> Apart from breaking umount -a and some other things?
> None at all ;)
> 
> (The breakage is visible e.g. with umount -a tmpfs, which used to be
> quite useful if you had a few chroots with /var/tmp/portage as tmpfs and
> wanted to reset them. Now it'll also punt random things like /run if
> you're lucky - and in the past it knocked out the OpenRC state directory
> reliably)
> 
> There are pretty good historical reasons for having /etc/mtab as a file,
> maybe you should do some archeology before just trying to change things.

and maybe you should think before you accuse. Coming to this list *is*
doing that archaeology. If I were going to change things without doing
that archaeology, I would just make the change happen without warning.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[yac]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

AFAIK this known historical behavior that what you find in
`/etc/mtab` are things mounted by mount(8) (if that's what's printed by
running just mount).

Whereas /proc/mounts is the kernel view on what's mounted.

Curiously I don't see any difference on my gentoo box, which I think I
should see but I'm not sure.

Anyway, I've seen differences when eg. automounter was used, iirc.
I wouldn't be surprised if there are things that depends on this
behavior or if there are more cases like automounter.

On Sun, 13 Oct 2013 14:32:32 -0500
William Hubbs <williamh@gentoo.org> wrote:

> All,
> 
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
> 
> Are there any remaining concerns about doing this?
> 
> If not, it seems like it would be pretty easy to make baselayout
> create this symlink in the stages (I'm willing to do this work), but
> what about on systems that are already installed? Should we send out
> a news item and have everyone convert their /etc/mtab manually or
> find a way to automate that?
> 
> William
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Rich Freeman]

On Mon, Oct 14, 2013 at 12:42 AM, yac <yac@gentoo.org> wrote:
>
> Curiously I don't see any difference on my gentoo box, which I think I
> should see but I'm not sure.

On mine the main difference seems to be bind mounts.  In /etc/mtab the
bind mount "device" is the directory that is being bind-mounted.  In
/proc/self/mounts it is the device that the directory sits on.  Other
than a little confusion, I"m not sure if that will actually cause any
issues.

Rich

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Peter Volkov]

В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
> 
> Are there any remaining concerns about doing this?

The only concern I have how this change affects *BSD or prefix? But yet
I failed to find a package that is affected and that is not Linux
specific.

--
Peter.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On 14-10-2013 10:00:03 +0400, Peter Volkov wrote:
> В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].
> > 
> > Are there any remaining concerns about doing this?
> 
> The only concern I have how this change affects *BSD or prefix? But yet
> I failed to find a package that is affected and that is not Linux
> specific.

If it works for the host system, then Prefix should be fine.

Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Mon, Oct 14, 2013 at 10:00:03AM +0400, Peter Volkov wrote:
> В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].
> > 
> > Are there any remaining concerns about doing this?
> 
> The only concern I have how this change affects *BSD or prefix? But yet
> I failed to find a package that is affected and that is not Linux
> specific.

Right, there are no plans to touch *bsd. This would just be a
modification to the Linux-specific portion of baselayout.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Ben de Groot]

On 14 October 2013 03:32, William Hubbs <williamh@gentoo.org> wrote:
> All,
>
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?
>
> William
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498

I don't see a compelling case being made for why we should make this
change apart from "all the other distros are doing it", and quite a
few reasons why we shouldn't. I'm open to being convinced, so please
tell me why this is good for Gentoo users.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Rich Freeman]

On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> I don't see a compelling case being made for why we should make this
> change apart from "all the other distros are doing it", and quite a
> few reasons why we shouldn't. I'm open to being convinced, so please
> tell me why this is good for Gentoo users.

So far I've seen a reference to a bug associated with a bunch of
systemd issues when it isn't mounted, and the point that many things
break in namespaces without the symlink, since /etc/mtab does not
reflect the state of the namespace.  The latter in particular seems
like a pretty fundamental limitation - the very concept of /etc/mtab
is that mounts are global, and the design of linux is that mounts are
NOT global.

If all the other distros are doing it, there is probably a reason.

As far as problems with switching - I've only seen one or two
correctable issues that seem compelling (NFS issues, and PAM issues).
There was a bunch of talk about how making this change will cause a
command designed to unmount everything actually unmount everything as
well.

But please continue to chime in with both pros and cons.

Rich

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Richard Yao]

On Oct 14, 2013, at 9:19 AM, Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> I don't see a compelling case being made for why we should make this
>> change apart from "all the other distros are doing it", and quite a
>> few reasons why we shouldn't. I'm open to being convinced, so please
>> tell me why this is good for Gentoo users.
> 
> So far I've seen a reference to a bug associated with a bunch of
> systemd issues when it isn't mounted, and the point that many things
> break in namespaces without the symlink, since /etc/mtab does not
> reflect the state of the namespace.  The latter in particular seems
> like a pretty fundamental limitation - the very concept of /etc/mtab
> is that mounts are global, and the design of linux is that mounts are
> NOT global.

Why should this not be treated as a systemd bug?

> If all the other distros are doing it, there is probably a reason.

Perhaps they lack a FreeBSD variant and therefore see no reason to be different than Fedora.

> As far as problems with switching - I've only seen one or two
> correctable issues that seem compelling (NFS issues, and PAM issues).
> There was a bunch of talk about how making this change will cause a
> command designed to unmount everything actually unmount everything as
> well.

How do these corrections affect Gentoo FreeBSD?

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

Dnia 2013-10-14, o godz. 09:26:43
Richard Yao <ryao@gentoo.org> napisał(a):

> On Oct 14, 2013, at 9:19 AM, Rich Freeman <rich0@gentoo.org> wrote:
> 
> > On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> >> I don't see a compelling case being made for why we should make this
> >> change apart from "all the other distros are doing it", and quite a
> >> few reasons why we shouldn't. I'm open to being convinced, so please
> >> tell me why this is good for Gentoo users.
> > 
> > So far I've seen a reference to a bug associated with a bunch of
> > systemd issues when it isn't mounted, and the point that many things
> > break in namespaces without the symlink, since /etc/mtab does not
> > reflect the state of the namespace.  The latter in particular seems
> > like a pretty fundamental limitation - the very concept of /etc/mtab
> > is that mounts are global, and the design of linux is that mounts are
> > NOT global.
> 
> Why should this not be treated as a systemd bug?

Is it a Linux kernel bug that it supports mount namespaces? Since
userspace clearly wasn't designed for that 20 years ago, so Linux
clearly has a bug supporting that!

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Richard Yao]

The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.

With that said, how does changing things benefit/affect users, especially non-systemd users?

On Oct 14, 2013, at 9:36 AM, Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2013-10-14, o godz. 09:26:43
> Richard Yao <ryao@gentoo.org> napisał(a):
> 
>> On Oct 14, 2013, at 9:19 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> 
>>> On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>>>> I don't see a compelling case being made for why we should make this
>>>> change apart from "all the other distros are doing it", and quite a
>>>> few reasons why we shouldn't. I'm open to being convinced, so please
>>>> tell me why this is good for Gentoo users.
>>> 
>>> So far I've seen a reference to a bug associated with a bunch of
>>> systemd issues when it isn't mounted, and the point that many things
>>> break in namespaces without the symlink, since /etc/mtab does not
>>> reflect the state of the namespace.  The latter in particular seems
>>> like a pretty fundamental limitation - the very concept of /etc/mtab
>>> is that mounts are global, and the design of linux is that mounts are
>>> NOT global.
>> 
>> Why should this not be treated as a systemd bug?
> 
> Is it a Linux kernel bug that it supports mount namespaces? Since
> userspace clearly wasn't designed for that 20 years ago, so Linux
> clearly has a bug supporting that!
> 
> -- 
> Best regards,
> Michał Górny

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Rich Freeman]

On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <ryao@gentoo.org> wrote:
> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
>
> With that said, how does changing things benefit/affect users, especially non-systemd users?

Better support for namespaces, for one.

If this is actually going to actually break something, by all means
speak up.  Otherwise this really comes across as the whole
I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
/etc/mtab a symlink, and if down the road something doesn't work as a
result feel free to fork it unless you can convince somebody else to
make it work.  So far the only concrete issues that have been raised
seem minor - pertaining to NFS and PAM (both having solutions
available).

If this causes trouble for the FreeBSD folks I'm interested in what
kinds of compromises can be reached.  I think a challenge is that
Linux and FreeBSD seem to be very slowly diverging - for software that
lives near the kernel/userspace boundary that could make things
interesting.  There doesn't seem to be much desire to limit Linux
distros to purely POSIX behavior.

Rich

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

On 10/14/2013 10:11 AM, Rich Freeman wrote:
> On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <ryao@gentoo.org> wrote:
>> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
>>
>> With that said, how does changing things benefit/affect users, especially non-systemd users?
> 
> Better support for namespaces, for one.
> 
> If this is actually going to actually break something, by all means
> speak up.  Otherwise this really comes across as the whole
> I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
> /etc/mtab a symlink, and if down the road something doesn't work as a
> result feel free to fork it unless you can convince somebody else to
> make it work.  So far the only concrete issues that have been raised
> seem minor - pertaining to NFS and PAM (both having solutions
> available).
> 
> If this causes trouble for the FreeBSD folks I'm interested in what
> kinds of compromises can be reached.  I think a challenge is that
> Linux and FreeBSD seem to be very slowly diverging - for software that
> lives near the kernel/userspace boundary that could make things
> interesting.  There doesn't seem to be much desire to limit Linux
> distros to purely POSIX behavior.
> 
> Rich
> 

My main concern is that some of the configure flags being proposed could
make packages that worked on Gentoo FreeBSD stop working there. I am not
making changes, but I think that there should be some benefit and that
care should be taken not to break things for everyone else.

That being said, mgorny said that this adds support for mount
namespaces, but I have yet to hear an explanation of what that actually
means. What are the use cases?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]

On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote:
> On 10/14/2013 10:11 AM, Rich Freeman wrote:
> > On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <ryao@gentoo.org> wrote:
> >> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
> >>
> >> With that said, how does changing things benefit/affect users, especially non-systemd users?
> > 
> > Better support for namespaces, for one.
> > 
> > If this is actually going to actually break something, by all means
> > speak up.  Otherwise this really comes across as the whole
> > I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
> > /etc/mtab a symlink, and if down the road something doesn't work as a
> > result feel free to fork it unless you can convince somebody else to
> > make it work.  So far the only concrete issues that have been raised
> > seem minor - pertaining to NFS and PAM (both having solutions
> > available).
> > 
> > If this causes trouble for the FreeBSD folks I'm interested in what
> > kinds of compromises can be reached.  I think a challenge is that
> > Linux and FreeBSD seem to be very slowly diverging - for software that
> > lives near the kernel/userspace boundary that could make things
> > interesting.  There doesn't seem to be much desire to limit Linux
> > distros to purely POSIX behavior.

As I said earlier in the thread, the planned baselayout change will only
affect Linux.

> My main concern is that some of the configure flags being proposed could
> make packages that worked on Gentoo FreeBSD stop working there. I am not
> making changes, but I think that there should be some benefit and that
> care should be taken not to break things for everyone else.

Richard, the packages we are discussing (nilfs-utils and nfs-utils)
are linux-specific, so there is nothing to worry about on the *bsd side
for them.

> That being said, mgorny said that this adds support for mount
> namespaces, but I have yet to hear an explanation of what that actually
> means. What are the use cases?

There has been a lot written on this; you might want to google
"per-process namespaces".

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]

On 10/14/2013 12:34 PM, William Hubbs wrote:
> On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote:
>> On 10/14/2013 10:11 AM, Rich Freeman wrote:
>>> On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao <ryao@gentoo.org> wrote:
>>>> The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too.
>>>>
>>>> With that said, how does changing things benefit/affect users, especially non-systemd users?
>>>
>>> Better support for namespaces, for one.
>>>
>>> If this is actually going to actually break something, by all means
>>> speak up.  Otherwise this really comes across as the whole
>>> I-DONT-LIKE-CHANGE argument.  I get it.  By all means don't make your
>>> /etc/mtab a symlink, and if down the road something doesn't work as a
>>> result feel free to fork it unless you can convince somebody else to
>>> make it work.  So far the only concrete issues that have been raised
>>> seem minor - pertaining to NFS and PAM (both having solutions
>>> available).
>>>
>>> If this causes trouble for the FreeBSD folks I'm interested in what
>>> kinds of compromises can be reached.  I think a challenge is that
>>> Linux and FreeBSD seem to be very slowly diverging - for software that
>>> lives near the kernel/userspace boundary that could make things
>>> interesting.  There doesn't seem to be much desire to limit Linux
>>> distros to purely POSIX behavior.
> 
> As I said earlier in the thread, the planned baselayout change will only
> affect Linux.
> 
>> My main concern is that some of the configure flags being proposed could
>> make packages that worked on Gentoo FreeBSD stop working there. I am not
>> making changes, but I think that there should be some benefit and that
>> care should be taken not to break things for everyone else.
> 
> Richard, the packages we are discussing (nilfs-utils and nfs-utils)
> are linux-specific, so there is nothing to worry about on the *bsd side
> for them.

That is good to hear. There were a few situations int he past where
changes were made for Gentoo Linux that broke Gentoo FreeBSD, so I
wanted to be certain that we were not going to have a repeat of that here.

>> That being said, mgorny said that this adds support for mount
>> namespaces, but I have yet to hear an explanation of what that actually
>> means. What are the use cases?
> 
> There has been a lot written on this; you might want to google
> "per-process namespaces".

If this merits discussion on the list, then it should merit answers for
these questions:

1. What are mount namespaces? How do they integrate with the kernel?
2. What does systemd do with them? What does systemd's use of them
provide to users?

Saying to google "per-process namespaces" does not really answer that.
Per-process namespaces provide a means to isolate processes into
containers that they have their own pid numbers and can neither nor
interact with processes outside of the container via traditional IPC
mechanisms such as signals. It is similar to the concept of FreeBSD
jails. That does not tell me what a "mount namespace is" or why systemd
has anything to do with it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Rich Freeman]

On Mon, Oct 14, 2013 at 1:01 PM, Richard Yao <ryao@gentoo.org> wrote:
>
> 1. What are mount namespaces? How do they integrate with the kernel?
> 2. What does systemd do with them? What does systemd's use of them
> provide to users?
>
> Saying to google "per-process namespaces" does not really answer that.
> Per-process namespaces provide a means to isolate processes into
> containers that they have their own pid numbers and can neither nor
> interact with processes outside of the container via traditional IPC
> mechanisms such as signals. It is similar to the concept of FreeBSD
> jails. That does not tell me what a "mount namespace is" or why systemd
> has anything to do with it.
>

You're describing a process namespace, which is only one type of
namespace.  All namespaces are "per-process," but process namespaces
are just one type of per-process namespace.  Confused yet?

All processes within the same mount namespace see the same filesystem.
 If I run mount /dev/cdrom /mnt/cdrom in one process, then all
processes in the same namespace will see it mounted.  However,
processes in another namespace will NOT see the new mount.

To illustrate, if you are on linux with util-linux installed launch
two root shells, and in one execute:
mkdir /tmp/foo
touch /tmp/foo/a
unshare -m /bin/bash
mount -t tmpfs none /tmp/foo
touch /tmp/foo/b
ls /tmp/foo

Then run ls /tmp/foo in your other process.  They'll see two different
directories, because the tmpfs mounted in the separate namespace
created by unshare is not visible to any other process.  To clean up
within the namespace umount /tmp/foo and exit (I have no idea if it is
possible to unmount the tmpfs if you exit first, or if the kernel does
it for you).

The possibilities are endless.  You could mount an encrypted home for
a user and make it visible only to the user.  Containers are an
obvious way to use them.

Systemd lets you configure daemons to have restricted access to the
filesystem as well - either read-only, or not at all - by directory.
I assume it just clones the mount namespace, and then sets up
bind-mounts to implement this before dropping root and launching the
process.

Rich

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On 10/14/2013 01:24 PM, Rich Freeman wrote:
> Systemd lets you configure daemons to have restricted access to the
> filesystem as well - either read-only, or not at all - by directory.
> I assume it just clones the mount namespace, and then sets up
> bind-mounts to implement this before dropping root and launching the
> process.

On 10/14/2013 01:08 PM, William Hubbs wrote:
> This functionality can't be fully supported if /etc/mtab is a file.

That is all that I needed to read. Make sure that there are no
regressions for existing users and I am all for it. :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On 10/14/2013 10:46 AM, Richard Yao wrote:
> My main concern is that some of the configure flags being proposed could
> make packages that worked on Gentoo FreeBSD stop working there. I am not
> making changes, but I think that there should be some benefit and that
> care should be taken not to break things for everyone else.
> 
> That being said, mgorny said that this adds support for mount
> namespaces, but I have yet to hear an explanation of what that actually
> means. What are the use cases?
> 

Someone brought to my attention that there was a slight error in the
above message. I had meant to write "I am not against making changes..."
rather than "I am not making changes...".

In hindsight, the statement that "I am not making changes" was a more
profound statement than the one that I meant to write because it can be
interpreted in any of two ways:

1. It could be interpreted as meaning that I intend to oppose proposed
changes when they have no benefit and I have the ability to oppose them.
2. It could be interpreted as meaning that I am not one of the people
who make decisions for the packages involved. Consequently, my opinion
here only matters to the extent that those who make decisions are
willing to consider it.

Both of which are correct. That being said, I am not against making
changes, but given that this is on the list, I would like to someone to
provide a technical justification. Some key questions that justification
should answer are "what capability does this provide to sysytemd that
cannot be obtained without this change? and "what does that do for
users"? So far, the only thing that I have read is "systemd wants it",
which answers neither question.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Mon, Oct 14, 2013 at 12:47:08PM -0400, Richard Yao wrote:

*snip*

> Both of which are correct. That being said, I am not against making
> changes, but given that this is on the list, I would like to someone to
> provide a technical justification. Some key questions that justification
> should answer are "what capability does this provide to sysytemd that
> cannot be obtained without this change? and "what does that do for
> users"? So far, the only thing that I have read is "systemd wants it",
> which answers neither question.

A quick google for per-process namespaces turns up this lwn series:

http://lwn.net/Articles/531114/

This functionality can't be fully supported if /etc/mtab is a file.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[David Leverton]

Rich Freeman wrote:
> [...] and the point that many things
> break in namespaces without the symlink, since /etc/mtab does not
> reflect the state of the namespace.  The latter in particular seems
> like a pretty fundamental limitation - the very concept of /etc/mtab
> is that mounts are global, and the design of linux is that mounts are
> NOT global.

If only someone would invent some sort of kernel feature that could make 
the name "/etc/mtab" refer to different files in different processes....

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Rich Freeman]

On Mon, Oct 14, 2013 at 2:58 PM, David Leverton
<levertond@googlemail.com> wrote:
>
> If only someone would invent some sort of kernel feature that could make the
> name "/etc/mtab" refer to different files in different processes....
>

Well, the symlink seems like the simpler solution to be honest.  I
mean, instead of having the ps command to list running processes you
could just have a daemon dump the list in a file every 10 seconds and
have programs read it, but...

However, FWIW, linux namespaces cannot be used to have only a single
file appear differently to different processes.  Mount namespaces can
only operate at the directory level.

I was actually looking into using namespaces as an alternative to the
sandbox model portage currently uses.  Basically you'd look at a
package's DEPENDs and build a namespace containing only those files,
and now devs don't inadvertently add ebuilds that are missing DEPENDs.

A bit of a tangent, but the sandbox functionality in portage CAN be
used to do just this with somewhat little effort.  I've just never
gotten around to trying it out.  By default sandbox is told to give
read-access to everything - the sandbox command does restrict both
reads and writes already and if that configuration were made dynamic
and set by portage per-package it would work just fine.  I just
figured namespaces would be a more elegant solution (it is also more
secure, but security isn't really a concern here).

Rich

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[David Leverton]

Rich Freeman wrote:
> However, FWIW, linux namespaces cannot be used to have only a single
> file appear differently to different processes.  Mount namespaces can
> only operate at the directory level.

So to work around that limitation we insist that everyone change how 
their systems are set up, and still have to reintroduce mtab under a 
different name ("utab", hidden away under /run) because 
/proc/self/mounts *doesn't* contain everything that's supposed to be in 
mtab after all?

If someone decides they want to use, say, different DNS servers in 
different namespaces, should we make the kernel store the server IP 
addresses, add a /proc file that dumps them out in the expected format, 
and demand that everyone replace their /etc/resolv.conf with a symlink 
to /proc/self/resolv.conf?  Or maybe, if people want namespaces, they 
can implement them properly, in which case it becomes literally a 
self-solving problem.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Mike Gilbert]

On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
<levertond@googlemail.com> wrote:
> Rich Freeman wrote:
>>
>> However, FWIW, linux namespaces cannot be used to have only a single
>> file appear differently to different processes.  Mount namespaces can
>> only operate at the directory level.
>
>
> So to work around that limitation we insist that everyone change how their
> systems are set up, and still have to reintroduce mtab under a different
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't*
> contain everything that's supposed to be in mtab after all?
>
> If someone decides they want to use, say, different DNS servers in different
> namespaces, should we make the kernel store the server IP addresses, add a
> /proc file that dumps them out in the expected format, and demand that
> everyone replace their /etc/resolv.conf with a symlink to
> /proc/self/resolv.conf?  Or maybe, if people want namespaces, they can
> implement them properly, in which case it becomes literally a self-solving
> problem.
>
>

This is a horrible example. /etc/resolv.conf is a configuration file
for code that lives entirely in userspace. Of course it makes no sense
to shove that into the kernel.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[David Leverton]

Mike Gilbert wrote:
> This is a horrible example. /etc/resolv.conf is a configuration file
> for code that lives entirely in userspace. Of course it makes no sense
> to shove that into the kernel.

My point is that it's silly to have a hard-coded special case in the 
kernel for mtab, especially if it doesn't do the job properly and 
requires an extra utab file, when the general solution could work for 
any file and wouldn't require any changes when the namespace feature 
isn't in use.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Rich Freeman]

On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
<levertond@googlemail.com> wrote:
> So to work around that limitation we insist that everyone change how their
> systems are set up, and still have to reintroduce mtab under a different
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't*
> contain everything that's supposed to be in mtab after all?

The whole design of /etc/mtab is broken.  It isn't a list of
everything that is mounted - it is a list of everything done by the
mount command (the command - not the system call).  The handbook even
has a line about having to manually populate it before running grub
since it is flat-out wrong when you're in a chroot.  There are lots of
things that can cause it to get out-of-sync.

Perhaps there are edge cases where the symlink isn't sufficient -
that's what this thread is all about.  However, I've never liked the
design of mtab.  It isn't surprising to me that distros are largely
ditching it.

>  /etc/resolv.conf

As Mike already pointed out, resolution is actually a userspace
function entirely (I'm not sure if I were designing things from
scratch that I'd put it in the C library, but...).

However, if you want to know the hostname, you should be calling uname
and not looking around for /etc/hostname or whatever.  The kernel will
tell you the truth as it applies to your process, not what you think
should be the truth based on what amounts to a logfile.

Rich

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Patrick McLean]

On Mon, 14 Oct 2013 15:50:36 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Oct 14, 2013 at 2:58 PM, David Leverton
> <levertond@googlemail.com> wrote:
> >
> > If only someone would invent some sort of kernel feature that could
> > make the name "/etc/mtab" refer to different files in different
> > processes....
> >
> 
> However, FWIW, linux namespaces cannot be used to have only a single
> file appear differently to different processes.  Mount namespaces can
> only operate at the directory level.

This is not true. Bind mounts can be performed on a single file, and
bind mounts are part of mount namespaces. Granted the target file _must_
exist (it could be a dead symlink, or a symlink to /dev/null) before
performing the bind mount.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[David Leverton]

Patrick McLean wrote:
> This is not true. Bind mounts can be performed on a single file, and
> bind mounts are part of mount namespaces. Granted the target file _must_
> exist (it could be a dead symlink, or a symlink to /dev/null) before
> performing the bind mount.

Well that's even better then. :-)

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[Richard Yao]

That is my impression as well.

With that said, the behavior is currently the same between our FreeBSD and Linux variants. This change would break that.

On Oct 14, 2013, at 7:59 AM, Ben de Groot <yngwin@gentoo.org> wrote:

> On 14 October 2013 03:32, William Hubbs <williamh@gentoo.org> wrote:
>> All,
>> 
>> from what I'm seeing, we should look into converting /etc/mtab to a
>> symlink to /proc/self/mounts [1].
>> 
>> Are there any remaining concerns about doing this?
>> 
>> If not, it seems like it would be pretty easy to make baselayout create
>> this symlink in the stages (I'm willing to do this work), but what about
>> on systems that are already installed? Should we send out a news item
>> and have everyone convert their /etc/mtab manually or find a way to
>> automate that?
>> 
>> William
>> 
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498
> 
> I don't see a compelling case being made for why we should make this
> change apart from "all the other distros are doing it", and quite a
> few reasons why we shouldn't. I'm open to being convinced, so please
> tell me why this is good for Gentoo users.
> 
> -- 
> Cheers,
> 
> Ben | yngwin
> Gentoo developer
> 

[gentoo-dev] rfc: read-only root Was: rfc: converting /etc/mtab to a symlink

[Duncan]

William Hubbs posted on Sun, 13 Oct 2013 14:32:32 -0500 as excerpted:

> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
> 
> Are there any remaining concerns about doing this?
> 
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?
> 
> William
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498

New subthread here as I don't see this mentioned in the others (tho pacho 
mentions it in the bug) ...

TL;DR: An /etc/mtab symlink is the generally recommended and simplest way 
to make a read-only root work, and I've been setup like that for some 
months now, so I'm all for it. =:^)

Some months ago I finally upgraded my core system to SSDs, and with that, 
btrfs (I had been on reiserfs for years with very good results even thru 
hardware issues as since ordered-by-default journaling went in, anyway, 
it's an incredibly stable filesystem that doesn't have the kernel folks 
monkeying around with it and trying stuff like the infamous ext3-
writeback-by-default tricks, like the ext* filesystems do, but 
unfortunately reiserfs simply was no designed for nor is it suited to 
SSDs), which of course is still an experimental filesystem, for good 
reason as altho the mainstream case tends to work relatively well, 
they're still fixing critical corner-case bugs with every kernel release.

So to hopefully counter some of the additional risk, and because I had 
been looking at the idea for a couple years anyway, I setup a read-only 
root by default.  And I'll tell you what, it sure is nice knowing that 
after a hard shutdown and reboot, while /home and /var/log will probably 
have integrity errors due to the bad shutdown and I'll need to do a btrfs 
scrub to repair them (a pair of SSDs with most filesystems in btrfs raid1 
mode for both data and metadata, so there's the second copy of all 
(meta)data to read and restore from if the first is corrupt and fails the 
integrity check), root itself should be safe, since it was mounted read-
only and thus no ongoing writes could have been occurring there when the 
crash occurred.  And of course the btrfs recovery tools are on root, so 
if worse did come to worse, they should be fine to use in recovering 
/home, since the root filesystem was read-only the entire period and thus 
should be undamaged. =;^)

Of course in ordered to setup a read-only root, I had to make some 
changes, including the one under discussion here, making /etc/mtab a 
symlink to /proc/self/mounts.  (Actually, I symlinked it to /proc/mounts, 
but as mentioned elsewhere in the thread, on a modern kernel since mount 
namespaces, that's a symlink to /proc/self/mounts already, so same 
ultimate result.)

So I'm all for the change, since that will bring the default gentoo 
installation one step closer to a read-only root, meaning one less thing 
for people who want to setup that way to have to worry about. =:^)

Meanwhile, the handbook has for years suggested a separate /boot and 
mentioned the separate /home option.  Once we have /etc/mtab as a 
symlink, the next logical step would be to consider upgrading that 
separate /home option to suggested default, adding /var/log as a 
suggested default, and making the default fstab options for / include ro, 
thus increasing default gentoo system data robustness dramatically.  Of 
course the system-updates/portage discussion would then need a reminder 
to remount / rw, but with /etc/mtab a symlink, further necessary changes 
are minor, and it really will improve gentoo system robustness 
dramatically, likely saving a number of users the headache of having to 
recover a screwed up root, simply because it was mounted writable and 
didn't happen to be in a consistent state when the system crashed.

(Arguably that should be a (sub-)thread of its own, thus the retitled 
subthread, already top-level.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman