As far as I know, Windows does not handle such a converted system disk as a special case once the conversion is done, so it should be treated exactly the same as a disk in a "fresh" GPT-based system.
In particular, Windows imposes the limitation that GPT-partitioned system disks must always boot Windows in UEFI native style: that is, using BIOS-style boot process on GPT-partitioned disks is not allowed.
First, a primer on differences between MBR and GPT partitioning:
- In GPT, there is no division to primary/extended/logical partitions like MBR partitioning has. All GPT partitions are just partitions.
- Although there is a "legacy BIOS bootable" partition attribute bit in GPT partition table, it is not used at all when booting in UEFI style.
- MBR-partitioned disk normally has a gap of unused disk blocks between the block #0 (the actual Master Boot Record) and the beginning of the first partition. On modern systems, the first partition is usually aligned exactly 1 MiB from the beginning of the disk, so if the common 512-byte blocks are used, the first partition will begin at block #2048. The gap between MBR and the first partition is used by bootloaders like GRUB. On GPT-partitioned disks, this area is occupied by the actual GPT partition table and cannot be used.
- On MBR-partitioned disks, partition type is identified by a single byte. On GPT-partitioned disks, the type of each partition is identified by an UUID.
- MBR-partitioned disks have a 32-bit disk signature; GPT-partitioned disks have a 128-bit UUID for the same purpose. Each GPT partition also has an unique UUID in the partition table: it can be used to uniquely identify a partition even if the filesystem used in it is unknown. Linux displays this as a
PARTUUID; for MBR-partitioned disks, a combination of the MBR disk signature and partition number is used in lieu of a real partition UUID.
- The MBR partition table exists in block #0; if extended partitions are used, the beginning of each logical partition has an add-on partition table. The GPT partition table starts in block #1 and occupies multiple blocks; there is also a backup GPT partition table at the very end of the disk. This often causes a surprise if you are used to wiping the partitioning off a disk by just zeroing a number of blocks at the beginning of a disk only.
Since partition type UUIDs are inconvenient for humans to use, different partitioning programs have used various methods to shorten them. gdisk will use four-digit type codes; Gparted represents the different partition type UUIDs by various flags (which is, in my opinion, an unfortunate choice).
A native UEFI-style boot process is also very different from classic BIOS-style boot process:
- A BIOS-style boot process begins by (usually) assigning the BIOS device ID 0x80 (=first BIOS hard disk) to the device that is currently selected by the BIOS settings as the boot drive. When booting in UEFI style, the firmware settings ("BIOS settings" in an UEFI system) define a boot path: it can take many forms, but the most common one for installed operating systems will specify a partition UUID and a boot file pathname.
- When booting BIOS-style, the firmware checks for a 2-byte boot signature at the end of block #0 of the selected boot disk, and then just executes the about 440 bytes of machine code that fits in the MBR block in addition of the actual partition table. When booting UEFI-style, the firmware has a built-in capability to understand some types of filesystems: the UEFI specification says a compliant UEFI firmware must understand FAT32, but it may understand other filesystem types too. An UEFI "bootable disk" must contain a partition with a special type UUID: this is called the EFI System Partition, or ESP for short. The firmware will look for an ESP partition whose unique UUID matches the one specified by the boot path, and then attempts to load the specified boot file from that partition.
- When booting UEFI-style from a removable media, or from a disk that has not previously been configured to the firmware settings, the firmware looks for an ESP partition that contains a filesystem the firmware can read, and a file with a particular pathname. For 64-bit x86 hardware, this UEFI fallback/removable media boot path will be
\EFI\boot\bootx64.efi when expressed in Windows-style, or <ESP mount point>/EFI/boot/bootx64.efi in Linux-style.
The ESP partition has a standard structure: each installed OS must set up a sub-directory \EFI\<vendor or distribution name>\ and only place their bootloader files within it. The \EFI\boot\ sub-directory is reserved for the fallback/removable-media bootloaders, which follow the Highlander rule: there can be only one (for each system architecture).
By setting the GParted "boot flag" on a non-ESP partition, you effectively changed the type UUID of that partition to ESP type UUID. That was a mistake: now the disk has two partitions with type ESP. You should change the type of the partition you changed back to what it originally was. In GParted, that would mean removing the "boot" and "esp" flags; in gdisk, it would probably mean setting the type code to 8300 ("Linux filesystem") or perhaps 8304 ("Linux x86-64 root").
Since you also have Windows on the same disk, trying to use a BIOS-Boot partition (gdisk type code ef02) is not recommended: that would usually force you to go to firmware settings and enable/disable CSM each time you wanted to switch between operating systems. Instead, you would want to use the live Linux boot media to mount your on-disk installation to e.g. /mnt, and then chroot to it to replace the current BIOS-style bootloader (usually GRUB with the i386-pc architecture type) with a native UEFI one (e.g. GRUB with x86_64-efi architecture type). Basically (all the following commands as root):
mount <your root filesystem device> /mnt
mount -o rbind /dev /mnt/dev
mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
chroot /mnt /bin/bash
Now your session will be using the environment of your installed Linux OS, and you should be able to use package manager and any other tools pretty much as usual (caveat: if you have parts of the standard system like /var as separate partitions, mount them now too!)
The first step should be adding a mount point for the ESP and mounting it. First run lsblk -o +UUID to find the UUID of your ESP partition; since its filesystem type is most likely FAT32, it should be of the form xxxx-yyyy. Replace <ESP UUID> in the following commands with the actual UUID:
mount UUID=<ESP UUID> /boot/efi
echo "UUID=<ESP UUID> /boot/efi vfat umask=0077,shortname=winnt,flush 0 2" >>/etc/fstab
The next step is switching the bootloader type.
Unfortunately you didn't mention which Linux distribution you're using. If it's Debian, or Ubuntu, or some distribution derived from those, it would be a matter of using the standard package management tools to remove the grub-pc and grub-pc-bin packages and install grub-efi-amd64 and grub-efi-amd64-bin in their stead, then running grub-install /dev/sda (or whichever disk contains your ESP partition), and finally running update-grub to rebuild the GRUB configuration.
At this point, you can exit the chroot, undo the mounts and see if your system can boot now.
(if you had to mount any extra partitions, unmount them now)
exit
umount /mnt/dev
umount /mnt/proc
umount /mnt/sys
umount /mnt
reboot
You might also want to install the efibootmgr utility, as it allows you to view, backup and modify the firmware boot settings while Linux is running. (Windows can do the same with its bcdedit command, but in my opinion that command is much more awkward to use than efibootmgr.)
sudo fdisk -lorcat /proc/partitionssudo fdisk -lorcat /proc/partitionsthat you're interested? The machine is currently unbootable and running from a live system. I need to manually re-type them here. That's why I want to know why it matters and what exactly you'd be looking at. thx