Henryk Paluch <hpal...@seznam.cz> writes:
> Hello! > >> The OpenBSD installer partitioning does not accept more than 15 partitions >> with GPT (partitions 'c' and 'i' are already defined in advance by the >> installer). It limits from partition 'a' to 'p', but GPT partitions must >> support up to 128 partitions. > > > It is actually more restricted: > - yes, total amount of disklabel slices is 16 - 'a' to 'p' > > BUT: > - only first 8 slices are reserved for OpenBSD slices inside single GPT > partition with OpenBSD ID. Where 'b' is reserved for swap, and 'c' is always > whole disk. So only 6 slices are available for slices inside OpenBSD > partition > - another 8 slices are automatically used to map other GPT partitions. So you > can access from OpenBSD up to 8 others partitions in GPT. > > Later mechanism is done by function spoofgpt() in > /usr/src/sys/kern/subr_disk.c > - see > https://cvsweb.openbsd.org/src/sys/kern/subr_disk.c?rev=1.272&content-type=text/x-cvsweb-markup > > > To fully understand it, here is complex example of my GPT disk partitioning > (note that I actually use BIOS mode, which is not officially supported on > OpenBSD, but it works fine using Linux + GRUB to load OpenBSD kernel). > > GPT partitions as seen by OpenBSD fdisk: > > isk: sd0 Usable LBA: 34 to 937703054 [937703088 Sectors] > #: type [ start: size ] > ------------------------------------------------------------------------ > 0: BIOS Boot [ 34: 2014 ] > 1: EFI Sys [ 2048: 2097152 ] > 2: Linux LVM [ 2099200: 312473601 ] > 3: EFI Sys [ 314574848: 204800 ] > 4: OpenBSD [ 314779648: 102400000 ] > 5: NetBSD [ 417181696: 100663296 ] > 6: 49f48d32-b10e-11dc-b99b-0019d1879648 [ 517844992: 16777216 ] > 7: 83bd6b9d-7f41-11dc-be0b-001560b84f0f [ 534622208: 1024 ] > 8: 516e7cb6-6ecf-11d6-8ff8-00022d09712b [ 534623232: 104856576 ] > 9: 516e7cb5-6ecf-11d6-8ff8-00022d09712b [ 639479808: 16777216 ] > 10: Linux files* [ 656257024: 104857600 ] > > > And here is disklabel (omitted header): > > 16 partitions: > # size offset fstype [fsize bsize cpg] > a: 98205696 314779648 4.2BSD 2048 16384 12960 # / > b: 4194304 412985344 swap # none > c: 937703088 0 unused > i: 2014 34 boot > j: 2097152 2048 MSDOS > k: 312473601 2099200 unknown > l: 204800 314574848 MSDOS > m: 100663296 417181696 unknown > n: 16777216 517844992 unknown > o: 1024 534622208 unknown > p: 104856576 534623232 unknown > > Note that: > - slices 'a' to 'h' are usable for OpenBSD, however 'a' should be root > filesystem, 'b' should be swap, and 'c' is synthetic entry covering whole > disk. All these slices are always inside single GPT partition of type > OpenBSD > - in this case: 4: OpenBSD > - slices from 'i' to 'p' are automatically mapped other GPT partitions. You > can > see (matching offset), that > - slice 'i' is GPT partition 0: BIOS Boot > - ... slice 'p': is GPT partition: 8: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > - however it means that additional GPT partitions (starting from 9) are simply > NOT accessible from OpenBSD. > > So briefly: > - there are total 16 slices ('a' to 'p') available > - first 8 slices are used to map OpenBSD slices inside single OpenBSD GPT > partition (but 'a', 'b', 'c' have special meaning as described above) > - remaining 8 slices are automatically mapped remaining GPT partitions so they > can be accessed from OpenBSD (through device in /dev/) It's important to remember that once the kernel has created or read a disklabel it completely ignores the GPT. Sufficiently determined manually editing of the disklabel can create partitions 'a' through 'p' (excluding 'c') that address arbitrary areas on the disk. Crossing GPT partition boundaries, overwriting the GPT, etc. Of course the kernel can then have shot itself in the foot by losing track of where it has written the disklabel. All part of the fun. Assuming you don't want to trash an existing GPT configuration, any collection of 15 GPT partitions out of the 128 possible can be mapped into disklabel partitions. The kernel takes a simple first come first served strategy when building a default disklabel, but this does not prevent the user from selecting a smaller/larger/different set of GPT partitions. The only constraints are 'c' is out of bounds and there must be someplace safe to write the disklabel if you want a non-default configuration to be remembered. 'safe' being an interesting topic of its own. Constraints around 'a' and 'b' relate to boot disks only. The disklabel created for a boot disk during install will default to up to 7 OpenBSD partitions with some spoofed partitions. But this is simply an implementation choice that the user can ignore. e.g. defining an 'a' for all OpenBSD data and 'b' through 'p' (excluding 'c') for any 14 GPT Microsoft Basic Data partitions would theoretically work fine as a weird but bootable OpenBSD system. You are of course completely on your own when spelunking in such dark caves. :-) .... Ken > > > Hopefully it will make things more clear. > > Best regards > --Henryk Paluch > > > > > On 12/18/23 17:15, spnti wrote: >> Hello guys! >> The OpenBSD installer partitioning does not accept more than 15 partitions >> with GPT (partitions 'c' and 'i' are already defined in advance by the >> installer). It limits from partition 'a' to 'p', but GPT partitions must >> support up to 128 partitions. >> Thank you for your attention and help. -- .... Ken
