Done a clean install (with GPT Partition table) from DVD on my Dell E6410 laptop (new SSD). After the install is complete and subsequently running gparted to check on the disk, I get the message from gparted “the backup gpt table is corrupt, but the primary appears OK, so that will be used”
I would like any experience on this issue that anyone might care to contribute. The laptop predates EUFI facility. The system does not seem to fail in any obvious way.
Try gdisk to examine, verify and fix GPT tables.
Thanks for the note. Loaded and ran gdisk from the command line withe the following results:
First message from gdisk was:
Caution: Found protective and hybrid MBR and corrupt GPT. Using GPT but disk verification and recovery are STRONGLY recommended.
used v command:
No problems found. 2014 free sectors (1007.0 KiB) available in 1 segments the largest of which is 2014 (1007.0 KiB) in size
ran command d, then command e, then command w
Booting and running gdisk again produced the same warning as listed above.
Comments and suggestion on the above are appreciated along with how to proceed.
y3:~ # **gdisk /dev/sda**
Command (? for help): **?**
...
r recovery and transformation options (experts only)
...
Command (? for help): **r**
Recovery/transformation command (? for help): ?
...
d use main GPT header (rebuilding backup)
...
Recovery/transformation command (? for help): **d**
Recovery/transformation command (? for help): **w**
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): **Y**
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
y3:~ #
Thanks for your followup instructions. The procedure you outlined produced the same result as earlier. Message from gdisk is that the backup GPT is corrupt and the primary is being used.
I am a bit stumped.
Did you reboot again after rewriting the partition table?
How was the SSD partitioned originally?
Are there any manufacturer tools to test or repair the drive?
Apart from gdiskI am only confident with using parted from a bash shell or via YaST or the openSUSE install CD/DVD. I do not use gparted.
The only thing I can suggest is to boot using the Recovery/Rescue option from the install DVD and then gdisk to erase the SSD partition table. Then try creating new partitions and verifying before proceeding further.
My guess is that your disk has a bad sector, so that rewriting the partition table doesn’t fix it.
Thanks again for all of your comments. Responding to most of the questions:
Yes I did reboot after each gdisk session.
The drive is a Crucial MX300 250 gig new out of the box. Think it was set up with an msdos partiton table from the factory. I do not know if there are any vendor tools to check the drive but I will check with crucial and if there are I will use that before proceeding
Looks to me, after review of your suggestions, that the next thing to try before returning the drive, is to use gdisk to erase the current partition table and then reload Leap 15 from the disk which has been checked with sha256.
Any comments are welcome but since it is already dinner time in the UK I will not look for any until tomorrow morning. Thanks again.
.
First steps would be to run tests on the drive. It could be faulty. If it is, then you have a warranty to deal with.
Small point the secondary table is on the final meg of the drive if a partition is set to use that area you can not put a table there so you may need to leave a bit of space at the end. Also in general it is good not to use ALL the space on a SSD because of how it spares blocks out. In theory a practitioner should not allow usage of the final 1 meg but…
Adding my 2 cents. I avoid those hybrid setups, using DOS formatted disks in legacy systems and GPT disks in UEFI systems.
I don’t see any benefit in using GPT on a relatively small disk in a legacy system.
GPT-unaware utilities in legacy systems might overwrite the backup GPT at the end of the disk.
As gogalthorp wrote, leaving some unallocated space at the end of the disk might help, but I don’t really know how the usual disk utilities deal with those hybrid setups and if / how they ensure consistency between the hybrid MBR and GPT tables.
Anyway, one valid MBR table and ONE consistent GPT table are all you need to use the disk; you miss some recovery capability of GPT but if your hybrid MBR were corrupt would you really trust your GPT information?
Quoting from “man gdisk”:
h Create a hybrid MBR. This is an ugly workaround that enables GPT-unaware OSes, or those that can’t boot from a GPT disk, to access up to three of the partitions on the disk by creating MBR
entries for them. Note that these hybrid MBR entries can easily go out of sync with the GPT entries, particularly when hybrid-unaware GPT utilities are used to edit the disk. Thus, you may
need to re-create the hybrid MBR if you use such tools. Unlike the ‘g’ option, this option does not support converting any partitions into MBR logical partitions.
I don’t know about this particular system. But, according to google, there are Dell E6410 systems with UEFI support.
If I am correctly reading earlier posts in this thread, the OP started with a new disk, then installed Leap 15. The installer does use GPT formatting for new disks. But I don’t see where anything has been done that would create hybrid partitioning.
To me, it looks as if either the disk is defective (bad sectors near the end of the disk), and the appearance of hyrbrid partitioning results from that; or the BIOS of that computer is messing up the partition table (unusual), or something else is happening that has been omitted.
I’ve used GPT partitioning with legacy BIOS systems, and have never run into a similar problem.
I don’t see any benefit in using GPT on a relatively small disk in a legacy system.
I’m inclined to agree with that. However, the Leap 15.0 installer uses GPT by default. So I don’t think this is a decision by the OP himself. On an empty disk, it is hard to persuade the Leap 15.0 to use legacy partitioning.
One of the options on the install DVD/USB drive after “Install” an Upgrade” is something like Rescue or Recovery – you may need to select More options to see it. This will give you access to a root shell with basic commands available. You can also get access to this functionality by pressing <alt+ctrl+F2> during the early stages of an installation.
From this root prompt (#) you can execute gdisk, parted, etc. on the SSD before booting from it.
Some of the other comments here do not seem particularly helpful. There are no OS level programs that can help a drive with low-level errors. All mass devices are expected to contain low-level media errors. To this end they are manufactured with spare capacity and the on-board firmware is responsible for providing the operating system with a map of continuous good blocks to match the nominal capacity. Manufacturers supply stand-alone utilities to update the firmware and reset the media scan and mapping etc. You can download Crucial’s toolset from:
After trying gdisk while the SSD is not in use, I would try removing and replacing the drive next. Remember to disconnect the battery/power supply first and take precautions to minimise static electricity. It is possible for a poor connection to be fixed by the wiping effect of dismantling-reassembly.
Then try the Crucial Storage Executive before recreating the GPT table and a couple of test partitions.
If that is not successful consider returning the drive either to the seller or to Crucial. My experience with Crucial, both online and calling into their local office, has been positive (including no-fuss exchange of a memory module that failed after eight years in a server).
Please let us know how you get on.
First a search of the bios settings on the E6410 in service does not yield any hint of UEFI present. Using the gdisk zap with a blanked mbr, then reloading DVD Leap 15 reproduces the results I have seen on this MX300 crucial drive.
I don’t have a windows machine readily available to run the crucial-storage-executive for the drive.
It seems clear that a decision was made during testing or finishing up the new Leap 15.0 installer disk to use GPT partition tables without any clear options during the setup.
Looks like the next move is to pursue the disk itself.
One idea might be to clear the disk with gdisk zap command, then move MX300 (secondary disk in a docking station connected through a usb port) to another machine running Leap 14.3 with gdisk installed. This would allow manual build of the GPT partition table.
Probably best to just replace the disk.
In any case thanks for all the notes and suggestions. I’ll be out of town next week so I will not be able to respond until July 23.
If you really want to try:
Start an install. Go to the expert partitioner. Click on the disk drive (probably “/dev/sda”) in the left column. There should be an option, I think it is called “Expert” near bottom right of the screen. Using that, you can have it create a new partition table. And you can choose between DOS partition table or GPT partition table. And then you have to manually partition the way you want.
But even if you do that, you might run into problems if there are bad sectors on the disk.
Completion of work on the issue and status.
First off thanks to everyone for their assistance and many ideas especially nrickert.
After consideration of all the suggestions, the size of the SSD and the lack of need for more than 4 partitions to install Leap 15, I performed the following steps:
A-Running gdisk I zaped all the existing partition tables
B- I ran fdisk and installed an msdos partition table
C- I started a Leap 15 install from a cd and selected the expert partitioning box.
D- I did a manual install using ext4 for the operating system and the /home partition.
The system seems to be running fine. Running gdisk again shows not anomalies on the disk, that is in comparison to what was experienced in initial work. Gparted does not reveal any problems either.
I learned a great deal on partition tables also and have a fuller understanding of UEFI although that does not enter into the current issues.