I don't think this is an anaconda bug.

I think this is probably what we are after:

    part biosboot --fstype=biosboot --size=1

I'm guessing Beaker will just have to figure out whether it's a GPT disk or not, and add then add this in. This seems to be needed in anaconda as of anaconda-16.21-1

Sorry, my mistake. I'll assign this back to anaconda and let them decide what they want to do with this particular change.

Hi, 

What's the status of this bug now? I can still hit it when testing RHEL7, and it's kind of a test blocker because many jobs aborted due to this bug.

Thanks!

Eryu Guan

As comment #9 indicates, a biosboot partition is required for this particular system type.  Since you are doing custom partitioning, anaconda expects the kickstart file to define all partitions required for installation.  If you do an autopart installation, biosboot would be created.

This should be noted in the Installation Guide, so I'm reassigning it to that component.  Section 16.4 that describes Kickstart Options should note the biosboot options and a Kickstart example should be provided somewhere in this section for how to define a biosboot partition (and why).

This is not an anaconda bug.  Beaker could be expanded to determine when it should add biosboot part lines, but I don't think that's necessary.  The beaker recipe should just define a biosboot partition.

(In reply to David Cantrell from comment #15)

The problem from Beaker's point of view is that the biosboot partition is needed *only* if GPT is used. The biosboot partition makes no sense on MBR. But Beaker doesn't control whether GPT is used, Anaconda decides based on (I believe) some fairly complicated logic.

How can we craft a kickstart template which will work correctly on both GPT and MBR?

To clarify the documentation/functionality requirements from the Beaker side, we need suitable guidance that will allow us to write a generic kickstart that supports *both* of the following cases:

- system is using MBR (/biosboot partition not needed and not actually wanted)
- system is using GPT (/biosboot required)

We have no apriori knowledge as to which case is going to apply for any given system, so if Anaconda expects the /biosboot partition to be created explicitly in the kickstart rather than doing it automatically when needed, we at least need to be able to run the "part biosboot --fstype=biosboot --size=1" command unconditionally without it failing on disks without a GUID Partition Table (or else a way to indicate in the "part" command that Anaconda should skip creating that partition for MBR disks).

It seems to me that some additional context may be needed on the origins of this bug, and what is needed to fully resolve it.

Beaker is an automated test system that is used, amongst other things, for automated testing of the Anaconda installer: http://beaker-project.org/

Eryu found that attempting to provision a system using GPT disks in Beaker resulted in the following error from Anaconda:

"""Your BIOS-based system needs a special partition to boot from a GPT disk label. To continue, please create a 1MB 'biosboot' type partition."""

Now, while Beaker *does* have the ability to include per-system snippets in the kickstart files, this is an incredibly high maintenance solution to provisioning problems like this, since it needs to be manually added to every affected system.

The documentation changes that have been made so far *are not sufficient* for us to address the problem in a generic kickstart file. To do that, we need to know how to either:

1. Issue a command to Anaconda in the kickstart that will create this partition *only if it is needed*.

2. Issue a command in the kickstart to *find out* if this partition is needed.

Either solution works for us, but the docs updates that have been made so far only address the "how to create the biosboot partition" part of the problem, they don't cover the question of how we figure out whether or not we need to create it in order to get the system to boot.

Aside from Nick's concerns about this having pivoted from being an anaconda RFE to being a documentation issue, there are some problems with the documentation as written.

1. It should specify that the BIOS boot partition is only required when doing a *BIOS native* install to a GPT disk. It is not required when doing a *UEFI native* install to a GPT disk. In that configuration, no BIOS boot partition is required, but an EFI system partition is.

This is a far more common configuration, and unless this is explicitly stated, people often get confused - thinking they can use a BIOS boot partition on a UEFI install (they can't), or they can use an EFI system partition for a BIOS install (they can't), or they need both (they never do). I would recommend having an expert on this topic review all the relevant documentation to make sure it's all sane and internally consistent, as this is a topic area prone to all kinds of confusion and misconceptions.

"mbr (the default value — installs the boot loader to either the Master Boot Record or a BIOS Boot partition)"

this is not correct. In *both* cases, grub's stage1 is installed to the MBR itself, and stage2 is installed to the /boot partition. The difference is in where stage1.5 is installed. With a BIOS-on-MBR-disk install, stage1.5 lives in the 'embedding area', the empty space between the MBR and the first partition. With a BIOS-on-GPT-disk install, stage1.5 lives in the BIOS boot partition. There is no 'embedding area' - no empty space between the GPT itself and the first partition - on a GPT-formatted disk. This is why the BIOS boot partition is required.

I should've made that last comment clearer, but just to be precise: yes, it really is true that grub stage1 is installed to "the MBR" on a GPT disk. That's not a typo or me being crazy. The GPT format retains the first sector (LBA 0) for an MBR, and we really do write grub stage1 to this when doing a BIOS-on-GPT install, and it really is what the firmware executes. It then goes and pulls stage1.5 from the BIOS boot partition. The firmware does not somehow directly execute grub from the BIOS boot partition, it could not do so.

"If I am installing on a BIOS system, how does Anaconda decide whether to write GPT or MBR? Does it vary by Anaconda version? by hardware detected? Can we control the use of GPT through kernel options or kickstart commands? If we don't specify, will we get GPT or not?"

On a BIOS install - note, you will also get a BIOS install if you boot a system with a UEFI firmware in BIOS compatibility mode:

* If the disk is already formatted and you do *not* choose to remove all existing partitions, anaconda will retain the existing format (changing from GPT to MBR or vice versa non-destructively is not reliable and we won't try to do it)

otherwise - if the disk is unformatted, or you choose to entirely wipe it as part of the installation process:

* If the disk is less than 2TB in size, MBR will be used by default
* If the disk is 2TB or larger, GPT will be used by default (you may want to check the *precise* border condition with anaconda team, but it's around 2TB)
* You can pass the parameter 'inst.gpt' to force the use of GPT for disks below 2TB
* There is no parameter to force the use of MBR for larger disks, AFAIK

On a native UEFI install, anaconda will always try to use GPT, and in fact will refuse to install to an MBR disk (even though this is technically allowed in the UEFI spec). You can't do a native UEFI install of Fedora/RHEL 7 to an existing, MBR-formatted disk without reformatting it.

(In reply to Adam Williamson from comment #31)

Thanks Adam, that is very helpful information. It's currently missing from the installer docs as far as I can tell.

The reason why this matters is because, if you are trying to write a kickstart which uses clearpart and custom partitions (no autopart) for an arbitrary system, then you need to include a biosboot partition *if and only if* the system's disk is > 2TB and it has BIOS firmware (or EFI firmware in CSM mode). That's the situation Beaker is currently in, although I don't want to make this sound like a Beaker-specific problem because it's really not.

Also, to be clear, this is only true for RHEL7 (and Fedora), right? As far as I can tell RHEL6 Anaconda doesn't support GPT disks, or boot disks > 2TB, so the whole issue of biosboot partitions is irrelevant on earlier RHELs.

Afraid I don't know about RHEL 6, to be honest I think I've installed it...ever...once. :) I think it does predate the GPT stuff in anaconda, but I'm hardly an authoritative reference for that.

Thanks for the additional info, gents. Since this keeps getting more complicated, we're going to move the whole explanation into 10.11.1. AMD64 and Intel 64 Boot Loader Installation and the bootloader command entry in Kickstart Commands and Options will only link to it.

Now that this is clearly documented (in particular the 2TB cut-off, which was the missing info for me previously) we can try handling this in Beaker, which was the original point of this bug. Cloned as bug 1108393.