Jump to content

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


Recommended Posts

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 by alexmocanu
Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by jaclaz
Link to comment
Share on other sites

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 by alexmocanu
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by jaclaz
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by alexmocanu
Link to comment
Share on other sites

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 by jaclaz
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...