Showing GRUB and cursor blinking and not boot.

I changed my hard disk partition table from MBR to GPT with gdisk, and it worked fine. But after rebooting the system, it showed "GRUB" and cursor blinking and did not boot.

Operating system: Parrot security mate

How can I fix this? And how do I get my files back?

  • 1
    You have to reinstall grub. If UEFI, you need an ESP or if BIOS a bios_grub partition for grub to correctly install. Use Ubuntu live installer to use gparted to add correct partition for your boot mode. Many vendors still call it BIOS, but most systems since 2012 are really UEFI. Then run this: Lets see details, use ppa version with your live installer (2nd option) or any working install, not Boot-Repair ISO: Please copy & paste the pastebin link to the Boot-info summary report ( do not post report), do not run the auto fix till reviewed. help.ubuntu.com/community/Boot-Repair
    – oldfred
    Sep 25, 2021 at 19:22
  • @oldfred it is more than a comment, it should be an answer.
    – GAD3R
    Sep 25, 2021 at 19:27
  • Need to know if UEFI or BIOS so answer can be correct and without Boot-Repair report, we cannot confirm that is only issue or with report can give better details on the answer.
    – oldfred
    Sep 25, 2021 at 19:29

1 Answer 1


Normally, when a BIOS-style GRUB is installed into the MBR, it also occupies the first few blocks after the actual MBR block. But on a GPT-partitioned disk, the GPT partition table that same location, so an essential part of your pre-existing GRUB must have been overwritten by the new GPT partition table.

If the conversion was otherwise executed correctly, your files are fine: the damage will be limited to the GRUB bootloader, which (in its version for BIOS-style systems) has essential parts of it located outside the partitions as essentially raw pieces of embedded binary code. If you boot your system using a live Linux media, you should be able to mount your partitions and access the files in them normally right now.

With UEFI, this issue does not happen, because UEFI bootloaders are completely contained as files. If Secure Boot is not in use, the core part of an UEFI version of GRUB will be contained in an *.efi file, typically grubx64.efi, on a special ESP partition, which is the standard location for any UEFI bootloaders, and the rest can be loaded as module files as needed.

If a MBR-partitioned disk is booted in UEFI-style, the ESP would typically be a FAT32 partition with a special type ID of 0xEF. On a GPT-partitioned disk, the ESP has a dedicated UUID type identifier, which is known to essentially all GPT partitioning programs.

The combination of using BIOS-style boot process together with a GPT-formatted system disk is something Windows does not support, and so it is a case that is probably not tested at all by system manufacturers. However, in theory it should work just fine, provided that a suitable new location is provided for the parts of GRUB whose normal location now conflicts with the GPT partition table itself. This new location would be the BIOS boot partition, which is what I believe oldfred refers to as a bios_grub partition in the comments.

The size of a BIOS boot partition does not need to be bigger than 1 MiB, but now such a partition needs to be created and GRUB reinstalled so that it will use that partition for embedding the components displaced by the new GPT partition table.

If you have at least 1 MiB of free unpartitioned space, or can safely shrink one of your existing partitions by that much, you could use a live Linux boot media to create a BIOS boot partition and set its type accordingly. If you don't have free space anywhere else, but have a swap partition, deleting the current swap partition and recreating it 1 MiB smaller would be one easy way to get free space for the BIOS boot partition.

Then you would have to mount your existing root partition (and any other partitions if necessary), chroot into it, verify that your current version of grub-install supports the BIOS boot partition, and use it to reinstall GRUB on your now GPT-partitioned system disk.

But I agree with oldfred's suggestion in the comments: to ensure there are no other issues, you should first prepare a bootable Boot-Repair utility (probably using some other computer) and then use it in your computer to generate a report of the current situation and post a link to it here.

I'd also like to ask: why were you doing this conversion in the first place? If you were using BIOS-style boot and your current system disk is less than 2 TiB in size, converting to GPT partitioning has very limited benefits. If you are planning to migrate to a larger system disk, it would have been safer to do the migration with the new disk, allowing you to just replace the new disk with the old one and retry if something went wrong with the conversion.

  • Thanks. solved.
    – pkpk7
    Sep 28, 2021 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.