"Jonathan A. Kollasch" <jakllsch%kollasch.net@localhost> writes:
> On Tue, Dec 30, 2014 at 07:13:15PM +0000, David Laight wrote:
>> On Wed, Dec 24, 2014 at 09:30:31PM -0500, Greg Troxel wrote:
>> >
>> > and a further question:
>> >
>> > I know /boot (with MBR) can skip the raidframe header. So given a
>> > disk with a single MBR partition of type RAID, and an inside-the-RAID1
>> > disklabel with raid0a starting at 0, booting works. (I'm sure because
>> > I do this all the time.)
>> >
>> > But, if I have gpt, with a RAID partition, and in the RAID1 have
>> > another gpt label, and in that a partition, is there any way to boot
>> > from that? Basicallly I'm thinking
>> >
>> > sd0
>> > A=gpt partition 1, type raid, starts at 1024, big
>> > raid0 (so starts at 1024*64)
>> > B=gpt partition 1, starts at say 1024+64+64
>> >
>> > and would like the bootxx_ffsv2 code written to the beginning of
>> > A to see type 'raid', skip 64, and then interpret gpt vs mbr and find
>> > the active inner gpt partition.
>>
>> The code that reads /boot (last time I looked) doesn't inspect any inner
>> labels (of any type). It just had a nasty hack to look for a filesytem
>> a further 64 sectors down the disk if it doesn't find /boot in the
>> expected place.
>>
>> Maybe a gpt disk has space for a larger boot image?
>> In which case it might be possible to have more code to find /boot.
>
> Not when booted by PC-BIOS. All the GPT MBR does is locate load and run
> a bootable GPT partition. This partition still contains the bootxx code
> just like any other bootable partition on x86.
Is it known to work to use the gptmbr sector-0 boot, as installed by
'gpt biosboot' to then load bootxx and /boot from a gpt partition with
just FFS in it? I would think this would be the normal case.
Two thoughts:
Given the current code (which is what someone running -6 or -7 will
have), it seems that the right approach (for RAID1) is one of:
* separate RAID1 for /, and /bigspace
- create a <2T gpt partittion of type RAID
- either disklabel it, and put root at offset zero (presumably a),
or just newfs it without a disklabel. Perhaps /usr and all
that can also fit, because really it just has to be less than
2T.
- use 'gpt biosboot' to point to the first RAID
- create another RAID partiition for the rest of the disk
- maybe put an inner gpt label inside the RAID, or
- hope the kernel will parse nested labels (probably it will)
- just newfs it, because you want a single huge /d0 anyway
* mostly RAID with a boot partition you can recontruct if you have to
- create a small (128 MB?) gpt partition with FFSv2 in it
- use 'gpt biosboot' to point to it
- newfs it and install bootxx_ffsv2, /boot, and a kernel
- as above, with a RAID partition
- but, have to figure out how to make RAID_AUTOCONFIG code find
the right gpt partition within the gpt label within the RAID
that is marked autoconfig-root
GIven all this, I think the first option is better, because the small
raid set can be marked autoconfig-root, and the entire root filesystem
can be there. This splits / and the rest of the system into two RAIDs,
but it avoids pushing the kernel, once loaded, out of its comfort zone.
And it keeps the gpt booting code in the simple path, where there is
just a single fs in the gpt partition.
Does this sound right?
Attachment:
pgpqun0k9g6Sb.pgp
Description: PGP signature