When Anaconda decides to use a GPT label (because it's UEFI, a big disk, the user asked for it, or whatever), it would be nice if it always created both an ESP partition and a BIOS boot partition, regardless of whether the system will boot using UEFI or BIOS. Pros: - It makes it much easier to switch between UEFI and BIOS boot later on. (Yes, I know that this is a silly / painful thing to do.) - It makes easier to reinstall the system using the other boot type -- there's no need to move partitions around. Cons: It wastes a tiny bit of space. Note: This RFE is not about the method by which Anaconda creates both partitions. See bug 1022316 for a discussion about how automatic creation of these types of partitions should work. Note 2: On non-x86 platforms, it might not make sense to create a BIOS boot partition. I'm okay with skipping it in that case. Note 3: I'm not asking to change the default from MBR to GPT on BIOS systems with small disks. This should only apply if GPT is being used anyway.
The proposal doesn't make it easier to switch from BIOS to UEFI because: a.) there's no BIOSBoot type code on MBR so it can't even be created; b.) it uses a highly valuable primary partition entry which most users will oppose outright; c.) it requires new code in parted, pyparted and blivet to support MBR type code 0XEF for the ESP. All for a total edge case. The UEFI to BIOS conversion is made easier, but it too is a total edge case. Anyone who can actually do the conversion steps needed is more than capable of preparing the partition scheme as described in advance of running anaconda.
(In reply to Chris Murphy from comment #1) > The proposal doesn't make it easier to switch from BIOS to UEFI because: I suspect you're misreading my proposal -- I'm talking about changing behavior on *GPT* installs. > > a.) there's no BIOSBoot type code on MBR so it can't even be created; Doesn't matter. AIUI the BIOSboot entry in the GPT isn't even parsed at boot time -- it just reserves a safe space for the first-stage bootloader to stash some code. On true MBR systems that boot from the MBR (as opposed to chaining to a partition), this code goes after the MBR and before the first partition. I think that this doesn't work on GPT, so instead bootloader installers will look for a BIOSboot partition and stick their stage 1.5 there. In other works, the relevant thing is that the the first sector of the disk contains a bit of code that loads from BIOSboot, referencing it by offset. As a concrete example, on a real, working computer, gdisk says: Disk /dev/sda: 468862128 sectors, 223.6 GiB Logical sector size: 512 bytes Disk identifier (GUID): 9B7A8655-4363-49E7-87F7-7E0B736A61B3 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 468862094 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 264191 128.0 MiB EF00 EFI System Partition 2 264192 329727 32.0 MiB EF02 BIOS boot partition 3 329728 6555647 3.0 GiB 0700 Linux filesystem 4 6555648 468862094 220.4 GiB 8300 Encrypted fdisk -t dos says: Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 468862127 234431063+ ee GPT There's no "BIOS boot partition", but it still works. > b.) it uses a highly valuable primary partition entry which most users will > oppose outright; No. The protective MBR will contain only one entry regardless. GPT entries aren't valuable. > c.) it requires new code in parted, pyparted and blivet to support MBR type > code 0XEF for the ESP. Still not true. See the above output from fdisk. The protective MBR is not affected *at all* by my proposal.
(In reply to Andy Lutomirski from comment #2) > (In reply to Chris Murphy from comment #1) > > The proposal doesn't make it easier to switch from BIOS to UEFI because: > > I suspect you're misreading my proposal -- I'm talking about changing > behavior on *GPT* installs. I completely missed NOTE 3, which pretty much explains all of the confusion between us, because at no time was I ever referring to a PMBR. All of my references to MBR limitations apply strictly to an MBR (no GPT at all). However, that confusion doesn't change the fact that overwhelming majority of GPT installs are UEFI installs, hence your proposal mostly benefits the UEFI->BIOS conversion direction, not the inverse. The BIOS+GPT case is rare, and the BIOS->UEFI conversion case will be even more rare still. And still needing UEFI->BIOS conversion implies something is broken. I find the conversion use case really uncompelling. Unworking UEFI installs are so obvious that the penalty for simply reinstalling is pretty low. A bigger problem is figuring out how to even get the firmware to boot with CSM-BIOS. The overwhelming majority of such installs are UEFI installs. Not BIOS. So the proposal is still benefiting pretty much UEFI->BIOS conversion. > > a.) there's no BIOSBoot type code on MBR so it can't even be created; > > Doesn't matter. When you said "easier to switch between UEFI and BIOS" I assumed also "easier to switch between GPT and MBR" because BIOS mainly implies MBR since that's the anaconda default, and booting 2+TB drives on BIOS is rare since Windows lacks support for this combination.
(In reply to Chris Murphy from comment #3) > (In reply to Andy Lutomirski from comment #2) > > (In reply to Chris Murphy from comment #1) > > > The proposal doesn't make it easier to switch from BIOS to UEFI because: > > > > I suspect you're misreading my proposal -- I'm talking about changing > > behavior on *GPT* installs. > > I completely missed NOTE 3, which pretty much explains all of the confusion > between us, because at no time was I ever referring to a PMBR. All of my > references to MBR limitations apply strictly to an MBR (no GPT at all). > > However, that confusion doesn't change the fact that overwhelming majority > of GPT installs are UEFI installs, hence your proposal mostly benefits the > UEFI->BIOS conversion direction, not the inverse. The BIOS+GPT case is rare, > and the BIOS->UEFI conversion case will be even more rare still. > I hope so :) The reason I'm seriously proposing this is that I think it'll be straightforward -- it might even be a net deletion of code. I expect that relatively few people will benefit. > And still needing UEFI->BIOS conversion implies something is broken. I find > the conversion use case really uncompelling. Unworking UEFI installs are so > obvious that the penalty for simply reinstalling is pretty low. A bigger > problem is figuring out how to even get the firmware to boot with CSM-BIOS. > For the time being, anyone who plays with NV-DIMMs is likely to need to convert back and forth. Hopefully this'll be fixed some day, but there's nothing that software can do about it. The firmware interface is fundamentally silly. > > The overwhelming majority of such installs are UEFI installs. Not BIOS. So > the proposal is still benefiting pretty much UEFI->BIOS conversion. > > > > a.) there's no BIOSBoot type code on MBR so it can't even be created; > > > > Doesn't matter. > > When you said "easier to switch between UEFI and BIOS" I assumed also > "easier to switch between GPT and MBR" because BIOS mainly implies MBR since > that's the anaconda default, and booting 2+TB drives on BIOS is rare since > Windows lacks support for this combination. I can't be the only person who's configured a 3 TB disk on a machine that's old enough that it can't (usefully) boot using UEFI. Also, there's another reason to use GPT: it supports large numbers of partitions, and it has partition labels. The benefits of this are independent of UEFI. I use GPT everywhere in part because I wrote a bunch of things that need those labels.
Changing the title to better distinguish it from bug 1022316. This bug requests always creating both an ESP and BIOS Boot partitions. Bug 1022316 merely requests the required applicable one (BIOS=BIOS Boot, UEFI=EFI System partition) be created without asking the user to do it manually.
We aren't going support swapping back and forth between BIOS and UEFI.
This is an unfortunate decision. I suspect that I'm far from the only user to move a hard disk into a new machine. Given that implementing this feature request probably involves very little code, I'm a bit unhappy to see it closed without any real explanation.
FWIW, for Fedora CoreOS <https://getfedora.org/coreos/> our disk images come out of the box in this setup. (We also don't use Anaconda to generate the disk images partly due to Anaconda not supporting this layout)