I'm trying to mount and access a floppy image file in the .ima format (raw dump to floppy, similar to .img) on ArchLinux.

This file is part of a set of 30. It is not bootable, but rather a continuation of a set. The purpose is not manipulation for the sake of installation or cloning. I'm interested in the documentation contained with other data on the disk.

Image file information

Here is some info about this image file:

# file U19.IMA
U19.IMA: PC formatted floppy with no filesystem

# fdisk -lu U19.IMA
Disk U19.IMA: 1.4 MiB, 1474560 bytes, 2880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

(parted) print
Error: /home/meh/Downloads/U19.IMA: unrecognised disk label
Model: (file)
Disk /home/meh/Downloads/U19.IMA: 1475kB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

Mount fail

Here's the generic error message:

mount -o ro,loop U19.IMA /mnt/cd/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error

I've tried many combinations trying to specify a type with -t i.e. ntfs, msdos, iso9660, vfat, and always getting that same error. I thought it's maybe some kind of ntfs file format but ntfs-3G doesn't do much better so no it's not:

# ntfs-3g -o loop U19.IMA /mnt
NTFS signature is missing.
Failed to mount '/home/meh/Downloads/U19.IMA': Invalid argument
The device '/home/meh/Downloads/U19.IMA' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

# ntfsclone -r -o file.img U19.IMA
ntfsclone v2013.1.13 (libntfs-3g)
ERROR: Input file is not an image! (invalid magic)

Someone suggested maybe a Minix fs. While it is not clear if I can really mount such a filesystem with my current configuration I tried:

mount -t minix -o loop U19.IMA /mnt/cd
which gave the generic error but there was this at the bottom of the log:
VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.

It seems this is not conclusive, as when you specify a specific type of filesystem you will have a specific type of error in the log. Also tried [fuseiso][2]:

# fuseiso U19.IMA /mnt/cd
init: wrong standard identifier in volume descriptor 0, skipping..
init: wrong standard identifier in volume descriptor 1, skipping..
init: wrong standard identifier in volume descriptor 2, skipping..
init: wrong standard identifier in volume descriptor 3, skipping..
init: wrong standard identifier in volume descriptor 4, skipping..
init: wrong standard identifier in volume descriptor 5, skipping..
init: wrong standard identifier in volume descriptor 6, skipping..
init: wrong standard identifier in volume descriptor 7, skipping..
init: wrong standard identifier in volume descriptor 8, skipping..
init: wrong standard identifier in volume descriptor 9, skipping..
init: wrong standard identifier in volume descriptor 10, skipping..
init: wrong standard identifier in volume descriptor 11, skipping..
init: wrong standard identifier in volume descriptor 12, skipping..
init: wrong standard identifier in volume descriptor 13, skipping..
init: wrong standard identifier in volume descriptor 14, skipping..
init: wrong standard identifier in volume descriptor 15, skipping..
init: wrong standard identifier in volume descriptor 16, skipping..
init: wrong standard identifier in volume descriptor 17, exiting..

Where I can see such things with dmesg:

[ 5316.082629] FAT-fs (loop0): invalid media value (0xf6)
[ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem

Also, lsmod | grep loop gives

loop 18511 0

There is no alternate superblock of any kind:

# mkfs -n U19.IMA
mke2fs 1.42.8 (20-Jun-2013)
U19.IMA is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=1572864
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group

Contrary to many cases I read about, there seems to be no need to specify any offset here as there are no partition built in the image. In such cases, sometimes the dd command is used to transfer the content to a similar image using an offset value which allows mounting. This seems the same as specifying an offset to the mount command directly. But this should be easy, like in this other case where a simple losetup is used and then the loop device is mounted. I can link the .ima file with losetup but when I try to mount the loop device I end up with my initial error message.

Data integrity

Finally, safecopy --stage1 doesn't report any issue with the data and the output up to stage 3 remains the same and yields the same error:

# safecopy U19.IMA test.img --stage1
Low level device calls enabled mode: 2
Reported hw blocksize: 4096
Reported low level blocksize: 4096
File size: 1474560
Blocksize: 4096
Fault skip blocksize: 147456
Resolution: 147456
Min read attempts: 1
Head moves on read error: 0
Badblocks output: stage1.badblocks
Marker string: BaDbLoCk
Starting block: 0
Source: U19.IMA
Destination: test.img
. ;-} 100%
Recovered bad blocks: 0
Unrecoverable bad blocks (bytes): 0 (0)
Blocks (bytes) copied: 360 (1474560)

Here's the top of the file and the content seems to be intact:

dd if=U19.IMA | hexdump -C | head -n 10
00000000 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 |................|
00004600 34 2e 30 2e 32 20 33 38 36 75 6e 69 78 20 46 6e |4.0.2 386unix Fn|
00004610 64 20 53 65 74 20 35 20 6f 66 20 31 30 0a 00 00 |d Set 5 of 10...|
00004620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|


Since a raw image consists of a sector-by-sector binary copy of the source medium, the actual format of the file contents will depend on the file system of the disk from which the image was created (such as a version of FAT).[...] Since IMG files hold no additional data beyond the disk contents, these files can only be handled by programs that can detect their file systems.

Following suggestions, I proceeded to analyze some of the other image files in the set(30):

fdisk -lu U14.IMA
Disk U14.IMA: 1.4 MiB, 1474560 bytes, 2880 sectors
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: 0x00000000
This doesn't look like a partition table. Probably you selected the wrong device.

Device Boot Start End Blocks Id System
U14.IMA1   3840       11519      3840       0  Empty
U14.IMA2   2425393152 4850786447 1212696648 0  Empty
U14.IMA3 ? 2425393296 4850786591 1212696648 90 Unknown
U14.IMA4 ? 2425393296 4850786591 1212696648 90 Unknown

Sorry but it does look like a partition table but it is unusual. It includes the id 90 property:

90h     MBR, EBR    CHS, LBA    x86, 68000, 8080/Z80    Hidden, Filesystem  FreeDOS     Free FDISK  Hidden FAT16 (corresponds with 04h i.e. MS Fat16 DOS 3.0+ < 65536 sectors)

So trying to mount the image I get:

# mount -t auto U14.IMA /mnt/cd
mount: unknown filesystem type 'sysv'  <-----

As someone hinted, you need to have something specific like 'System V and Coherent filesystem support' compiled in the kernel in order to use something like mount -t sysv. The sysv string is not so suprising, since this is part of AT&T UNIX System V/386 Release 4 Version 2.1 install media - a port which was supported by Sun until 2006 - and these images ended up in the wild in 2007. Actually a text file bundled with the images indicates that they are required for installation because of the nature of the boot sector and the format in use. There is an indication that the material was originally in Teledisk (TD0) format. I want to stress here that this is not original material. In any case I can't actually calculate the offsets like explained in the question - either I don't end up with integers when dividing by 512, and even if I try it seems I can't find the proper offset - dd: cannot skip to specified offset, 0 writes etc. So at this point the answer is about forensics, and no longer about an image file.

Quick historical image source OS emulation with qemu

AT&T UNIX System V Release 4 Version 2.1

                          LABEL             Version         X of X
  AT&T UNIX SVR4.0 2.1 --------------------------------------------------

  U01.IMA                 Maintanace Disk1  2.1             2 of 2
  U02.IMA                 Remote Terminal   2.1             1 of 1
  U03.IMA                 BSD Comp. Pkg.    2.1             1 of 2
  U04.IMA                 BSD Comp. Pkg.    2.1             2 of 2
  U05.IMA                 Networking Supp.  2.1             1 of 1
                          Util. Pkg.
  U06.IMA                 Xenix Comp. Pkg   2.1             1 of 1
  U07.IMA                 FACE Pkg.         2.1             1 of 1
  U08.IMA                 FMLI Pkg.         2.1             1 of 1
  U09.IMA                 Editing Utils.    2.1             1 of 1
  U10.IMA                 OA&M Basic & Ext. 2.1             1 of 3
  U11.IMA                 OA&M Basic & Ext. 2.1             2 of 3
  U12.IMA                 OA&M Basic & Ext. 2.1             3 of 3
  U13.IMA                 Foundation Set    2.1             1 of 10
                          Base System Pkg.
                          2 User System
  U14.IMA                 Base              2.1a            1 of 10
  U15.IMA                 Base              2.1             2 of 10
  U16.IMA                 Base              2.1a            2 of 10
  U17.IMA                 Base              2.1             3 of 10
  U18.IMA                 Base              2.1             4 of 10
  U19.IMA                 Base              2.1             5 of 10
  U20.IMA                 Base              2.1             6 of 10
  U21.IMA                 Base              2.1             7 of 10
  U22.IMA                 Base              2.1             8 of 10
  U23.IMA                 Base              2.1             10 of 10
  U24.IMA                 Maintanance 1     2.1             1 of 2
  U25.IMA                 Base              2.1             9 of 10
  U26.IMA                 Printer Pkg       2.1             3 of 3
  U27.IMA                 Printer Pkg       2.1             2 of 3
  U28.IMA                 Printer Pkg       2.1             1 of 3
  U29.IMA                 16 to unlimited   2.1             1 of 1
                          User License
  U30.IMA                 2 to 16 User      2.1             1 of 1

As was suggested, I installed from a prior image in the set. It involves using qemu like explained here basically starting with image 14 (first losetup /dev/loop0 U14.IMA then a simple qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a), as U19 is not bootable. What is nice here is that you don't have to mount/umount images in the OS itself, you just use ctrl-alt-2 or 1 with qemu to access or leave the monitor and you use list blocks to see what is mounted and change floppy0 imagename in that interface to change the image file i.e. during install for instance.

I had to supply U19.IMA (disk 5) during installation (for a textual log of the install, see this - a highlight is the reference to MS-DOS!), and I ended up with this i.e. a properly installed AT&T UNIX Sys V 386 OS, so this pretty much confirms U19.IMA is a working disk image:

enter image description here

By default /dev/fd is mounted on /dev/fd and there is also floppy access through a block (/dev/dsk/f0) and raw (/dev/dsk/f0) device. Changing directory to the floppy just shows files numbered from 1 to 23 (this is just the structure of the character device I guess). You can also cat the raw and block devices and see the floppy data is there but that's as close as it gets.

I've noticed that in that OS, you don't install stuff from floppies by launching some script from a directory on them like you do with decompressed binary files for instance - here you use pkgadd -d diskette1 (surely that last word is some alias, but I found a reference to the -d switch in the SCO stuff for pkgadd(1M) and generally it appears often in commercial Unix (Oracle, HP share pkgadd(1M) ). Issuing the command launches a routine where you supply floppies and you have no control, except saying "no" after the routine finds out what's in the drive. In the case of disks which begin an installation sequence (U03, U05 etc.), this will install then ask for the next floppy etc until the package install is complete. If you put a floppy that isn't the beginning of a set, it finds basically nothing but tells you maybe you have to use the installpkg command instead.

Will I be installing a physical floppy drive to my rig to access the data in that image file?

  • Just a guess: It could be a Minix filesystem. You probably need to recompile your kernel to support it. Installing a physical floppy drive does not help. How big is the image file? If your file is just a raw image, it definitely does not contain any of the (current/modern) filesystems you tried. It seems that it is not bootable on i386 systems.
    – jofel
    Commented Dec 27, 2013 at 13:03
  • @jofel The file is 1475k big. If I try to mount it like so mount -t minix -o loop U19.IMA /mnt/cd and I get the generic error but this lands in dmesg VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0. Is that any indication the kernel already has it or I can't rely on that?. Anyways, I'll investigate what you said. I know it's not bootable, I want to access the contents though. Thanks.
    – user44370
    Commented Dec 27, 2013 at 13:11
  • The output of file suggests there is no filesystem on the image. Are you sure your data is actually there? It sounds like you are trying to mount an image of a raw drive with no partitions and no filesystem.
    – terdon
    Commented Dec 27, 2013 at 13:24
  • @terdon This is exactly what I want to do indeed. Is that a logic fail? This is an installation set. I hoped to find "files", including documentation. Can I not access this outside of installing the whole thing?
    – user44370
    Commented Dec 27, 2013 at 13:26
  • 2
    If it is an installation disk, it could be that only the first disk contains a filesystem / is bootable. The other disks could contain only data in a custom format without any filesystem overhead.
    – jofel
    Commented Dec 27, 2013 at 15:10

1 Answer 1


If you can't mount the image you might still be able in some cases to "stream out" some of its data with cpio.

Once you've ascertained whether the image is:

  • An image using a supported filesystem and a partition --> mount
  • An image using a supported filesystem and more than one partition --> mount with offset, or use dd to extract a partition with offset then mount that partition only or use something like kpartx
  • An image not using a supported filesystem or with no filesystem at all --> kernel support and further investigation...

You can use the hexdump and strings utilities to try to analyze the header and to extract text strings from the image and gain more information about the image file and its structure.

Something captured my interest in doing so:

@(#)/usr/bin/echo.sl 1.1 4.0 10/01/90 16865 AT&T-SF

There's a line like this for every single binary in the image so you somewhat know what's in there. Also, in this case, when you take a closer look at how the installation process occurs on the original platform with installpkg, you find out that:

The basic mechanism to transfer software from a floppy disk to the UNIX System V /386 hard disk is cpio.

Basically, the data is extracted with cpio to /usr/tmp/install and a series of files are included with this (an install, ascii, file, name and size file). It so happens here that this command:

cat U19.IMA | cpio -imdv

outputs malformed number errors to begin with, but then creates a /usr/bin folder with the contents of the image! The tr I was looking for is there:

#file tr
tr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped.

Trying cpio in the first place can't hurt!

  • 1
    Just be careful with the -d option and cpio. I seem to remember this tried to extract directly to my root drive!
    – user44370
    Commented Feb 22, 2014 at 18:04

You must log in to answer this question.