gparted persistently claims that GPT table is corrupt

1

Question: gparted keeps claiming "The backup GPT table is corrupt, but the primary appears OK, so that will be used.". It persists even when I wipe the GPT table using gdisk, try to create new gpt table, try to create new mbr table.

Background: Recently, I got a new SSD drive. I used clonezilla to copy my old Ubuntu installation from a smaller SSD over to it, and it worked fine. Then I installed Windows on the side. There were some problems, but each system booted correctly more or less half of the time, but at some point, I could no longer boot Ubuntu at all.

I booted into a live usb, and in there, gparted and parted both gave me a message:

The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes

I thought maybe clonezilla did something wrong in the new ssd, so I turned off the computer, unplugged the new SSD and left an old HDD plugged in. To my surprise, I got the same message from gparted after rebooting, so I decided to use the HDD as a test ground for solutions. There were some similar posts here and elsewhere -- only they were for usb sticks -- and according to the answers given there, I backed up all the data from the HDD to an external drive (this time without any low-level tools, just nautilus), and erased the whole disk via dd if=/dev/zero of=/dev/sda bs=100M.

When it finished, I no longer got the message. However, parted threw at me

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

I tried to create new partition table (gpt and msdos both), create new partitions, tried zapping everything with sgdisk -Z /dev/sda, overwriting the gpt via gdisk, tried installing windows and linux on top of the zapped gpt, and the problem persists. Installed Linux boots up fine. I did not try to boot Windows (I did not go past partitioning phase, I just wanted it to create new partition table with its own tools). Except for the gparted alert, there does not seem to be anything overtly wrong, but I'm worried that if I just ignore it, it will not only be annoying, but also lead to some more problems downhill.

I feel entirely helpless at this point. I have no idea what the problem might be. Unfortunately, I don't have any other device at hand to check the disks (though if all else fails, I suppose I'll try that).

tomasz

Posted 2016-12-05T10:32:43.433

Reputation: 131

I'm not sure how dd handles it if you have a full drive. You told it to use a block size of 100 MB for reading and writing. Maybe it skipped overwriting the last 100 MB of the disk? As the backup for a GPT table would be stored at the end of the disk it might be seeing a, possibly, damaged table. As for the message about 512 Byte/2KB sectors check your drive description. It doesn't sound like you have a problem anymore right now? – Seth – 2016-12-05T12:20:15.433

@Seth: I see. That might make sense. But why doesn't creating and zapping gpt fix it? If that's true, do you have any idea how to delete what remains without dd ing the whole disk with physical blocksize? I think it would take over 10 hours... As for the blocksize issue, it is not present on the HDD, but it is still (I believe) there for the ssd. If you have any idea on how to fix it without nuking the disk, I would be interested in that. – tomasz – 2016-12-05T13:57:40.807

Although obviously, zeroing the ssd would be much faster. But I don't want to do it unless I'm sure that will actually resolve all the issues. – tomasz – 2016-12-05T13:58:52.677

By the way, the solution at http://askubuntu.com/q/386752/226024 does not solve the problem. :(

– tomasz – 2016-12-05T14:01:35.780

It was just my guess. I might be wrong on this. After all, as your askubuntu link points out, the table should be "repaired" by writing it again. How much smaller was the old SSD? For you blocksize issue at least this question doesn't make it look like there is a solution short of nuking it.

– Seth – 2016-12-05T15:15:00.150

@Seth the smaller one is 128 GB, the bigger one is twice the size. – tomasz – 2016-12-05T15:28:22.160

@Seth: I think you are right about the secondary gpt, if you believe Wikipedia, see: https://en.wikipedia.org/wiki/GUID_Partition_Table#/media/File:GUID_Partition_Table_Scheme.svg.

– tomasz – 2016-12-05T16:01:04.103

@Seth: Actually, the answer was far less serious. The complaint about corrupt GPT was not about the HDD, but the pendrive I had booted from... sorry for wasting your time and thanks a lot for the help! – tomasz – 2016-12-05T16:34:04.033

Answers

0

Actually, it turned out that the problem with GPT table was not on the hard drive I had nuked, but the very pendrive I used for rescue. Furthermore, it seems like the initial problem was not at all present on the ssd, and I am not sure if it was even present on the hard disk. Long story short, I very much do not recommend using rufus for making live usb.

The source of my confusion (in both cases) is that gparted didn't tell me which drive it had problems with.

For future reference, if anyone has a problem like this, you can do the following:

  1. Start parted (the terminal version).
  2. Type select /dev/sdX to select the device in question.
  3. Type print (not print all). Then it will tell you if it thinks something is wrong with the device you have selected.

tomasz

Posted 2016-12-05T10:32:43.433

Reputation: 131

Rufus author here. Mind indicating the exact ISO you used when creating the USB (as well as whether you used DD or ISO mode when creating the ISO, and confirming that you selected "GPT partition scheme for UEFI")? I'm trying to replicate the issue you report with ubuntu-16.10-desktop-amd64.iso but gparted does not see any problem with the backup table, so, unless you can provide more information, I doubt Rufus was at fault here... – Akeo – 2016-12-05T20:08:41.360

@Akeo: I haven't tested nearly enough to be certain that Rufus is (solely?) at fault here. I used the image you have described and the 16.04.1-desktop-amd64.iso. One of them had the sector size problem, while the other had the gpt issue. In one of these, I used the "iso mode", while in the other I used the "dd" mode. I don't remember now which I used for which (I've since reformatted them both). I'm not sure if I used the "GPT partition scheme for UEFI" or the "MBR for BIOS or UEFI" option, I think I used different one in each case, and again, I don't remember which was which. – tomasz – 2016-12-06T15:25:26.237

@Akeo: It might be (at least in part) that the issue is with the sticks I have used, or the machine I used for making them (I think I recall it complaining about at least one of them). If/when I feel like testing it, I will ping you with an update (no promises though, I feel kinda worn out by the experience). – tomasz – 2016-12-06T15:26:29.890

thanks for the details. DD mode will create an MBR drive (and ignores any of the GPT or MBR option you selected), so I don't think you could have gotten a GPT error from that. Or at least, if you got one, it wasn't from the USB, since it wasn't a GPT drive. So the only way you could have gotten a GPT error message from the USB is if you selected GPT as well as ISO mode. If, on the other hand, you got the GPT error even when you selected MBR with ISO mode or DD mode, then it's likely that the error came from something else than the USB. – Akeo – 2016-12-07T12:07:54.530

Asked: 2016-12-05T10:32:43.433

Viewed: 2 187 times

Active: 2016-12-05T16:51:01.937