Failed Linux Installation Due to a Residual GPT Signature

A Successful Installation That Refuses to Boot

One afternoon at a friend's place, you are looking into an old PC running Windows 7 or Vista that had been sluggish for years. You offer to give it a second life with Linux. The installation goes smoothly, you're satisfied. You reboot, pleased with yourself… and then, nothing. The PC stubbornly refuses to boot into its new system. PXE, boot menu looping, black screen, or even the system's boot menu appearing without you being able to actually boot into the Linux distribution, despite an otherwise successful installation.

Disappointed and puzzled, you offer to take the PC back to your place, to take the time to investigate the problem.

What could have happened? In the case encountered here, the cause was insidious: the disk had already been used with a GPT partition table (typically for a UEFI system), and residual signatures persisted at the end of the disk. The firmware detected them and behaved accordingly, even though GParted had produced and displayed a clean MS-DOS table.

Here are the command lines that will allow you to detect key information on the storage disk.

1. Detecting Residual Signatures

List what the kernel actually sees on the disk, beyond what the active partition table indicates:

(Replace /dev/sdX with your target disk, for example /dev/sdb.)

Example of an actual conflict:

The simultaneous presence of both signatures is the source of the problem.

2. Alternative Diagnosis with TestDisk

If you want additional visual confirmation, testdisk gives you another insight into the situation. Its output may explicitly reveal the GPT artifact:

The line 1 P EFI GPT confirms the presence of the residual GPT signature. The Warning: Bad ending head indicates that the CHS geometry read by testdisk does not match modern LBA addressing — which is normal on an SSD, but here signals the conflict.

⚠️ Warning: testdisk is useful for diagnostics, but do not reuse its partition addresses to attempt a manual reconstruction in fdisk. Testdisk works with CHS geometry while fdisk uses LBA — addresses are not directly transferable, and the reconstruction will fail.

3. Removing the Ghost Signature

Remove only the GPT signature using its exact disk address, noted in step 1, without touching the partitions or rewriting the entire disk:

The MBR/DOS partition table becomes the sole reference again. GParted will no longer see a ghost esp partition, and the boot flag will become a simple standard boot indicator again.

You can run sudo wipefs /dev/sdX again to confirm that the artifact has indeed disappeared.

4. Verify After Installation

Once the installation is complete, verify that the filesystem is correctly recognized on the main partition:

Expected response: Linux rev 1.0 ext4 filesystem data... — the superblock is found, the partition is healthy.

Unexpected output: data — the superblock cannot be found, the partition is misaligned or improperly formatted.

If the response is incorrect and the situation does not resolve, start the installation over from scratch: if necessary, erase and recreate the partitions with GParted.

Important: after any change to the partitioning, reboot the system before launching the installation, so that the kernel properly takes the new disk layout into account.

Conclusion

A GPT artifact is a rare, insidious, and poorly documented cause of boot failure. It leaves no visible trace in GParted, and the symptoms — looping back to the boot menu, PXE boot attempts, black screen — can suggest dozens of other problems.

sudo wipefs allows you to reveal and safely target and eliminate it.