Sto cercando di mountaccedere a un file di immagine floppy nel formato .ima (da dump grezzo a floppy, simile a .img ) su ArchLinux.
Questo file fa parte di un set di 30. Non è avviabile, ma piuttosto una continuazione di un set. Lo scopo non è la manipolazione per motivi di installazione o clonazione. Sono interessato alla documentazione contenuta con altri dati sul disco.
Informazioni sul file di immagine
Ecco alcune informazioni su questo file immagine:
# 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:
Il montaggio non riesce
Ecco il messaggio di errore generico:
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
Ho provato molte combinazioni cercando di specificare un tipo con -t cioè ntfs, msdos, iso9660, vfat e ottenendo sempre lo stesso errore. Ho pensato che fosse forse una sorta di formato di file ntfs ma ntfs-3G non fa molto meglio quindi no non lo è:
# 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)
Qualcuno ha suggerito forse un Minix fs. Anche se non è chiaro se posso davvero montare un tale filesystem con la mia configurazione attuale, ho provato:
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.
Sembra che ciò non sia conclusivo, poiché quando si specifica un tipo specifico di filesystem si avrà un tipo specifico di errore nel registro. Ho anche provato [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..
Dove posso vedere queste cose con dmesg:
[ 5316.082629] FAT-fs (loop0): invalid media value (0xf6)
[ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem
Inoltre, lsmod | grep loopdà
loop 18511 0
Non esiste alcun superblocco alternativo di alcun tipo:
# 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
Contrariamente a molti casi di cui ho letto, sembra che non ci sia bisogno di specificare alcun offset qui poiché non ci sono partizioni integrate nell'immagine. In tali casi, a volte il ddcomando viene utilizzato per trasferire il contenuto su un'immagine simile utilizzando un valore di offset che consente il montaggio. Ciò equivale a specificare direttamente un offset per il mountcomando. Ma questo dovrebbe essere facile, come in questo altro caso in cui losetupviene utilizzato un semplice e quindi viene montato il dispositivo loop. Posso collegare il file .ima con losetup ma quando provo a montare il dispositivo loop finisco con il mio messaggio di errore iniziale.
Integrità dei dati
Infine, safecopy --stage1non segnala alcun problema con i dati e l'output fino allo stadio 3 rimane lo stesso e produce lo stesso errore:
# 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)
Ecco la parte superiore del file e il contenuto sembra essere intatto:
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 |................|
"Forense"
Poiché un'immagine non elaborata è costituita da una copia binaria settore per settore del supporto di origine, il formato effettivo del contenuto del file dipenderà dal file system del disco da cui è stata creata l'immagine (come una versione di FAT). [...] Poiché i file IMG non contengono dati aggiuntivi oltre al contenuto del disco, questi file possono essere gestiti solo da programmi in grado di rilevare i loro file system.
Seguendo i suggerimenti, ho proceduto ad analizzare alcuni degli altri file di immagine nel 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
Ci dispiace ma sembra una tabella delle partizioni ma è insolito. Include la proprietà 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)
Quindi provando a montare l'immagine ottengo:
# mount -t auto U14.IMA /mnt/cd
mount: unknown filesystem type 'sysv' <-----
Come qualcuno ha accennato, è necessario avere qualcosa di specifico come " Supporto per file system V e coerente " compilato nel kernel per poter usare qualcosa del genere mount -t sysv. La stringa sysv non è così sorprendente, poiché fa parte del supporto di installazione AT&T UNIX System V / 386 versione 4 versione 2.1 - una porta che è stata supportata da Sun fino al 2006 - e queste immagini sono finite in natura nel 2007. In realtà un testo il file in bundle con le immagini indica che sono necessari per l'installazione a causa della natura del settore di avvio e del formato in uso. V'è un'indicazione che il materiale era originariamente nel Teledisk (TD0) formato. Voglio sottolineare qui che questo non è materiale originale. In ogni caso non riesco davvero a calcolare gli offset come spiegato nella domanda - o non finisco con numeri interi quando si divide per 512, e anche se provo sembra che non riesca a trovare l'offset corretto - dd: cannot skip to specified offset, 0 writesecc. Quindi a questo punto la risposta riguarda la medicina legale e non più un file di immagine.
Emulazione rapida del sistema operativo della sorgente di immagini storiche con qemu
AT&T UNIX System V versione 4 versione 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
Come è stato suggerito, ho installato da un'immagine precedente nel set. Implica l'utilizzo di qemu come spiegato qui sostanzialmente a partire dall'immagine 14 (prima losetup /dev/loop0 U14.IMApoi una semplice qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a), poiché U19 non è avviabile. Ciò che è bello qui è che non devi montare / smontare immagini nel sistema operativo stesso, basta usare ctrl-alt-2o 1 con qemu per accedere o lasciare il monitor e usi list blocksper vedere cosa è montato e change floppy0 imagenamein quell'interfaccia per cambiare l'immagine file, ad esempio durante l'installazione.
Ho dovuto fornire U19.IMA (disco 5) durante l'installazione (per un registro testuale dell'installazione, vedi questo - un punto culminante è il riferimento a MS-DOS!), E ho finito con questo cioè un AT&T UNIX Sys correttamente installato V 386 OS, quindi questo conferma praticamente U19.IMA è un'immagine del disco funzionante:
Di default / dev / fd è montato su / dev / fd e c'è anche un accesso floppy attraverso un dispositivo a blocchi (/ dev / dsk / f0) e raw (/ dev / dsk / f0). Il cambio della directory nel floppy mostra solo i file numerati da 1 a 23 (questa è solo la struttura del dispositivo a caratteri immagino). Puoi anche cati dispositivi grezzi e bloccati e vedere che i dati del floppy sono lì, ma sono vicini.
Ho notato che in quel sistema operativo, non installi cose dai floppy avviando alcuni script da una directory su di loro come fai con i file binari decompressi per esempio - qui usi pkgadd -d diskette1(sicuramente l'ultima parola è un alias, ma io trovato un riferimento all'opzione -d nella roba SCO per pkgadd (1M)e generalmente appare spesso in Unix commerciale (Oracle, HP share pkgadd (1M)). L'emissione del comando avvia una routine in cui si forniscono floppy e non si ha alcun controllo, tranne dire "no" dopo che la routine ha scoperto cosa c'è nel drive. Nel caso di dischi che iniziano una sequenza di installazione (U03, U05 ecc.), Verrà installato, quindi verrà richiesto il floppy successivo, ecc. Fino al completamento dell'installazione del pacchetto. Se metti un floppy che non è l'inizio di un set, non trova praticamente nulla ma ti dice che forse devi usare il installpkgcomando.
Installerò un floppy drive fisico sul mio rig per accedere ai dati in quel file di immagine?
mount -t minix -o loop U19.IMA /mnt/cde ottengo l'errore generico ma questo arriva in dmesg VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.C'è qualche indicazione che il kernel ha già o non posso fare affidamento su quello ?. Comunque, indagherò su quello che hai detto. So che non è avviabile, tuttavia voglio accedere ai contenuti. Grazie.
filesuggerisce che non ci sia filesystem sull'immagine. Sei sicuro che i tuoi dati siano effettivamente lì? Sembra che tu stia provando a montare un'immagine di un'unità raw senza partizioni e senza filesystem.