Rocky Hotas <rockyhotas%firemail.cc@localhost> writes:
> Obviously, disklabel creates custom partitions only in the portion of
> the disk which is related to NetBSD, the only one where it is intended
> to act. It leaves unchanged any other area of the disk. If MBR did not
> exist, the extension of disklabel partitions `a', `b', `e', `f', etc.
> could span the whole disk, and in fact this is the case of my last
> example, where disklabel only is used, without MBR.
This isn't really true. While the installer might only create
partitions within the NetBSD MBR partition, it is entirely feasible and
reasonable to create a disklable partition that refers to some other MBR
partition.y
This is the default on RPI, where you have (skipping uninteresting lines)
Partition table:
0: Primary DOS with 32 bit FAT - LBA (sysid 12)
start 8192, size 188416 (92 MB, Cyls 0/130/3-12/60/48), Active
1: NetBSD (sysid 169)
start 458752, size 61875200 (30213 MB, Cyls 28/141/50-3880/27/51)
PBR is not bootable: All bytes are identical (0x00)
8 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 61875200 458752 4.2BSD 0 0 0 # (Cyl. 224 - 30436*)
b: 262144 196608 swap # (Cyl. 96 - 223)
c: 62333952 0 unused 0 0 # (Cyl. 0 - 30436*)
d: 62333952 0 unused 0 0 # (Cyl. 0 - 30436*)
e: 188416 8192 MSDOS # (Cyl. 4 - 95)
So here 'a' is the NetBSD filesystem within the NetBSD MBR partition,
'b' is the swap partition which is not actually in any MBR partition,
and 'e' is an alias for the MBR partition (used as /boot).
This is how a real RPI install from 8, maybe 7, now 9, has ended up and
that may not be really the best way to do it. But it's an example of
the real complexity of things out there.
Attachment:
signature.asc
Description: PGP signature