FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-18-2012, 07:02 PM
"brian m. carlson"
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

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?

It's due to the libata transition. Since drives that might formerly
have been hd? are now sd?, there was a debconf question to ask to
convert them all into UUIDs. Then it doesn't matter which driver (ide
or libata or something else entirely) is being used.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 01-18-2012, 07:10 PM
Ben Hutchings
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

On Wed, Jan 18, 2012 at 08:02:03PM +0000, brian m. carlson wrote:
> 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?
>
> It's due to the libata transition. Since drives that might formerly
> have been hd? are now sd?, there was a debconf question to ask to
> convert them all into UUIDs. Then it doesn't matter which driver (ide
> or libata or something else entirely) is being used.

...or whether you have a USB storage device plugged in at boot.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120118201029.GC12704@decadent.org.uk">http://lists.debian.org/20120118201029.GC12704@decadent.org.uk
 
Old 01-19-2012, 02:09 PM
Michael Tokarev
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F18323D.60505@msgid.tls.msk.ru">http://lists.debian.org/4F18323D.60505@msgid.tls.msk.ru
 
Old 01-19-2012, 05:07 PM
Michael Tokarev
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F185BD8.5020201@msgid.tls.msk.ru">http://lists.debian.org/4F185BD8.5020201@msgid.tls.msk.ru
 
Old 01-20-2012, 06:55 AM
Goswin von Brederlow
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vco6lsez.fsf@frosties.localnet">http://lists.debian.org/87vco6lsez.fsf@frosties.localnet
 
Old 01-20-2012, 08:19 AM
Michael Tokarev
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F193184.4050104@msgid.tls.msk.ru">http://lists.debian.org/4F193184.4050104@msgid.tls.msk.ru
 
Old 01-20-2012, 09:21 AM
Roger Leigh
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

On Fri, Jan 20, 2012 at 01:19:00PM +0400, Michael Tokarev wrote:
> 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)!
>
> 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.

At least on my system (udev), they certainly do exist, for example:

% ls -l /dev/mapper/ravenclaw-root
lrwxrwxrwx 1 root root 7 Jan 20 09:01 /dev/mapper/ravenclaw-root -> ../dm-0
% ls -l /dev/ravenclaw/root
lrwxrwxrwx 1 root root 7 Jan 20 09:01 /dev/ravenclaw/root -> ../dm-0
% ls -l /dev/dm-0
brw-rw---T 1 root disk 253, 0 Jan 20 09:01 /dev/dm-0

So the dm-n devices all do exist, and one can work out which
logical volume each represent by looking at the symlinks.


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.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120120102102.GF8797@codelibre.net">http://lists.debian.org/20120120102102.GF8797@codelibre.net
 
Old 01-20-2012, 10:04 AM
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

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
 
Old 01-20-2012, 02:50 PM
Michael Tokarev
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

On 20.01.2012 14:21, Roger Leigh wrote:
> On Fri, Jan 20, 2012 at 01:19:00PM +0400, Michael Tokarev wrote:
>> 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)!
>>
>> 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.
>
> At least on my system (udev), they certainly do exist, for example:
>
> % ls -l /dev/mapper/ravenclaw-root
> lrwxrwxrwx 1 root root 7 Jan 20 09:01 /dev/mapper/ravenclaw-root -> ../dm-0

Aha. I was looking at squeeze version where they didnt.

So Goswin, instead of getting a more preferred for him /dev/r/usr,
will get /dev/dm-1

Thanks,

/mjt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F198D39.3060507@msgid.tls.msk.ru">http://lists.debian.org/4F198D39.3060507@msgid.tls.msk.ru
 
Old 01-26-2012, 10:13 AM
Goswin von Brederlow
 
Default Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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?
>
> It's due to the libata transition. Since drives that might formerly
> have been hd? are now sd?, there was a debconf question to ask to
> convert them all into UUIDs. Then it doesn't matter which driver (ide
> or libata or something else entirely) is being used.

That is why there now is an UUID in /etc/fstab. That wasn't the
question.

Anyway, the answere was that busybox mount does not canonicalize the
device name. Only mount from util-linux does.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k44e7m3n.fsf@frosties.localnet">http://lists.debian.org/87k44e7m3n.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 10:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org