Re: The backup GPT table is corrupt
On 8/11/25 17:35, mick.crane wrote:
I thought I might upgrade to Trixie.
This bookworm install I think I let the installer decide what to do.
I don't really understand EFI and GPT, I might have done but I've
forgotten.
Take a look at your BIOS/EUFI Setup settings --"Mode", "BIOS", "UEFI",
"Legacy", etc..
I was concerned that the backup GPT table being corrupt might cause
issues upgrading to Trixie.
Fixing the secondary GPT sounds like a good idea, regardless.
The internet says that the backup GPT is at the end of the disk.
Is that the end of the disk or the partition?
AIUI:
https://en.wikipedia.org/wiki/GUID_Partition_Table
* The protective MBR occupies the first block (512 bytes) of the disk.
* The primary GPT occupies the next 33 blocks of the disk -- 1 block for
the header and 32 blocks for the entries (4 entries per block).
* The secondary GPT occupies the last 33 blocks of the disk -- 32 blocks
for the entries (4 entries per block) and 1 block for the header.
Not being very good at calculating sector sizes is the swap partition at
the end of the disk?
The swap partition ends 945 blocks from the end of the disk, which
leaves plenty of room for the secondary GPT:
2025-08-11 21:07:42 dpchrist@laalaa ~
$ perl -e 'print 234441648-234440703, $/'
945
There's 62Gb of memory so I shouldn't need the swap.
I tried building Linux systems without swap in the past. They crashed
under memory pressure. I have since allocated a "1 GB" swap partition
whenever I install or build a system disk.
Is there anything I should do before trying to get gdisk to fix the issue?
Taking an image of the first 34 blocks of the disk and taking an image
of the last 33 blocks of the disk could be useful for disaster recovery,
curiosity, etc..
Alternatively, take an image of the entire disk. If the disk supports
TRIM, running fstrim(8) first and using compression during image
creation will produce a smaller image file.
mick
root@courgette:/home/mick# fdisk -l /dev/sda
The backup GPT table is corrupt, but the primary appears OK, so that
will be used.
Disk /dev/sda: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: V Series SATA SS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CEC0C0B6-A933-426A-921B-04BDA99E808B
Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 232441855 231391232 110.3G Linux filesystem
/dev/sda3 232441856 234440703 1998848 976M Linux swap
root@courgette:/home/mick# df -h
Filesystem Size Used Avail Use% Mounted on
udev 32G 0 32G 0% /dev
tmpfs 6.3G 1.6M 6.3G 1% /run
/dev/sda2 109G 37G 66G 36% /
tmpfs 32G 65M 32G 1% /dev/shm
tmpfs 5.0M 12K 5.0M 1% /run/lock
/dev/sda1 511M 12M 500M 3% /boot/efi
/dev/sdf1 2.7T 830G 1.8T 32% /home/mick/WORK
tmpfs 6.3G 68K 6.3G 1% /run/user/1000
root@courgette:/home/mick# free -g
total used free shared buff/cache
available
Mem: 62 4 37 0 22
58
Swap: 0 0 0
David
Reply to: