+++ This bug was initially created as a clone of Bug #1032428 +++ Description of problem: I have specified user-defined partitions in job xml <partitions> <partition fs="xfs" name="/mnt/xfstests/mnt1" size="10" type="part"/> <partition fs="xfs" name="/mnt/xfstests/mnt2" size="10" type="part"/> </partitions> If the host has a GPT disk, installation fails with Your BIOS-based system needs a special partition to boot from a GPT disk label. To continue, please create a 1MB 'biosboot' type partition.
The bug this was cloned from has all the gory details, but the short version is that from RHEL7 onwards, if the system has BIOS(-compatible) firmware and the installation disk is >2TB then Anaconda will use a GPT and a 1MB 'biosboot' partition is needed. This requirement is now fully documented in the RHEL7 Anaconda docs. At present Beaker has some logic which attempts to satisfy the system-specific boot requirements when the user requests custom partitioning. This is so that a recipe can be independent of any particular system and still run Now that Beaker tracks disk info, it could check whether the first disk is >2TB. Firmware type can be inferred from the netboot method, currently stored in the NETBOOT_METHOD key-value (it will be pxelinux for BIOS-compatible systems). So in theory Beaker could handle this, at least under most circumstances. If the user passes ondisk= then the installation disk will not necessarily be the first disk though, and there is no way in general for Beaker to map all the possible ondisk parameters to disks recorded in the hardware details. Also, if ondisk= is given in the recipe then it is presumably intended for one system in particular because most parameters for ondisk are system-specific. So it's not really clear what Beaker should do in that case.
(In reply to Dan Callaghan from comment #1) > Firmware type can be inferred from the netboot method, currently > stored in the NETBOOT_METHOD key-value (it will be pxelinux for > BIOS-compatible systems). Correction: pxe (not pxelinux)
One possible workaround for this issue is to exclude x86_64 EFI systems when using custom <partitions/>. To do this you can add the following to <hostRequires/>: <key_value key="NETBOOT_METHOD" op="!=" value="efigrub" />
(In reply to Dan Callaghan from comment #5) > One possible workaround for this issue is to exclude x86_64 EFI systems when > using custom <partitions/>. To do this you can add the following to > <hostRequires/>: > > <key_value key="NETBOOT_METHOD" op="!=" value="efigrub" /> Dan, thank you following this bug! Also thanks for the workaround, but it seems not a good way for our testings, we have hundreds of jobs use custom partitions and there're more and more EFI systems in beaker, the workaround could reduce the suitable system count and increase the tension of jobs. But still it's great to know there's a workaround. Thank you for working on this! Eryu
For the ondisk problem, I think we can say "you're on your own" at that point (and tweak the docs for ondisk accordingly). Otherwise, using NETBOOT_METHOD and the disk info to inject the biosboot partition when not using autopart makes sense to me. We'll still need to mention it in the docs, since if someone tries to fully allocate a 2 TB+ disk, they may end up not having enough space for the implied partition. We'll also need logic to check if there's already an explicit biosboot partition and skip adding it implicitly in that case.
For systems with multiple disks, disk ordering is currently not guaranteed in the metadata, so we would need to start preserving the ordering before we could fix this properly. (Providing the partition when it isn't actually needed will confuse MBR systems) Given the updated documentation, the suggested workaround could be enhanced to *also* allow EFI systems where no individual disk is >= 2 TB.
Hi, what's status of this bug? We're testing RHEL7.1 now and found that this bug is still blocking our tests on UEFI hosts. Most of our x86_64 jobs are aborted and required a rechedule. Proposed as Testblocker, We can use the workaround in comment 5 for now, hope it can be fixed soon, as explained in comment 6. Thanks a lot!
I try to use the workaround " <key_value key="NETBOOT_METHOD" op="!=" value="efigrub" />" to exclude the efi systems, but it seems not work for the job running. I submit 4 jobs, but 3 aborted.Below is the job links: https://beaker.engineering.redhat.com/jobs/802182 https://beaker.engineering.redhat.com/jobs/802181 https://beaker.engineering.redhat.com/jobs/802180
(In reply to XuWang from comment #10) > I try to use the workaround " <key_value key="NETBOOT_METHOD" op="!=" > value="efigrub" />" to exclude the efi systems, but it seems not work for > the job running. Beaker is giving you systems which have a disk >2TB which is why you are hitting this issue. You could try: <key_value key="NETBOOT_METHOD" op="!=" value="efigrub" /> <not><disk><size op=">" value="2097152000000" /></disk></not> as a more complete workaround. This will filter out EFI systems and systems with disks >2TB.
I really wish Anaconda could deal with the hardware-specific partition requirements for us automatically, I should file an RFE for that...
Bug 1164660 is the RFE against RHEL 7 requesting the ability to tell Anaconda to create all required partitions, while still being able to define custom partitions.
Alexander Todorov mentioned that his team unconditionally defines the biosboot partition on RHELs which support it, and that works (even on BIOS systems with disks <2TB). Need to investigate further. Is Anaconda ignoring the defined biosboot partition when it's not applicable (MBR)? If so can Beaker also just unconditionally define it on distros that support it?
(In reply to Dan Callaghan from comment #14) Or another possibility... the presence of the biosboot partition triggers Anaconda to use GPT where it would otherwise have used MBR (in which case, adding it unconditionally would be bad, since it has an unintended influence on the test scenario)...
(In reply to Dan Callaghan from comment #14) > Alexander Todorov mentioned that his team unconditionally defines the > biosboot partition on RHELs which support it, and that works (even on BIOS > systems with disks <2TB). Need to investigate further. Is Anaconda ignoring > the defined biosboot partition when it's not applicable (MBR)? If so can > Beaker also just unconditionally define it on distros that support it? Hi Dan, I'm not sure if anaconda ignores it or forces the use of GPT. I think the later. At the moment QE has 22 custom partitioning test cases where we've defined the biosboot partition based only on OS Major number and they seemed to have worked. Let me bring up this question on anaconda devel list and see what the answer is.
(In reply to Dan Callaghan from comment #15) > (In reply to Dan Callaghan from comment #14) > > Or another possibility... the presence of the biosboot partition triggers > Anaconda to use GPT where it would otherwise have used MBR (in which case, > adding it unconditionally would be bad, since it has an unintended influence > on the test scenario)... No. GPT is used if the disk is > 2TiB, if it is a UEFI system, or if inst.gpt is passed on the cmdline. A biosboot partition on a UEFI installation is not used for anything and since it only needs to be 1M it doesn't even waste a significant amount of space.
(In reply to Dan Callaghan from comment #12) > I really wish Anaconda could deal with the hardware-specific partition > requirements for us automatically, I should file an RFE for that... Looks like bug 1022316.
Hi Dan, what's the status here? Can we create a distro feature variable in Beaker (e.g. uses_biosboot_partition) which vaguely indicates that such partitions may be in use for the particular distro or should QE just go ahead and put that logic inside our templates ? We've had these partitions unconditionally defined and that's worked well so far. At present the templates are in a limbo state and I want to resolve this either way.
(In reply to bcl from comment #17) > A biosboot partition on a UEFI installation is not used for anything and > since it only needs to be 1M it doesn't even waste a significant amount of > space. Right, that's fine. The case I was worried about here is if we define a biosboot partition but Anaconda is actually using MBR. In that case it looks like the biosboot partition is indeed created with size 1MB and partition type 0x83 but Anaconda just leaves it empty and everything ignores it. So it looks like we can just unconditionally define the biosboot partition for x86 RHEL7/Fedora, as the solution to this bug, and it shouldn't have any adverse affects aside from adding one more partition to everyone's partition tables (when using custom partitioning).
http://gerrit.beaker-project.org/3997
Beaker 20.0 has been released.