On a Ubuntu 20.04 box, I have two 6TB disks in a LVG spanning both disks for a Logical Volume of 12TB. It has been working fine since I set it up approx a year ago. The two drives are in an external USB3 drive bay. This past weekend, I powered down both the Ubuntu device and the drive bay due to due to maintenance work on my building's electrical service. When I powered back up, the volume group did not mount.
sudo gparted
Unit tmp.mount does not exist, proceeding anyway.
GParted 1.0.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
Invalid argument during seek for read on /dev/sdg
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
Invalid argument during seek for read on /dev/sdh
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
sudo fdisk -lu /dev/sdg
Disk /dev/sdg: 5.47 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: USB3.0 DISK00
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/sdg1 1 4294967295 4294967295 2T ee GPT
Partition 1 does not start on physical sector boundary.
sudo fdisk -lu /dev/sdh
Disk /dev/sdh: 5.47 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: USB3.0 DISK01
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/sdh1 1 4294967295 4294967295 2T ee GPT
Partition 1 does not start on physical sector boundary.
sudo gdisk
GPT fdisk (gdisk) version 1.0.5
Type device filename, or press <Enter> to exit: /dev/sdg
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help): i
Using 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: CC098100-9E59-4A16-BD05-CC3F25E59B91
First sector: 2048 (at 1024.0 KiB)
Last sector: 11721043967 (at 5.5 TiB)
Partition size: 11721041920 sectors (5.5 TiB)
Attribute flags: 0000000000000000
Partition name: ''
Command (? for help): v
Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Problem: Disk is too small to hold all the data!
(Disk size is 11721045168 sectors, needs to be 253879390758630 sectors.)
The 'e' option on the experts' menu may fix this problem.
Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 253879390758596, but backup header is at
253879390758629 and disk size is 11721045168 sectors.
The 'e' option on the experts' menu will probably fix this problem
Identified 4 problems!
Command (? for help):
sudo gdisk /dev/sdh
GPT fdisk (gdisk) version 1.0.5
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help): i
Using 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 42E52C6C-C33C-4D2E-9ECB-3D8DF60DCB25
First sector: 2048 (at 1024.0 KiB)
Last sector: 11721043967 (at 5.5 TiB)
Partition size: 11721041920 sectors (5.5 TiB)
Attribute flags: 0000000000000000
Partition name: ''
Command (? for help): v
Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Problem: Disk is too small to hold all the data!
(Disk size is 11721045168 sectors, needs to be 253879390758630 sectors.)
The 'e' option on the experts' menu may fix this problem.
Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 253879390758596, but backup header is at
253879390758629 and disk size is 11721045168 sectors.
The 'e' option on the experts' menu will probably fix this problem
Identified 4 problems!
Command (? for help):
Any suggestions on recovering the Logical Volume?
I have a backup of the data. But it is in another country and thanks to COVID travel restrictions may be a while before I can retrieve it. :-)
