Message-ID: <20120208073559.GA3163@tugrik.mns.mnsspb.ru>
Date:	Wed, 8 Feb 2012 11:35:59 +0400
From:	Kirill Smelkov <kirr@....spb.ru>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: No /dev/root with devtmpfs?

On Tue, Feb 07, 2012 at 11:05:42AM +0100, Kay Sievers wrote:
> On Tue, Feb 7, 2012 at 08:55, Kirill Smelkov <kirr@....spb.ru> wrote:
> > On Mon, Feb 06, 2012 at 08:45:24PM +0100, Kay Sievers wrote:
> >> On Mon, Feb 6, 2012 at 12:18, Kirill Smelkov <kirr@....spb.ru> wrote:
> >> > Recently I've reworked my system not to use udev, but use devtmpfs
> >> > instead and discovered there is no /dev/root symlink in devtmpfs case.
> >> >
> >> > My setup uses /dev/root early to know what is the boot device and then
> >> > do some operations on it like checksumming, etc...
> >> >
> >> > Now when /dev/root is gone the best workaround I could come up with is
> >> > to   grep /proc/partitions for '[hs]d[a-z]1'  but it's ugly and will
> >> > break when there are several block devices attached.
> >> >
> >> > Is it somehow possible to add /dev/root to devtmpfs?
> >>
> >> No, devtmpfs has no business in knowing anything about the rootfs or
> >> who mounted what ans where. I can not create such links.
> >>
> >> The entire concept of /dev/root is flawed anyway, and nothing should
> >> really depend on that.
> >>
> >> Modern filesystems will not offer a direct relation to a single block
> >> device, they allocate an superblock which has a major == 0, so there
> >> can be by definition never such a link. Better get rid of all uses of
> >> /dev/root, it will just fail in the future.
> >
> > Kay, thanks for explanation.
> >
> > Though now I'm confused about how to know on what "place" root
> > filesystem was mounted... To me the question makes sense, but you say
> > with modern filesystems there by definition is no answer (or did I
> > misunderstood you?) Strange...
> 
> The root filesystem will still be mounted at /, but you can not
> identify by a device. Check the difference between:
>   $ mountpoint -d /
>   8:1
> which is a classic ext4 sda1 device behind "/".
> 
> With 'btrfs' it will just look like 'tmpfs' looks today:
>   $ mountpoint -d /dev/shm
>   0:17
> 
> and while the 'btrfs' file system is surely backed by a
> disk/partition, just like ext4 is, there can still never be a symlink
> to the disk device.

Kay, thanks again for explanation.

I understand that in case filesystems allocate major 0 there could not
be a well-defined /dev/root, but I don't understand the rationale for
doing so.

Maybe allocating major=0 is a good thing, but look at it this way:

"On what disk/partition was / mounted?" is a well-defined question for
cases when backing store is local hdd, so there should be well-defined
answer.

Previously it was /dev/root, but if /dev/root is not good there should be
some other way for getting the answer. With ext2 I've switched to
`mountpoint -d /` and then grepping major/minor in /proc/partitions, but
with major=0 case I suspect this won't work.


My use case is to check md5 sum of mbr + bootloader area +
root-partition early right after the boot, to verify whether software is
not corrupt, and for doing so it was useful to know / -> root-partition
-> whole block device. It's not tivo, just checking for medium damage. (I
understand this would be better done in the early bootloader but that
part is out of my control)



Sorry for maybe repeating myself and thanks again,
Kirill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists