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. christos