Bug 1112439

Summary: [RFE]track x86 boot mode (BIOS or EFI) in Beaker hardware info
Product: [Retired] Beaker Reporter: Dan Callaghan <dcallagh>
Component: inventoryAssignee: beaker-dev-list
Status: CLOSED WONTFIX QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 0.16CC: atodorov, cbouchar, vedran, xiawu
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-19 21:47:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Callaghan 2014-06-24 00:49:25 UTC
Beaker needs to distinguish between x86 EFI systems and BIOS-based systems (or EFI systems booting in BIOS-compatible mode). This is needed for Anaconda partitioning (bug 1108393, bug 1088761) and will probably be needed for more stuff in future as x86 EFI systems become more common.

Currently we can distinguish them by examining the NETBOOT_METHOD key, which is set based on which network boot loader ran the installer ("pxelinux" or "efigrub"). This works, but ideally we should be storing this in a real database field instead of a key-value, and it should be read by beaker-system-scan so that we don't depend on netbooting a Beaker installation to get the right value (for example running beaker-system-scan on a manually provisioned machine).

Some ideas:

A "boot mode" or "firmware type" field. The distinction is only important for x86 so it could even be called "x86 boot mode".

There are also other firmware details which would be useful to collect, in particular the version/revision which is useful for finding systems which need their firmware flashed. Other possibilities include vendor, release date, ROM/flash size, and features supported/enabled (for example, virt extensions: bug 738881).

Hopefully we can collect the necessary info from lshw. If not, dmidecode is another possibility (in that case ideally we would patch lshw to collect the same info that dmidecode collects).

Comment 2 Dan Callaghan 2017-08-15 07:25:51 UTC
*** Bug 1465317 has been marked as a duplicate of this bug. ***