Re: gptmbr.bin vs RAIDframe

[David Brownlee <abs%absd.org@localhost>]

On 17 June 2015 at 19:24, Christos Zoulas <christos%astron.com@localhost> wrote:
> 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.

The issue is less encoding which is the root partition, more how the
(very space limited) initial boot blocks can find it.

Absent the workaround suggested by Stephen (of which I am now a huge
fan and currently have 5.3TB of data copying across to :), the basic
options to allow booting from gpt->raid->gpt root might be:

a) Chain the bootloaders so the initial (gpt) one loads a later one
b) plug the offset to the actual root filesystem into the initial boot blocks
c) squeeze the logic for gtp->raid->gpt and similar into the first
level boot blocks - possibly by having a custom boot block just for
that