問題は、バックアップ パーティション テーブルの場所でした。通常、最初にプライマリ パーティション テーブルがあり、最後にバックアップ パーティション テーブルが必要です。ディスクのサイズを変更すると、使用可能なセクターが増えましたが、バックアップ テーブルは移動されませんでした。 fdisk はこれが気に入らなかったので、それは MyLBA mismatch with real position at backup header. だったと思います エラーメッセージ。明確ではありません。
fdisk から切り替えました gdisk まで 出力は少し異なりました。 gdisk には...
r recovery and transformation options (experts only)
そこに入って v を実行すると erify は、より役立つエラー メッセージを表示しました...
Recovery/transformation command (? for help): v
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.
Identified 1 problems!
gdisk未満 エキスパートモードには次のオプションがあります...
e relocate backup data structures to the end of the disk
... 正常に実行され、検証出力は次のようになりました...
Expert command (? for help): v
No problems found. 15625881566 free sectors (7.3 TiB) available in 2
segments, the largest of which is 15625879552 (7.3 TiB) in size.
パーティション テーブルを印刷すると、最後の使用可能なセクターが 390 億ではなく 560 億と表示され、新しいパーティションを作成して LVM に追加することができました。
partprobe <-- add the /dev/sdb2 device if you don't want to reboot
pvcreate /dev/sdb2
vgextend bak /dev/sdb2
lvextend /dev/mapper/bak-bak -l 100%PVS -r
このスナフの鍵はこれです:
Last LBA: 39064698846
GPT ラベルは、変更された中サイズを反映していません。 fdisk 完全ではない方法で空き領域を検索しますが、少なくとも論理的です。GPT ラベルの間で利用可能な最大の空き領域で最初に利用可能なセクタを探します。 最初と最後の LBA。
それを回避する1つの方法は、 sfdisk を使用することです ラベルをダンプするには、中程度のサイズに適切に編集して書き戻すか、 parted を使用することをお勧めします その問題IMOを処理する必要があります。