I have a hard-disk from a dead machine that I'm trying to mount on my Linux machine. For reference, I'm using Fedora 39 and mdadm v4.2. First, I tried just mounting it, correctly showing it's a RAID device and cannot be used directly:
$ sudo mount /dev/sda /mnt/raid/ --verbose
mount: /mnt/windows10: unknown filesystem type 'isw_raid_member'.
dmesg(1) may have more information after failed mount system call.
All as expected. Next, I assembled the RAID device:
$ sudo IMSM_NO_PLATFORM=1 mdadm --assemble --scan --verbose
Now, this mounts on md127 and examining it gives the expected results.
$ sudo mdadm --examine --verbose --scan
ARRAY metadata=imsm UUID=e259cc7b:...
devices=/dev/sda
ARRAY /dev/md/977KMHHGS container=e259cc7b:... member=0 UUID=ee9548f1:...
However, attempting to get the de5ails gives nothing:
$ sudo mdadm --detail /dev/md127
/dev/md127:
Version : imsm
Raid Level : container
Total Devices : 1
Working Devices : 1
Member Arrays :
Number Major Minor RaidDevice
- 8 0 - /dev/sda
Looking at mdstat tells me it's inactive:
$ cat /proc/mdstat
Personalities :
md127 : inactive sda[0](S)
5201 blocks super external:imsm
unused devices: <none>
Attempting to mount it then tells me it has a bad super block and cannot read past the end of the device:
$ sudo mount -o ro /dev/md/imsm0 /mnt/raid
mount: /mnt/windows10: can't read superblock on /dev/md127.
dmesg(1) may have more information after failed mount system call.
dmesg then tells me it's trying to read past the end of the disk:
[18419.063560] GPT:Primary header thinks Alt. header is not at the end of the disk.
[18419.063564] GPT:3907024623 != 3907029167
[18419.063566] GPT:Alternate GPT header not at the end of the disk.
[18419.063567] GPT:3907024623 != 3907029167
[18419.063568] GPT: Use GNU Parted to correct GPT errors.
[18419.063590] sda: sda1 sda2 sda3 sda4 sda5
[18796.913051] mount: attempt to access beyond end of device
md127: rw=4096, sector=2, nr_sectors = 2 limit=0
[18796.913060] EXT4-fs (md127): unable to read superblock
Looking back at the logs of assembling the RAID disk it seems the device was busy:
mdadm: /dev/sda is identified as a member of /dev/md/imsm0, slot -1.
mdadm: added /dev/sda to /dev/md/imsm0 as -1
mdadm: Container /dev/md/imsm0 has been assembled with 1 drive
mdadm: looking for devices for further assembly
mdadm: looking for devices for further assembly
mdadm: Cannot assemble mbr metadata on /dev/sda5
mdadm: Cannot assemble mbr metadata on /dev/sda4
mdadm: no recogniseable superblock on /dev/sda3
mdadm: no recogniseable superblock on /dev/sda2
mdadm: Cannot assemble mbr metadata on /dev/sda1
mdadm: /dev/sda is busy - skipping
mdadm: no correct container type: /dev/md/imsm0
Is there anything ideal I should do? Is my drive corrupted? I believe this is the only disk from original machine, so it wouldn't require 2 disks or similar. I'm sorry if what I'm asking is relatively rudimentary, and I'd rather not do anything potentially destructive (I'll take it to a data recovery place if there's nothing obviously wrong).
Update 1
Replugging in the device and checking dmesg gives the following result:
[19449.194221] usb 2-1: new SuperSpeed USB device number 13 using xhci_hcd
[19449.207506] usb 2-1: New USB device found, idVendor=1f75, idProduct=0611, bcdDevice= 0.06
[19449.207513] usb 2-1: New USB device strings: Mfr=4, Product=5, SerialNumber=6
[19449.207515] usb 2-1: Product: Ext. HDD
[19449.207516] usb 2-1: Manufacturer: Innostor
[19449.207518] usb 2-1: SerialNumber: 20131012
[19449.210360] usb-storage 2-1:1.0: USB Mass Storage device detected
[19449.210581] scsi host8: usb-storage 2-1:1.0
[19450.215543] scsi host8: scsi scan: INQUIRY result too short (5), using 36
[19450.215549] scsi 8:0:0:0: Direct-Access Innostor Ext. HDD PQ: 0 ANSI: 0
[19450.216002] sd 8:0:0:0: Attached scsi generic sg0 type 0
[19450.225777] sd 8:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[19450.226556] sd 8:0:0:0: [sda] Write Protect is off
[19450.226561] sd 8:0:0:0: [sda] Mode Sense: 3b 00 00 00
[19450.227327] sd 8:0:0:0: [sda] No Caching mode page found
[19450.227331] sd 8:0:0:0: [sda] Assuming drive cache: write through
[19450.256096] GPT:Primary header thinks Alt. header is not at the end of the disk.
[19450.256099] GPT:3907024623 != 3907029167
[19450.256101] GPT:Alternate GPT header not at the end of the disk.
[19450.256101] GPT:3907024623 != 3907029167
[19450.256102] GPT: Use GNU Parted to correct GPT errors.
[19450.256122] sda: sda1 sda2 sda3 sda4 sda5
[19450.256351] sd 8:0:0:0: [sda] Attached SCSI disk
So it seems that the GPT headers are wrong and this affecting assembling and mounting the disk?
Update 2
Attempting to find the partitions on the assembled drive creates an invalid error.
$ sudo fdisk -l /dev/md127
fdisk: cannot open /dev/md127: Invalid argument
As expected, however, showing the partitions on /dev/sda produces the drives we'd expect:
sudo fdisk -l /dev/sda
The backup GPT table is not on the end of the device.
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Ext. HDD
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: gpt
Disk identifier: B98CF9F3-1544-4F34-B8A2-E7B01AE38579
Device Start End Sectors Size Type
/dev/sda1 2048 1026047 1024000 500M EFI System
/dev/sda2 1026048 1288191 262144 128M Microsoft reserved
/dev/sda3 1288192 3904918338 3903630147 1.8T Microsoft basic data
/dev/sda4 3904919552 3906052095 1132544 553M Windows recovery environment
/dev/sda5 3906054144 3907002367 948224 463M Windows recovery environmen
Update 3
Attempting to mount just /dev/sda3 gives the following error:
$ sudo mount /dev/sda3 /mnt/windows10 -o ro
mount: /mnt/windows10: fsconfig system call failed: /dev/sda3: Can't lookup blockdev.
dmesg(1) may have more information after failed mount system call
The dmesg logs seem to be more ominous:
[ 9189.684483] usb 2-1: USB disconnect, device number 13
[ 9189.684519] sd 8:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
[ 9189.684534] sd 8:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 e8 c0 58 08 00 00 08 0
[ 9189.684540] I/O error, dev sda, sector 3904919560 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 9189.684650] device offline error, dev sda, sector 3904919560 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 9189.684662] Buffer I/O error on dev sda4, logical block 1, async page read
[ 9189.684723] device offline error, dev sda, sector 1026056 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 9189.684789] device offline error, dev sda, sector 1026056 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 9189.684798] Buffer I/O error on dev sda2, logical block 1, async page read
[ 9189.685127] device offline error, dev sda, sector 1288200 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 9189.685187] device offline error, dev sda, sector 3907002104 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 9189.685242] device offline error, dev sda, sector 3907002104 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 9189.685254] Buffer I/O error on dev sda5, logical block 118495, async page read
[ 9189.685391] device offline error, dev sda, sector 1288200 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 9189.685404] Buffer I/O error on dev sda3, logical block 8, async page read
[ 9189.685971] device offline error, dev sda, sector 1025784 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 9189.686025] device offline error, dev sda, sector 1025784 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 9189.686035] Buffer I/O error on dev sda1, logical block 127967, async page read
[ 9189.687413] Buffer I/O error on dev sda3, logical block 9, async page read
[ 9189.689419] Buffer I/O error on dev sda3, logical block 10, async page read
[ 9189.689432] Buffer I/O error on dev sda3, logical block 11, async page read
[ 9189.689438] Buffer I/O error on dev sda3, logical block 12, async page read
[ 9189.689444] Buffer I/O error on dev sda3, logical block 13, async page rea
Update 4
Everything looks promising. I tried using dd on the raw drive and there's a lot of plain-text data there so it's clearly not encrypted (it was Windows 10 Home so it couldn't have been via Bitlocker). Running the following:
$ sudo dd if=/dev/sda3 of=test bs=512 count=500 skip=7626293
Gave output consisting of this, in plain text (as strings in binary):
/
usr/share/locale/hr/LC_MESSAGES/
usr/share/locale/hr/LC_MESSAGES/wget.mo
usr/share/locale/hu/
usr/share/locale/hu/LC_MESSAGES/
usr/share/locale/hu/LC_MESSAGES/wget-gnulib.mo
usr/share/locale/hu/LC_MESSAGES/wget.mo
usr/share/locale/id/
usr/share/locale/id/LC_MESSAGES/
usr/share/locale/id/LC_MESSAGES/wget.mo
usr/share/locale/it/
usr/share/locale/it/LC_MESSAGES/
usr/share/locale/it/LC_MESSAGES/wget-gnulib.mo
usr/share/locale/it/LC_MESSAGES/wget.mo
So the drive is fine, I'm guessing the offsets for the drive are just off substantially? I'll try to find the actual start of the filesystem.
fdisk -l /dev/md127says it' an invalid argument. Updating some info now.