Examining ADFS HDD image created by 'dd'

[mmelbourne]

Hi,

I've created a backup of my HDD from an old Risc PC, using 'dd' on Linux.

I am now struggling to open the file. The version of Ubuntu I have (22.04) in a VM allows me to mount it ("mount -t adfs <foo>") but doesn't allow navigation beyond the root directory (I/O errors are generated for any subdirectories). I understand that this module is now deprecated, so perhaps doesn't support the later disk formats as reliably?

I've tried Gerald Holdsworth's brilliant "Disc Image Manager" but that doesn't recognise the disk image (it is 40GB). I've also tried "ADFS Explorer".

The original disk, plugged into an IDE-to-USB adapter, and into a Pi yields:

pi@raspberrypi:~ $ lsblk /dev/sda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 37.3G 0 disk
├─sda1 8:1 0 1K 0 part
└─sda5 8:5 0 37.3G 0 part

pi@raspberrypi:~ $ sudo fdisk -l /dev/sda
Disk /dev/sda: 37.27 GiB, 40020664320 bytes, 78165360 sectors
Disk model: A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb3be3e36

Device Boot Start End Sectors Size Id Type
/dev/sda1 16065 78156224 78140160 37.3G f W95 Ext'd (LBA)
/dev/sda5 16128 78156224 78140097 37.3G b W95 FAT32

[davidb]

I would suggest making a copy of the backup, just in case any software you use with it wants to modify it, and use RPCEmu to look at it.

[chrissawer]

Is the RiscPC running RISC OS 3 or 4?

I have had more success in the past with older versions of Ubuntu eg. 18.04 or 16.04 so might be worth trying that if you have time to spin up another VM. Like you I have encountered errors when trying to use Ubuntu 22.04, and last time I checked the Raspberry Pi kernel did not include adfs support.

[mmelbourne]

Thanks for the suggestions.

I think the Risc PC it was taken from was running at least RO4 (I don't have it now to check, and should've made a note of it). I'm thinking it must've been a release which supported >32GB partitions (as this is larger).

I've just tried RPCemu with both Easy-Start bundles and neither work: I suspect the RO 3.7 one doesn't recognise the RO4 ADFS format, and Risc OS Direct (5.27) doesn't support accessing *.hdf images (as far as I can tell).

I can definitely try an older version of Ubuntu.

[MillieTD83]

ADFS (Extended) came in RO4, and the ADFS module in Linux I don't think supports that either. Throw some RO4 ROMs at RPCEmu and that should read it quite happily.

RO5 doesn't support the IDE system in RPCEmu so it won't be able to read and image files. You need 3.7, 4 or 6 for best results I believe.

[mmelbourne]

Is the RiscPC running RISC OS 3 or 4?

I have had more success in the past with older versions of Ubuntu eg. 18.04 or 16.04 so might be worth trying that if you have time to spin up another VM. Like you I have encountered errors when trying to use Ubuntu 22.04, and last time I checked the Raspberry Pi kernel did not include adfs support.

I've just tried Ubuntu 18.04.6 and that can read the image without issues.

In terms of OS, I don't remember having long filenames, so maybe not ADFS (Extended)?

I'll try RPCEmu with some RO4 ROMs as another option.

Thanks!

[mmelbourne]

ADFS (Extended) came in RO4, and the ADFS module in Linux I don't think supports that either. Throw some RO4 ROMs at RPCEmu and that should read it quite happily.

RO5 doesn't support the IDE system in RPCEmu so it won't be able to read and image files. You need 3.7, 4 or 6 for best results I believe.

I tried RO 4.02 in RPCEmu, and the drive is not recognised (:5 below icon) and generates a "Disc Error 02 at :5/0000000000000006".

[MillieTD83]

ADFS (Extended) came in RO4, and the ADFS module in Linux I don't think supports that either. Throw some RO4 ROMs at RPCEmu and that should read it quite happily.

RO5 doesn't support the IDE system in RPCEmu so it won't be able to read and image files. You need 3.7, 4 or 6 for best results I believe.

I tried RO 4.02 in RPCEmu, and the drive is not recognised (:5 below icon) and generates a "Disc Error 02 at :5/0000000000000006".

Disklabel type: dos
Disk identifier: 0xb3be3e36

Device Boot Start End Sectors Size Id Type
/dev/sda1 16065 78156224 78140160 37.3G f W95 Ext'd (LBA)
/dev/sda5 16128 78156224 78140097 37.3G b W95 FAT32


I'm guessing fdisk isn't quite sure what to make of ADFS so it just assumes it's FAT32? But if it is indeed FAT32 then RISCOS wouldn't know what to do with it.

[BeebMaster]

I imaged the hard drive in my RISC PC 700 (running RISC OS 3.70) and can mount it in Ubuntu.

I made the image from RISC OS, however, reading disc sectors using the ADFS SWI calls and putting the contents to file stored on my Ubuntu NFS server (in chunks, then catted it together).

So it's possible it didn't capture anything prior to "RISC OS sector 0" so to speak, like the partition table etc.

The disc is 40GB, as is the image file, and I can mount the image "RPCHD4" with:

sudo mount -t adfs -o loop,uid=1000 RPCHD4 /media/disc

The problem I had is that Linux ADFS doesn't support space-character directory names (L4 file server uses directories named with a CHR$160 character to extend to 255 entries required by the Econet spec) so much of the disc isn't readable when it is mounted.

[mmelbourne]

ADFS (Extended) came in RO4, and the ADFS module in Linux I don't think supports that either. Throw some RO4 ROMs at RPCEmu and that should read it quite happily.

RO5 doesn't support the IDE system in RPCEmu so it won't be able to read and image files. You need 3.7, 4 or 6 for best results I believe.

I tried RO 4.02 in RPCEmu, and the drive is not recognised (:5 below icon) and generates a "Disc Error 02 at :5/0000000000000006".

Disklabel type: dos
Disk identifier: 0xb3be3e36

Device Boot Start End Sectors Size Id Type
/dev/sda1 16065 78156224 78140160 37.3G f W95 Ext'd (LBA)
/dev/sda5 16128 78156224 78140097 37.3G b W95 FAT32


I'm guessing fdisk isn't quite sure what to make of ADFS so it just assumes it's FAT32? But if it is indeed FAT32 then RISCOS wouldn't know what to do with it.

I agree. That looked odd to me too, I don't know whether it's a mis-identification or if there's something unique and odd to this disk. However, there is data on the disk which looks like a MSWIN4.1 boot sector (looking at the hexdump), but it's also readable under Ubuntu 18, so there must be enough of an ADFS disk structure there. I just can't remember the history of this drive and if it was an original or a replacement.

[BeebMaster]

Another idea might be that it was previously used in a PC and the remnants of its previous use are still there. That's the case with my RISC PC hard drive, it came from a Dell PC. Although I formatted it with !HForm, there are still tons of references to its previous life littered throughout the disc. I don't think it was actually "formatted" in the sense we would understand, I think the formatter just wrote a new RISC OS ADFS structure to the disc.

[wiggy]

I'm guessing fdisk isn't quite sure what to make of ADFS ....

I'm fairly sure the Linux fdisk only understands "PC" partition tables, and most (if not all) only understand MBR and not GPT.

It's a user-space tool, so doesn't get to share the kernel's extra knowledge of partition tables.

Which might also be why newer Ubuntu is struggling: not the ADFS File System module is missing (it's probably unsupported), but that the kernel wasn't built with support for the Acorn partition tables (which is in a different area of the kernel code and IIRC can't be built as modules - they have to be built into the core kernel image (and are probably also unsupported).

[Phipli]

Another idea might be that it was previously used in a PC and the remnants of its previous use are still there. That's the case with my RISC PC hard drive, it came from a Dell PC. Although I formatted it with !HForm, there are still tons of references to its previous life littered throughout the disc. I don't think it was actually "formatted" in the sense we would understand, I think the formatter just wrote a new RISC OS ADFS structure to the disc.

To save time when formatting, (unless you do a secure format, which writes all zeros or random zeros and ones to a disk) all the old content remains, except where the new formatting overwrites it.

This means when you look at a raw disk image it's all full of old data not identified in the file listings... Which is why you should always think long and hard before uploading a disk image of your hard disk.

Some software allows you to zero out unused space when generating a disk image (not talking Acorn specifically here).

A good clue to whether there is lots of data in the unused space on your disk image is, say you have a 40MB disk with 5MB of files, and you image it, if it is all zeros other than your files, it should easily compress from 40MB to 5MB or less... If it doesn't compress close to 5MB, say only to 20MB, it likely has lots of recoverable data hidden in the unused space!