Debian Bug report logs - #653073
why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: submit@bugs.debian.org

Subject: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Fri, 23 Dec 2011 22:23:27 +0800

X-debbugs-Cc: rleigh@debian.org
Package: initscripts
Version: 2.88dsf-16

I have little idea of which package causes
$ { df; mount;}|grep disk
/dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78   1071468  287800    729240  29% /
/dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 on / type ext3 (rw,noatime,errors=remount-ro,commit=333,barrier=1,data=ordered)
to thus report the root file system, instead of its
$ ls -l /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78
lrwxrwxrwx 1 root root 11 12-23 22:00 /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 -> ../../sda11
short name.
$ grep UUID /etc/fstab
UUID=551e44e1-2cad-42cf-a716-f2e6caf9dc78 / ext3 defaults,commit=333,noatime,errors=remount-ro 0 1
UUID=355d426a-cbfc-4faf-91d6-4f9405199517 /home ext3 defaults,commit=333,noatime 0 2
UUID=34610b6a-70a3-48d9-b135-96907dc2ba16 /var ext3 defaults,commit=333,noatime 0 2
UUID=1d11e0e3-26d7-42be-89d2-00fbe939dc1c /usr ext3 defaults,commit=333,noatime 0 2
shows that the others are UUIDs in /etc/fstab but don't become ugly as
such when reported by mount or df.

Message #10 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: jidanni@jidanni.org, 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Fri, 23 Dec 2011 15:38:31 +0000

On Fri, Dec 23, 2011 at 10:23:27PM +0800, jidanni@jidanni.org wrote:
> X-debbugs-Cc: rleigh@debian.org
> Package: initscripts
> Version: 2.88dsf-16
> 
> I have little idea of which package causes
> $ { df; mount;}|grep disk
> /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78   1071468  287800    729240  29% /
> short name.
> $ grep UUID /etc/fstab
> UUID=551e44e1-2cad-42cf-a716-f2e6caf9dc78 / ext3 defaults,commit=333,noatime,errors=remount-ro 0 1

I would suggest checking what is in /etc/mtab and /proc/mounts.
/etc/mtab was changed to be a symlink to /proc/mounts.  If you
are mounting by UUID, then I think this is to be expected.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Message #15 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: rleigh@codelibre.net

Cc: 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Fri, 23 Dec 2011 23:46:18 +0800

>>>>> "RL" == Roger Leigh <rleigh@codelibre.net> writes:
RL> I would suggest checking what is in /etc/mtab and /proc/mounts.
RL> /etc/mtab was changed to be a symlink to /proc/mounts.  If you
RL> are mounting by UUID, then I think this is to be expected.
Yes I see the same situation there too. But in all cases it only affects
/, even though as you see I mount many filesystems by UUID. It only
started acting this way today.

Message #20 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: rleigh@codelibre.net

Cc: 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Fri, 23 Dec 2011 23:47:58 +0800

23:43 ~$ cat /etc/mtab
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=248048k,nr_inodes=62012,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=50564k,mode=755 0 0
/dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 / ext3 rw,noatime,errors=remount-ro,commit=333,barrier=1,data=ordered 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=101128k 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=101128k 0 0
/dev/sda6 /home ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0
/dev/sda7 /var ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0
/dev/sda8 /usr ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0
/dev/sda9 /var/cache/wwwoffle ext3 rw,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0
/dev/sda10 /music ext3 rw,nosuid,nodev,noexec,noatime,errors=continue,commit=333,barrier=1,data=ordered 0 0
/dev/sdg2 /mnt/usb/cf ext3 rw,noatime,errors=remount-ro,barrier=1,data=ordered 0 0
$ ll /etc/mtab
lrwxrwxrwx 1 root root 12 12-23 22:00 /etc/mtab -> /proc/mounts

Message #25 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: rleigh@codelibre.net

Cc: 653073@bugs.debian.org

Subject: mount(1) and df(1) now ugly

Date: Sat, 24 Dec 2011 08:32:11 +0800

I still have one system that I will update today. But before I do,
$ ls -l /etc/mtab /proc/mounts #still separate
-rw-r--r-- 1 root root 712 12-24 07:49 /etc/mtab
lrwxrwxrwx 1 root root  11 12-24 08:04 /proc/mounts -> self/mounts
$ sort -k 2 /etc/mtab /proc/mounts|head
#only root FS called a different name, lots of extra info too that makes mount(1) look ugly.
/dev/sda5 / ext3 rw,errors=remount-ro 0 0
/dev/disk/by-uuid/efd74e43-e0cb-4aa9-8a1d-d258cd465773 / ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
rootfs / rootfs rw 0 0
udev /dev devtmpfs rw,relatime,size=106452k,nr_inodes=26613,mode=755 0 0
udev /dev tmpfs rw,mode=0755 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620,gid=5,mode=620 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/sda6 /home ext3 rw 0 0
/dev/sda6 /home ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,size=5120k,mode=755 0 0

So simply linking them will affect df(1) and mount(1) output.
df is no longer readable on small screens, as the one long column now
shoves the rest off the screen.
mount now shows lots of extraneous information that it didn't used to.
Both had been pleasant reading for ~forty years up until today!

Message #30 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: jidanni@jidanni.org

Cc: 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Sat, 24 Dec 2011 12:40:32 +0000

On Fri, Dec 23, 2011 at 11:46:18PM +0800, jidanni@jidanni.org wrote:
> >>>>> "RL" == Roger Leigh <rleigh@codelibre.net> writes:
> RL> I would suggest checking what is in /etc/mtab and /proc/mounts.
> RL> /etc/mtab was changed to be a symlink to /proc/mounts.  If you
> RL> are mounting by UUID, then I think this is to be expected.
> Yes I see the same situation there too. But in all cases it only affects
> /, even though as you see I mount many filesystems by UUID. It only
> started acting this way today.

This is presumably because the rootfs is mounted by the initramfs,
while everything else is mounted by init scripts using regular
mount(8).

Note that the extra detail is in general an improvement--mtab
previously excluded information such as some mount options.

I would suggest identifying /why/ the rootfs was mounted recording
the long UUID.  Candidates are:

- initramfs mount command line
- initramfs busymox mount binary
- initramfs /dev [but should be udev]

Should be fairly simple to address.  Note that this is not a bug in
initscripts--it's simply reporting what's really there, rather than
hiding the real situation as before.  I would suggest reassigning to
the appropriate package once this has been identified.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Message #35 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: rleigh@codelibre.net

Cc: 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Sat, 24 Dec 2011 22:21:26 +0800

RL> - initramfs mount command line
RL> - initramfs busymox mount binary
RL> - initramfs /dev [but should be udev]
Does your fstab have any UUID in it?
We were told that's what we should use.
Does your df(1) or mount(1) output also have none, some, or all of them?
Is there a way to get back the readable sda stuff without ripping the
UUID stuff out of fstab?
Is the UUID stuff more readable than the short sda strings?
I have no idea what is causing it.

Message #40 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: jidanni@jidanni.org

Cc: 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Sat, 24 Dec 2011 16:48:32 +0000

On Sat, Dec 24, 2011 at 10:21:26PM +0800, jidanni@jidanni.org wrote:
> RL> - initramfs mount command line
> RL> - initramfs busymox mount binary
> RL> - initramfs /dev [but should be udev]
> Does your fstab have any UUID in it?

No.  I use LVM.

> We were told that's what we should use.

This is correct advice.

> Does your df(1) or mount(1) output also have none, some, or all of them?

None, due to using LVM.

> Is there a way to get back the readable sda stuff without ripping the
> UUID stuff out of fstab?
> Is the UUID stuff more readable than the short sda strings?
> I have no idea what is causing it.

This is why I asked you to investigate the origin in my previous
message.  It's likely it originates from the rootfs being mounted
in the initramfs.  If you are using an initramfs.  It's possible
that it could be corrected by tweaking the script run in the
initramfs.  But I really can't speculate here; it's something
you would need to investigate for yourself.  I mentioned potential
culprits in my previous message.  If you mount using
root= on the kernel command-line, rather than an initramfs, it may
also be the case that the UUID is the only thing available to
the kernel in early boot, and this is preserved.

Readability of the strings is not really related here.  UUIDs
are used for unambiguity when referring to a specific partition,
given that on modern systems device names are not guaranteed to
be stable.  While it would be preferable for readability to use
shorter strings, this is not strictly a bug--it's obviously
correct, just not in the most readable format.

I would suggest that you add 'break=bottom' to your kernel
command-line, and check in the initramfs whether the root
device UUID exists, and if so if it is a symlink to the
short-form device name.  I would then mount the rootfs onto
e.g. /mnt and check /proc/mounts to compare mounting the short
and long names.  I would then do the same on a normally booted
system to compare how mount behaves here.  If it's doing
something odd in the initramfs, maybe we can fix it to behave
the same as on a real system.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Message #45 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: rleigh@codelibre.net

Cc: 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Sun, 25 Dec 2011 08:38:46 +0800

RL> root= on the kernel command-line, rather than an initramfs, it may
RL> also be the case that the UUID is the only thing available to
RL> the kernel in early boot, and this is preserved.

That must be the case.

RL> Readability of the strings is not really related here.  UUIDs
RL> are used for unambiguity when referring to a specific partition,
RL> given that on modern systems device names are not guaranteed to
RL> be stable.  While it would be preferable for readability to use
RL> shorter strings, this is not strictly a bug--it's obviously
RL> correct, just not in the most readable format.

OK, I can get used to the new way, I just wish it was consistent.
I.e., I wish $ mount, and $ df, would either use all the
/proc/partitions names or all the UUID names or all the names they found
in fstab, instead of treating root different.

RL> I would suggest that you add 'break=bottom' to your kernel
RL> command-line, and check in the initramfs whether the root
RL> device UUID exists, and if so if it is a symlink to the
RL> short-form device name.  I would then mount the rootfs onto
RL> e.g. /mnt and check /proc/mounts to compare mounting the short
RL> and long names.  I would then do the same on a normally booted
RL> system to compare how mount behaves here.  If it's doing
RL> something odd in the initramfs, maybe we can fix it to behave
RL> the same as on a real system.

Errr... too deep water for me, however I have some basic conclusions
that I will post in a wider post...

Message #50 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: rleigh@codelibre.net, debian-devel@lists.debian.org

Cc: 653073@bugs.debian.org, bug-coreutils@gnu.org

Subject: /etc/mtab -> /proc/mounts symlink affects df(1) output for /

Date: Sun, 25 Dec 2011 08:40:42 +0800

The new symlink on Debian,
  $ ls -og /etc/mtab
  lrwxrwxrwx 1 12 12-23 22:00 /etc/mtab -> /proc/mounts
Has caused
  $ df
  Filesystem                                             1K-blocks    Used Available Use% Mounted on
  rootfs                                                   1071468  287940    729100  29% /
  udev                                                      248048       0    248048   0% /dev
  tmpfs                                                      50564     372     50192   1% /run
  /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78   1071468  287940    729100  29% /
  tmpfs                                                     101128     712    100416   1% /tmp
  tmpfs                                                     101128       0    101128   0% /run/shm
  /dev/sda6                                                4270273 3711316    341987  92% /home
  /dev/sda7                                                5341549 4336289    733858  86% /var
  /dev/sda8                                                6406856 3024600   3056800  50% /usr
output to 1) repeat / twice, 2) give the long name for /.
This should be reproducible for anyone who has used standard grub and thus has
  $ grep -h UUID /boot/grub/grub.cfg /proc/cmdline
matches. More details in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073 .

Message #55 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Timo Juhani Lindfors <timo.lindfors@iki.fi>

To: jidanni@jidanni.org

Cc: 653073@bugs.debian.org

Subject: Re: /etc/mtab -> /proc/mounts symlink affects df(1) output for /

Date: Sun, 25 Dec 2011 02:52:02 +0200

jidanni@jidanni.org writes:
> output to 1) repeat / twice,

There are two filesystems mounted on top of each other so this sounds
quite correct to me? The first one is of type "rootfs" and contained
your initramfs and the second one is probably ext4 and contains your
debian installation.

Message #60 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: timo.lindfors@iki.fi

Cc: 653073@bugs.debian.org

Subject: Re: /etc/mtab -> /proc/mounts symlink affects df(1) output for /

Date: Sun, 25 Dec 2011 09:32:35 +0800

>>>>> "TJL" == Timo Juhani Lindfors <timo.lindfors@iki.fi> writes:
TJL> jidanni@jidanni.org writes:
>> output to 1) repeat / twice,

TJL> There are two filesystems mounted on top of each other so this sounds
TJL> quite correct to me? The first one is of type "rootfs" and contained
TJL> your initramfs and the second one is probably ext4 and contains your
TJL> debian installation.

Well even though the byte counts are exactly the same, I suppose I can
get used to this too. Just glad they aren't listed thrice.

I guess I'll have to
alias df='df -x rootfs'
But then there's also the UUID inconsistencies the df designers didn't
plan for.

Message #65 received at 653073@bugs.debian.org (full text, mbox, reply):

From: "Alan Curry" <pacman-cu@kosh.dhis.org>

To: jidanni@jidanni.org

Cc: rleigh@codelibre.net, debian-devel@lists.debian.org, 653073@bugs.debian.org, 10363@debbugs.gnu.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Mon, 26 Dec 2011 18:27:05 -0500 (GMT+5)

jidanni@jidanni.org writes:
> 
>   Filesystem                                             1K-blocks    Used Available Use% Mounted on
>   rootfs                                                   1071468  287940    729100  29% /
>   /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78   1071468  287940    729100  29% /

(I'm replying only on the issue of the duplicate mount point. Someone else
can tackle the long ugly name.)

The one with "rootfs" as its device is the initramfs which you automatically
get with all recent kernels. Even if you aren't using an initramfs, there's
an empty one built into the kernel which gets mounted as the first root
filesystem. The real root gets mounted on top of that.

So this is a special case of a general problem with no easy solution: What
should df do when 2 filesystems are mounted at the same location? It can't
easily give correct information for both of them, since the later mount
obscures the earlier mount from view.

If there's a way for df to get the correct information for the lower mount, I
don't know what it would be. If you have a process with a leftover cwd or
open fd in the obscured filesystem, you can use that. But generally you
won't.

But maybe we could do better than reporting incorrectly that the lower mount
has size and usage identical to the upper mount! At least df could print a
warning at the end if it has seen any duplicate entries. Perhaps there is
some way it could figure out which one is on top, and print a bunch of
question marks as the lower mount's statistics.

If df is running as root, it might be able to unshare(2) the mount namespace,
unmount the upper level, and then statfs the mount point again to get the
correct results for the lower level. That won't work in all cases (even in a
private namespace you can't unmount the filesystem containing your own cwd)
and it does nothing for you if you're not root, but still... it would be a
cool bonus in the cases where it does work.

As a special case, "rootfs" should probably be excluded from the default
listing, since the initramfs is not very interesting most of the time. It
could still be shown with the -a option, although it would always have the
wrong statistics. Or if you really want to be impressive, default to showing
the initramfs if and only if it is the only thing mounted on "/" - so you can
run df within the initramfs before the real root is mounted and get the right
result.

Or... (brace yourself for the most bold idea yet)... can you imagine a kernel
interface that would *cleanly* give access to obscured mount points?

Comments on any of the above? Do the BSDs have any bright ideas we can steal,
or is their df as embarrassingly bad at handling obscured mount points as
ours?

-- 
Alan Curry

Message #70 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Olaf Titz <olaf@bigred.inka.de>

To: debian-devel@lists.debian.org

Cc: jidanni@jidanni.org, rleigh@codelibre.net, 653073@bugs.debian.org, 10363@debbugs.gnu.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 29 Dec 2011 19:28:51 +0100

> So this is a special case of a general problem with no easy solution: What
> should df do when 2 filesystems are mounted at the same location? It can't
> easily give correct information for both of them, since the later mount
> obscures the earlier mount from view.

It is a special case of an even more general problem, that mtab or
/proc/self/mounts and therefore mount(8), df(1) etc. only represent the
linear path where a filesystem was mounted at the time it was mounted,
not the underlying tree structure.

What happens with the following sequences, assuming / is the only
mounted filesystem:

mkdir /mnt/p1
mount /dev/sde1 /mnt/p1
mkdir /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2

versus

mkdir -p /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2
mount /dev/sde1 /mnt/p1

not that that would be very useful, but in general it is possible. In
the second case the filesystem on sdh1 is completely invisible, yet
mtab and /proc/mounts in both cases contain something like

/dev/sde1 /mnt/p1 ...
/dev/sdh1 /mnt/p1/p2 ...

only in different order: the last mounted filesystem comes last.

This way df(1) should already be able to just hide any obscured
filesystem: it could make two passes over the mount list, remembering
every mount point and if a later mount point is equal or a parent of
an earlier one (which can be determined by a simple string compare),
mark the earlier one as invisible. Then in the second pass over the
list output the remaining mounts.

Remains the question whether this is correct in all cases and actually
desirable behaviour. I think the latter is true, because df(1) output
is just a snapshot of how the system looks like to a newly created
process, and a newly created process can't access the obscured
filesystems at all. (The fact that /proc/mounts is a symlink to
/proc/self/mounts hints in the same direction.)

If what's really wanted is the status of all mounted filesystems
whether visible or not, I fear this can't be done without kernel help,
because exactly by the "snapshot as seen by a new process" nature you
don't get a handle to statfs() from the obscured parts. They can be
found by looking in /sys/block or /proc/diskstats but there doesn't
seem to be useful info, perhaps just another sysfs file containing the
statfs() output would already suffice.

Or perhaps just propose that one of the three nearly-identical
/proc/self/mount* files get two additional columns with the info df(1)
needs...

Olaf

Message #75 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: 653073@bugs.debian.org

Subject: Re: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Tue, 3 Jan 2012 17:39:17 -0400

[Message part 1 (text/plain, inline)]

The df output has two distinct problems, which will have separate
solutions. 


Regarding the duplicate rootfs entry, I had thought (from d-i) that it
was possible to use pivot_root and then umount the initrd afterwards.
However, hpa tells me that the rootfs is the cwd for kernel threads so
cannot be unmounted. It might also be used as the hardcoded head of the
linked list of active mounts, if they haven't found a better data
structure yet in the kernel.. :P

So this seems to be a limitation of linux, and short of going back to a
/etc/mtab file, df needs to be fixed to either paper over the problem
with a special case exclude of the rootfs, or take one of the general
purpose approaches for hiding non-available filesystems that have been
discussed. Or violate the least surprise of every user who looks at df
and sees two root filesystems, but I personally don't think that is a
good option.


Regarding the ugly uuid display, a recent release of coreutils actually
made this worse.  It used to wrap long device paths:

tmpfs                  200M  340K  200M   1% /run/shm
/dev/disk/by-uuid/6a7e9145-b76d-4bcf-a243-67c65891549a
			29G   27G  2.0G  93% /

But that's not really a fix, and was removed due to it breaking naive
scripts that did not use df -P.

The proper fix is to make klibc-utils's mount (and perhaps also
busybox's), do the same path canonicalization that /bin/mount does.
That canonicalization is why mounting by uuid does not normally cause
the problem:

joey@gnu:~>sudo mount /dev/disk/by-uuid/e55f93bc-53ce-4111-af1e-8feb07759362 /mnt
joey@gnu:~>df /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       917G  737G  181G  81% /mnt
joey@gnu:~>sudo umount /mnt
joey@gnu:~>sudo mount --no-canonicalize /dev/disk/by-uuid/e55f93bc-53ce-4111-af1e-8feb07759362 /mnt
joey@gnu:~>df /mnt
Filesystem                                              Size  Used Avail Use% Mounted on
/dev/disk/by-uuid/e55f93bc-53ce-4111-af1e-8feb07759362  917G  737G  181G  81% /mnt

If klibc-utils somehow cannot be fixed, the only other option would be to
make df try to canonicalize paths, but that would be problimatic to get
right (imagine running df in a chroot without /dev etc). Also, it would
not fix anything else that displays mounted devices, such as perhaps GUI
programs.

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #80 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: 653073@bugs.debian.org

Subject: Re: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Wed, 4 Jan 2012 14:51:38 -0400

[Message part 1 (text/plain, inline)]

Since this bug was making my life miserable, I patched df to fix its
output. The attached patch hides "rootfs" type mount points, and
canonicalizes device paths when displaying them.

Result:

Filesystem      Size  Used Avail Use% Mounted on
udev            495M     0  495M   0% /dev
tmpfs           100M  696K  100M   1% /run
/dev/sda1        29G   27G  1.4G  96% /
tmpfs           200M  340K  200M   1% /run/shm

The rootfs part of the patch is about as good a fix as I think we're going
to get. There's nothing wrong with the device path canonicalization
(it will handle correctly all cases including remote devices, special devices, 
deleted or inaccessible device files, even relative devices), but
df is not the best place to put it; fixing klibc would be better.

-- 
see shy jo

[df.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #85 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: jidanni@jidanni.org, debian-devel@lists.debian.org, 653073@bugs.debian.org

Subject: Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

Date: Wed, 18 Jan 2012 14:18:36 +0000

clone 653073 -1
retitle -1 df: [patch] Please ignore rootfs in df output
reassign -1 coreutils
thanks

On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
> jidanni@jidanni.org writes:
> 
> > Forty years of pleasant df(1) and mount(1) reading shattered in one day,
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
> 
> Any update on why the root filesystem is listed by UUID? Is that a
> problem of busybox mount reporting the long device name to the kernel
> why real mount uses the short one?

This needs to be investigated by Dan, as I requested in the report.
It's just a matter of looking at what is really happening in the
initramfs with e.g. break=init-bottom.

I'll clone this into a separate bug against df/coreutils for Joey's
rootfs patch.  The bug is not a bug in initscripts; it should be
reassigned to klibc, busybox or initramfs-tools as appropriate.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Message #92 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: "Alan Curry" <pacman-cu@kosh.dhis.org>

Cc: jidanni@jidanni.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 653073@bugs.debian.org, 10363@debbugs.gnu.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Wed, 18 Jan 2012 15:25:05 +0100

"Alan Curry" <pacman-cu@kosh.dhis.org> writes:

> jidanni@jidanni.org writes:
>> 
>>   Filesystem                                             1K-blocks    Used Available Use% Mounted on
>>   rootfs                                                   1071468  287940    729100  29% /
>>   /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78   1071468  287940    729100  29% /
>
> (I'm replying only on the issue of the duplicate mount point. Someone else
> can tackle the long ugly name.)
>
> The one with "rootfs" as its device is the initramfs which you automatically
> get with all recent kernels. Even if you aren't using an initramfs, there's
> an empty one built into the kernel which gets mounted as the first root
> filesystem. The real root gets mounted on top of that.
>
> So this is a special case of a general problem with no easy solution: What
> should df do when 2 filesystems are mounted at the same location? It can't
> easily give correct information for both of them, since the later mount
> obscures the earlier mount from view.

The problem also exists in a larger extend with chroots. There will be
lots of entries from outside the chroot that are inaccessible to a df
running inside the chroot.

What df should do is automatically skip the entries that are obscured or
generally inaccessible. Unfortunately the kernel does not (re)sort the
entries correctly following a mount --move call:

rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=491516k,nr_inodes=122879,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/s-root / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
...

Going by that list the /dev/mapper/s-root filesystems obscures the
rootfs, /sys, /proc, /dev and /dev/pts. In reality though only the
rootfs is obscured because the rest was moved prior to the initramfs
switching / around. What the kernel should do is move the relevant
entries so they appear below the filesystem they are moved to (and
before any that do obscure them, moving them to the bottom isn't always
the right solution).

So at the moment is a bit of a guess which entries are real and which
are obscured. The best you can do is check that each entry is actually a
mountpoint and guess that the last of identical mountpoints is the right
one.

> If there's a way for df to get the correct information for the lower mount, I
> don't know what it would be. If you have a process with a leftover cwd or
> open fd in the obscured filesystem, you can use that. But generally you
> won't.

There afaik isn't and there should not be a way to do so.

> But maybe we could do better than reporting incorrectly that the lower mount
> has size and usage identical to the upper mount! At least df could print a
> warning at the end if it has seen any duplicate entries. Perhaps there is
> some way it could figure out which one is on top, and print a bunch of
> question marks as the lower mount's statistics.

Maybe compare the major/minor of the device node with statfs() output.

> If df is running as root, it might be able to unshare(2) the mount namespace,
> unmount the upper level, and then statfs the mount point again to get the
> correct results for the lower level. That won't work in all cases (even in a
> private namespace you can't unmount the filesystem containing your own cwd)
> and it does nothing for you if you're not root, but still... it would be a
> cool bonus in the cases where it does work.
>
> As a special case, "rootfs" should probably be excluded from the default
> listing, since the initramfs is not very interesting most of the time. It
> could still be shown with the -a option, although it would always have the
> wrong statistics. Or if you really want to be impressive, default to showing
> the initramfs if and only if it is the only thing mounted on "/" - so you can
> run df within the initramfs before the real root is mounted and get the right
> result.

What if you only have a rootfs?

Imho the /proc/mounts file should only contain entries visible in the
processes mount namespace. So for normal systems the rootfs shouldn't
appear and in chroots the list should be even shorter.

> Or... (brace yourself for the most bold idea yet)... can you imagine a kernel
> interface that would *cleanly* give access to obscured mount points?

I fear that would let too much information escape from/into the mount
namesapces.

But there could be a /proc/global-mounts or something that is only
readable from the root namespace.

> Comments on any of the above? Do the BSDs have any bright ideas we can steal,
> or is their df as embarrassingly bad at handling obscured mount points as
> ours?

MfG
        Goswin

Message #97 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Jon Dowland <jmtd@debian.org>

To: Goswin von Brederlow <goswin-v-b@web.de>, 653073@bugs.debian.org

Subject: Re: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Wed, 18 Jan 2012 16:03:04 +0000

On Wed, Jan 18, 2012 at 03:25:05PM +0100, Goswin von Brederlow wrote:
> What df should do is automatically skip the entries that are obscured or
> generally inaccessible

I disagree.  It's quite conceivable for a user to accidentally mount two
things over the same VFS path.  When they do, they may rely on df(1)'s
output to help them untangle the mess.  If one of the two mounts is hidden,
they may not be able to fathom what they did: worse, they might tug a disk
with a mounted filesystem by accident, being unable to determine that it
was mounted.

-- 
Jon Dowland

Message #102 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Jon Dowland <jmtd@debian.org>, 653073@bugs.debian.org

Cc: Goswin von Brederlow <goswin-v-b@web.de>

Subject: Re: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Wed, 18 Jan 2012 16:51:12 +0000

On Wed, Jan 18, 2012 at 04:03:04PM +0000, Jon Dowland wrote:
> On Wed, Jan 18, 2012 at 03:25:05PM +0100, Goswin von Brederlow wrote:
> > What df should do is automatically skip the entries that are obscured or
> > generally inaccessible
> 
> I disagree.  It's quite conceivable for a user to accidentally mount two
> things over the same VFS path.  When they do, they may rely on df(1)'s
> output to help them untangle the mess.  If one of the two mounts is hidden,
> they may not be able to fathom what they did: worse, they might tug a disk
> with a mounted filesystem by accident, being unable to determine that it
> was mounted.

Is this not a case of using the wrong tool for the job?  The primary
purpose of "df" is to show free space on mounted filesystems.  This
could be interpreted to be "show free space on visible mounts".

mount(8) and findmnt(8) [new, and very nice] are more appropriate for
this task.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Message #107 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Paul Eggert <eggert@cs.ucla.edu>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Wed, 18 Jan 2012 10:12:36 -0800

On 01/18/12 06:25, Goswin von Brederlow wrote:
> What df should do is automatically skip the entries that are obscured or
> generally inaccessible.

Isn't this missing some of the larger context?  df is just doing what
lots of other programs do: finding out what file systems one has,
and reporting statistics on them.  It sounds suboptimal to require
the maintainers of all these programs (coreutils, nautilus, etc.)
to rewrite their apps to deal with obscured entries.  Surely it would
be better to have the kernel ordinarily return just the ordinary entries,
and to return obscured entries only when they are specially requested.
That way, this issue would be isolated to the few bits of code that really
want to see obscured entries.

Message #112 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Patrik Axelsson <patrik.bo@gmail.com>

To: 653073@bugs.debian.org

Subject: Re: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Thu, 19 Jan 2012 00:13:48 +0100

In addition to this, df also reports bind mounts where "Filesystem" is the device of the bind mount source and the "Mounted on" is the bind mount destination.

Is this intended? It sure is very impractical on my system with many bind mounts and it doesn't say where the bind mount originates from really.

Message #117 received at 653073@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: rleigh@codelibre.net

Cc: 653073@bugs.debian.org

Subject: Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

Date: Thu, 19 Jan 2012 07:38:44 +0800

>>>>> "RL" == Roger Leigh <rleigh@codelibre.net> writes:

RL> This needs to be investigated by Dan

Dan wishes to thank the other investigators. As I am not the best person
to investigate such deep things.

Message #122 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: Paul Eggert <eggert@cs.ucla.edu>

Cc: Goswin von Brederlow <goswin-v-b@web.de>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 10:57:22 +0100

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 01/18/12 06:25, Goswin von Brederlow wrote:
>> What df should do is automatically skip the entries that are obscured or
>> generally inaccessible.
>
> Isn't this missing some of the larger context?  df is just doing what
> lots of other programs do: finding out what file systems one has,
> and reporting statistics on them.  It sounds suboptimal to require
> the maintainers of all these programs (coreutils, nautilus, etc.)
> to rewrite their apps to deal with obscured entries.  Surely it would
> be better to have the kernel ordinarily return just the ordinary entries,
> and to return obscured entries only when they are specially requested.
> That way, this issue would be isolated to the few bits of code that really
> want to see obscured entries.

+1. Kernel knows best anyway.

MfG
        Goswin

Message #127 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: Jon Dowland <jmtd@debian.org>

Cc: Goswin von Brederlow <goswin-v-b@web.de>, 653073@bugs.debian.org

Subject: Re: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 10:55:43 +0100

Jon Dowland <jmtd@debian.org> writes:

> On Wed, Jan 18, 2012 at 03:25:05PM +0100, Goswin von Brederlow wrote:
>> What df should do is automatically skip the entries that are obscured or
>> generally inaccessible
>
> I disagree.  It's quite conceivable for a user to accidentally mount two
> things over the same VFS path.  When they do, they may rely on df(1)'s
> output to help them untangle the mess.  If one of the two mounts is hidden,
> they may not be able to fathom what they did: worse, they might tug a disk
> with a mounted filesystem by accident, being unable to determine that it
> was mounted.
>
> -- 
> Jon Dowland

"skip" could also mean show -- instead of bogus numbers for the obscured
filesystems.

MfG
        Goswin

Message #132 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Paul Eggert <eggert@cs.ucla.edu>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 09:23:00 -0200

On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
> Paul Eggert <eggert@cs.ucla.edu> writes:
> > On 01/18/12 06:25, Goswin von Brederlow wrote:
> >> What df should do is automatically skip the entries that are obscured or
> >> generally inaccessible.
> >
> > Isn't this missing some of the larger context?  df is just doing what
> > lots of other programs do: finding out what file systems one has,
> > and reporting statistics on them.  It sounds suboptimal to require
> > the maintainers of all these programs (coreutils, nautilus, etc.)
> > to rewrite their apps to deal with obscured entries.  Surely it would
> > be better to have the kernel ordinarily return just the ordinary entries,
> > and to return obscured entries only when they are specially requested.
> > That way, this issue would be isolated to the few bits of code that really
> > want to see obscured entries.
> 
> +1. Kernel knows best anyway.

The kernel has to return all entries that are visible to the current
namespace, otherwise you pretty much cannot know about the existence of
shadowed entries in the first place, and that has all sort of nasty
implications for security and troubleshooting.

The kernel should NOT include entries that are out of reach due to
namespaces or chrooting, but I don't think this is quite correct right now.

If you don't want to show to the user shadowed entries, fix it in the
UI, maybe write a nice LGPL lib and get the various GNU utils to use it
to avoid duplicated effort...  or fix it in glibc, if applicable.  But
/proc/mounts really has to return complete information.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #137 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Jon Dowland <jmtd@debian.org>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Jon Dowland <jmtd@debian.org>, 653073@bugs.debian.org

Subject: Re: ~ Re: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 11:41:22 +0000

On Thu, Jan 19, 2012 at 10:55:43AM +0100, Goswin von Brederlow wrote:
> "skip" could also mean show -- instead of bogus numbers for the obscured
> filesystems.

Much more preferable (to me)

Message #142 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Jon Dowland <jmtd@debian.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: Jon Dowland <jmtd@debian.org>, 653073@bugs.debian.org, Goswin von Brederlow <goswin-v-b@web.de>

Subject: Re: ~ Re: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 11:41:09 +0000

On Wed, Jan 18, 2012 at 04:51:12PM +0000, Roger Leigh wrote:
> Is this not a case of using the wrong tool for the job?  The primary purpose
> of "df" is to show free space on mounted filesystems.  This could be
> interpreted to be "show free space on visible mounts".

Possibly, but then I am certainly guilty of using df(1) for these purposes, and
I know of many experienced sysadmins that are the same.  I'd wager most
google-able advice on the matter would suggest df(1).

> mount(8) and findmnt(8) [new, and very nice] are more appropriate for this
> task.

Perhaps, but their manpage sections strongly imply they aren't as
generally-useful/usable as df(1), to an ordinary user. (sysadmin tools? here be
dragons!)

Message #147 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Roger Leigh <rleigh@codelibre.net>

Cc: Goswin von Brederlow <goswin-v-b@web.de>, jidanni@jidanni.org, debian-devel@lists.debian.org, 653073@bugs.debian.org

Subject: Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

Date: Thu, 19 Jan 2012 19:09:49 +0400

On 18.01.2012 18:18, Roger Leigh wrote:
> clone 653073 -1
> retitle -1 df: [patch] Please ignore rootfs in df output
> reassign -1 coreutils
> thanks
> 
> On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
>> jidanni@jidanni.org writes:
>>
>>> Forty years of pleasant df(1) and mount(1) reading shattered in one day,
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
>>
>> Any update on why the root filesystem is listed by UUID? Is that a
>> problem of busybox mount reporting the long device name to the kernel
>> why real mount uses the short one?
> 
> This needs to be investigated by Dan, as I requested in the report.
> It's just a matter of looking at what is really happening in the
> initramfs with e.g. break=init-bottom.

It is due to busybox mount, which does not perform any canonicalizing
of the device argument but passes it as-is to the kernel.  On the
contrary, mount from util-linux resolves the symlink if given as
the device name.

And initramfs does this:

init:		UUID=*)
init:			ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"

whichis later passed to busybox's mount, which happily passes
this /dev/disk/... stuff to kernel, which in turn happily
shows it in /proc/mounts.

It looks like mount from klibc does not do any canonicalisation
too, only util-linux mount does.

> I'll clone this into a separate bug against df/coreutils for Joey's
> rootfs patch.  The bug is not a bug in initscripts; it should be
> reassigned to klibc, busybox or initramfs-tools as appropriate.

It is not clear - to me anyway - if it is a bug or not.  Yes it
definitely makes df and other utils output difficult to read.

And yes it is kinda trivial to add a call to realpath(3) to
busybox (or equivalent).

Thanks,

/mjt

Message #152 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Paul Eggert <eggert@cs.ucla.edu>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net

Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 13:29:24 -0200

On Thu, 19 Jan 2012, Henrique de Moraes Holschuh wrote:
> On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
> > Paul Eggert <eggert@cs.ucla.edu> writes:
> > > On 01/18/12 06:25, Goswin von Brederlow wrote:
> > >> What df should do is automatically skip the entries that are obscured or
> > >> generally inaccessible.
> > >
> > > Isn't this missing some of the larger context?  df is just doing what
> > > lots of other programs do: finding out what file systems one has,
> > > and reporting statistics on them.  It sounds suboptimal to require
> > > the maintainers of all these programs (coreutils, nautilus, etc.)
> > > to rewrite their apps to deal with obscured entries.  Surely it would
> > > be better to have the kernel ordinarily return just the ordinary entries,
> > > and to return obscured entries only when they are specially requested.
> > > That way, this issue would be isolated to the few bits of code that really
> > > want to see obscured entries.
> > 
> > +1. Kernel knows best anyway.
> 
> The kernel has to return all entries that are visible to the current
> namespace, otherwise you pretty much cannot know about the existence of
> shadowed entries in the first place, and that has all sort of nasty
> implications for security and troubleshooting.
> 
> The kernel should NOT include entries that are out of reach due to
> namespaces or chrooting, but I don't think this is quite correct right now.
> 
> If you don't want to show to the user shadowed entries, fix it in the
> UI, maybe write a nice LGPL lib and get the various GNU utils to use it
> to avoid duplicated effort...  or fix it in glibc, if applicable.  But
> /proc/mounts really has to return complete information.

Note: there is no reason why the kernel could not return the mount
information with shadowed paths removed in a separate procfs node, as
that would cause no security/troubleshooting problems.  I do think
kernel people will tell you to fix that in userspace, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #157 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Paul Eggert <eggert@cs.ucla.edu>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: Goswin von Brederlow <goswin-v-b@web.de>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net

Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 07:48:37 -0800

On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
> Note: there is no reason why the kernel could not return the mount
> information with shadowed paths removed in a separate procfs node, as
> that would cause no security/troubleshooting problems.

That's what I was thinking of, and it'd be a much better fix,
as it would fix things for all applications.

The current approach expects all app developers to modify
their applications in order to deal with a feature that app
developers typically don't know about and don't understand;
this isn't a good way to introduce a new feature.

Message #162 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Paul Eggert <eggert@cs.ucla.edu>

Cc: Goswin von Brederlow <goswin-v-b@web.de>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net

Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 14:30:06 -0200

On Thu, 19 Jan 2012, Paul Eggert wrote:
> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
> > Note: there is no reason why the kernel could not return the mount
> > information with shadowed paths removed in a separate procfs node, as
> > that would cause no security/troubleshooting problems.
> 
> That's what I was thinking of, and it'd be a much better fix,
> as it would fix things for all applications.
> 
> The current approach expects all app developers to modify
> their applications in order to deal with a feature that app
> developers typically don't know about and don't understand;
> this isn't a good way to introduce a new feature.

On the app side, I will tell you what you're likely to get back from the
crowd on LKML:  write a proper BSD/MIT/LGPL library so that people don't
have to reinvent the wheel, and fix it in userspace.  It gets worse: such
library interface already exists, in the form of getmntent, setmntent,
addmntent, endmntent, hasmntopt, getmntent_r.  So they will tell you to fix
it in glibc.

AFAIK, the kernel is not in any better position to remove shadowed paths
than userspace, both are perfectly capable of doing it.   Now, removing
paths that are outside of the current process scope (due to namespaces or
chroot or whatever), THAT is something only the kernel can do correctly...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #167 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Roger Leigh <rleigh@codelibre.net>

Cc: Goswin von Brederlow <goswin-v-b@web.de>, jidanni@jidanni.org, debian-devel@lists.debian.org, 653073@bugs.debian.org

Subject: Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

Date: Thu, 19 Jan 2012 22:07:20 +0400

On 19.01.2012 19:09, Michael Tokarev wrote:
> On 18.01.2012 18:18, Roger Leigh wrote:
>> clone 653073 -1
>> retitle -1 df: [patch] Please ignore rootfs in df output
>> reassign -1 coreutils
>> thanks
>>
>> On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
>>> jidanni@jidanni.org writes:
>>>
>>>> Forty years of pleasant df(1) and mount(1) reading shattered in one day,
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
>>>
>>> Any update on why the root filesystem is listed by UUID? Is that a
>>> problem of busybox mount reporting the long device name to the kernel
>>> why real mount uses the short one?
>>
>> This needs to be investigated by Dan, as I requested in the report.
>> It's just a matter of looking at what is really happening in the
>> initramfs with e.g. break=init-bottom.
> 
> It is due to busybox mount, which does not perform any canonicalizing
> of the device argument but passes it as-is to the kernel.  On the
> contrary, mount from util-linux resolves the symlink if given as
> the device name.
> 
> And initramfs does this:
> 
> init:		UUID=*)
> init:			ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
> 
> whichis later passed to busybox's mount, which happily passes
> this /dev/disk/... stuff to kernel, which in turn happily
> shows it in /proc/mounts.
> 
> It looks like mount from klibc does not do any canonicalisation
> too, only util-linux mount does.
[]
> And yes it is kinda trivial to add a call to realpath(3) to
> busybox (or equivalent).

Or add readlink into initramfs-tools, for that matter.

But it is still not clear if it is a bug or not :)

/mjt

Message #172 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Paul Eggert <eggert@cs.ucla.edu>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: Alan Curry <pacman-cu@kosh.dhis.org>, Goswin von Brederlow <goswin-v-b@web.de>, 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net

Subject: Re: bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Thu, 19 Jan 2012 14:17:11 -0800

On 01/19/12 08:30, Henrique de Moraes Holschuh wrote:
> On the app side, I will tell you what you're likely to get back from the
> crowd on LKML:  write a proper BSD/MIT/LGPL library

This argument would have stronger force if there were real code in
a real application, code that solved the overall problem -- code
that we could read and run.  I don't know of any such code.

> the kernel is not in any better position to remove shadowed paths
> than userspace, both are perfectly capable of doing it.

This seems to contradict an earlier comment made by someone else,
"So at the moment is a bit of a guess which entries are real and which
are obscured." <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10363#53>

I don't know who's right, nor do I understand what all the underlying
issues are.  I expect most other app developers are in a similar boat.
It's not a good situation to be in.

Message #177 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: Goswin von Brederlow <goswin-v-b@web.de>, Paul Eggert <eggert@cs.ucla.edu>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Fri, 20 Jan 2012 08:42:26 +0100

Henrique de Moraes Holschuh <hmh@debian.org> writes:

> On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
>> Paul Eggert <eggert@cs.ucla.edu> writes:
>> > On 01/18/12 06:25, Goswin von Brederlow wrote:
>> >> What df should do is automatically skip the entries that are obscured or
>> >> generally inaccessible.
>> >
>> > Isn't this missing some of the larger context?  df is just doing what
>> > lots of other programs do: finding out what file systems one has,
>> > and reporting statistics on them.  It sounds suboptimal to require
>> > the maintainers of all these programs (coreutils, nautilus, etc.)
>> > to rewrite their apps to deal with obscured entries.  Surely it would
>> > be better to have the kernel ordinarily return just the ordinary entries,
>> > and to return obscured entries only when they are specially requested.
>> > That way, this issue would be isolated to the few bits of code that really
>> > want to see obscured entries.
>> 
>> +1. Kernel knows best anyway.
>
> The kernel has to return all entries that are visible to the current
> namespace, otherwise you pretty much cannot know about the existence of
> shadowed entries in the first place, and that has all sort of nasty
> implications for security and troubleshooting.
>
> The kernel should NOT include entries that are out of reach due to
> namespaces or chrooting, but I don't think this is quite correct right now.
>
> If you don't want to show to the user shadowed entries, fix it in the
> UI, maybe write a nice LGPL lib and get the various GNU utils to use it
> to avoid duplicated effort...  or fix it in glibc, if applicable.  But
> /proc/mounts really has to return complete information.

But isn't the rootfs out of reach because the initramfs "chroots" to the
real root and starts /sbin/init? Back when pivot_root was used that
was combined with an actual call to chroot. Before run-init combined the
two.

I'm not realy disagreeing with you but argue that the duplicate rootfs
entry is not visible to the namespace.

Same with later chroots:

mrvn@frosties:~/chroot% sudo chroot . df           
df: `/sys': No such file or directory
df: `/dev': No such file or directory
df: `/dev/pts': No such file or directory
df: `/run': No such file or directory
df: `/tmp': No such file or directory
df: `/usr': No such file or directory
df: `/var': No such file or directory
df: `/home': No such file or directory
df: `/var/lib/nfs/rpc_pipefs': No such file or directory
df: `/sys/fs/fuse/connections': No such file or directory
Filesystem         1K-blocks  Used Available Use% Mounted on
rootfs               1789128  1808   1787320   1% /
/dev/mapper/r-root   1789128  1808   1787320   1% /
tmpfs                1789128  1808   1787320   1% /

What it should show is only the last entry, the tmpfs the chroot is
on. All other entries are not visible to the processes inside the
chroot.

Note that in a chroot any mountpoints inside the chroot have their
prefix removed (/home/mrvn/chroot becomes /) while others are left as
is. That is wrong too IMHO. The filesystem the chroots / is on should
become / even if the chroot is a directory instead of a mountpoint and
entries outside the chroot should not be listed at all.

MfG
        Goswin

Message #182 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: Paul Eggert <eggert@cs.ucla.edu>, Goswin von Brederlow <goswin-v-b@web.de>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net

Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Fri, 20 Jan 2012 08:50:55 +0100

Henrique de Moraes Holschuh <hmh@debian.org> writes:

> On Thu, 19 Jan 2012, Paul Eggert wrote:
>> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
>> > Note: there is no reason why the kernel could not return the mount
>> > information with shadowed paths removed in a separate procfs node, as
>> > that would cause no security/troubleshooting problems.
>> 
>> That's what I was thinking of, and it'd be a much better fix,
>> as it would fix things for all applications.
>> 
>> The current approach expects all app developers to modify
>> their applications in order to deal with a feature that app
>> developers typically don't know about and don't understand;
>> this isn't a good way to introduce a new feature.
>
> On the app side, I will tell you what you're likely to get back from the
> crowd on LKML:  write a proper BSD/MIT/LGPL library so that people don't
> have to reinvent the wheel, and fix it in userspace.  It gets worse: such
> library interface already exists, in the form of getmntent, setmntent,
> addmntent, endmntent, hasmntopt, getmntent_r.  So they will tell you to fix
> it in glibc.

How do you decide which of two conflicting entries is real? Since mount
--move does not change the order of entries you can not just pick the
last one.

For example which entry is the right one with an output like this:

tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0
tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0

I don't think this can be fixed in userspace alone. At a minimum the
kernel has to keep entries in order of visibility, i.e. the later
entries always shadow earlier entries. Which means that on mount --move
the kernel has to move the entry in /proc/mounts up or down as needed.

MfG
        Goswin

PS: I think you can also mount something below an already shadowed entry
(if you have a shell with cwd in the shadowed one) and it would show up
in the wrong spot in /proc/mounts.

Message #187 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: Roger Leigh <rleigh@codelibre.net>, Goswin von Brederlow <goswin-v-b@web.de>, jidanni@jidanni.org, debian-devel@lists.debian.org, 653073@bugs.debian.org

Subject: Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

Date: Fri, 20 Jan 2012 08:55:16 +0100

Michael Tokarev <mjt@tls.msk.ru> writes:

> On 19.01.2012 19:09, Michael Tokarev wrote:
>> On 18.01.2012 18:18, Roger Leigh wrote:
>>> clone 653073 -1
>>> retitle -1 df: [patch] Please ignore rootfs in df output
>>> reassign -1 coreutils
>>> thanks
>>>
>>> On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
>>>> jidanni@jidanni.org writes:
>>>>
>>>>> Forty years of pleasant df(1) and mount(1) reading shattered in one day,
>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
>>>>
>>>> Any update on why the root filesystem is listed by UUID? Is that a
>>>> problem of busybox mount reporting the long device name to the kernel
>>>> why real mount uses the short one?
>>>
>>> This needs to be investigated by Dan, as I requested in the report.
>>> It's just a matter of looking at what is really happening in the
>>> initramfs with e.g. break=init-bottom.
>> 
>> It is due to busybox mount, which does not perform any canonicalizing
>> of the device argument but passes it as-is to the kernel.  On the
>> contrary, mount from util-linux resolves the symlink if given as
>> the device name.
>> 
>> And initramfs does this:
>> 
>> init:		UUID=*)
>> init:			ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
>> 
>> whichis later passed to busybox's mount, which happily passes
>> this /dev/disk/... stuff to kernel, which in turn happily
>> shows it in /proc/mounts.
>> 
>> It looks like mount from klibc does not do any canonicalisation
>> too, only util-linux mount does.
> []
>> And yes it is kinda trivial to add a call to realpath(3) to
>> busybox (or equivalent).
>
> Or add readlink into initramfs-tools, for that matter.
>
> But it is still not clear if it is a bug or not :)
>
> /mjt

As a side note: With LVM you get entries like:

/dev/mapper/r-usr       7224824     6392404     465460  94% /usr

I would much rather have:

/dev/r/usr       7224824     6392404     465460  94% /usr


But I guess the solution for this would be to have udev make /dev/r/usr
the real device and /dev/mapper/r-usr a symlink.


What result does "LABEL=..." get?

MfG
        Goswin

Message #192 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Roger Leigh <rleigh@codelibre.net>, jidanni@jidanni.org, debian-devel@lists.debian.org, 653073@bugs.debian.org

Subject: Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

Date: Fri, 20 Jan 2012 13:19:00 +0400

On 20.01.2012 11:55, Goswin von Brederlow wrote:
[]
>>> And yes it is kinda trivial to add a call to realpath(3) to
>>> busybox (or equivalent).
>>
>> Or add readlink into initramfs-tools, for that matter.
>>
>> But it is still not clear if it is a bug or not :)
> 
> As a side note: With LVM you get entries like:
> 
> /dev/mapper/r-usr       7224824     6392404     465460  94% /usr
> 
> I would much rather have:
> 
> /dev/r/usr       7224824     6392404     465460  94% /usr

> But I guess the solution for this would be to have udev make /dev/r/usr
> the real device and /dev/mapper/r-usr a symlink.

Exactly.  And note that actually, these are dm devices, which
usually appear as /dev/dm-N (cf. multipath devices created by
multipathd - they symlink from /dev/mapper/name to /dev/dm-N).

And this is an interesting place.

The "problem" is that kernel does not know what /dev/mapper
is, or what does /dev/r/usr thing mean.  It knows these by
their canonical (and meaningless) dm-N names, like this:

[    6.887981] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
[    6.917555] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: usrquota

Go figure which is dm-0 and which is dm-1 (lvm is here)!

There are references to these dm-N names in /proc/partitions
and in /sys and elsewhere, too.

I consider this a bug, a quite serious one at it: there's
no device node which corresponds to kernel names!  So it is
impossible to get, eg, device usage statistics for a
particular volume, or map i/o error to particular dvice and
so on.  This is wrong.

But this is a different problem entirely.

My point is that actually, _both_ /dev/mapper/r-usr and
/dev/r/usr are wrong!  But at least they - hopefully -
lead to the actual device, unlike kernel messages I
mentioned above which leads to nothing due to /dev/dm-0
non-existing.

> What result does "LABEL=..." get?

It is exactly the same as with UUID=.  For both of these,
util-linux mount will canonicalize the name to final
device (like /dev/sda1 or /dev/dm-0 or /dev/mapper/r-usr
as in your case), be it LABEL= or /dev/disk/by-label/LABEL.
While neither busybox nor klibc will do that.  Besides,
klibc does not support LABEL or UUID, in busybox it is
optional (compile-time), and it will do its own resolution
of LABEL/UUID, without using /dev/disk/by-*/.

In initramfs, both are handled the same way
(omiting some details for brevity):

initramfs:init:
                case $ROOT in
                LABEL=*)
                        ROOT="${ROOT#LABEL=}"
                        ROOT="/dev/disk/by-label/${ROOT}"
                        ;;
                UUID=*)
                        ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
                        ;;

So this gives /dev/disk/... arg to mount, be it from
busybox or klibc, and neither calls realpath(3).

Thanks,

/mjt

Message #197 received at 653073@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

Cc: debian-devel@lists.debian.org, 653073@bugs.debian.org

Subject: Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

Date: Fri, 20 Jan 2012 12:04:33 +0100

[Message part 1 (text/plain, inline)]

On Jan 20, Goswin von Brederlow <goswin-v-b@web.de> wrote:

> But I guess the solution for this would be to have udev make /dev/r/usr
> the real device and /dev/mapper/r-usr a symlink.
No, because udev does not creates/renames devices anymore.
(This makes devtmpfs mandatory, BTW.)

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #202 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Andreas Schwab <schwab@linux-m68k.org>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Henrique de Moraes Holschuh <hmh@debian.org>, Paul Eggert <eggert@cs.ucla.edu>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Fri, 20 Jan 2012 12:10:23 +0100

Goswin von Brederlow <goswin-v-b@web.de> writes:

> Note that in a chroot any mountpoints inside the chroot have their
> prefix removed (/home/mrvn/chroot becomes /) while others are left as
> is. That is wrong too IMHO. The filesystem the chroots / is on should
> become / even if the chroot is a directory instead of a mountpoint and
> entries outside the chroot should not be listed at all.

You can get such a view from /proc/self/mountinfo.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #207 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Paul Eggert <eggert@cs.ucla.edu>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net

Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Fri, 20 Jan 2012 15:28:19 -0200

On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > On Thu, 19 Jan 2012, Paul Eggert wrote:
> >> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
> >> > Note: there is no reason why the kernel could not return the mount
> >> > information with shadowed paths removed in a separate procfs node, as
> >> > that would cause no security/troubleshooting problems.
> >> 
> >> That's what I was thinking of, and it'd be a much better fix,
> >> as it would fix things for all applications.
> >> 
> >> The current approach expects all app developers to modify
> >> their applications in order to deal with a feature that app
> >> developers typically don't know about and don't understand;
> >> this isn't a good way to introduce a new feature.
> >
> > On the app side, I will tell you what you're likely to get back from the
> > crowd on LKML:  write a proper BSD/MIT/LGPL library so that people don't
> > have to reinvent the wheel, and fix it in userspace.  It gets worse: such
> > library interface already exists, in the form of getmntent, setmntent,
> > addmntent, endmntent, hasmntopt, getmntent_r.  So they will tell you to fix
> > it in glibc.
> 
> How do you decide which of two conflicting entries is real? Since mount
> --move does not change the order of entries you can not just pick the
> last one.
> 
> For example which entry is the right one with an output like this:
> 
> tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0
> tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0
> 
> I don't think this can be fixed in userspace alone. At a minimum the
> kernel has to keep entries in order of visibility, i.e. the later
> entries always shadow earlier entries. Which means that on mount --move
> the kernel has to move the entry in /proc/mounts up or down as needed.

Yes, it would have to order in that way.

> PS: I think you can also mount something below an already shadowed entry
> (if you have a shell with cwd in the shadowed one) and it would show up
> in the wrong spot in /proc/mounts.

I believe that's correct, and should be fixed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #212 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Goswin von Brederlow <goswin-v-b@web.de>

Cc: Paul Eggert <eggert@cs.ucla.edu>, Alan Curry <pacman-cu@kosh.dhis.org>, 653073@bugs.debian.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org

Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Date: Fri, 20 Jan 2012 15:41:28 -0200

On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > The kernel has to return all entries that are visible to the current
> > namespace, otherwise you pretty much cannot know about the existence of
> > shadowed entries in the first place, and that has all sort of nasty
> > implications for security and troubleshooting.
> >
> > The kernel should NOT include entries that are out of reach due to
> > namespaces or chrooting, but I don't think this is quite correct right now.

...

> But isn't the rootfs out of reach because the initramfs "chroots" to the
> real root and starts /sbin/init? Back when pivot_root was used that
> was combined with an actual call to chroot. Before run-init combined the
> two.

That's what I meant with "I don't think this is quite correct right
now".

> I'm not realy disagreeing with you but argue that the duplicate rootfs
> entry is not visible to the namespace.

I am not sure how /proc/mounts and friends should play with chroot().  I
suppose it depends on whether one can actually reach that path somehow.
If it is forever unacessible, IMO it is effectively outside the
namespace and I believe it should not be visible.  But that's where I
reach the limits of my knowledge, and I can't really argue about it.

> What it should show is only the last entry, the tmpfs the chroot is
> on. All other entries are not visible to the processes inside the
> chroot.

I think you're correct in this.

> Note that in a chroot any mountpoints inside the chroot have their
> prefix removed (/home/mrvn/chroot becomes /) while others are left as
> is. That is wrong too IMHO. The filesystem the chroots / is on should
> become / even if the chroot is a directory instead of a mountpoint and
> entries outside the chroot should not be listed at all.

I also think you're correct here, but as I said, chroot() is tricky, and
I am wary of arguing too much about it without strong knowledge about
the nuances, which I don't have.

Maybe this thread really ought to move to linux-fsdevel or LKML?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #217 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Matthieu CASTET <matthieu.castet@parrot.com>

To: Debian Bug Tracking System <653073@bugs.debian.org>

Subject: Re: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Mon, 20 Feb 2012 10:53:02 +0100

Package: initscripts
Version: 2.88dsf-22
Followup-For: Bug #653073

This happen even if there no uuid mount in fstat :

$ LC_ALL=C df
Filesystem                                              1K-blocks       Used  Available Use% Mounted on
rootfs                                                   19228308   15989032    2262524  88% /
udev                                                      1795456          0    1795456   0% /dev
tmpfs                                                      360312        344     359968   1% /run
/dev/disk/by-uuid/5f80d55a-8b6a-42c1-a9ab-0979e1a875f8   19228308   15989032    2262524  88% /
tmpfs                                                        5120          0       5120   0% /run/lock
tmpfs                                                      720620        132     720488   1% /run/shm
/dev/sdc4


$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sdc2       /               ext3    defaults,errors=remount-ro 0       1
[...]

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages initscripts depends on:
ii  coreutils       8.13-3
ii  debianutils     4.2.1
ii  libc6           2.13-26
ii  lsb-base        3.2-28.1
ii  mount           2.20.1-1.2
ii  sysv-rc         2.88dsf-22
ii  sysvinit-utils  2.88dsf-22
ii  ucf             3.0025+nmu2

Versions of packages initscripts recommends:
ii  e2fsprogs  1.42-1
ii  psmisc     22.15-2

initscripts suggests no packages.

-- no debconf information

Message #222 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Ognyan Kulev <ogi@tower.3.bg>

To: 653073@bugs.debian.org

Subject: Solved for me

Date: Wed, 19 Sep 2012 13:45:19 +0300

Hi :-)

I successfully solved the issue by:

1. setting label (tune2fs -L root /dev/...) for root fs
2. patching /etc/grub.d/10_linux using the small patch in 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542170
3. adding GRUB_ENABLE_LINUX_LABEL=true to /etc/default/grub
4. running update-grub and rebooting

Now df shows the much shorter "/dev/disk/by-label/root" :-)

Regards,
Ognyan Kulev

Message #227 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Samuel Bronson <naesten@gmail.com>

To: Matthieu CASTET <matthieu.castet@parrot.com>, 653073@bugs.debian.org

Cc: 653073@bugs.debian.org

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Thu, 08 Nov 2012 12:30:48 -0500

Control: tags -1 + fixed-upstream
Control: severity -1 important

It seems that this was worked-around upstream in
<http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1e18d8416f9ef43bf08982cabe54220587061a08>.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Message #236 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Samuel Bronson <naesten@gmail.com>, 653073@bugs.debian.org

Cc: Matthieu CASTET <matthieu.castet@parrot.com>

Subject: Re: Bug#653073: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Thu, 8 Nov 2012 21:44:16 +0000

reassign 653073 coreutils
found 653073 6.10-6
thanks

On Thu, Nov 08, 2012 at 12:30:48PM -0500, Samuel Bronson wrote:
> Control: tags -1 + fixed-upstream
> Control: severity -1 important
> 
> It seems that this was worked-around upstream in
> <http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1e18d8416f9ef43bf08982cabe54220587061a08>.

Thanks.

Reassigning to coreutils, since this isn't a sysvinit issue.  Setting
version back to oldstable, since this is present in all releases to
date.


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

Message #247 received at 653073-close@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 653073-close@bugs.debian.org

Subject: Bug#653073: fixed in coreutils 8.20-1

Date: Wed, 14 Nov 2012 04:17:37 +0000

Source: coreutils
Source-Version: 8.20-1

We believe that the bug you reported is fixed in the latest version of
coreutils, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 653073@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Stone <mstone@debian.org> (supplier of updated coreutils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 13 Nov 2012 20:49:45 -0500
Source: coreutils
Binary: coreutils mktemp
Architecture: source all amd64
Version: 8.20-1
Distribution: unstable
Urgency: low
Maintainer: Michael Stone <mstone@debian.org>
Changed-By: Michael Stone <mstone@debian.org>
Description: 
 coreutils  - GNU core utilities
 mktemp     - coreutils mktemp transitional package
Closes: 653073 685238 693171
Changes: 
 coreutils (8.20-1) unstable; urgency=low
 .
   * New upstream version
     - fixes possible data loss in sort -u (from 8.6) (Closes: #685238)
     - df prefers shorter device names (Closes: #653073)
   * Update watch file (Closes: #693171)
Checksums-Sha1: 
 42387fe372d856c49275967593cf58c15c14e55e 1854 coreutils_8.20-1.dsc
 92dd4188c2f763f85e20d7e9bfb92ae8f14552d7 12091321 coreutils_8.20.orig.tar.gz
 5cd8570c658e92fa1eb0d81fc0041d5f7837575c 22519 coreutils_8.20-1.diff.gz
 e842f344dac539ba01c36ccbe5cf08a004c6b962 16292 mktemp_8.20-1_all.deb
 ba818016e15890e54a63ee8e884b2a1506ef8859 5806492 coreutils_8.20-1_amd64.deb
Checksums-Sha256: 
 e60e73135d6e7fd50d8761332d1510fbe7e42d7d5c0ced59759457666581a06f 1854 coreutils_8.20-1.dsc
 b0a4d968cf40bce9544814b4b4c6243b5b76cfd05e2f48b8611e5c6d1126ec78 12091321 coreutils_8.20.orig.tar.gz
 84526a23fbd01fbe4666e4c9f63e92fd03dce0a82e63621b3e7c6467fecb5023 22519 coreutils_8.20-1.diff.gz
 03d87d50da98d64a54e470b8693fc8e7fb11c8fbe1c246a152af862b806dca5e 16292 mktemp_8.20-1_all.deb
 c2871c7baa9dbbafbcec77d5f97da8e308d19fdb25015054ac5185de12b08640 5806492 coreutils_8.20-1_amd64.deb
Files: 
 bf2d287869ec29bcf7ff6d90a2622009 1854 utils required coreutils_8.20-1.dsc
 e0f07479a149b693c0648172b6a92337 12091321 utils required coreutils_8.20.orig.tar.gz
 9561cc8ebcf3b656dd863767bcfe7323 22519 utils required coreutils_8.20-1.diff.gz
 02552180c80a140d5c9f8b5b3c911543 16292 oldlibs extra mktemp_8.20-1_all.deb
 0f1996df7f3021712bf3f4fd4f17abe1 5806492 utils required coreutils_8.20-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUBUKMXCfYarNz6Ef/eAQhYnA/6A5wYLZzmduKZ63HBL2azkM4MV+9Uw42e
bv0NwQQr6feVV6RVLOT585m4M1J1KEe2/SY9gQQuXEGJQ87ek0BNCmj2RguGI4Qa
bkNeFbwIfRFpafRn6fkgDAL6fmdBsj74G+V/CNkA0t9IFfrgWgUiNYpG443UKacZ
n3j9C+l0d0viF7EoQLroThwmomjnQZ3RQ0gbKOnNoxRWowgpp48m/JXurKTgkNPd
xUNAEQcTJ0m0RYKJpJBRAZsSJRlST8sgvVGWFwXEDpVY6BXwUg3GXAC9PbtgaWRf
oSR4VOL7p9Wa23fwbfCheYVFgXBhb68Hyp06ckLdh2dLwOOHm8eC6vg74fUTnb/t
LKWWjsZfno5noCPAs8GRp5I6dMi+6XN5lbLcTC26u4fM5LvNbzSZ5IYGUJRtFMEl
0o0n+ZVM4i62usehctKrsPoSao33RgG9be6segqOuMvep5wSBNJvLdX0sJE2le1n
XlABk4BeqzdTvaudaeJRPboW0DIzFyZbgokb4qDgutdvNKEixuiTpYO1wutiE/9G
U1qOXIPmlwRrfgJPI1YqPfgXOJSFJwk0FY8QQIZiqU4o46cIQidum/lK+l8ptKUa
kQ0K68ewGuOmpaQigofqv3qlM6xlkVzXyQVeC8ief5bh5evzJqGTcHAaoRmHiA9v
01yghKG+RIc=
=WK1w
-----END PGP SIGNATURE-----

Message #252 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Andreas Stempfhuber <reportbug2013@afulinux.de>

To: 653073@bugs.debian.org, Michael Stone <mstone@debian.org>

Subject: why root filesystem reported as /dev/disk/by-uuid/ long name starting today?

Date: Wed, 13 Feb 2013 22:57:29 +0100

Hi,

unfortunately the build of coreutils 8.20-1 has not made it to i386 and other 
architectures.

Also Wheezy is affected by this issue. Any chance that this get fixed in 
Wheezy as well?

Thanks

Andi

Message #257 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Chris Frey <cdfrey@foursquare.net>

To: 653073@bugs.debian.org, reportbug2013@afulinux.de, mstone@debian.org

Subject: df still using uuid in wheezy

Date: Fri, 5 Apr 2013 19:44:55 -0400

Hi,

Just a reminder that as of 2013/04/05, this behaviour still exists in
Wheezy.

Are there plans to fix it before release?

Thanks,
- Chris

Message #262 received at 653073@bugs.debian.org (full text, mbox, reply):

From: Michael Jensen <gu2764@gmail.com>

To: 653073@bugs.debian.org

Subject: Not solved root filesystem reported as /dev/disk/by-uuid/ long name

Date: Wed, 17 Jul 2013 14:22:16 +0200

[Message part 1 (text/plain, inline)]

Hello,

On 2012-11-14

> We believe that the bug you reported is fixed in the latest version of
> coreutils, which is due to be installed in the Debian FTP archive.

This seems not to be the case. The problem exists in "Testing" as of today.
Can you please reopen it and check where the changes went?

Best regards,
Michael

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.