NeXT format disklabels/partition tables

toby

unread,

Apr 14, 2006, 1:59:21 AM4/14/06

to

Hi,

I've been trying to get NEXTSTEP 3.3/Intel running under QEMU and
Bochs. I have taken a CD image of my NS 3.3 install CD but find that
the following sequence always ends in a failure to boot the installer,
exactly the same under either emulator:
- boot from 3.3 Boot floppy with hard disk image attached at primary
master, and CD-ROM image attached at primary slave (you have to patch
QEMU vl.c to achieve this setup)
- load Device Drivers floppy, nominate bogus SCSI CD-ROM driver
- load Additional Drivers floppy, nominate EIDE/ATAPI driver
- proceed - get to Mach boot screen, ATA hard disk (hd0) and ATAPI
drive (sd0) detected
System Panic:
vfs_mountroot: cannot mount root
The earlier error is sd0a: Read attempt with no valid label

On the face of it, it would look like the CD image is bad, or maybe
there is some header that needs to be stripped from the image (I
believe I created them using dd on the raw disk device on a Mac
Powerbook G4). However, I have no way of confirming their integrity,
since I cannot find any documentation of what a NEXTSTEP disk
label/partition table should look like! A dump of the first few bytes
of the CD image is below. Can anyone shed any light on this?

Since I am a long way from where my NS CDs are stored, I'd like to try
and confirm that these images are no good before I try to obtain new
ones.

--Toby

$ hexdump -C ns33.cdimage |head|cut -c 11-
00 ff ff ff ff ff ff ff ff ff ff 00 00 02 00 01 |................|
64 6c 56 33 00 00 00 00 00 00 00 00 4e 45 58 54 |dlV3........NEXT|
53 54 45 50 5f 33 2e 33 00 00 00 00 00 00 00 00 |STEP_3.3........|
00 00 00 00 00 00 00 00 17 52 64 88 4e 45 58 54 |.........Rd.NEXT|
53 54 45 50 5f 33 2e 33 00 00 00 00 00 00 00 00 |STEP_3.3........|
00 00 00 00 72 65 6d 6f 76 61 62 6c 65 5f 72 77 |....removable_rw|
5f 73 63 73 69 00 00 00 00 00 00 00 00 00 08 00 |_scsi...........|
00 00 00 20 00 00 00 40 00 00 04 00 00 00 01 2c |... ...@.......,|
00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 10 |.P..............|
00 00 00 30 73 64 6d 61 63 68 00 00 00 00 00 00 |...0sdmach......|

Graham Lee

unread,

Apr 14, 2006, 9:04:23 AM4/14/06

to

On 14/4/06 06:59, toby wrote:
>
> On the face of it, it would look like the CD image is bad, or maybe
> there is some header that needs to be stripped from the image (I
> believe I created them using dd on the raw disk device on a Mac
> Powerbook G4). However, I have no way of confirming their integrity,
> since I cannot find any documentation of what a NEXTSTEP disk
> label/partition table should look like! A dump of the first few bytes
> of the CD image is below. Can anyone shed any light on this?
>
> Since I am a long way from where my NS CDs are stored, I'd like to try
> and confirm that these images are no good before I try to obtain new
> ones.
>

I expect your diagnosis is correct; I had the same problem trying to use
NeXTSTEP's dd to create images of the install floppies. It was putting
some interpreted device files into /dev, and not the raw device (in this
case, it would only make the partitions available not the whole disk).
Try running 'file' on the image you've created; if it claims to be Fast
File System then you've just imaged the partition, not the disk.

The way I generated images of the OS4.2 media was to use Disk Utility;
right-click on the device representing the CD-ROM and create a new
CD/DVD Master image.

toby

unread,

Apr 14, 2006, 12:37:51 PM4/14/06

to

Graham Lee wrote:
> On 14/4/06 06:59, toby wrote:
> >

> > On the face of it, it would look like the CD image is bad, ...

> >
>
> I expect your diagnosis is correct; I had the same problem trying to use
> NeXTSTEP's dd to create images of the install floppies. It was putting
> some interpreted device files into /dev, and not the raw device (in this
> case, it would only make the partitions available not the whole disk).
> Try running 'file' on the image you've created; if it claims to be Fast
> File System then you've just imaged the partition, not the disk.

At offset 16 the signature 'dlV3' can be seen - according to Apple
sources floating on the web (apparently removed from 10.4), this is a
NEXTSTEP partition map signature, and I wouldn't expect to see that if
I'd only taken a single partition. The signature appears again at
offset 0x21a0, 0x4460 and 0x6720:

According to
http://darwinsource.opendarwin.org/10.3.9/IOStorageFamily-44.4/IONeXTPartitionScheme.h,
the disk label structure is defined as:

SInt32 dl_version; /* (unique signature for map) */
SInt32 dl_label_blkno; /* (block on which this map resides) */
SInt32 dl_size; /* (device block count) */
char dl_label[MAXLBLLEN]; /* (device name) */
UInt32 dl_flags; /* (device flags) */
UInt32 dl_tag; /* (device tag) */
struct disktab dl_dt; /* (device info, partition entries) */
dl_un_t dl_un;
UInt16 dl_checksum; /* (V1-V2: ones complement checksum) */

Dumping this for the first entry (ignoring the 16 bytes preceding the
signature):

64 6c 56 33 dl_version = dlV3
00 00 00 00 dl_label_blkno
00 00 00 00 dl_size
4e 45 58 54 53 54 45 50 5f 33 2e 33
00 00 00 00 00 00 00 00 00 00 00 00 dl_label = NEXTSTEP_3.3
00 00 00 00 dl_flags
17 52 64 88 dl_tag

dl_dt: (see e.g.
http://darwinsource.opendarwin.org/10.3.7/xnu-517.9.5/bsd/sys/disktab.h)
4e 45 58 54 53 54 45 50 5f 33 2e 33
00 00 00 00 00 00 00 00 00 00 00 00 d_name = NEXTSTEP_3.3

72 65 6d 6f 76 61 62 6c 65 5f 72 77

5f 73 63 73 69 00 00 00 00 00 00 00 d_type = removable_rw_scsi
00 00 08 00 d_secsize
00 00 00 20 d_ntracks
00 00 00 40 d_nsectors
00 00 04 00 d_ncylinders
00 00 01 2c d_rpm
00 50 d_front; /* size of front porch (sectors) */
00 00 d_back; /* size of back porch (sectors) */
00 00 d_ngroups; /* number of alt groups */
00 00 d_ag_size; /* alt group size (sectors) */
00 00 d_ag_alts; /* alternate sectors / alt group */
00 00 d_ag_off; /* sector offset to first alternate */
00 00 00 10 d_boot0_blkno[NBOOTS]; /* "blk 0" boot locations */

00 00 00 30
73 64 6d 61 63 68 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 d_bootfile = sdmach
6c 6f 63 61 6c 68 6f 73 74 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d_hostname = localhost
61 d_rootpartition = a
62 d_rwpartition = b

d_partitions[8]:
00 00 00 00 p_base; /* base sector# of partition */
00 02 c8 00 p_size; /* #sectors in partition */
20 00 p_bsize; /* block size in bytes */
08 00 p_fsize; /* frag size in bytes */
74 00 = t p_opt; /* 's'pace/'t'ime optimization pref */
00 02 p_cpg; /* cylinders per group */
10 00 p_density; /* bytes per inode density */
0a p_minfree; /* minfree (%) */
01 p_newfs; /* run newfs during init */
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 p_mountpt
01 p_automnt; /* auto-mount when inserted */
34 2e 33 42 53 44 00 00 00 = 4.3BSD p_type[];/* file system type */

followed by 7 entries like this:

ff ff ff ff
ff ff ff ff
ff ff

ff ff
00 00

ff ff
ff ff
ff

00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
00 00 00 00 00 00 00 00 00

The worrisome part is that all that looks pretty much valid, so I'm
still unsure why it won't mount/boot.

toby

unread,

Apr 15, 2006, 2:17:29 AM4/15/06

to

toby wrote:
> Graham Lee wrote:
> > On 14/4/06 06:59, toby wrote:
> > >
> > > On the face of it, it would look like the CD image is bad, ...
> > >
> >

> > I expect your diagnosis is correct; I had the same problem ...
>
> At offset 16 the signature 'dlV3' can be seen ...

> The worrisome part is that all that looks pretty much valid, so I'm
> still unsure why it won't mount/boot.

Okay, I again tried stripping the first 16 bytes from the image. This
time I paid more attention and noticed the following new behaviour,
which *might* indicate progress -- instead of "no valid disk label", I
now see:

sd0: Device Block Size: 2048 bytes
sd0: Device Capacity: 409 MB
sd0: Disk Label: NEXTSTEP_3.3
...
root on sd0
rootdev 600, howto 0
vfs_mountroot: error=22
panic: (Cpu 0) vfs_mountroot: cannot mount root

Graham Lee

unread,

Apr 17, 2006, 4:44:17 AM4/17/06

to

On 15/4/06 07:17, toby wrote:
> toby wrote:
>> Graham Lee wrote:
>>> On 14/4/06 06:59, toby wrote:
>>>> On the face of it, it would look like the CD image is bad, ...
>>>>
>>> I expect your diagnosis is correct; I had the same problem ...
>> At offset 16 the signature 'dlV3' can be seen ...
>> The worrisome part is that all that looks pretty much valid, so I'm
>> still unsure why it won't mount/boot.
>
> Okay, I again tried stripping the first 16 bytes from the image. This
> time I paid more attention and noticed the following new behaviour,
> which *might* indicate progress -- instead of "no valid disk label", I
> now see:
>
> sd0: Device Block Size: 2048 bytes
> sd0: Device Capacity: 409 MB
> sd0: Disk Label: NEXTSTEP_3.3
> ...
> root on sd0
> rootdev 600, howto 0
> vfs_mountroot: error=22
> panic: (Cpu 0) vfs_mountroot: cannot mount root
>

It's good that the disklabel is now being understood. However, getting
EINVAL from vfs_mountroot is on the 'not so' side of good...

toby

unread,

Apr 18, 2006, 2:36:12 AM4/18/06

to

Graham Lee wrote:
> On 15/4/06 07:17, toby wrote:
> > toby wrote:
> >> Graham Lee wrote:
> >>> On 14/4/06 06:59, toby wrote:
> >>>> On the face of it, it would look like the CD image is bad, ...
> >>>>

> >>> I expect your diagnosis is correct; ...

>
> It's good that the disklabel is now being understood. However, getting
> EINVAL from vfs_mountroot is on the 'not so' side of good...

It was indeed a bad CD image; I have obtained a good image now, and
completed the install in Bochs. After reboot, it hangs at Configuring
Network..., but I'll deal with that tomorrow.