* new mount is broken w/regard to devnames in /etc/fstab
@ 2013-05-18 23:02 Linda Walsh
2013-05-20 7:53 ` Karel Zak
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Linda Walsh @ 2013-05-18 23:02 UTC (permalink / raw)
To: util-linux, LKML
There are 2 problems -- they are unlikely to be
directly related, but are in so much as they are in the new version
of mount.
1) How is one supposed to get the real root device?
It's not /dev/root -- and on my system /dev/root doesn't even exist.
(though to be fair, it has in the past -- udev musta got sloppy this time,
and did point to the real root device). But how can I get /proc to display
the real root device instead of some fake name.
It's insecure the way it is -- as /dev/root could be "anything"...
2) I'd like lvm's naming to be available through mount. Ideally, lvm's
naming would be available in /proc/mounts... At least, though
in going from /dev/VG/LV => /dev/mapper/VG-LV, that can be
scripted reliably to get the mount device name.
But /dev/root?... How to script that, *reliably*...
And why the bogus name?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: new mount is broken w/regard to devnames in /etc/fstab
2013-05-18 23:02 new mount is broken w/regard to devnames in /etc/fstab Linda Walsh
@ 2013-05-20 7:53 ` Karel Zak
2013-05-20 8:03 ` Helmut Hullen
2013-05-21 2:28 ` Helmut Hullen
2 siblings, 0 replies; 8+ messages in thread
From: Karel Zak @ 2013-05-20 7:53 UTC (permalink / raw)
To: Linda Walsh; +Cc: util-linux, LKML
On Sat, May 18, 2013 at 04:02:02PM -0700, Linda Walsh wrote:
> 1) How is one supposed to get the real root device?
> It's not /dev/root -- and on my system /dev/root doesn't even exist.
> (though to be fair, it has in the past -- udev musta got sloppy this time,
> and did point to the real root device). But how can I get /proc to display
> the real root device instead of some fake name.
>
> It's insecure the way it is -- as /dev/root could be "anything"...
I don't think this is util-linux issue. It's more distro specific and
related to kernel & initramfs & udevd.
For example my Fedora 18:
$ findmnt /
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda4 ext4 rw,relatime,data=ordered
$ df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda4 35146488 16233036 17121452 49% /
$ grep ' / ' /proc/mounts
rootfs / rootfs rw 0 0
/dev/sda4 / ext4 rw,relatime,data=ordered 0 0
> 2) I'd like lvm's naming to be available through mount. Ideally, lvm's
> naming would be available in /proc/mounts... At least, though
> in going from /dev/VG/LV => /dev/mapper/VG-LV, that can be
> scripted reliably to get the mount device name.
For example lsblk(8) should be able to convert to the /dev/mapper
format
lsblk -rno NAME /dev/VG/LV
you can also use /dev/VG/LV for findmnt(8), it should be able to
convert the names for /dev/mapper/VG-LV to search for mountpoint.
.. or use /dev/mapper/<name> in your /etc/fstab ;-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: new mount is broken w/regard to devnames in /etc/fstab
2013-05-18 23:02 new mount is broken w/regard to devnames in /etc/fstab Linda Walsh
2013-05-20 7:53 ` Karel Zak
@ 2013-05-20 8:03 ` Helmut Hullen
2013-05-21 2:28 ` Helmut Hullen
2 siblings, 0 replies; 8+ messages in thread
From: Helmut Hullen @ 2013-05-20 8:03 UTC (permalink / raw)
To: util-linux
Hallo, Linda,
Du meintest am 18.05.13:
> There are 2 problems -- they are unlikely to be
> directly related, but are in so much as they are in the new version
> of mount.
> 1) How is one supposed to get the real root device?
> It's not /dev/root -- and on my system /dev/root doesn't even exist.
> (though to be fair, it has in the past -- udev musta got sloppy this
> time, and did point to the real root device). But how can I get
> /proc to display the real root device instead of some fake name.
rdev
should do the job.
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: new mount is broken w/regard to devnames in /etc/fstab
2013-05-18 23:02 new mount is broken w/regard to devnames in /etc/fstab Linda Walsh
2013-05-20 7:53 ` Karel Zak
2013-05-20 8:03 ` Helmut Hullen
@ 2013-05-21 2:28 ` Helmut Hullen
2 siblings, 0 replies; 8+ messages in thread
From: Helmut Hullen @ 2013-05-21 2:28 UTC (permalink / raw)
To: util-linux
Hallo, Linda,
Du meintest am 18.05.13:
> 1) How is one supposed to get the real root device?
rdev
> It's not /dev/root -- and on my system /dev/root doesn't even exist.
> (though to be fair, it has in the past -- udev musta got sloppy this
> time, and did point to the real root device).
My system doesn't use "udev", it has no "/dev/root" entry, and it shows
since some (few) years "/dev/root" when I invoke "df". No problem.
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: new mount is broken w/regard to devnames in /etc/fstab
2013-05-20 20:52 ` Linda Walsh
@ 2013-05-22 0:39 ` Rob Landley
0 siblings, 0 replies; 8+ messages in thread
From: Rob Landley @ 2013-05-22 0:39 UTC (permalink / raw)
To: Linda Walsh; +Cc: LKML
On 05/20/2013 03:52:29 PM, Linda Walsh wrote:
>
>
>
>
> Rob Landley wrote:
> > On 05/19/2013 12:01:18 AM, Linda Walsh wrote:
> >> 1) How is one supposed to get the real root device?
> >> It's not /dev/root -- and on my system /dev/root doesn't even
> exist.
> > There was a thread on this a couple months ago:
> > https://lkml.org/lkml/2013/3/20/315
> >
> > You can get the major/minor of a filesystem with the stat() system
> > call, or even the stat command line utility. That gives you the
> > major/minor of the device the filesystem was mounted from.
> >
> > Note that there's only a major/minor when the filesystem _has_ a
> > backing block device. If it's initramfs or tmpfs: there isn't one.
> If
> > it's nfs, smbfs, or v9fs: there isn't one.
> ----
> Indeed.
>
> Just that having to go through the extra stat call breaks
> *scripts* that relied on previous behavior. I mean why the kernel
> can't put /dev/sdc1 in /proc/mounts instead of /dev/root when it
> was specifically passed root=/dev/sdc1 on it's command line
> seems a bit puzzling.
That part, I've never understood.
> The thing is -- while there is a /dev/root in '/proc/mounts',
> there
> is no '/dev/root' in '/dev/ NOR is there a "root" or "rootfs" listed
> in '/proc/devices'. I.e. saying the boot occurred from /dev/root when
> /dev/root doesn't exist is a bit obfuscating, at best.
I taught mdev to make a symlink. I believe this predated the existence
of devtmpfs. :)
> That said, it's also incredibly non-portable to have to ...
> call 'stat' on '/'
Dynamically populating /dev is incredibly non-portable. It was all
static devices back in the 90's.
> As for the boot from ramfs, it's odd that it doesn't list
> dev/ramdisk or /dev/mem as the major.
Because ramfs is not a ramdisk. It's a tiny shim that mounts the disk
cache as a filesystem, and gives the data nowhere to go so it can't be
freed unless you delete the files. The dentries are just dentry cache
with no backing store, the file contents are just page cache with no
backing store. It allocates more memory when you write files into it,
and frees memory when you delete files out of it. (tmpfs is a layer on
top of ramfs that imposes a maximum size so "cat /dev/zero > file"
won't fill up all memory and kill your system, and adds hooks to copy
them to swap space when the VM asks the filesystem to flush those pages
instead of replying "no can do".)
I explicitly listed ramfs and tmpfs in the "no block device" entries
above.
You're thinking of "ramdisk", in which you take a chunk of memory and
treat it as a block device, then format it and mount it via a
filesystem driver. This means that page cache is copied from said block
device, so there's two copies of the data and an unnecessary filesystem
driver copying data back and forth. All that's considerably more
complicated and less efficient than just mounting the disk cache as a
filesystem directly. (Ramdisk was the old way, ramfs is the new way.
Between ramfs and loopback devices, ramdisks are pretty thoroughly
obsolete.)
See Documentation/filesystems/ramfs-rootfs-initramfs.txt
Rob
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: new mount is broken w/regard to devnames in /etc/fstab
2013-05-20 19:39 ` Rob Landley
@ 2013-05-20 20:52 ` Linda Walsh
2013-05-22 0:39 ` Rob Landley
0 siblings, 1 reply; 8+ messages in thread
From: Linda Walsh @ 2013-05-20 20:52 UTC (permalink / raw)
To: Rob Landley; +Cc: LKML
Rob Landley wrote:
> On 05/19/2013 12:01:18 AM, Linda Walsh wrote:
>> 1) How is one supposed to get the real root device?
>> It's not /dev/root -- and on my system /dev/root doesn't even exist.
> There was a thread on this a couple months ago:
> https://lkml.org/lkml/2013/3/20/315
>
> You can get the major/minor of a filesystem with the stat() system
> call, or even the stat command line utility. That gives you the
> major/minor of the device the filesystem was mounted from.
>
> Note that there's only a major/minor when the filesystem _has_ a
> backing block device. If it's initramfs or tmpfs: there isn't one. If
> it's nfs, smbfs, or v9fs: there isn't one.
----
Indeed.
Just that having to go through the extra stat call breaks
*scripts* that relied on previous behavior. I mean why the kernel
can't put /dev/sdc1 in /proc/mounts instead of /dev/root when it
was specifically passed root=/dev/sdc1 on it's command line
seems a bit puzzling.
The thing is -- while there is a /dev/root in '/proc/mounts', there
is no '/dev/root' in '/dev/ NOR is there a "root" or "rootfs" listed
in '/proc/devices'. I.e. saying the boot occurred from /dev/root when
/dev/root doesn't exist is a bit obfuscating, at best.
That said, it's also incredibly non-portable to have to ...
call 'stat' on '/', get back a hex device, then use the
major/minor to find the device name -- a bit more hairy
if a devmapper was involved. While that's not my
situation, to force a shell script to scan devices in /dev/block
to find a reverse mapping seems like a huge jump in work-involved
from the previous "df <dirname>|cut..." approach.
As for the boot from ramfs, it's odd that it doesn't list
dev/ramdisk or /dev/mem as the major.
Thanks for the archive pointer, BTW...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: new mount is broken w/regard to devnames in /etc/fstab
2013-05-19 5:01 Linda Walsh
@ 2013-05-20 19:39 ` Rob Landley
2013-05-20 20:52 ` Linda Walsh
0 siblings, 1 reply; 8+ messages in thread
From: Rob Landley @ 2013-05-20 19:39 UTC (permalink / raw)
To: Linda Walsh; +Cc: LKML
On 05/19/2013 12:01:18 AM, Linda Walsh wrote:
> 1) How is one supposed to get the real root device?
> It's not /dev/root -- and on my system /dev/root doesn't even exist.
There was a thread on this a couple months ago:
https://lkml.org/lkml/2013/3/20/315
You can get the major/minor of a filesystem with the stat() system
call, or even the stat command line utility. That gives you the
major/minor of the device the filesystem was mounted from.
Note that there's only a major/minor when the filesystem _has_ a
backing block device. If it's initramfs or tmpfs: there isn't one. If
it's nfs, smbfs, or v9fs: there isn't one.
Rob
^ permalink raw reply [flat|nested] 8+ messages in thread
* new mount is broken w/regard to devnames in /etc/fstab
@ 2013-05-19 5:01 Linda Walsh
2013-05-20 19:39 ` Rob Landley
0 siblings, 1 reply; 8+ messages in thread
From: Linda Walsh @ 2013-05-19 5:01 UTC (permalink / raw)
To: LKML
There are 2 problems -- they are unlikely to be
directly related, but are in so much as they are in the new version
of mount.
1) How is one supposed to get the real root device?
It's not /dev/root -- and on my system /dev/root doesn't even exist.
(though to be fair, it has in the past -- udev musta got sloppy this time,
and did point to the real root device). But how can I get /proc to display
the real root device instead of some fake name.
It's insecure the way it is -- as /dev/root could be "anything"...
2) I'd like lvm's naming to be available through mount. Ideally, lvm's
naming would be available in /proc/mounts... At least, though
in going from /dev/VG/LV => /dev/mapper/VG-LV, that can be
scripted reliably to get the mount device name.
But /dev/root?... How to script that, *reliably*...
And why the bogus name?
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-05-22 18:48 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-18 23:02 new mount is broken w/regard to devnames in /etc/fstab Linda Walsh
2013-05-20 7:53 ` Karel Zak
2013-05-20 8:03 ` Helmut Hullen
2013-05-21 2:28 ` Helmut Hullen
2013-05-19 5:01 Linda Walsh
2013-05-20 19:39 ` Rob Landley
2013-05-20 20:52 ` Linda Walsh
2013-05-22 0:39 ` Rob Landley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.