I have just moved a 3TB disk from an external USB enclosure to inside a computer and I cannot see the only one ext4 partition which is supposed to be there. The disk has extremely important data that I cannot lose. Please advise how to proceed, here are some details:

$ sudo mount -vvv -t ext4 /dev/sdb1 /mnt/
mount: /mnt: /dev/sdb1 is not a valid block device.
$ sudo fdisk -l /dev/sdb
GPT PMBR size mismatch (732566645 != 5860533167) will be corrected by w(rite).
Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1           1 732566645 732566645 349.3G ee GPT

Partition 1 does not start on physical sector boundary.

$ sudo parted /dev/sdb print
Error: /dev/sdb: unrecognised disk label
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

lshw output (excerpt):

      physical id: 2
      logical name: scsi1
      capabilities: emulated
         description: ATA Disk
         product: WDC WD30EZRX-00D
         vendor: Western Digital
         physical id: 0.0.0
         bus info: scsi@1:0.0.0
         logical name: /dev/sdb
         version: 0A80
         serial: WD-WCC1T1561951
         size: 2794GiB (3TB)
         capabilities: partitioned partitioned:dos
         configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
       *-volume UNCLAIMED
            description: EFI GPT partition
            physical id: 1
            bus info: scsi@1:0.0.0,1
            capacity: 349GiB
            capabilities: primary nofs
  • 1
    Have you actually tried to mount the disk via mount -t ext4 /dev/sdb1 /mnt/point? All of the physical disks in my CentOS 7.5 file server give that message except for the one containing the OS and they always mount with no issues. – Nasir Riley Aug 25 '18 at 11:53
  • Yes, there is no such device as /dev/sdb1. – abali Aug 25 '18 at 11:59
  • Add that command and the output to your question. In fact, use this command: mount -vvv -t ext4 /dev/sdb1 /mnt/point. – Nasir Riley Aug 25 '18 at 12:10
  • 1
    Do not do anything that makes changes to the disk before putting it back into the enclosure. Do not let fsck "correct" anything. – Johan Myréen Aug 25 '18 at 12:32
  • 1
    To add to what Johan said, use fsck.ext4 -n or e2fsck -n which will send any errors to standard output instead of repairing them. If you run it without the -n switch, it will prompt but it's better just to run it with the -n switch. – Nasir Riley Aug 25 '18 at 12:43

The comment answerers are not reading the output in your question. The output tells us this:

  • GPT PMBR size mismatch (732566645 != 5860533167) will be corrected by w(rite).
    fdisk is telling you that you have an EFI partition table with a so-called "protective" old-style MBR partition record. But the protective partition record does not correctly protect the contents of your disc, because it ends way before the actual end of the disc, leaving a couple of TiB of free space unaccounted for. fdisk says that it will fix this for you. Do not attempt to use fdisk to do so. fdisk is wrong.
  • Disklabel type: dos
    Disk identifier: 0x00000000
    Device     Boot Start       End   Sectors   Size Id Type
    /dev/sdb1           1 732566645 732566645 349.3G ee GPT
    So fdisk has decided to not show you the EFI partition table at all. It is showing you the "protective" old-style MBR partition table instead, as if that were how you had partitioned your disc. That contains one entry, which is really (since it is type ee) a dummy entry that is supposed to encompass the entire disc, including the EFI partition table. But it is only 732566645 sectors long, which is roughly 349GiB, not 2.7TiB.

    This is one of several reasons why it is wrong to run fsck against this. It is not a disc volume containing a formatted filesystem. It is a dummy old-style partition that is supposed to span the entire disc.

  • Partition 1 does not start on physical sector boundary.
    This is a red herring. Your dummy protective partition is supposed to begin at sector 1. Sector 1 is where the EFI partition table begins. It is the alignment of the real partitions, recorded in the new EFI partition table that fdisk isn't reading, that matters, and that for performance reasons. You should be able to mount misaligned volumes. But you haven't even got as far as using the right partition table, so whether this is even a problem in the first place is unknown.

    However, it is likely that it is not. Alignment is likely entirely a red herring here. Because what you are experiencing is well known, and is something else.

  • $ sudo parted /dev/sdb print
    Error: /dev/sdb: unrecognised disk label
    parted is failing to read your EFI partition table, too. Unlike fdisk, it isn't falling back to treating your disc as being partitioned in the old style, and reporting one big dummy partition. It is failing outright.
  • size: 2794GiB (3TB)
    description: EFI GPT partition
    physical id: 1
    bus info: scsi@1:0.0.0,1
    capacity: 349GiB
    lshw is seeing a 3TB (2.7TiB) disc. It is also seeing the EFI partition table. But your EFI partition table claims that this is a 349GiB disc.

Why did 2.7TiB become 349GiB?

Well, notice what you get when you multiply 349GiB by 8.

When it is in your USB disc enclosure, the system thinks that your disc has 4KiB sectors, and everything has been accessing it using that as the sector size. In the USB enclosure, the rest of the system sees your disc with its native, true, sector size. Moreover, with 4KiB sectors 732566645 sectors really does encompass the entire 2.7TiB of your disc, and both the old-style protective partition and the actual EFI partition table have the right numbers.

Outwith your USB disc enclosure, your disc is being read in "512e" compatibility mode, where most of the system pretends that your disc has 0.5KiB sectors. (There is a more complex explanation to do with a second inverse transformation undoing the first when the USB enclosure is involved, but I am glossing over that here, as it is beyond the scope of this answer.) The partition start and size numbers in your partition tables, and indeed anything else that points to a logical block address on your disc, are all wrong.

4KiB is 8 times 0.5KiB.

Downgrading from native 4KiB sector sizes to "512e" is possible, but it is not for the fainthearted. I recommend as the far simpler course of action that you put the disc back into the enclosure to read it, where it will be seen with its true 4KiB sector size by the rest of the system and the numbers will come out right.

Further reading

  • Thanks, this makes a lot of sense and is very informative. Can you please just explain if it is possible to downgrade the sector size without data loss and if yes, what is the required process for that? – abali Aug 26 '18 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.