Re: Specifying root device in /etc/fstab

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 1 Oct 2018 17:52:15 -0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <potms7$qpe$1%serpens.de@localhost>

  | The device doesn't know anything about it.

The device, obviously not, the filesystem on the device does though,
at least when it is using disklabel type partitioning, which is what
matters here.

  | You may chose a convention
  | like using the first partition as root

You can choose whatever you like, what matters is that partition x
(in a disklabel) is partition x, always, and will never alter by itself.

How that partition is selected by the boot manager doesn't matter,
but once selected it is the root, and it knows its own partition (or
should) and the other partitions on the drive that it needs to mount.

What it doesn't know is its drive name.

  | In every case the kernel finally selects a root partition to be mounted and
  | exactly that partition should be referenced in fstab, what is written there
  | will be remounted read-write during the boot process.

Yes, that is what we need - but without knowing what the drive name is, as
that can vary.   That's what NAME= allows for wedges with configurable names.
Something is needed for the case when the name is not coonfigurable, but
simply depends upon whatr the kernel decides to call the drive being used.

  | Now of course you can duplicate the information what partition you
  | selected for booting

yes, and that's reaosnable, as it doesn't change.   This is what has always
been done, using "/dev/wd0x / . ..." type entries in fstab.   It works, and it
it weren't for "wd0" randombly changing to "sd0" or "wd2" or something,
depending upon how the drive happens to be connected, and what other
drives are powered up, would be all that is needed.

  | or just assume that nobody would ever use anything
  | other than partition 'a'.

Of course not, you can put whatever partition name you like in fstab.
But if it is the x partition in the label, it is the x partition in the 
kernel, and needs to be referenced as the x partition in fstab, and
other than modifying the label, that does not change.

I'm not arguing that everyone should do it this way, or in fact that anyone
should, I use GPT and wedges, and NAME= everywhere (even to the
extent of adding "support" by having my scripts that start Xen DomU's
rewrite a protytpe startup script that uses NAME= to insert thet correct
/dev/dkN as it is when the scfript is run (it's possible that xen supports
this kind of naming now, but not the oldish verrsion on my Dom0)

  | And obviously you rule out that someone is
  | using a wedge here, because there is no such thing as a partition of
  | a partition.

Not rule out, wedges use NAME=  .... that a facility exists for the people
who need it does not mean that those who don't are somehow required to
use it.

[Aside: I have plenty of wedges that have either dislabels, or GPT tables
in them - either the wedge is a CGD, and that CGD contains (one of those)
labels, and severl mountable partitions, or the wedge is passed as a device
to a Xen DomU, which treats it just like any other drive, including 
partitioning.   Not that any of that is relevant for this discussion .... the 
same is true (or was on older systems) of partitions created by disklabels
of course.)

  | Thus my suggestion is to not bother with that duplicate
  | partition information, but have something that is just an alias for
  | 'whatever the kernel uses as read-only root'.

That's fine for root, but how do we then name "the 'e' partition on
the drive root came from is /usr" ?   (and swap, and ...)

  | It currently stops you from using wedges on the one-size-fits-all images
  | for arm SoCs as the first thing done is resizing the OS partition while
  | it is still mounted read-only.

OK.

  | The problem Jared tries to solve is that without wedges the same image
  | will be visible as different devices, depending on what hardware
  | configuration exists and wether some pluggable devices like SD cards
  | are found or not.

Yes.   But even when the user could config it (which would mean booting
to single user, fscking root, and remounting rw, then using ed (or also
mounting /usr and often /var) to change fstab.   They should not need to.

The facility as designed seems like it does exactly what is needed, at
relativey low cost.   It might not be the solution we'd really like to see,
but deferring implementing anything because it is not the perfect dream
solution (even when we think we know what that is) is never a good
approach.   If you want the "perfect" solution, then implement it, now,
otherwise allow the intermediate solution to be implemented - if it becomes
redundant in the futurem it can be removed again.

kre