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 <k...@munnari.oz.au> wrote: > Date: Sun, 11 May 2014 22:53:48 -0400 > From: chris...@zoulas.com (Christos Zoulas) > Message-ID: <20140512025348.ab23b17f...@rebar.astron.com> > > | 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 > > > -- ----