On Jun 17, 9:42pm, David Brownlee wrote: } On 17 June 2015 at 19:24, Christos Zoulas <chris...@astron.com> wrote: } > In article <pine.neb.4.64.1506171043190....@ugly.internal.precedence.co.uk>, } > Stephen Borrill <net...@precedence.co.uk> 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