The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Quick to answer questions about finding your way around Linux Mint as a new user.
Forum rules
There are no such things as "stupid" questions. However if you think your question is a bit stupid, then this is the right place for you to post it. Stick to easy to-the-point questions that you feel people can answer fast. For long and complicated questions use the other forums in the support section.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Locked
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

I just switched over 2 Windows machines into Linux Mint Cinnamon machines. I'm creating RAID-1 arrays for all my existing HDs.

The Cinnamon GUI just popped up this cryptic message ("The primary GPT table is corrupt, but the backup appears OK, so that will be used."). It doesn't tell me which HD, what files, it tells me nothing. It's worse than a Windows error message :mrgreen:

How do I begin to diagnose this? I left one Linux machine copying files to another overnight and I found this in the morning...

I have terabytes of irreplaceable customer files that I can't really afford to loose (hence RAID). Any help is greatly appreciated!
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

Update: I came across "fdisk -l" and here's the relevant output (disk IDs masked)..

Code: Select all

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 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
Disklabel type: gpt
Disk identifier: XXXXXXX-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxxxx


The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 7814037168 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
Disklabel type: gpt
Disk identifier: XXXXXXX-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

reveals that /sdb and /sdc are in the RAID-1 array md2.
gm10

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by gm10 »

Well, RAID-1 is for redundancy but that doesn't help you much if you set out building one with an already damaged disk. ;)
TrogdorMenoo wrote: Tue Dec 11, 2018 12:33 pm (disk IDs masked)..
That one always cracks me up. I'm not sure why people do that but ok.
User avatar
trytip
Level 14
Level 14
Posts: 5371
Joined: Tue Jul 05, 2016 1:20 pm

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by trytip »

it would make much more logic to buy a 6TB drive, these days you shouldn't have to mess with raid on a GPT
you made a bad choice doing this, hopefully you can backup your customer data and reformat your drives with new partition table non-gpt
Image
gm10

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by gm10 »

trytip wrote: Tue Dec 11, 2018 1:34 pm it would make much more logic to buy a 6TB drive, these days you shouldn't have to mess with raid on a GPT
you made a bad choice doing this, hopefully you can backup your customer data and reformat your drives with new partition table non-gpt
Lol what? RAID has nothing to do with GPT or not. Also he shouldn't do non-GPT in 2018...
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

gm10 wrote: Tue Dec 11, 2018 12:36 pm Well, RAID-1 is for redundancy but that doesn't help you much if you set out building one with an already damaged disk. ;)
TrogdorMenoo wrote: Tue Dec 11, 2018 12:33 pm (disk IDs masked)..
That one always cracks me up. I'm not sure why people do that but ok.
So how do I figure out which disk is bad?
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

trytip wrote: Tue Dec 11, 2018 1:34 pm it would make much more logic to buy a 6TB drive, these days you shouldn't have to mess with raid on a GPT
you made a bad choice doing this, hopefully you can backup your customer data and reformat your drives with new partition table non-gpt
Why is it more logic to buy a 6TB drive?

What's wrong with RAID on GPT? What's the alternative? MBR?
https://www.howtogeek.com/193669/whats- ... g-a-drive/
gm10

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by gm10 »

TrogdorMenoo wrote: Tue Dec 11, 2018 2:20 pm So how do I figure out which disk is bad?
Dunno, whichever drive was first in the array since the bad partition table got mirrored when you set up the array, i.e. it predates the array. Maybe it's also the controller that's bad or the driver. But partition tables don't corrupt themselves, so this is pretty serious. Check S.M.A.R.T. data and possibly run a badblocks check.
User avatar
JerryF
Level 16
Level 16
Posts: 6554
Joined: Mon Jun 08, 2015 1:23 pm
Location: Rhode Island, USA

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by JerryF »

You should stay with GPT. Maximum size for a usual MBR is 2 TB.
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

gm10 wrote: Tue Dec 11, 2018 2:38 pm
TrogdorMenoo wrote: Tue Dec 11, 2018 2:20 pm So how do I figure out which disk is bad?
Dunno, whichever drive was first in the array since the bad partition table got mirrored when you set up the array, i.e. it predates the array. Maybe it's also the controller that's bad or the driver. But partition tables don't corrupt themselves, so this is pretty serious. Check S.M.A.R.T. data and possibly run a badblocks check.
There should have been nothing predating the array. After I moved data off the drive (they were NTFS), I used Disk Manager (or was it GParted?) to delete every partition on the drive. Then I followed these instructions to get RAID up and running: https://www.digitalocean.com/community/ ... untu-18-04 (Scroll down to RAID-1 instructions)

It had me create an EXT4 file system after the RAID array was set up with mdadm. As far as the controller goes, would this be mdadm?

How do you check SMART or badblocks on a member of the RAID array?
gm10

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by gm10 »

TrogdorMenoo wrote: Tue Dec 11, 2018 2:51 pm There should have been nothing predating the array. After I moved data off the drive (they were NTFS), I used Disk Manager (or was it GParted?) to delete every partition on the drive. Then I followed these instructions to get RAID up and running: https://www.digitalocean.com/community/ ... untu-18-04 (Scroll down to RAID-1 instructions)

It had me great an EXT4 file system after the RAID array was set up with mdadm. As far as the controller goes, would this be mdadm?

How do you check SMART or badblocks on a member of the RAID array?
The problem is with the partition table, not the file system.

For SMART status or badblocks it doesn't matter what's on the disks, RAID or not.
deepakdeshp
Level 20
Level 20
Posts: 12334
Joined: Sun Aug 09, 2015 10:00 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by deepakdeshp »

TrogdorMenoo wrote: Tue Dec 11, 2018 2:51 pm
gm10 wrote: Tue Dec 11, 2018 2:38 pm
TrogdorMenoo wrote: Tue Dec 11, 2018 2:20 pm So how do I figure out which disk is bad?
Dunno, whichever drive was first in the array since the bad partition table got mirrored when you set up the array, i.e. it predates the array. Maybe it's also the controller that's bad or the driver. But partition tables don't corrupt themselves, so this is pretty serious. Check S.M.A.R.T. data and possibly run a badblocks check.
There should have been nothing predating the array. After I moved data off the drive (they were NTFS), I used Disk Manager (or was it GParted?) to delete every partition on the drive. Then I followed these instructions to get RAID up and running: https://www.digitalocean.com/community/ ... untu-18-04 (Scroll down to RAID-1 instructions)

It had me create an EXT4 file system after the RAID array was set up with mdadm. As far as the controller goes, would this be mdadm?

How do you check SMART or badblocks on a member of the RAID array?
https://help.ubuntu.com/community/Smartmontools
If I have helped you solve a problem, please add [SOLVED] to your first post title, it helps other users looking for help.
Regards,
Deepak

Mint 21.1 Cinnamon 64 bit with AMD A6 / 8GB
Mint 21.1 Cinnamon AMD Ryzen3500U/8gb
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

I tried using the Gnome Disk Utility to run SMART tests but it's grayed out. I had unmounted the RAID array (md2) before trying to run SMART tests.
User avatar
trytip
Level 14
Level 14
Posts: 5371
Joined: Tue Jul 05, 2016 1:20 pm

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by trytip »

i was under the assumption that your raid consisted of 3.7 TiB of old drives, my mistake
gm10 wrote: Tue Dec 11, 2018 3:02 pm The problem is with the partition table, not the file system.
did you create a new GPT partition table for all the drives first?
Image
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

deepakdeshp wrote: Tue Dec 11, 2018 3:17 pm
TrogdorMenoo wrote: Tue Dec 11, 2018 2:51 pm
gm10 wrote: Tue Dec 11, 2018 2:38 pm

Dunno, whichever drive was first in the array since the bad partition table got mirrored when you set up the array, i.e. it predates the array. Maybe it's also the controller that's bad or the driver. But partition tables don't corrupt themselves, so this is pretty serious. Check S.M.A.R.T. data and possibly run a badblocks check.
There should have been nothing predating the array. After I moved data off the drive (they were NTFS), I used Disk Manager (or was it GParted?) to delete every partition on the drive. Then I followed these instructions to get RAID up and running: https://www.digitalocean.com/community/ ... untu-18-04 (Scroll down to RAID-1 instructions)

It had me create an EXT4 file system after the RAID array was set up with mdadm. As far as the controller goes, would this be mdadm?

How do you check SMART or badblocks on a member of the RAID array?
https://help.ubuntu.com/community/Smartmontools
Thanks. I installed GSmartControl (the one with a GUI) and ran the SMART short test on both drives. Both drives completed the Short Self-test 'without error'. The extended self-test will take 9 hrs and I'll have to report back with results.

Should I copy data off the RAID array now, then do the SMART tests, and possibly just destroy/rebuild the array?
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

trytip wrote: Tue Dec 11, 2018 3:40 pm i was under the assumption that your raid consisted of 3.7 TiB of old drives, my mistake
gm10 wrote: Tue Dec 11, 2018 3:02 pm The problem is with the partition table, not the file system.
did you create a new GPT partition table for all the drives first?
I don't remember precisely. I think I might have but does it matter? When I run mdadm, I think you make a reference to the entire hard disk (/dev/sdb) rather than a specific partition... wouldn't this wipe out a GPT partition? I thought mdadm did its own thing with the whole disk, then you can create a file system on top of it. I followed these instructions: https://www.digitalocean.com/community/ ... untu-18-04

The guide does say 2 things (scroll down to "Create RAID-1"):
The mdadm tool will start to mirror the drives. This can take some time to complete, but the array can be used during this time. You can monitor the progress of the mirroring by checking the /proc/mdstat file:
As you can see in the first highlighted line, the /dev/md0 device has been created in the RAID 1 configuration using the /dev/sda and /dev/sdb devices. The second highlighted line shows the progress on the mirroring. You can continue the guide while this process completes.
In light of these quotes from the guide, would it be safe to start writing files during the initial mirror? Or, should I wait until cat /proc/mdstat shows resync = 100% ?
User avatar
trytip
Level 14
Level 14
Posts: 5371
Joined: Tue Jul 05, 2016 1:20 pm

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by trytip »

my experience always made me create a new partition table everytime i bought a new hard drive before i format it for ntfs or linux
only way to be certain your disk has no errors is if you backup your data and create new GPT partition table and start from scratch. there's no easy fix i can see. and if you still get GPT corrupt after then you might just do MBR

yes creating a new partition table will wipe out anything on that drive and gparted doesn't give a confirmation before it delete everything, so i would not create any new partition table unless you can forfeit the drive data
Image
gm10

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by gm10 »

TrogdorMenoo wrote: Tue Dec 11, 2018 4:05 pm In light of these quotes from the guide, would it be safe to start writing files during the initial mirror? Or, should I wait until cat /proc/mdstat shows resync = 100% ?
Wait, so your mirroring a live system and the process isn't even complete yet? Wait for it to complete then before you start diagnosing errors that might go away once mdadm is done with it. mdadm has to modify the partition table to fit the raid's metadata.
TrogdorMenoo
Level 2
Level 2
Posts: 99
Joined: Sun Nov 04, 2018 8:44 am

Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Post by TrogdorMenoo »

Not exactly... mdadm was still in the process of mirroring. Per the aforementioned instructions, I understood that I could immediately begin using the array. Therefore, I started copying files to array while initial mirroring was in progress. The error popped up a day after mdadm had finished initial mirroring.
Locked

Return to “Beginner Questions”