Coreutils-8.20

[Matthew Burgess]

New version. No release announcement as yet.

[Gilles Espinasse]

tests/du/bind-mount-dir-cycle.sh fail with regular /etc/mtab but work with symlink to /proc/mounts

[Gilles Espinasse]

As this new tests/du/bind-mount-dir-cycle.sh fail even on old coreutils version (I tested 8.5 from debian stable), I would suggest to skip the test using something like

sed -i -e "s/print_ver_ du/skip_ 'unsupported /etc/mtab configuration, see bug#12730'/" tests/du/bind-mount-dir-cycle.sh

unless you want to switch to /etc/mtab as symlink ;-) This look like the only futur-proof solution.

[Matthew Burgess]

Replying to gespinasse:

tests/du/bind-mount-dir-cycle.sh fail with regular /etc/mtab but work with symlink to /proc/mounts

Test failure confirmed here. I also note that you've taken this upstream (thread starting at ​http://lists.gnu.org/archive/html/bug-coreutils/2012-10/msg00139.html), so thanks for that!

Interestingly, LFS has flip-flopped a couple of times on the issue of a real or symlinked /etc/mtab file. It was last changed in r2415, following a discussion started by the previous maintainer of 'mount' at ​http://www.linuxfromscratch.org/pipermail/lfs-dev/2003-January/030854.html.

It is my understanding that the current util-linux maintainer expects a symlinked mtab. I'll try to go through that long discussion thread again and pull out the use cases that failed with the symlink and see if they're still relevant (that discussion is 10 years old, so things may have moved on since then).

[Gilles Espinasse]

The kernel has changed since 2003 to better support symlinked mtab. Fedora has switched to mtab symlink and the few issue with symlink should have been solved before (probably in 2.6.37).

I already hit a few issue with regular mtab when testing util-linux-2.22. I was using a running kernel <2.6.37 and that was clearly something not tested with 2.22 and fixed in 2.22.1 following my reports.

I look at the suggested way to fix the issue and that would be hard for me to code that. I had an other idea to fix the test issue using a different way than to modify coreutils/gnulib mountlist behavior.

mount --bind now produce a different mtab with symlink or regular mtab. In case of symlink, fstype is the fs of the directory mounted. In case of regular mtab, fstype is always none. So maybe mount code could be modified to produce the same fstype info. I don't know yet if that would be easier to code/accepted upstream.

[bdubbs@…]

My problem with a symlinked mtab is that I can't tell what the root partition is:

$ mount | head -n1
/dev/sda12 on / type ext3 (rw)

$ cat /proc/mounts | head -n2
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,relatime,errors=continue,barrier=1,data=writeback 0 0

rootfs and /dev/root don't tell me anything.

[Matthew Burgess]

Replying to bdubbs@…:

My problem with a symlinked mtab is that I can't tell what the root partition is:

...

rootfs and /dev/root don't tell me anything.

But if 'mount' and 'df' and similar tools show you the right output, does it really matter that 'cat /etc/mtab' or 'cat /proc/mounts' doesn't? To me, /etc/mtab shouldn't ever have been there; it's not like it's a configuration file that a sysadmin would want or need to change. As long as userspace can produce the correct information with whatever implementation of /etc/mtab we decide upon, that's fine by me.

[bdubbs@…]

Replying to matthew@…:

Replying to bdubbs@…:

My problem with a symlinked mtab is that I can't tell what the root partition is:

...

rootfs and /dev/root don't tell me anything.

But if 'mount' and 'df' and similar tools show you the right output, does it really matter that 'cat /etc/mtab' or 'cat /proc/mounts' doesn't?

I agree that the proper output from mount or df would remove my objection. However, that has not been my experience in the past.

[Gilles Espinasse]

Doesn't lsblk or findmnt show what you would see for the root partition?

​http://karelzak.blogspot.fr/search?updated-min=2010-01-01T00:00:00%2B01:00&updated-max=2011-01-01T00:00:00%2B01:00&max-results=7

[bdubbs@…]

Replying to gespinasse:

Doesn't lsblk or findmnt show what you would see for the root partition?

​http://karelzak.blogspot.fr/search?updated-min=2010-01-01T00:00:00%2B01:00&updated-max=2011-01-01T00:00:00%2B01:00&max-results=7

lsblk is ok for visual output, but not very convenient for scripting. I suppose that something like this would work:

$ lsblk -P -o NAME,MOUNTPOINT|grep '"/"'

findmnt gives /dev/root which is not useful. Note that /dev/root does not actualy exist.

cat /proc/cmdline works if you are not using a label or uuid for mounting.

[Matthew Burgess]

lsblk doesn't look useful to me. With /etc/mtab symlinked to /proc/mounts it has no entry in the MOUNTPOINT column for / - the root partition doesn't have a mountpoint given. At this point, I think we should keep things as they are for now, and use Gilles's workaround of disabling the failing test. I'll raise the issue of symlinked /etc/mtab upstream - mount, df and lsblk all show unfortunate behaviour in that configuration, so I suspect that libmount is actually to blame.

[bdubbs@…]

Where are we on this ticket? AFAICT we just need to either mention a failing test or use a sed to skip it.

Are there other issues?

[Matthew Burgess]

Hmm, I hit another issue with the testsuite that I thought I'd reported here. Looks like I took it straight upstream: ​http://lists.gnu.org/archive/html/bug-coreutils/2012-11/msg00002.html. It's gained no traction yet, and I think it's harder to explain away than the 'du' test that Gilles mentions in comment 1.

[Gilles Espinasse]

I explained the second issue in ​http://lists.gnu.org/archive/html/bug-coreutils/2012-11/msg00123.html

For 8.20, adding SUBDIRS= on command line should work, so using 'make NON_ROOT_USERNAME=nobody SUBDIRS= check-root'

I may try to reanimate the bug report.

[Matthew Burgess]

Fixed in r10089.