View Full Version : The backup GPT table is corrupt
I get this error when running parted on the internal drive:
~# parted /dev/mmcblk0
GNU Parted 3.4
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel?
I checked and gdisk/sgdisk is not installed. What is recommended way to rebuild the backup GPT from the primary table?
Is /dev/mmcblk0 the internal drive?
Is /dev/mmcblk0 the internal drive?
Yes, it is:
~# parted /dev/mmcblk0
GNU Parted 3.4
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? OK
Model: MMC 4FPD3R (sd/mmc)
Disk /dev/mmcblk0: 3909MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 4194kB 3146kB boot msftdata
2 4194kB 12.6MB 8389kB kernel1
3 12.6MB 851MB 839MB ext4 rootfs1
4 851MB 860MB 8389kB kernel2
5 860MB 1699MB 839MB ext4 rootfs2
6 1699MB 1707MB 8389kB kernel3
7 1707MB 2546MB 839MB ext4 rootfs3
8 2546MB 2554MB 8389kB kernel4
9 2554MB 3393MB 839MB rootfs4
10 3393MB 3908MB 515MB linux-swap(v1) swap swap
EDIT: By "internal drive" I mean it is the SD card on which the OS is installed.
So you are running the image from an SD card? What machine is this?
So you are running the image from an SD card? What machine is this?
The machine is a Mut@nt HD51. The OS is running off an MMC card using the SD controller. That's how I bought it, I haven't changed anything.
OK, I fixed it. Brief steps in case others come across the same problem.
1. Check if parted can read the main GPT table. Run it on the device:
~# parted /dev/mmcblk0
GNU Parted 3.4
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? OK
Model: MMC 4FPD3R (sd/mmc)
Disk /dev/mmcblk0: 3909MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 4194kB 3146kB boot msftdata
2 4194kB 12.6MB 8389kB kernel1
3 12.6MB 851MB 839MB ext4 rootfs1
4 851MB 860MB 8389kB kernel2
5 860MB 1699MB 839MB ext4 rootfs2
6 1699MB 1707MB 8389kB kernel3
7 1707MB 2546MB 839MB ext4 rootfs3
8 2546MB 2554MB 8389kB kernel4
9 2554MB 3393MB 839MB rootfs4
10 3393MB 3908MB 515MB linux-swap(v1) swap swap
The above output shows the primary table is sound, since I can see all the partitions, but the backup table is not OK.
2. Install the package "gptfdisk" and run it:
~# gdisk /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.8
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
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): p
Disk /dev/mmcblk0: 7634944 sectors, 3.6 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): F291D54B-F806-44C3-9011-91F4FB4D63D6
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 7634910
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 8191 3.0 MiB 0700 boot
2 8192 24575 8.0 MiB 8300 kernel1
3 24576 1662975 800.0 MiB 8300 rootfs1
4 1662976 1679359 8.0 MiB 8300 kernel2
5 1679360 3317759 800.0 MiB 8300 rootfs2
6 3317760 3334143 8.0 MiB 8300 kernel3
7 3334144 4972543 800.0 MiB 8300 rootfs3
8 4972544 4988927 8.0 MiB 8300 kernel4
9 4988928 6627327 800.0 MiB 8300 rootfs4
10 6627328 7632895 491.0 MiB 8200 swap
3. Quit with 'q' without making any changes and create a dump of the GPT tables to be able to restore from it if something goes wrong.
:~# sgdisk -b /media/usb/backup/mmcblk0.gpt /dev/mmcblk0
The operation has completed successfully.
If you need to restore the original GPT table, replace '-b' with '-l' in the above command syntax.
4. Run gdisk once more and press 'r' to enter the Recovery and Transformation menu. Then check if the backup table can be read and how it differs with the primary table, by pressing 'c' and then 'p' to view it. In my case the loaded backup table was empty, which explains why parted and gdisk outputs complained.
5. I pressed 'd' to use the primary GPT header and then 'e' to rebuild the backup with the data in the primary table. 'v' will verify the currently loaded table is in good order. 'w' to write the backup table at the end of the disk and 'q' to quit. Careful to get these steps in the correct order, in case the corruption is on the primary table rather than the backup. You do not want to overwrite healthy data.
A reboot showed all was fine and 'v' verified the status of the GPT table:
~# gdisk /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.8
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/mmcblk0: 7634944 sectors, 3.6 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): F291D54B-F806-44C3-9011-91F4FB4D63D6
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 7634910
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 8191 3.0 MiB 0700 boot
2 8192 24575 8.0 MiB 8300 kernel1
3 24576 1662975 800.0 MiB 8300 rootfs1
4 1662976 1679359 8.0 MiB 8300 kernel2
5 1679360 3317759 800.0 MiB 8300 rootfs2
6 3317760 3334143 8.0 MiB 8300 kernel3
7 3334144 4972543 800.0 MiB 8300 rootfs3
8 4972544 4988927 8.0 MiB 8300 kernel4
9 4988928 6627327 800.0 MiB 8300 rootfs4
10 6627328 7632895 491.0 MiB 8200 swap
Command (? for help): v
No problems found. 4029 free sectors (2.0 MiB) available in 2
segments, the largest of which is 2015 (1007.5 KiB) in size.
The HD51 doesn‘t have an sd card slot, so you are running off the eMMC - and in reality you didn‘t have an issue, Messing around with the eMMc is not a good idea due to the way they are formatted when flashed,.
The HD51 doesn‘t have an sd card slot, so you are running off the eMMC - and in reality you didn‘t have an issue, Messing around with the eMMc is not a good idea due to the way they are formatted when flashed,.Not doubting you, but I'd expect an eMMC to show up as an mtd* device.
An mmcblk* is a MultiMedia Card (i.e. an SD card).
Not doubting you, but I'd expect an eMMC to show up as an mtd* device.
An mmcblk* is a MultiMedia Card (i.e. an SD card).
All the eMMC receivers ( mostly multiboot ) use mmcblk for their partitions, which is why there is additional code in HarddiskManger to handle the sf8008 ( and some zgemma boxes) which do have an sdcard which also uses mmcblk … just to make life interesting
Not doubting you, but I'd expect an eMMC to show up as an mtd* device.
An mmcblk* is a MultiMedia Card (i.e. an SD card).
My mutant and AX61Hd both show mmcblock* on their internal soldered eMMC flash 4GB storage. Similar setup on the removable MMC storage on my Odroid N2+.
@Mickkie - I would echo what @twol says as regards playing around with various partitioning and fsck utilities on the eMMC storage. I don't think they all understand the internal partitioning schema and sometimes report errors where there are none which affect normal usage. I do recall seeing parted reporting GPT errors on my mutant HD51 and tried various utilities to clear the problem, but without success. It never affected the normal running of the box and I regularly installed four sets of images from OpenVix, ATV etc., and swapped them around the different partitions without problems.
Thank you all, I didn't recall seeing a SD slot when I had opened the box some years ago now to add a HDD, so I had assumed it was soldered on the board. I saw dmesg mentioning mmc - as twol advised it is an eMMC. This is what dmesg shows:
[ 1.507261] sdhci: Secure Digital Host Controller Interface driver
[ 1.513459] sdhci: Copyright(c) Pierre Ossman
[ 1.517829] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.557588] mmc0: SDHCI controller on f03e0200.sdhci [f03e0200.sdhci] using ADMA
snip ...
[ 1.700025] mmc0: new high speed MMC card at address 0001
[ 1.705854] mmcblk0: mmc0:0001 4FPD3R 3.64 GiB
[ 1.710538] mmcblk0boot0: mmc0:0001 4FPD3R partition 1 4.00 MiB
[ 1.716648] mmcblk0boot1: mmc0:0001 4FPD3R partition 2 4.00 MiB
[ 1.722700] mmcblk0rpmb: mmc0:0001 4FPD3R partition 3 512 KiB
[ 1.731514] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
[ 1.743526] EXT4-fs (mmcblk0p5): warning: mounting unchecked fs, running e2fsck is recommended
[ 1.753635] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
I didn't know I wasn't meant to interfere with the partition tables on an eMMC. I've rebooted the box since and it seems to be OK so far - so thankfully partitions mmcblk0p1, mmcblk0p4 and mmcblk0p5 were not affected. Phew! I'll see what I get when I update to a later image soon on a different slot.
I didn't know I wasn't meant to interfere with the partition tables on an eMMC. I've rebooted the box since and it seems to be OK so far - so thankfully partitions mmcblk0p1, mmcblk0p4 and mmcblk0p5 were not affected. Phew! I'll see what I get when I update to a later image soon on a different slot.
I had some time to look into this issue again today. I had originally started checking the partitions and filesystem because following some historical crashes I noticed dmesg reporting mmcblk0p5 needing fsck. Interestingly partition 5 was able to boot without any observable problems, either with the same or with a new image installed on it, but the warnings in dmesg continued.
Then I ran parted, which reported "the backup GPT table is corrupt" as per #1 post above and this led me to restoring the backup table from the primary table as per #6 above. Having done this I came across a problem with partition 9 - filesystem headers missing or something like that, I can't recall exactly. I don't know if restoring the backup table on the drive caused some area on partition 9 to be overwritten, or if this was a long standing problem. I hadn't ever installed an image on slot 4 to notice anything wrong with this partition. Anyhow, I booted with the image on slot 1 and reformatted partition 9 as ext4, ran fsck on partition 5 which found and corrected some errors and finally rebooted with the image on slot 3. Since then I have installed new images on slots 2, 3 and 4. All boot and run without any problems. No more errors in dmesg.
This story had a happy ending, but given the warnings by contributors to this thread I wouldn't recommend my solution to others.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.