Mounting partitions on a drive that's using Ontrack Disk Manager?

[alexmocanu]

I have a very old laptop (Dell Latitude L400) I use for retro-gaming in which I replaced the the hard drive with a CF Card Adapter and I use several 16 GB cards with it, swapping them as needed.

Since the BIOS doesn't recognize the cards at their full capacity (it sees them as 400 MB drives) I had to use Ontrack Disk Manager (version 9.4) to setup those cards, So far everything seems to be ok, I was able to install DOS and Windows 98 on them and they see these cards at full capacity.

The problem is that sometimes I would like to be able to use these cards with my main Windows 10 machine to transfer files faster than using the network, usb drives or burning cd's. Since Ontrack uses a custom partitioning scheme (it installs itself at the beginning of the drive and shifts the partition table to make room) I can't use these cards with neither Windows 10 or Linux (Ubuntu 18.04).

So Is there any tool that would allow me to either mount the drives or be able to read/write data to them using a standard USB card reader? Any solution that would work on Windows, Linux or OSX would be perfect.

 

Edited September 3, 2018 by alexmocanu

[rloew]

I could modify an USB Driver to access the cards, but only for Windows 9x.

A tool to shift the data back to a normal position would not be hard to write. You could then use a non-interfering DDO, such as my BOOTMAN Package, to support your L400 as well.

[alexmocanu]

Thank You for answering.

Modifying a USB driver would not do for my use case, I need to be able to read those cards on any modern machine to transfer files easily.

BOOTMAN would seem to be a better choice, so I downloaded both demo packages from you site and ran the "48bitlba.exe" tests and they returned these messages:

BOOTMAND => "Drive 80: 495MB = 0967680 Sectors Not 48-Bit Disk"
BOOTMAN1 => "Drive 1: 495MB = 967680 Sectors Not 48-Bit Disk"

That means that my cf adapter and card might not be combatible with BOOTMAN on this particular machine?

For reference I used the same CF Card with both packages (a 16 GB Sandisk Ultra card) and the CF adapter is a Delock 91655.
If it makes any difference I copied the contents of those 2 packages to some win98 boot floppy images and booted them using CD's and over the network using PXE with the same result.

[jaclaz]

Well, more or less, the volume(s) on those cards must be on (contiguous) extent(s).

Nothing - in theory - would prevent you to use  IMDISK to map a contiguous extent to a volume, allowing you to access it.

See:

http://reboot.pro/topic/20450-mounting-split-image/?p=192170

Whether this will be allowed in (stupid) Windows 10 is to be tested.

On Linux, mount using the offset and (if needed) sizelimit *like*:

https://raspberrypi.stackexchange.com/questions/13137/how-can-i-mount-a-raspberry-pi-linux-distro-image/13138#13138

should do nicely,

The only needed thing is to find the beginning offset and length/size of the volume(s), but this shouldn't be difficult if you can view the actual sector on the machine where the Ontack software is installed.

jaclaz

Edited September 3, 2018 by jaclaz

[alexmocanu]

I was able to mount the FAT32 partition on that card on Linux like this. From what I read so far Ontrack shifts the partition table to sector 63 So I thought about trying with loop devices.

On my machine the USB CF card reader appears as /dev/sdb with this OnTrack partition:
 

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *        9 31291784 31291776 14.9G 54 OnTrackDM6

First I scanned the device:

losetup --partscan --find --show -o 32256 /dev/sdb

Where 32256 = 63 sectors * 512 bytes per sector
This return the name of a loop device (in my case it was loop0)

Then i listed the content of that loop device:
 

fdisk /dev/loop0 -l

Which returned this:
 

Device       Boot Start      End  Sectors  Size Id Type
/dev/loop0p1 *       63 31278554 31278492 14.9G  c W95 FAT32 (LBA)

From there I saw that the FAT32 partition is accessible under /dev/loop0p1 so I mounted that with a command like this:
 

mount /dev/loop0p1 /mnt/my_card

And now I can easily transfer files from/to that card. Next step would be to find a solution for Windows.

I tried using IMDISK (as administrator) but no luck so far ... it mounted something under the "X:" letter but asked me to format the drive:
 

imdisk -a -f \\.\physicaldrive3 -b 32256 -s 16014587904 -o ro -m X:

For "-s" I calculated size = no. of sectors * 512

Edited September 3, 2018 by alexmocanu

[rloew]

BOOTMAN was written to support >137GB Hard Drives with BIOSes that supported up to 137GB.

The 48BITLBA Program only tests for that limit.

I have different versions of BOOTMAN for even older BIOSes.

You would still need a program to remove the OnTrack Offset.

[jaclaz]

14 hours ago, alexmocanu said:

I was able to mount the FAT32 partition on that card on Linux like this.

Good.

14 hours ago, alexmocanu said:

I tried using IMDISK (as administrator) but no luck so far ... it mounted something under the "X:" letter but asked me to format the drive:
 

imdisk -a -f \\.\physicaldrive3 -b 32256 -s 16014587904 -o ro -m X:

For "-s" I calculated size = no. of sectors * 512

It is possible that *something* in Windows 10 prevents that from working, but you should have a look at the first sector of the X: drive, maybe - for whatever reasons - the way the offset is "seen" under windows is different, I was expecting more (in case of issues) something like an "access denied" kind of error.

Or maybe viceversa the losetup is using a different offset, not relative to the sector 0 of the physical device (i.e. since you already started with an offset of 32256 bytes its scan, the actual bootsector is on 63+63=126 sectors inside the image), though from what you posted it doesn't seem so, you can still try the "direct" mount with offset I suggested early that should be the direct equivalent to IMDISK usage.

Unfortunately - due to the nature of IMDISK being a volume (and not a disk) virtual driver - it hooks not to many of the usual windows subsystems, so mountvol, diskpart and disk manager cannot be used to see what is happening and you need a hex view of the first sector to check it is actually the bootsector/PBR.

 

Alternatively, dd the first 128 sectors of the physicaldrive (or of sdb in Linux) to a file, compress it to a zip and attach it to your next post, and I will have a look at it.

jaclaz

 

Edited September 4, 2018 by jaclaz

[rloew]

Try Sector 72. Use Offset 36864.

[alexmocanu]

Sorry for the late reply.

I tried with that offset but it's the same... no luck.

I have attached the first 500 KB from one of those CF cards in case it helps.

dump.img

[rloew]

The offset is 63 Sectors. The MBR is at Sector 63. The PBR is at Sector 126.

There appear to be 3 Files, using less than 350KB.

[jaclaz]

Yep .

The MBR (shifted to offset 63 sectors) has these data:

#0 0C 80 0 1 1 1023 254 63   63 31278492

The PBR which  is at offset 63 from the MBR, i.e. offset 126 of the physicaldrive and has these data: 

 3     0003    OEM String:           MSWIN4.1                
11     000B    Bytes per sector:     0200   512
13     000D    Sectors per cluster:    10   16
14     000E    Reserved sectors:     0020   32
16     0010    Number of FAT(s):       02   2
17     0011    Max ROOT entries:     0000   0
19     0013    Small type sectors:   0000   0
21     0015    Media type:             F8   248
22     0016    Secs per FAT (small): 0000   0
24     0018    Sectors per Head:     003F   63
26     001A    Number of Heads:      00FF   255
28     001C    Sectors Before:   0000003F   63
32     0020    Large Sectors:    01DD459C   31278492

Since IMDISK mounts the volume you need to double the offset

offset=(63+63)*512= 64512

whilst the length is correct:

length= 31278492*512=16014587904

jaclaz

[alexmocanu]

Thanks for your help,

Offset 64512 worked perfectly and Windows recognized the new drive.

I've done some more tests by transferring data to/from the CF card, booted the old laptop from it, ran some dos games and so far it seems to work, no data loss or anything so far.

Edited September 8, 2018 by alexmocanu

[jaclaz]

Good.

Bonus (in theory, needs to be tested), should you need for any reason to have a "normal" device.

If from the IMDISK GUI you have available the mounted drive and press the "Save Image" button, you should have the option to save the image "as is" (aka volume or "superfloppy") or to prepend to it a MBR (without booting code but with valid partition table) and 62 empty sectors[1], in practice a valid "whole disk" image that you can dd to another media, essentially stripping the Ontrack overlay. 

jaclaz

[1] this is the behaviour under XP cannto say if newer IMDISK and/or having it running on windows 10 makes that 2047, but I doubt it.

Edited September 8, 2018 by jaclaz