Re: Strange boot problems on amd64-current (6.99.40)

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

    Date:        Sun, 11 May 2014 22:53:48 -0400
    From:        christos%zoulas.com@localhost (Christos Zoulas)
    Message-ID:  <20140512025348.AB23B17FDA1%rebar.astron.com@localhost>

  | This should work... But it is sub-optimal.
 
It returns the state to as it was before the 1.306 commit.  That is,
previously, the raid autoconfig code was called before anything called
cpu_rootconf().   And (assuming it was successful) that set booted_device.

Then when something else later called cpu_rootconf() it did nothing, the
(almost) first line is to return if booted_device is set (which it now is).

Nothing ever set booted_partition, so it got left at its uninitialized
value (ie: 0).   That means raidNa became the root.

After your change, cpu_rootconf() is being called before the raid autoconfig
has set booted_device, it sets a (in this case meaningless) value into
booted_partition, then booted_device gets set, and booted_partition will
never be altered again.

Forcing booted_partition to be 0 when raidframe sets booted_device is
about as good as it will be possible to be when the raid device contains
a disklabel.   If it is GPT inside, then it should be possible to use
some attribute from the label to find a suitable root partition (defaulting
to the partition labelled "raidNa" as it does now .. it took me a while to
figure out that I needed to label my root partition (as in "gpt label ...")
"raid7a" to get it to autoconfigure, that isn't docmented anywhere I saw.)

One possibility that would be a backwards compatible, and slightly less
hacky (and more flexible) solution, might be to use

                booted_partition = (whatever)->root_partition >> 8;

(where 8 could be anything, and probably not be an inline constant of course).

For existing raid arrays, that is going to have the same effect as
                booted_partition = 0;
as root_partition is 0 or 1 (or after your change, perhaps 2).

But now there would be the possibility to set the partition number (or for
GPT, the index) into root_partition and allow the raidframe config to
select whatever it wants to be the root.   Index 0 isn't valid for GPT, so
that would either mean "look for raidNa" as now, or perhaps look for some
label attribute indicating rootness...

kre