After adding disks, "The backup GPT table is not on the end of the device. This problem will be corrected by write."

Ask Fedora Ask in English
1

Fedora 31 is installed. I added 2 disks into the server which has a Dell PERC H730P with RAID 10. Using the tips here, I ran Gparted, right-clicked to choose the resize option, ran pvresize then lvextend, and thought I was done. However after a reboot fdisk -l shows this error:

The backup GPT table is not on the end of the device. This problem will be corrected by write.
Disk /dev/sdb: 4.93 TiB, 5399176544256 bytes, 10545266688 sectors
Disk model: PERC H730P Adp
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: gpt
Disk identifier: 5FD63791-D324-4648-AA89-9A39B21CBEDC

Device      Start        End    Sectors  Size Type
/dev/sdb1    2048       6143       4096    2M BIOS boot
/dev/sdb2    6144     980991     974848  476M Linux filesystem
/dev/sdb3  980992 7030175743 7029194752  3.3T Linux LVM


Disk /dev/mapper/fedora_newserver-root: 931.33 GiB, 1000001765376 bytes, 1953128448 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


Disk /dev/mapper/fedora_newserver-swap: 22.36 GiB, 24004001792 bytes, 46882816 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


Disk /dev/mapper/fedora_newserver-home: 1.82 TiB, 1974934175744 bytes, 3857293312 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

Disk /dev/mapper/fedora_newserver-var: 558.82 GiB, 600003575808 bytes, 1171881984 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

Then hdparm -N /dev/sdb

/dev/sdb:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0d 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0d 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 max sectors   = 0/1, HPA is enabled

I ran gdisk:

gdisk /dev/sdb1
GPT fdisk (gdisk) version 1.0.4

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

Creating new GPT entries in memory.

Command (? for help): p
Disk /dev/sdb1: 4096 sectors, 2.0 MiB
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 0C7F2B90-AC1C-4ED3-9396-89F32EFD2DA8
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 4062
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

No problems found. 4029 free sectors (2.0 MiB) available in 1
segments, the largest of which is 4029 (2.0 MiB) in size.

So how can I fix the error? And running df shows that /home has:

/dev/mapper/fedora_newserver-home 1.8T 1.9G 1.8T 1% /home

2

Just wanted to chime in that I received an out of band email response from Rod that helped me fix the The backup GPT table is not on the end of the device error.

Basically, the main problem you’re encountering is caused by the fact that GPT places partition table data both at the start of the disk and at the end of the disk. When you expanded your RAID array, the “disk” grew in size, but the backup GPT data (normally at the end of the disk) fell short of that location. To use the array in its new, larger, configuration, the backup GPT data must be moved to the end of the disk. I haven’t studied how fdisk handles this, but the message “This problem will be corrected by write” suggests that using the fdisk write ("w") command will move the backup GPT data. You can try that; or you can try using gdisk: Type “x” to enter the experts’ menu, followed by “e” to move the backup partition table to the end of the disk, and finally “w” to save the changes. If you don’t relocate the GPT data, you won’t be able to use the increased RAID array capacity, since you can’t create partitions after the backup GPT data on the disk.

Note, however, that when you used gdisk, you entered the wrong device filename. Like fdisk and parted, gdisk must be launched on a WHOLE-DISK DEVICE, like /dev/sdb, not on an individual partition, like /dev/sdb1, which is what you used.

I’m still getting the SG_IO: bad/missing sense data, sb[]: error with hdparm and here was his take on it:

Your hdparm output indicates that the ATA host protected area (HPA) feature is active on the disk. This feature is normally used to hide part of a disk even from low-level utilities for certain very exotic purposes. The hdparm output also complained about “bad/missing sense data.” It’s possible that these messages are both artifacts of your RAID controller, so they may not be cause for concern;
but it’s also possible that one or both is an indication of a misconfiguration. If I were you, I think I’d try relocating the GPT backup data and then try hdparm again, on the off chance that hdparm was confused by the backup data’s location. (AFAIK, hdparm doesn’t check partition table data, so this shouldn’t be the case, but I could be mistaken about this.) If the hdparm warnings persist, then you should research them the be sure that they’re innocuous, but I’m afraid I don’t have a definitive answer about this offhand.

Hope this helps someone down the line. If/when I get an answer to the hdparm error I’ll update this.