Alex Hornung <ahornung@gmail.com> added the comment:
It seems gpt starts numbering slices at 0, so the usual ad4s1 is ad4s0, ...=
=20
leading to the fact that the expected ad4s3 is at ad4s2.
In any case, I'll update our GPT code to fix some other issues (for example=
=20
the slice type is always set to 1).
For reference:
7:46:26 dragon:~=20
# gpt show /dev/ad0
start size index contents
0 1 - PMBR
1 1 - Pri GPT header
2 32 - Pri GPT table
34 6 - =20
40 409600 0 GPT part - EFI System
409640 293391 1 GPT part - Apple HFS
703031 400000 - =20
1103031 185671 2 GPT part - MS/Linux Basic Data
1288702 808417 - =20
2097119 32 - Sec GPT table
2097151 1 - Sec GPT header
=20
7:47:05 dragon:~=20
# newfs_msdos /dev/ad0s2=20
/dev/ad0s2: 185276 sectors in 46319 FAT16 clusters (2048 bytes/cluster)
bps=3D512 spc=3D4 res=3D1 nft=3D2 rde=3D512 mid=3D0xf8 spf=3D181 spt=3D63 h=
ds=3D256 hid=3D1103031=20
bsec=3D185671
Observe carefully that the bsec of the newfs actually matches the number of=
=20
sectors of the third partition, with gpt index 2.
Cheers,
Alex Hornung
_____________________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue1622>
_____________________________________________________