mountArchLinuxで.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コマンドにオフセットを直接指定するのと同じように見えます。しかし、これは、simple が使用されてからループデバイスがマウントされるこの他の場合のように、簡単なはずlosetupです。.imaファイルをlosetupでリンクできますが、ループデバイスをマウントしようとすると、最初のエラーメッセージが表示されます。
データの整合性
最後に、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 |................|
「フォレンジック」
RAWイメージはソースメディアのセクターごとのバイナリコピーで構成されるため、ファイルの内容の実際のフォーマットは、イメージの作成元のディスクのファイルシステム（FATのバージョンなど）によって異なります。 [...] IMGファイルはディスクの内容以外の追加データを保持しないため、これらのファイルは、ファイルシステムを検出できるプログラムによってのみ処理できます。
提案に従って、私は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
申し訳ありませんが、パーティションテーブルのように見えますが、異常です。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とCoherentファイルシステムのサポート」のような特定のものをコンパイルする必要がありますmount -t sysv。これはAT＆T UNIXシステムV / 386リリース4バージョン2.1インストールメディア（2006年まで Sunによってサポートされていたポート）の一部であり、これらのイメージは2007年に乱暴に使用されたため、sysv文字列はそれほど驚くべきものではありません。イメージにバンドルされているファイルは、ブートセクターの性質と使用中のフォーマットのため、インストールに必要であることを示しています。素材がもともとTeledisk（TD0）形式であったという指摘があります。これはオリジナルの素材ではないことを強調しておきます。いずれにしても、質問で説明されているように実際にオフセットを計算することはできません-512で除算したときに整数で終わらないか、試しても適切なオフセットが見つからないようです- dd: cannot skip to specified offset, 0 writesなど。この時点での答えはフォレンジックについてであり、もはや画像ファイルについてではありません。
qemuによる過去のイメージソースOSのエミュレーション
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
提案されたように、私はセット内の以前のイメージからインストールしました。U19は起動できないため、基本的にqemu はここで説明されているように、イメージ14（最初losetup /dev/loop0 U14.IMAは単純なqemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a）から使用します。ここで良いのは、OS自体でイメージをマウント/アンマウントする必要がないことですctrl-alt-2。qemuでor 1を使用list blocksして、モニターにアクセスしたり、モニターから離れたりすることで、マウントさchange floppy0 imagenameれているものを確認し、そのインターフェイスでイメージを変更できます。たとえば、インストール中のファイル。
インストール中にU19.IMA（ディスク5）を提供する必要があり（インストールのテキストログについては、これを参照してください-ハイライトはMS-DOSへの参照です！）、つまり、適切にインストールされたAT＆T UNIX Sysになりました。 V 386OS。U19.IMAが作業用ディスクイメージであることを確認します。
デフォルトでは、/ dev / fdは/ dev / fdにマウントされ、ブロック（/ dev / dsk / f0）およびraw（/ dev / dsk / f0）デバイスを介したフロッピーアクセスもあります。ディレクトリをフロッピーに変更すると、1から23までの番号が付いたファイルが表示されます（これは私が推測するキャラクターデバイスの構造にすぎません）。cat未加工デバイスとブロックデバイスを使用して、フロッピーデータが存在することを確認することもできますが、それは可能な限り近くなります。
そのOSでは、たとえば解凍したバイナリファイルを使用する場合のように、ディレクトリからスクリプトを起動してフロッピーからのものをインストールしないことに気づきました-ここで使用しますpkgadd -d diskette1（確かに、最後の単語はエイリアスですが、私はpkgadd（1M）の SCOに-dスイッチへの参照が見つかりましたそして一般的にそれは商用Unix（Oracle、HP共有pkgadd（1M））にしばしば現れます。コマンドを発行すると、フロッピーを提供するルーチンが起動し、ルーチンはドライブに何があるかを見つけた後に「いいえ」と言う以外は制御できません。インストールシーケンスを開始するディスク（U03、U05など）の場合、これはインストールされ、パッケージのインストールが完了するまで次のフロッピーなどを要求します。セットの先頭ではないフロッピーを置くと、基本的に何も検出されませんが、installpkg代わりにコマンドを使用する必要があることが通知されます。
リグに物理フロッピードライブをインストールして、そのイメージファイルのデータにアクセスしますか？
mount -t minix -o loop U19.IMA /mnt/cdと、一般的なエラーが発生しますが、これはdmesgにVFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.表示されます。カーネルがすでにそれを持っているか、それを信頼できないということですか。とにかく、私はあなたが言ったことを調査します。起動できないことはわかっていますが、コンテンツにアクセスしたいのですが。ありがとう。
file、イメージにファイルシステムがないことを示しています。データは実際にそこにありますか？パーティションもファイルシステムもないrawドライブのイメージをマウントしようとしているようです。