Bug #1622

devfs doesn't create my ad4s3 (macbook)

Added by herrgard over 4 years ago. Updated over 1 year ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:alexh% Done:

0%

Category:-
Target version:-

Description

Hi.

DragonFly doesn't create ad4s3 in /dev. fdisk shows it. I don't know how
this Mac (unibody macbook of late 2008) has its partitions set up, but
it's probably in a weird way. I created the extra slice through bootcamp
in OS X. Right now i have OpenBSD installed in it.

Attached is output of
verbose dmesg
dmesg with kern.disk_debug=3
fdisk ad4, ad4s0, ad4s1, ad4s2
gpt show ad4, ad4s0, ad4s1

I got the outputs using the live cd and what I want is to install
DragonFly into this ad4s3 slice.
There was some crap in the top of the dmesgs that I cut off.

Thanks,
Max

dmesg_kern.disk_debug3_2 (11.5 KB) herrgard, 12/07/2009 10:45 PM

fdisk_ad4 (977 Bytes) herrgard, 12/07/2009 10:45 PM

fdisk_ad4s0 (579 Bytes) herrgard, 12/07/2009 10:45 PM

fdisk_ad4s1 (787 Bytes) herrgard, 12/07/2009 10:45 PM

fdisk_ad4s2 (1.07 KB) herrgard, 12/07/2009 10:45 PM

gptshowad4 (521 Bytes) herrgard, 12/07/2009 10:45 PM

gptshowad4s0 (89 Bytes) herrgard, 12/07/2009 10:45 PM

gptshowad4s1 (72 Bytes) herrgard, 12/07/2009 10:45 PM

vdmesg2 (33.8 KB) herrgard, 12/07/2009 10:45 PM

History

#1 Updated by alexh over 4 years ago

seems to be a problem with our gpt. I'll take this one.

Cheers,
Alex Hornung

#2 Updated by alexh over 4 years ago

It seems gpt starts numbering slices at 0, so the usual ad4s1 is ad4s0, ...
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
the slice type is always set to 1).

For reference:
7:46:26 dragon:~
# gpt show /dev/ad0
start size index contents
0 1 - PMBR
1 1 - Pri GPT header
2 32 - Pri GPT table
34 6 -
40 409600 0 GPT part - EFI System
409640 293391 1 GPT part - Apple HFS
703031 400000 -
1103031 185671 2 GPT part - MS/Linux Basic Data
1288702 808417 -
2097119 32 - Sec GPT table
2097151 1 - Sec GPT header

7:47:05 dragon:~
# newfs_msdos /dev/ad0s2
/dev/ad0s2: 185276 sectors in 46319 FAT16 clusters (2048 bytes/cluster)
bps=512 spc=4 res=1 nft=2 rde=512 mid=0xf8 spf=181 spt=63 hds=256 hid=1103031
bsec=185671

Observe carefully that the bsec of the newfs actually matches the number of
sectors of the third partition, with gpt index 2.

Cheers,
Alex Hornung

#3 Updated by dillon over 4 years ago

: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).

Yah, I'm responsible for the numbering. With GPT 's0' is index entry 0
in the GPT. I did it that way so the index number in the GPT table
matched the slice number in the device name because it was really
confusing when they were 1-off.

I don't know what the best solution is but numbering from 0 has caused
us other headaches so if you want to change it back to numbering from 1
it's ok with me. It will mess up anyone using GPT right now, thougg,
they will have to fix up their fstab and such.

: 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

So e.g. ^ index 0, 1 and 2 corresponds to s0, s1, and s2
right now.

:# 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

-Matt
Matthew Dillon
<>

#4 Updated by dillon over 4 years ago

Ooh, it also occurs to me that we could change the construction of
the device name instead of overloading 's#' to remove the confusion.
So for a native GPT we could call it 's0.<index>' instead of 's<index>'.
Or perhaps we could just call it 'g<index'> instead of 's<index>', so
something like: ad4g0, ad4g1, ad4g2, ad4g3.

Just throwing out ideas.

-Matt

#5 Updated by herrgard over 4 years ago

Den 2009-12-08 21:26:32 skrev Matthew Dillon <>:

> Ooh, it also occurs to me that we could change the construction of
> the device name instead of overloading 's#' to remove the confusion.
> So for a native GPT we could call it 's0.<index>' instead of
> 's<index>'.
> Or perhaps we could just call it 'g<index'> instead of 's<index>', so
> something like: ad4g0, ad4g1, ad4g2, ad4g3.
>
> Just throwing out ideas.
>
> -Matt

I really like the 'g<index>' idea.

Max

#6 Updated by dillon over 4 years ago

:> 's<index>'.
:> Or perhaps we could just call it 'g<index'> instead of 's<index>', so
:> something like: ad4g0, ad4g1, ad4g2, ad4g3.
:>
:> Just throwing out ideas.
:>
:> -Matt
:
:I really like the 'g<index>' idea.
:
:Max

Oh, except 'g' could be misinterpreted as a partition id
(a-p). So we have: q r s t u v w x y z left. We use 't'
for track identifiers on audio CDs.

Maybe we should use 'r' or something like that :-)

-Matt
Matthew Dillon
<>

#7 Updated by herrgard over 4 years ago

Den 2009-12-09 01:13:51 skrev Matthew Dillon <>:
>
> Oh, except 'g' could be misinterpreted as a partition id
> (a-p). So we have: q r s t u v w x y z left. We use 't'
> for track identifiers on audio CDs.
>
> Maybe we should use 'r' or something like that :-)
>
> -Matt
> Matthew Dillon
> <>

Meh, you are right. 'g' would have been the perfect one though :-)

'r' is fine too, I think. The important thing is that the index differs
from 's' so people notice that there is something special with it.

Max

#8 Updated by tuxillo over 1 year ago

  • Description updated (diff)
  • Status changed from New to Feedback

Max,

What's left in this issue?

Cheers,
Antonio Huete

#9 Updated by herrgard over 1 year ago

  • Status changed from Feedback to Closed

I don't know really what's left and what we should do about it. devfs do create the devices in /dev, it's just that the slice number is off. This will confuse the installer as it expects ad4s3* but devfs created ad4s2*. Anyone hitting this while installing can use devfs rules to create links named ad4s3 pointing at ad4s2. You need to create links for the partitions (a, b, d etc) too.

I'll close this issue as I don't see it as a devfs bug any more. The question about how we should handle GPT/MBR tables is still open though.

I don't know if this issue with slice number being off is something that only upsets the installer on Macs with their hybrid GPT/MBR table.

Also available in: Atom PDF