0

I run an iSCSI disk on a Linux server (RHEL7). The disk has a normal ext4 partition containing a loop device called disk01.img, which is mapped to a virtual disk with a Windows NTFS file system. All was well untill the Ethernet connection between the Windows and Linux systems was interrupted. Windows decided it should examine the NTFS volume, ultimately advising to re-format it. Before accepting that, I saved the file disk01.img into /savedir on the Linux server. I am now trying to restore disk01.img but I am running into problems.

[root@server ~]# losetup -P /dev/loop1 /savedir/disk01.img
[root@server ~]# mount -t ntfs /dev/loop1 /mount/point
Failed to read bootsector (size=0)
Failed to sync device /dev/loop1: Input/output error
Failed to mount '/dev/loop1': Ongeldig argument
The device '/dev/loop1' 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?

I imagine the NTFS volume might be damaged and I will need to dd the file disk01.img onto a USB disk with an empty NTFS partition, then porting the USB disk to Windows, run chkdsk and if that fails, try recovering the files using something like PhotoRec. Or am I just using the wrong code?

Edit: Result of fdisk (in Dutch)

[root@server ~]# fdisk -l /savedir/disk01.img

Schijf /savedir/disk01.img: 750.2 GB, 750155323392 bytes, 1465147116 sectoren
Eenheid = sectoren van 1 * 512 = 512 bytes

Sectorgrootte (logischl/fysiek): 512 bytes / 512 bytes
in-/uitvoergrootte (minimaal/optimaal): 512 bytes / 512 bytes

[root@server ~]#

Edit 2: The NTFS volume is damaged, so losetup -P was working but produced an empty partition. I will probably need to mount /savedir/disk01.img with an offset for the iSCSI sector, like

mount -o loop,offset=512 /savedir/disk01.img /mount/point

but I have difficulty finding the correct offset (looking for NTFS signatures, comparing the hexdump of the *.img file to the hexdump of the newly made virtual disk). BTW: I have also ported a dd copy of disk01.img back to Windows, trying to resolve the files. Still working on that cumbersome action. Finding the start of the NTFS filesystem on disk01.img seems a much better option.

Edit 3. Having run TestDisk 4 times there seem to be geometry problems I cannot yet resolve. Output:

losetup -P /dev/loop1 /savedir/disk01.img
testdisk /dev/loop1

Disk /dev/loop1 - 750 GB / 698 GiB - 1465147116 sectors
... ... ...
  Linux filesys. data            0 1465147111 1465147112
  Linux filesys. data            0 1465147111 1465147112
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
  MS Data                100452352 1526511615 1426059264
  Linux filesys. data            0 1465147111 1465147112
... ... ...
  Linux filesys. data    730080712 2195227823 1465147112
  Linux filesys. data    730090720 2195237831 1465147112
... ... ...
  Linux filesys. data    730093536 2195240647 1465147112
  Linux filesys. data            0 1465147111 1465147112
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
  MS Data               1346517247 2772576510 1426059264

------------------------------------------------------

-- After Reboot --

  Linux                          0 1465147111 1465147112
  Linux                          0 1465147111 1465147112
check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT16 LBA             3179978961 3795078107  615099147
  FAT16 LBA             3179978961 3795078107  615099147
  Linux                          0 1465147111 1465147112
Invalid FAT boot sector
 0 D FAT12                  202831329 1489073369 1286242041
  FAT12                  202831329 1489073369 1286242041
  Linux                          0 1465147111 1465147112
Invalid NTFS or exFAT boot
 0 D HPFS - NTFS           2833862451 3582746086  748883636
  HPFS - NTFS           2833862451 3582746086  748883636
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
  HPFS - NTFS            100452352 1526511615 1426059264


Disk /dev/loop1 - 750 GB / 698 GiB - 1465147116 sectors

The harddisk (750 GB / 698 GiB) seems too small! (< 1943 GB / 1809 GiB)
Check the harddisk size: HD jumper settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
>  HPFS - NTFS            100452352 1526511615 1426059264
   FAT12                  202831329 1489073369 1286242041
   Linux                  730069008 2195218167 1465149160
   Linux                  730071112 2195218223 1465147112
   Linux                  730079744 2195226855 1465147112
   Linux                  730080712 2195227823 1465147112
   Linux                  730090720 2195237831 1465147112
   Linux                  730093536 2195240647 1465147112
   HPFS - NTFS           1346517247 2772576510 1426059264
   HPFS - NTFS           1465145007 2930290014 1465145008


NTFS, blocksize=4096, 730 GB / 679 GiB

--------------------------------------

-- After adding TestDisk MBR, Reboot

  Linux                          0 1465147111 1465147112
  Linux                          0 1465147111 1465147112
  Linux                          0 1465147111 1465147112
  Linux                          0 1465147111 1465147112
check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT16 LBA             3179978961 3795078107  615099147
  FAT16 LBA             3179978961 3795078107  615099147
  Linux                          0 1465147111 1465147112
  Linux                          0 1465147111 1465147112
Invalid FAT boot sector
 0 D FAT12                  202831329 1489073369 1286242041
  FAT12                  202831329 1489073369 1286242041
  Linux                          0 1465147111 1465147112
Invalid NTFS or exFAT boot
 0 D HPFS - NTFS           2833862451 3582746086  748883636
  HPFS - NTFS           2833862451 3582746086  748883636
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
  HPFS - NTFS            100452352 1526511615 1426059264

-------------------------------------

-- After Reboot, running Deeper Analysis ---

Disk /dev/loop1 - 750 GB / 698 GiB - 1465147116 sectors


  No partition          36028797018963967 1465147115 1465147117

Enter the ending sector 

--------------------------------------
5
  • shouldn't you mount it as mount -t ntfs /savedir/disk01.img /mount/point ?
    – Archemar
    May 23, 2022 at 13:50
  • Can you tell me the fdisk -l /savedir/disk01.img output?
    – K-attila-
    May 23, 2022 at 13:56
  • Mount directly as disk01.img is identical to the above, as Linux will see this is loop device and react accordingly.
    – roelvdh
    May 23, 2022 at 15:37
  • Since you used losetup -P, any partitions in the image should now be available as individual /dev/loop1pN devices. Try e.g. mount -t ntfs /dev/loop1p1 /mount/point if /dev/loop1p1 exists.
    – telcoM
    May 23, 2022 at 16:26
  • losetup -P doesn't seem to be working, see Edit2
    – roelvdh
    May 24, 2022 at 7:25

1 Answer 1

0

The failure to mount /dev/loop1 indicates this the image file is not a valid partition image. Since it is a copy of an image that was used as an iSCSI disk, I would expect it to be a full disk image that includes a partition table.

However, fdisk -l /savedir/disk01.img indicates there is no recognizable partition table present. Even if the iSCSI disk was used as part of a Microsoft Storage Spaces set-up, there should be at least one partition present.

Even if you had an old version of fdisk that only recognizes MBR partition tables, and the image used a GPT partition table instead, it should have at least detected GPT's protective MBR with its dummy partition entry of type 0xee.

This suggests the partition table may have been corrupted or overwritten. You might want to try testdisk on the whole-disk loop device and see if it can find the beginning and end of the filesystem and reconstruct the partition table for you.

testdisk /dev/loop1

Alternatively, modern versions of Windows normally place the beginning of the first partition of the disk exactly 1 MiB off the beginning of the disk. So you could try:

mount -o loop,offset=1M /savedir/disk01.img /mount/point
8
  • After running TestDisk 4 times, rebooting after each run (see Edit3), TestDisk proposed changing the geometry. I would appreciate some guidance before doing that. The 1MiB offset mount clearly doesn't work yet, as the geometry seems to be incorrect.
    – roelvdh
    May 25, 2022 at 7:07
  • Modern OSs are not really interested in disk geometry, as on disks larger than about 8.4 GB the C/H/S style fields of the MBR partition table are useless and are filled with a 1024/255/63 placeholder value anyway.The important values are location (block number) of the first block of the partition, and the size of the partition as a number of blocks. On disks between 8.4 .. 136.9 GB, a "translated C/H/S geometry" used to be possible, but on disks larger than 136.9 GB, LBA addressing (= just by block number, ignoring the geometry entirely) is the only possible way as far as I know.
    – telcoM
    May 25, 2022 at 9:04
  • It seems like there might be more damage than just a simply wiped partition table. If the beginning of the NTFS filesystem has also been damaged, testdisk may be unable to determine the beginning & end of the partition. In that case, something like PhotoRec or contacting data recovery professionals might be only viable ways to go on.
    – telcoM
    May 25, 2022 at 9:33
  • Thank you very much for the explanation and help. Just out of interest I will try one more thing. I can run testdisk on the "new" iSCSI disk (after umounting it and running losetup), learn the beginning and ending sector, assuming they would be identical to /savedir/disk01.img, and feeding that back into the latter. I also could have 2 loop devices (/dev/loop1 as "old" and /dev/loop2 as "new") and then dd some applicable parts from "new" to "old". Any chance?
    – roelvdh
    May 25, 2022 at 15:44
  • For the former, cannot hurt to try. For the latter, difficult to predict results without knowing exact details.
    – telcoM
    May 25, 2022 at 19:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .