挂载旧的软盘映像文件（.ima 格式） - 有多难？
我正在尝试在 ArchLinux 上mount访问 .ima 格式的软盘映像文件（原始转储到软盘，类似于.img）。
此文件是 30 个文件集的一部分。它不可引导，而是文件集的延续。目的不是为了安装或克隆而进行操作。我对磁盘上其他数据所包含的文档感兴趣。
图像文件信息
以下是有关此图像文件的一些信息：
# 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 -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
我尝试了多种组合，尝试使用 -t 指定类型，即 ntfs、msdos、iso9660、vfat，但总是遇到相同的错误。我认为这可能是某种 ntfs 文件格式，但 ntfs-3G 并没有做得更好，所以不，它不是：
# 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)
有人建议使用 Minix fs。虽然不清楚我是否真的可以使用当前的配置挂载这样的文件系统，但我尝试过：
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.
这似乎不是决定性的，因为当您指定特定类型的文件系统时，日志中将出现特定类型的错误。也试过[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..
我在哪里可以看到这样的事情dmesg：
[ 5316.082629] FAT-fs (loop0): invalid media value (0xf6)
[ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem
另外，lsmod | grep loop给
loop 18511 0
没有任何类型的备用超级块：
# 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
与我读到的许多情况相反，似乎没有必要在此处指定任何偏移量，因为图像中没有内置分区。在这种情况下，有时该dd命令用于使用允许安装的偏移值将内容传输到类似图像。这似乎与mount直接指定命令的偏移量相同。但是，这应该是很容易，像在这其中一个简单的另一种情况下losetup被使用，并且然后循环装置被安装。我可以将 .ima 文件与 Lostup 链接，但是当我尝试安装循环设备时，我最终得到了初始错误消息。
数据的完整性
最后，safecopy --stage1不报告任何数据问题，直到第 3 阶段的输出保持不变并产生相同的错误：
# 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%
Done!
Recovered bad blocks: 0
Unrecoverable bad blocks (bytes): 0 (0)
Blocks (bytes) copied: 360 (1474560)
这是文件的顶部，内容似乎完好无损：
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 |................|
“法医”
由于原始映像由源介质的逐个扇区二进制副本组成，文件内容的实际格式将取决于创建映像的磁盘的文件系统（例如 FAT 的版本）。 [...] 由于 IMG 文件不包含磁盘内容之外的其他数据，因此这些文件只能由可以检测其文件系统的程序处理。
根据建议，我继续分析集合中的其他一些图像文件（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
抱歉，它确实看起来像一个分区表，但它不寻常。它包括id 90 属性：
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)
所以试图挂载我得到的图像：
# mount -t auto U14.IMA /mnt/cd
mount: unknown filesystem type 'sysv' <-----
正如有人暗示的那样，您需要在内核中编译诸如“ System V and Coherent filesystem support ”之类的特定内容，以便使用类似. sysv 字符串并不令人惊讶，因为它是 AT&T UNIX System V/386 Release 4 Version 2.1 安装介质的一部分 - Sun一直支持到 2006年的端口- 这些图像最终在 2007 年被废弃。实际上是一个文本与映像捆绑在一起的文件表明由于引导扇区的性质和使用的格式，它们是安装所必需的。有迹象表明该材料最初是Teledisk (TD0)格式mount -t sysv. 我想在这里强调，这不是原创材料。在任何情况下，我都无法像问题中解释的那样实际计算偏移量 - 或者我在除以 512 时没有得到整数，即使我尝试似乎也找不到合适的偏移量 -dd: cannot skip to specified offset, 0 writes等等。所以在这一点上，答案是关于取证，而不是关于图像文件。
使用 qemu 快速模拟历史图像源操作系统
AT&T UNIX System V 第 4 版 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
Package
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
License
正如建议的那样，我从集合中的先前图像安装。它涉及使用qemu 这里所解释的，基本上从镜像 14 开始（先是losetup /dev/loop0 U14.IMA简单的qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a），因为 U19 是不可引导的。这里的好处是您不必在操作系统本身中挂载/卸载图像，您只需使用ctrl-alt-2qemu 或 1 来访问或离开监视器，然后您就list blocks可以查看已挂载的内容并change floppy0 imagename在该界面中更改图像文件，例如在安装过程中。
我必须在安装期间提供 U19.IMA（磁盘 5）（有关安装的文本日志，请参阅此- 一个亮点是对 MS-DOS 的引用！），我最终得到了这个，即正确安装的 AT&T UNIX Sys V 386 OS，所以这几乎证实了 U19.IMA 是一个可用的磁盘映像：
默认情况下 /dev/fd 安装在 /dev/fd 上，并且还可以通过块 (/dev/dsk/f0) 和原始 (/dev/dsk/f0) 设备进行软盘访问。将目录更改为软盘只会显示编号为 1 到 23 的文件（我猜这只是字符设备的结构）。您还可以cat查看原始设备和块设备并查看软盘数据是否存在，但这已经很接近了。
我注意到在该操作系统中，您不会像使用解压缩的二进制文件那样从软盘上的目录启动一些脚本来安装软盘中的东西 - 在这里您使用pkgadd -d diskette1（当然最后一个词是一些别名，但我在pkgadd(1M)的 SCO 资料中找到了对 -d 开关的引用通常它经常出现在商业 Unix 中（Oracle，HP share pkgadd(1M) ）。发出命令会启动一个例程，您可以在其中提供软盘并且您无法控制，除非在例程找到驱动器中的内容后说“不”。对于开始安装顺序的磁盘（U03、U05 等），这将安装然后请求下一张软盘等，直到软件包安装完成。如果您放置的软盘不是一组开始，它基本上什么也找不到，但会告诉您可能必须使用该installpkg命令。
我是否会在我的设备上安装物理软盘驱动器以访问该映像文件中的数据？
小智 5
如果您无法安装图像，在某些情况下您仍然可以使用cpio.
一旦您确定图像是否：
- 使用受支持的文件系统和分区的映像 -->
mount - 使用受支持的文件系统和多个分区的映像 -->
mount with offset，或用于dd提取带有偏移量的分区，然后仅安装该分区或使用类似的东西kpartx - 不使用受支持的文件系统或根本没有文件系统的映像 --> 内核支持和进一步调查...
您可以使用hexdump和strings实用程序尝试分析标头并从图像中提取文本字符串，并获取有关图像文件及其结构的更多信息。
有件事引起了我这样做的兴趣：
@(#)/usr/bin/echo.sl 1.1 4.0 10/01/90 16865 AT&T-SF
图像中的每个二进制文件都有这样的一行，因此您在某种程度上知道其中的内容。另外，在这种情况下，当您仔细查看原始平台上的安装过程是如何发生的时installpkg，您会发现：
将软件从软盘传输到 UNIX System V /386 硬盘的基本机制是 cpio。
基本上，数据是通过cpio/usr/tmp/install 提取的，并且其中包含一系列文件（安装、ascii、文件、名称和大小文件）。这里碰巧的是这个命令：
cat U19.IMA | cpio -imdv
首先输出格式错误的数字错误，但随后创建一个包含图像内容的 /usr/bin 文件夹！我tr正在寻找的就在那里：
#file tr
tr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped.
cpio首先尝试不会有什么坏处！