Re: gptmbr.bin vs RAIDframe

[christos%astron.com@localhost (Christos Zoulas)]

In article <Pine.NEB.4.64.1506171043190.534%ugly.internal.precedence.co.uk@localhost>,
Stephen Borrill  <netbsd%precedence.co.uk@localhost> wrote:
>On Tue, 16 Jun 2015, David Brownlee wrote:
>> OK, I've identified the problem (if not the solution :)
>>
>> I'm trying to setup
>> - gpt with a wedge (at offset +64) that covers the entire disk, containing:
>>  - a raid1 partition, which offsets its context by +64, containing:
>>    - gpt with a wedge (at offset +64) that contains the root filesystem
>>
>> By my count thats means /boot will be in a filesystem at 64+64+64 =
>> 192, while bootxx_ will only try for filesystems at the partition
>> start, plus another attempt at +64 (so 64 and 128). If I manually add
>> another attempt at an additional +64 bootxx will find /boot. At which
>> point /boot will fail to find /netbsd (as I haven't mangled it as
>> well)
>>
>> The first +64 comes from the initial gpt partition, so thats fine - if
>> the initial gpt had a wedge starting at 2048 then the gpt biosboot
>> would plug things in appropriately.
>>
>> The second +64 is looking for the the fixed offset of raidframe which
>> is also ~fine (its either there or not, and if its there, its 64).
>>
>> The final +64 is a kludge which just happens to match my 'gpt-on-raid'
>> layout, and is clearly not a solution.
>>
>> The problem is there not being enough space in the bootxx blocks to
>> parse the disk layout for the gpt-on raid.
>>
>> As I see it my options are
>>
>> 1) Separate boot partition, simple but not elegant
>>
>> 2) An initial 'root' wedge which has a RAID1 with a disklabel for
>> booting, then another wedge for everything else. Also simple, no less
>> inelegant, and avoids the annoying extra boot partition(s), but means
>> you cannot have root on a named wedge (minor point)
>
>2) is what I ended up doing, so instead of dk -> raid -> dk it was just 
>dk -> raid (just remember the installboot step from my earlier mail). Even 
>with a separate boot partition (or with a fixed bootloader), dk -> raid -> dk
>doesn't allow you to set -A root on the RAID (well it sets it, but it 
>doesn't work), so there's still a missing piece of the puzzle. Yes, you 
>need to know the device name for root in your fstab, perhaps the name 
>lookup code could learn to recognise %ROOT% or such like to mean
>/dev/<kern.root_device><'a'+kern.root_partition>


As the comment hints, it should probably be done using an attribute...

        /*
         * XXX: The following code assumes that the root raid
         * is the first ('a') partition. This is about the best
         * we can do with a BSD disklabel, but we might be able
         * to do better with a GPT label, by setting a specified
         * attribute to indicate the root partition. We can then
         * stash the partition number in the r->root_partition
         * high bits (the bottom 2 bits are already used). For
         * now we just set booted_partition to 0 when we override
         * root.
         */

It is pretty simple to implement.

christos