Project

General

Profile

Actions

Bug #1622

closed

devfs doesn't create my ad4s3 (macbook)

Added by herrgard about 15 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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


Files

dmesg_kern.disk_debug3_2 (11.5 KB) dmesg_kern.disk_debug3_2 herrgard, 12/07/2009 10:45 PM
fdisk_ad4 (977 Bytes) fdisk_ad4 herrgard, 12/07/2009 10:45 PM
fdisk_ad4s0 (579 Bytes) fdisk_ad4s0 herrgard, 12/07/2009 10:45 PM
fdisk_ad4s1 (787 Bytes) fdisk_ad4s1 herrgard, 12/07/2009 10:45 PM
fdisk_ad4s2 (1.07 KB) fdisk_ad4s2 herrgard, 12/07/2009 10:45 PM
gptshowad4 (521 Bytes) gptshowad4 herrgard, 12/07/2009 10:45 PM
gptshowad4s0 (89 Bytes) gptshowad4s0 herrgard, 12/07/2009 10:45 PM
gptshowad4s1 (72 Bytes) gptshowad4s1 herrgard, 12/07/2009 10:45 PM
vdmesg2 (33.8 KB) vdmesg2 herrgard, 12/07/2009 10:45 PM
Actions #1

Updated by alexh about 15 years ago

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

Cheers,
Alex Hornung

Actions #2

Updated by alexh about 15 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:~
  1. 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:~
  1. 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

Actions #3

Updated by dillon about 15 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
<>
Actions #4

Updated by dillon about 15 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
Actions #5

Updated by herrgard about 15 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

Actions #6

Updated by dillon about 15 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
&lt;&gt;
Actions #7

Updated by herrgard about 15 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

Actions #8

Updated by tuxillo almost 12 years ago

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

Max,

What's left in this issue?

Cheers,
Antonio Huete

Actions #9

Updated by herrgard almost 12 years 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.

Actions

Also available in: Atom PDF