Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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?
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.
