Bug 1112439 - [RFE]track x86 boot mode (BIOS or EFI) in Beaker hardware info
Summary: [RFE]track x86 boot mode (BIOS or EFI) in Beaker hardware info
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Beaker
Classification: Retired
Component: inventory
Version: 0.16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
: 1465317 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-24 00:49 UTC by Dan Callaghan
Modified: 2020-11-19 21:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-19 21:47:06 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1162317 0 medium CLOSED [RFE] track system firmware version in inventory 2021-02-22 00:41:40 UTC

Internal Links: 1162317

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. ***


Note You need to log in before you can comment on or make changes to this bug.