The primary GPT table is corrupt, but the backup appears OK, so that will be used.
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.
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.
-
- 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.
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
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!
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
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.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
-
- 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.
Update: I came across "fdisk -l" and here's the relevant output (disk IDs masked)..
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
reveals that /sdb and /sdc are in the RAID-1 array md2.
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
reveals that /sdb and /sdc are in the RAID-1 array md2.
Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Well, RAID-1 is for redundancy but that doesn't help you much if you set out building one with an already damaged disk.
That one always cracks me up. I'm not sure why people do that but ok.
Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
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
you made a bad choice doing this, hopefully you can backup your customer data and reformat your drives with new partition table non-gpt
Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Lol what? RAID has nothing to do with GPT or not. Also he shouldn't do non-GPT in 2018...
-
- 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.
-
- 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.
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/
Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
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.Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
You should stay with GPT. Maximum size for a usual MBR is 2 TB.
-
- 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.
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)gm10 wrote: ⤴Tue Dec 11, 2018 2:38 pmDunno, 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 abadblocks
check.
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?
Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
The problem is with the partition table, not the file system.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?
For SMART status or badblocks it doesn't matter what's on the disks, RAID or not.
-
- 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.
https://help.ubuntu.com/community/SmartmontoolsTrogdorMenoo wrote: ⤴Tue Dec 11, 2018 2:51 pmThere 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)gm10 wrote: ⤴Tue Dec 11, 2018 2:38 pmDunno, 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 abadblocks
check.
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?
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
Regards,
Deepak
Mint 21.1 Cinnamon 64 bit with AMD A6 / 8GB
Mint 21.1 Cinnamon AMD Ryzen3500U/8gb
-
- 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.
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.
-
- 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.
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.deepakdeshp wrote: ⤴Tue Dec 11, 2018 3:17 pmhttps://help.ubuntu.com/community/SmartmontoolsTrogdorMenoo wrote: ⤴Tue Dec 11, 2018 2:51 pmThere 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)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 abadblocks
check.
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?
Should I copy data off the RAID array now, then do the SMART tests, and possibly just destroy/rebuild the array?
-
- 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.
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:
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% ?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.
Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
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
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
Re: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
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 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% ?
-
- 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.
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.