Access partition table / get partition information of a NeXTStep image

Dear all,

How can I get information about the partitions in a NeXTStep disk image?

I have created images of two SCSI hard disk drives from a NeXT cube using the ZuluSCSI RP2040. One image looks ok but the other one is strange: it is an image of a Quantum Fireball ST3.2S with a capacity of 3.2GB. The image file is 3240376832 bytes (3.1GB) large and the log file from creating it shows only a neglible error.

I can mount the image without any problems using

mount -t ufs -o ufstype=nextstep,ro quantum_st32_2024-11-25.hda /mnt/
However, df shows a 1.5GB partition of which only 30MB are used:

Filesystem                Size  Used Avail Use% Mounted on
/dev/loop0                1.5G   30M  1.3G   3% /mnt
Since compressing the file with gzip results in a 830MB file I suspect that there's more in the image. (Although this could also be due to deleted files.)

I suspect that there is another partition but I can not check that using the typical tools: partx fails with "failed to read partition table" and parted shows this:

Error: quantum_st32_2024-11-25.hda: unrecognised disk label
Model:  (file)
Disk quantum_st32_2024-11-25.hda: 3240MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Are there any other tools I could use? Or could there be other explanations for what I observe? How could I check the integrity of the found partition?

Any help is appreciated!

Robert

Previous includes ditool. IIRC I was able to extract different partitions from a NeXTstep disk image.

Thank you very much! That helped:

> ditool -im quantum_st32_2024-11-25.hda -lsp
Disk 'QUANTUM FIREBALL ST3.2S' 'NeueDisk' 'fixed_rw_scsi' 2208 MBytes
  Sector size: 1024 Bytes

  Partition #0: 4.3BSD 1532 MBytes
    Mount point:  '/NeueDisk'
    Fragment size: 1024 Bytes
    Block size:    8192 Bytes
  Partition #1: 4.3BSD 1558 MBytes
    Mount point:  '/d2'
    Fragment size: 1024 Bytes
    Block size:    8192 Bytes

---- done.

I am not sure what the "2208 MBytes" mean ... because this does neither fit to the size of the partition(s) nor to the size of the whole disk. Any ideas?


Listing the files in the second (so far unknown) partition works but throws some errors at the end:

Can't read 1024 bytes at offset 3240370176
Can't read 7168 bytes at offset 3237396480
WARNING: unknown format (0) '/LocalApps/DARTApps/VarioData_3.22/Application/VarioData.app/German.lproj/Evaluate.nib/.'
/LocalApps/DARTApps/VarioData_3.22/Application/VarioData.app/German.lproj/Evaluate.nib/.
Can't read 7168 bytes at offset 3163832320
...

It is nice that I can copy files with ditool. However, I am not sure how/whether I can extract the second partition as a separate image. Without exact byte positions that's difficult and the option -lsp does not seem to show them. Looking at the source code of ditool it's probably possible to add some code to get the exact positions. Are there any simpler alternatives?

Quote from: rjoberon on November 29, 2024, 02:31:46 PMI am not sure what the "2208 MBytes" mean ... because this does neither fit to the size of the partition(s) nor to the size of the whole disk. Any ideas?

I think this information is directly derived from on-disk data in DiskImage.cpp:

ostream& operator<< (ostream& os, const DiskImage& im) {
    int64_t size = im.sectorSize;
    size *= fsv(im.dl.dl_dt.d_ntracks);
    size *= fsv(im.dl.dl_dt.d_nsectors);
    size *= fsv(im.dl.dl_dt.d_ncylinders);
    size >>= 20;
    os << "Disk '" << im.dl.dl_dt.d_name << "' '" << im.dl.dl_label << "' '" << im.dl.dl_dt.d_type << "' " << size << " MBytes" << endl;
Perhaps this on-disk information is incorrect (initialized with a disktab for a different drive or so), but that would not explain how the larger partitions were created.

You could try to extract the second partition from the disk image with dd using something like

dd if=quantum_st32_2024-11-25.hda of=d2.img bs=1024 skip=1568768
(1568768 is 1536 * 1024) and see if you can mount the partition image on its own.

QuoteYou could try to extract the second partition from the disk image with dd using something like

Code Select Expand

dd if=quantum_st32_2024-11-25.hda of=d2.img bs=1024 skip=1568768

Thank you. That did the job. I was reluctant to try this on my own because I expected some additional offset due to, e.g., the boot block or the partition table. But well, in the end I could have just tried it. Now that I know that it is so simple, I can also mount the partition as follows:

mount -t ufs -o ufstype=nextstep,ro,offset=1568768K quantum_st32_2024-11-25.hda /mnt/
Perfect. Thank you all!

So, was there anything interesting on the disks? :)

QuoteSo, was there anything interesting on the disks? :)

Yes. Data from the 90s. :-)

Our institute bought a NeXTCube at the beginning of the 90s (some files are from 1992) and used it approximately until the end of the 1990s. Since then it lay dormant (did not boot). Now we want to resurrect it and also save the data. A ZuluSCSI helped us a lot. We can now do both: boot the old system and access the data using the Previous emulator (which I did today ... it works nicely) and run the old hardware using the ZuluSCSI (which is much nicer than noisy hard disks).

I rather like the hum from the monster full-sized 660MB drive in the 68030 original NeXt Computer that I have...slow as molasses running NS 3.3 but all original, and the MegaPixel display is still quite bright...