When a major Linux distribution is properly installed to either an MBR-layout SSD or a GPT-layout, and there are no boot files whatsoever on either SSD, the situation is supposed to be considered (nearly) ideal. Except that it won't boot yet :\
All it needs are boot files in an EFI folder in the dedicated FAT32 boot partition these days, the first partition on the SSD is good whether MBR or GPT.
A partition that's quite easy for a user to select, and even easier than ever for a computer. Actually most Linux install routines mastered this over a decade ago when it was truly more difficult to get right, but they all seem to have dropped the ball in recent years. While the actual problem has become less of a challenge by far.
People just have to accept that FAT32 is here to stay now that GPT is having its way. Like for a decade now.
And take advantage of FAT32 on MBR, plus that's how FAT got going to begin with.
Motherboard firmware that's up to UEFI spec will boot either MBR or GPT beautifully, this is by design. So what if there are numerous attempts to code UEFI firmware that fail to meet specs, even from big PC companies. Lots of them will still boot an SSD with either MBR or GPT layout as long as there is a sensible EFI folder on an early FAT32 volume, it's not that hard. Even on some of the otherwise shoddier firmware implementations.
That's no excuse at all to be a slacker on open-source.
All Grub needs is a sensible one-liner and it will put fresh boot files into your chosen FAT volume into a brand new EFI folder, populating it with boot files that point to your root partition.
No data in any other partition needs to be written.
Even Grub 1.x would do this, but there were not as many FAT volumes back then so you best made other choices manually. Now the variables are dramatically reduced, all an installer needs is to autofind the FAT volume and plunk down an EFI folder if there's not already one there. Grub has been autofinding the root real well for decades.
What needs to be done on a distro installer like Anaconda, is not give up on the MBR layout. Just admit defeat at making MBR disks boot on a BIOS PC or under CSM.
Only stick to booting by UEFI and make the installer give an MBR disk the same kind of EFI folder it does with GPT.
Done.
Easy on MBR or GPT with a suitable FAT32 boot volume in addition to their main OS partition(s) on their SSD to begin with. MBR layout simply needs to conform to a vague representation of where the corresponding volumes would be if it was GPT, and a properly simplified installer could do the job quite identically either way. Especially since you need the exact same boot files in the EFI folder either way, unless you're doing it obviously way wrong.
If you're throwing in the towel on MBR then you're failing on BIOS booting by definition. Now if BIOS booting is so challenging, there's still really no need to give up the MBR layout, just give up the BIOS booting as far as the mainstream installer goes.
That will work every time and be more reliable on the FAT boot volume than even the most coherent system files on any other volume by comparison. MBR layout will always boot using UEFI unless the mainboard firmware is true garbage then you're going to need GPT anyway and that would be a good time for a meaningful error message to inform the user. Garbage firmware is a pretty low bar, I would want my installer code to benchmark way above that when it comes to meeting specs.
Those having MBR can go the extra mile if they want to boot in BIOS mode, with an "Active" MBR partition, and things like special bootsectors, but none of that matters with UEFI. It may be 10x as hard to come up with the ideal Grub one-liner(s) and surrounding code in the BIOS case compared to UEFI today, but it's still not that hard.
Things like this shouldn't be the least bit challenging for a coding professional.
When a major Linux distribution is properly installed to either an MBR-layout SSD or a GPT-layout, and there are no boot files whatsoever on either SSD, the situation is supposed to be considered (nearly) ideal. Except that it won't boot yet :\
All it needs are boot files in an EFI folder in the dedicated FAT32 boot partition these days, the first partition on the SSD is good whether MBR or GPT.
A partition that's quite easy for a user to select, and even easier than ever for a computer. Actually most Linux install routines mastered this over a decade ago when it was truly more difficult to get right, but they all seem to have dropped the ball in recent years. While the actual problem has become less of a challenge by far.
People just have to accept that FAT32 is here to stay now that GPT is having its way. Like for a decade now.
And take advantage of FAT32 on MBR, plus that's how FAT got going to begin with.
Motherboard firmware that's up to UEFI spec will boot either MBR or GPT beautifully, this is by design. So what if there are numerous attempts to code UEFI firmware that fail to meet specs, even from big PC companies. Lots of them will still boot an SSD with either MBR or GPT layout as long as there is a sensible EFI folder on an early FAT32 volume, it's not that hard. Even on some of the otherwise shoddier firmware implementations.
That's no excuse at all to be a slacker on open-source.
All Grub needs is a sensible one-liner and it will put fresh boot files into your chosen FAT volume into a brand new EFI folder, populating it with boot files that point to your root partition.
No data in any other partition needs to be written.
Even Grub 1.x would do this, but there were not as many FAT volumes back then so you best made other choices manually. Now the variables are dramatically reduced, all an installer needs is to autofind the FAT volume and plunk down an EFI folder if there's not already one there. Grub has been autofinding the root real well for decades.
What needs to be done on a distro installer like Anaconda, is not give up on the MBR layout. Just admit defeat at making MBR disks boot on a BIOS PC or under CSM.
Only stick to booting by UEFI and make the installer give an MBR disk the same kind of EFI folder it does with GPT.
Done.
Easy on MBR or GPT with a suitable FAT32 boot volume in addition to their main OS partition(s) on their SSD to begin with. MBR layout simply needs to conform to a vague representation of where the corresponding volumes would be if it was GPT, and a properly simplified installer could do the job quite identically either way. Especially since you need the exact same boot files in the EFI folder either way, unless you're doing it obviously way wrong.
If you're throwing in the towel on MBR then you're failing on BIOS booting by definition. Now if BIOS booting is so challenging, there's still really no need to give up the MBR layout, just give up the BIOS booting as far as the mainstream installer goes.
That will work every time and be more reliable on the FAT boot volume than even the most coherent system files on any other volume by comparison. MBR layout will always boot using UEFI unless the mainboard firmware is true garbage then you're going to need GPT anyway and that would be a good time for a meaningful error message to inform the user. Garbage firmware is a pretty low bar, I would want my installer code to benchmark way above that when it comes to meeting specs.
Those having MBR can go the extra mile if they want to boot in BIOS mode, with an "Active" MBR partition, and things like special bootsectors, but none of that matters with UEFI. It may be 10x as hard to come up with the ideal Grub one-liner(s) and surrounding code in the BIOS case compared to UEFI today, but it's still not that hard.
Things like this shouldn't be the least bit challenging for a coding professional.