Re: gptmbr.bin vs RAIDframe

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jun 17,  9:42pm, David Brownlee wrote:
} 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:

     Given that a GPT typically has a minimum of 128 slots, would
you do gpt->raid->gpt?  Why not just create a sufficient number of
RAID partitions?

} 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
}-- End of excerpt from David Brownlee