Bug#702935: 'mount -f' does not update /run/mount/utab

[Steve Langasek]

Package: mount
Version: 2.20.1-5.3
Severity: serious
Justification: breaks handling of network-based filesystems on shutdown

The use of a symlink for /etc/mtab in wheezy means that 'mount -f' no longer
works. As a consequence, extra mount options that libmount *should* record
in /run/mount/utab are not recorded for any filesystem that is mounted
before the rootfs is marked rw, including but not limited to _netdev. This
potentially leaves the system with no way to cleanly unmount some
network-dependent filesystems at shutdown time.

Relatedly, even if /run/mount/utab were being updated properly by 'mount
-f', there appears to be no interface for querying these values.
/etc/init.d/umountnfs.sh currently assumes it should read from /etc/mtab;
and the 'findmnt' utility doesn't appear to honor utab even when using the
'-m' option:

$ findmnt -m -O _netdev
$ echo $?
1
$

This is a significant regression in handling of network-based block devices,
such as iscsi and nbd, compared with squeeze. I think it's important that
this be resolved before release.

-- System Information:
Debian Release: 6.0.6
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mount depends on:
ii libblkid1 2.20.1-5.3 block device id library
ii libc6 2.13-38 Embedded GNU C Library: Shared lib
ii libmount1 2.20.1-5.3 block device id library
ii libselinux1 2.0.96-1 SELinux runtime shared libraries
ii libsepol1 2.0.42-1 SELinux library for manipulating b

mount recommends no packages.

Versions of packages mount suggests:
ii nfs-common 1:1.2.6-3 NFS support files common to client

-- no debconf information


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

[Roger Leigh]

On Tue, Mar 12, 2013 at 09:19:06PM -0700, Steve Langasek wrote:
> The use of a symlink for /etc/mtab in wheezy means that 'mount -f' no longer
> works. As a consequence, extra mount options that libmount *should* record
> in /run/mount/utab are not recorded for any filesystem that is mounted
> before the rootfs is marked rw, including but not limited to _netdev. This
> potentially leaves the system with no way to cleanly unmount some
> network-dependent filesystems at shutdown time.

[...]

> This is a significant regression in handling of network-based block devices,
> such as iscsi and nbd, compared with squeeze. I think it's important that
> this be resolved before release.

Hi Steve,

I'm afraid I'm away and without internet access until next weekend.
I've attached what I've done so far to work around this in
initscripts.

While bugs in mount/libmount/findmnt are certainly the cause of the
lack of _netdev, I'm doubtful that these are addressable in time for
wheezy. And we would have to adapt the initscripts to use mount or
findmnt in order to merge in the utab content rather than looking
at mtab directly (which is easy--I've already done it locally, but
it needs the changes in util-linux from newer upstream releases, and
possibly additional work). Certainly do-able for jessie.

In initscripts, we make the choice of a dynamic or static mtab in the
mtab_migrate function called from checkroot.sh. This is only ever
run on read-write root, since it's not possible to change things if
it's read-only (here, the admin is responsible). As discussed on IRC,
we can't realistically change this at upgrade time due to loss of
information such as nfs/cifs extended mount options.

At boot time, we currently migrate mtab to a symlink where possible.
Other alternatives are
- migrating back to a static file (not recommended; this would
reintroduce more problems than it solves)
- making the choice of symlink or static file based upon particular
criteria

The attached patch does the latter. It looks to see if _netdev is in
use, and if so will refuse to migrate to a symlink. Though it will
do nothing if a symlink already exists, so it won't revert back to
a static file (this could be added easily; I'm just attaching what I've
done so far prior to going away for the week in case you want to push
a fix for this before I get back).

This isn't an ideal solution, and I certainly wouldn't want to keep it
for jessie, but it will cover the majority of the _netdev usecases
fairly simply as an immediate workaround for wheezy. I'm not sure of
the scope of this problem, but given that it took around 15-16 months
before this came up as an issue, I don't think it's particularly large,
especially when considering the scope of the bugs affecting static
mtab files, which was vastly larger and could cause worse problems.


Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

[Roger Leigh]

On Tue, Apr 16, 2013 at 07:43:32PM +0100, Adam D. Barratt wrote:
> > The attached patch does the latter. It looks to see if _netdev is in
> > use, and if so will refuse to migrate to a symlink. Though it will
> > do nothing if a symlink already exists, so it won't revert back to
> > a static file (this could be added easily; I'm just attaching what I've
> > done so far prior to going away for the week in case you want to push
> > a fix for this before I get back).
>

> What's the current status here?

I've not made any changes as yet. Given that this will only affect
users who are using e.g. nbd as their rootfs, and not any regular
use of network nfsroot etc., the best option may be to simply
document how to re-enable a static mtab in the release notes, for
users who are dependent upon _netdev working. This would
essentially be to
- comment out the mtab_migrate conditional in /etc/init.d/checkroot.sh
- rm /etc/mtab
- cat /proc/mounts > /etc/mtab
and to reboot; the _netdev flag will then be stored in mtab correctly.

If we want to do anything more sophisticated, I'm happy to look at
something like the proposed patch. This would be a relatively safe
change to make. Likewise if there are any alternative proposals,
I'll be happy to look at that. But if the release notes are an
acceptable stopgap, I'll draft something.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800