I backupped a lot of data from a Linux Centos guest and a Windows guest running on ESXI 5 to a 1TB hard disk mounted inside a USB enclosure. The usb enclosure was connected directly to the guests thru the ESXI 5 hypervisor.
When finished copying the data, I correclty disconnected the usb disk, reformatted the server and upgraded to KVM hypervisor running on a Centos distribution.
I then created a Linux Centos guest and connected the usb disk directly to it thru the KVM hypervisor. No problem copying the data from the linux partition back to the guest. After copying I correctly disconnected the disk.

Now, after some time, I have put that same disk, untouched, in a IBM x3200 M3 server with LSI raid controller, in order to retrieve some data from the original linux backup. The disk is configured as a single device, no RAID.
The disk is correctly seen by the Centos Linux running on the IBM.
fdisk correctly shows the 2 partitions:

 fdisk -l /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 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
Disk label type: dos
Disk identifier: 0x7ca397d5

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63   128005919    64002928+   7  HPFS/NTFS/exFAT
/dev/sda2       128006144   244190645    58092251   83  Linux

And so does gdisk:

gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present

Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.

Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8AE1EC87-71EF-4340-8D94-E0EFC30FB4E4
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 1709334742 sectors (815.1 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              63       128005919   61.0 GiB    0700  Microsoft basic data
   2       128006144       244190645   55.4 GiB    8300  Linux filesystem

Nonetheless, I am not able to mount the second partition (don't have Windows here, so I'm not trying with the first).
The error message is:

mount /dev/sda2 /mnt/usb/
mount: /dev/sda2 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/sda2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Trying to mount read-only with -o ro options does not change the result.

Trying fsck gives the following results:

[root@localhost ~]# fsck -N /dev/sda2
fsck from util-linux 2.23.2
[/sbin/fsck.ext2 (1) -- /dev/sda2] fsck.ext2 /dev/sda2

[root@localhost ~]# fsck.ext4 -n /dev/sda2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda2

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
  • 1
    What does sudo file -s /dev/sda2 return? If it's ext2/3/4 fs, try running e2fsck -n /dev/sda2 and see what's wrong. Nov 10, 2020 at 19:07
  • The file command just returns "/dev/sda2: data". I've updated the question with fsck results Nov 10, 2020 at 19:39
  • If it's just data either you have a major corruption (IO might be implicated as well) or your partition offset is wrong. Nov 10, 2020 at 19:39
  • Also it's quite weird one partition ends at 128005919 and the second one starts at 128006144. Either there's an error or someone partitioned the disk quite weirdly. Nov 10, 2020 at 19:44
  • The Linux partition was added after the NTFS one that was made in Windows indeed. May that fdisk left some space? Nov 10, 2020 at 19:47

1 Answer 1


This may be almost a duplicate of this other question. Please read my answer there to learn what could happen. Almost, because I would not suspect similar problems for a disk reporting 512 as its physical sector size.

So maybe the RAID controller distorts the value(s) now; maybe the USB enclosure interfered like in the other question; maybe ESXI did some translation. I don't know.

Anyway I suspect its about 512 vs 4096. In such case you should try if the offset (start sector) is valid when counted in 4096-byte sectors.

Before we get to the actual command note the end sector of the last partition is a huge clue. The disk now reports 1953525168 logical sectors of 512 bytes, but if the sectors were 4096 bytes then you had 244190646 (i.e. 8 times less) sectors numbered from 0 to 244190645. 244190645 is exactly the end sector of the last partition, so most likely this entry in the partition table is valid for 4096-byte sectors.

Try this:

mount -o ro,offset=$((128006144*4096)) /dev/sda /some/mountpoint

ro here is just in case.


You must log in to answer this question.

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