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).

Improve this question
8
  • 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
    Dec 5, 2016 at 12:20
  • @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
    Dec 5, 2016 at 13:57
  • 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
    Dec 5, 2016 at 13:58
  • By the way, the solution at askubuntu.com/q/386752/226024 does not solve the problem. :(
    – tomasz
    Dec 5, 2016 at 14:01
  • 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
    Dec 5, 2016 at 15:15

2 Answers 2

Reset to default
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.
Improve this answer
4
  • 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
    Dec 5, 2016 at 20:08
  • @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
    Dec 6, 2016 at 15:25
  • @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
    Dec 6, 2016 at 15:26
  • 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
    Dec 7, 2016 at 12:07
0

You can tell which drive GParted is having problems with: when the error comes up, you can see, behind the popup error message, that in the GParted status bar, at the bottom left corner of the GParted window, the message "Searching /dev/sdb partitions," where /dev/sdb will be replaced with whatever device is applicable in your situation.

Improve this answer
1
  • 1
    Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    May 13 at 14:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .