util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Discrepancies between real and symlinked mtab
@ 2012-10-30 23:03 Matt Burgess
  2012-10-31  7:59 ` Bernhard Voelker
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Matt Burgess @ 2012-10-30 23:03 UTC (permalink / raw)
  To: util-linux

Hi,

Consider trying to answer the question "What partition is mounted
on /" (it happens to be /dev/sda3 in this example), when /etc/mtab is a
symlink pointing to /proc/mounts:

1) mount(8)

/dev/root on / type ext3 (rw,relatime,data=ordered)

Nope, that's not /dev/sda3.  And what is /dev/root anyway? There's no
such node under /dev here.

2) df(1)

Filesystem     1K-blocks    Used Available Use% Mounted on
rootfs          20642428 1576788  18017064   9% /
/dev/root       20642428 1576788  18017064   9% /

Uh-oh - now I appear to have 2 filesystems mounted at '/' (yes, I know
you can tell by the same stats that it is in fact the same FS).  What is
this rootfs entry?

3) lsblk(8)

NAME FSTYPE LABEL UUID                                 MOUNTPOINT
sda3 ext3   /lfs  aaf09e8b-d50e-429e-ba8e-11fa07ab5b75 

Well, that's odd.  I know that /dev/sda3 is mounted at /, but apparently
lsblk(8) doesn't!

If /etc/mtab is a real file, then the output of all 3 commands is
correct (and by that I mean it shows /dev/sda3).

As all 3 utils show the same issue, I assume this is something to do
with libblkid?

Thanks,

Matt.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Discrepancies between real and symlinked mtab
  2012-10-30 23:03 Discrepancies between real and symlinked mtab Matt Burgess
@ 2012-10-31  7:59 ` Bernhard Voelker
  2012-10-31 12:24 ` Karel Zak
  2012-11-08 13:48 ` Karel Zak
  2 siblings, 0 replies; 7+ messages in thread
From: Bernhard Voelker @ 2012-10-31  7:59 UTC (permalink / raw)
  To: Matt Burgess; +Cc: util-linux

Hi Matt,

On 10/31/2012 12:03 AM, Matt Burgess wrote:
> Consider trying to answer the question "What partition is mounted
> on /" (it happens to be /dev/sda3 in this example), when /etc/mtab is a
> symlink pointing to /proc/mounts:

I'll only answer for df here because it is not part of util-linux,
but rather in the coreutils package.

> 2) df(1)
> 
> Filesystem     1K-blocks    Used Available Use% Mounted on
> rootfs          20642428 1576788  18017064   9% /
> /dev/root       20642428 1576788  18017064   9% /
> 
> Uh-oh - now I appear to have 2 filesystems mounted at '/' (yes, I know
> you can tell by the same stats that it is in fact the same FS).  What is
> this rootfs entry?

That rootfs entry comes from early boot time when '/' is mounted on
itself.

BTW there is already a discussion on the coreutils ML about this:

http://www.mail-archive.com/coreutils@gnu.org/msg03582.html

> As all 3 utils show the same issue, I assume this is something to do
> with libblkid?

No, df doesn't use libblkid. It uses gnulib's function
  read_file_system_list ()
to read the mount list.

Have a nice day,
Berny

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Discrepancies between real and symlinked mtab
  2012-10-30 23:03 Discrepancies between real and symlinked mtab Matt Burgess
  2012-10-31  7:59 ` Bernhard Voelker
@ 2012-10-31 12:24 ` Karel Zak
  2012-10-31 12:46   ` Kay Sievers
  2012-11-08 13:48 ` Karel Zak
  2 siblings, 1 reply; 7+ messages in thread
From: Karel Zak @ 2012-10-31 12:24 UTC (permalink / raw)
  To: Matt Burgess; +Cc: util-linux

On Tue, Oct 30, 2012 at 11:03:59PM +0000, Matt Burgess wrote:
> 1) mount(8)
> 
> /dev/root on / type ext3 (rw,relatime,data=ordered)

 I see (Fedora 17, util-linux 2.21.2)

   /dev/sda4 on / type ext4 (rw,relatime,data=ordered)

anyway, it's not mount(8) responsibility what you have in /proc/mounts
or /proc/self/mountinfo.

> Nope, that's not /dev/sda3.  And what is /dev/root anyway? There's no
> such node under /dev here.

if I good remember there was symlink in some distributions

> 3) lsblk(8)
> 
> NAME FSTYPE LABEL UUID                                 MOUNTPOINT
> sda3 ext3   /lfs  aaf09e8b-d50e-429e-ba8e-11fa07ab5b75 

I see:

 $ lsblk --fs /dev/sda4
 NAME FSTYPE LABEL UUID                                 MOUNTPOINT
 sda4 ext4         33230ae2-1093-4353-824c-f7ca09a2a882 /

> As all 3 utils show the same issue, I assume this is something to do
> with libblkid?

We use libmount to get information about mountpoints. The libblkid is
responsible for information about filesystems (LABEL, UUID, ...).


    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Discrepancies between real and symlinked mtab
  2012-10-31 12:24 ` Karel Zak
@ 2012-10-31 12:46   ` Kay Sievers
  2012-10-31 14:33     ` Karel Zak
  0 siblings, 1 reply; 7+ messages in thread
From: Kay Sievers @ 2012-10-31 12:46 UTC (permalink / raw)
  To: Karel Zak; +Cc: Matt Burgess, util-linux

On Wed, Oct 31, 2012 at 1:24 PM, Karel Zak <kzak@redhat.com> wrote:
> On Tue, Oct 30, 2012 at 11:03:59PM +0000, Matt Burgess wrote:

>> 1) mount(8)
>>
>> /dev/root on / type ext3 (rw,relatime,data=ordered)
>
>  I see (Fedora 17, util-linux 2.21.2)

>    /dev/sda4 on / type ext4 (rw,relatime,data=ordered)

We see that only if we use an initramfs. In case the kernel mounts the
fs directly and internally, there is /dev/root showing up.

>> Nope, that's not /dev/sda3.  And what is /dev/root anyway? There's no
>> such node under /dev here.

The kernel creates that node in its own 'rootfs' names filesystem, the
parent of the entire filesystem mount tree; but this is never visible
anywhere in the real system, and never was.

Ideally, the kernel would be fixed to use the root= string, and not
invent a name that does never exist.

> if I good remember there was symlink in some distributions

Some distributions created /dev/root with udev rules which have been
composed at bootup. We dropped all that, because it is logic backwards
and nothing on the system should rely on /dev/root being available.
Modern filesystems like btrfs do not follow the "there is a single
device below that mountpoint logic".

Kay

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Discrepancies between real and symlinked mtab
  2012-10-31 12:46   ` Kay Sievers
@ 2012-10-31 14:33     ` Karel Zak
  0 siblings, 0 replies; 7+ messages in thread
From: Karel Zak @ 2012-10-31 14:33 UTC (permalink / raw)
  To: Kay Sievers; +Cc: Matt Burgess, util-linux

On Wed, Oct 31, 2012 at 01:46:43PM +0100, Kay Sievers wrote:
> On Wed, Oct 31, 2012 at 1:24 PM, Karel Zak <kzak@redhat.com> wrote:
> > On Tue, Oct 30, 2012 at 11:03:59PM +0000, Matt Burgess wrote:
> 
> >> 1) mount(8)
> >>
> >> /dev/root on / type ext3 (rw,relatime,data=ordered)
> >
> >  I see (Fedora 17, util-linux 2.21.2)
> 
> >    /dev/sda4 on / type ext4 (rw,relatime,data=ordered)
> 
> We see that only if we use an initramfs. In case the kernel mounts the
> fs directly and internally, there is /dev/root showing up.

 Ah, good point.

> >> Nope, that's not /dev/sda3.  And what is /dev/root anyway? There's no
> >> such node under /dev here.
> 
> The kernel creates that node in its own 'rootfs' names filesystem, the
> parent of the entire filesystem mount tree; but this is never visible
> anywhere in the real system, and never was.
> 
> Ideally, the kernel would be fixed to use the root= string, and not
> invent a name that does never exist.

 Yes, hmm... I'll try to improve libmount to convert /dev/root to
 something usable.

> > if I good remember there was symlink in some distributions
> 
> Some distributions created /dev/root with udev rules which have been
> composed at bootup. We dropped all that, because it is logic backwards
> and nothing on the system should rely on /dev/root being available.
> Modern filesystems like btrfs do not follow the "there is a single
> device below that mountpoint logic".

 I guess it's still necessary to use some magic btrfs ioctls to get
 info about the filesystem, right? It would be nice to have something
 in /sys/fs/btrfs.

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Discrepancies between real and symlinked mtab
  2012-10-30 23:03 Discrepancies between real and symlinked mtab Matt Burgess
  2012-10-31  7:59 ` Bernhard Voelker
  2012-10-31 12:24 ` Karel Zak
@ 2012-11-08 13:48 ` Karel Zak
  2012-11-08 13:54   ` Matthew Burgess
  2 siblings, 1 reply; 7+ messages in thread
From: Karel Zak @ 2012-11-08 13:48 UTC (permalink / raw)
  To: Matt Burgess; +Cc: util-linux

On Tue, Oct 30, 2012 at 11:03:59PM +0000, Matt Burgess wrote:
> 1) mount(8)
> 
> /dev/root on / type ext3 (rw,relatime,data=ordered)

 I have improved libmount and now it returns the real device name if
 the file /proc/cmdline contains root= option.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Discrepancies between real and symlinked mtab
  2012-11-08 13:48 ` Karel Zak
@ 2012-11-08 13:54   ` Matthew Burgess
  0 siblings, 0 replies; 7+ messages in thread
From: Matthew Burgess @ 2012-11-08 13:54 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On Thu, 8 Nov 2012 14:48:01 +0100, Karel Zak <kzak@redhat.com> wrote:
> On Tue, Oct 30, 2012 at 11:03:59PM +0000, Matt Burgess wrote:
>> 1) mount(8)
>>
>> /dev/root on / type ext3 (rw,relatime,data=ordered)
> 
>  I have improved libmount and now it returns the real device name if
>  the file /proc/cmdline contains root= option.

Thanks, Karel!

Regards,

Matt.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-11-08 13:54 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-30 23:03 Discrepancies between real and symlinked mtab Matt Burgess
2012-10-31  7:59 ` Bernhard Voelker
2012-10-31 12:24 ` Karel Zak
2012-10-31 12:46   ` Kay Sievers
2012-10-31 14:33     ` Karel Zak
2012-11-08 13:48 ` Karel Zak
2012-11-08 13:54   ` Matthew Burgess

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).