Re: new mount is broken w/regard to devnames in /etc/fstab

[Linda Walsh <lkml@tlinx.org>]

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