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

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

Just for the record, the suggested patch did not make any difference
for my problem, which otherwise appears to be linked to this
discussion - root on raidframe. In my case GENERIC still boots fine if
I enable DEBUG and DIAGNOSTIC.

Chavdar

On 12 May 2014 09:19, Robert Elz <kre%munnari.oz.au@localhost> wrote:
>     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
>
>
>



-- 
----