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?
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-
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...
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-