Description of problem: Many times when problems are reported to partners, systems will require bios updates to fix known problems. It would be helpful in providing partners with the current version of bios on a system if it were shown on the front page. This information can easly be accessed from the dmesg log during an inventory. Example: DMI: Hewlett-Packard HP Z400 Workstation/0B4Ch, BIOS 786G3 v03.54 11/02/2011 Version-Release number of selected component (if applicable): 18.4 How reproducible: N/A Steps to Reproduce: during inventory grab DMI: entry from dmesg file if avalable. If DMI: entry exists move it to "Previous BIOS release" and update the biso release. Actual results: None Expected results: Beaker should be able to provide both the current and previous BIOS release on the main page. Additional info: None
Jeff, I'm trying to simplify bios update version tracking. If beaker could track bios updates I think it would be very helpful to users. Currently we log bios updates in RT requests that are closed. When tickets have 35 systems that need to be updated, adding the system specific information becomes chaotic and makes finding information very hard. If the versioning information is kept in beaker it's per system, which makes it easier to find. Very often we get vendor upgrade CD's or bundles that don't show us the new or old bios versions while doing the updates. The installer is required to go into bios (before and after upgrades) and transcribe the versions from the bios setup window into our RT tickets. This increases the chance of mistakes while recording the versions. My request was for a way to allow for more consistent tracking of BIOS versions using a beaker history. I'm open to any ideas. Thanks, Arthur
Arthur, I think it is great that you are trying to simplify the process. I was only pointing out that your request of having Beaker do it, doesn't solve the problem. It just moves it from a RT/bookeeping issue to a Beaker/bookeeping issue. Since in your request the information is collected only when you run a inventory job in Beaker. My examples in Comment #1 was only to show you that we do already collect the data in Beaker, but it is only collected by 'kernelinstall' task. So another task would have to be added or you could modify the /distribution/install Sysinfo task to collect the same data that kernelinstall Sysinfo collects. However it is not displayed on the System page. Regards, Jeff
The "force" option on hostRequires makes it possible to inventory Manual and Broken systems now, so it's much simpler to keep these kinds of inventory task based records up to date than it used to be. Bug 1121462 (adding a "bkr update-inventory" CLI command) and bug 846185 (providing a "1 click" mechanism to run inventory jobs through the web UI) are designed to make it even easier to run inventory jobs on a system.
Yes and we could even take it to further extremes -- almost all of beaker-system-scan is quite fast and non-destructive (the multipath stuff is the only exception) so we could consider running it in *every* recipe in /distribution/install. At least in future when it is lshw-based and we can easily support all platforms+arches. The problem of stale inventory data is not really specific to this request (firmware versions) either, it applies to all the inventory info in Beaker. So I don't think we should let that stop us from recording as much useful info as we can. As far as collecting firmware versions... We have another open RFE, bug 1112439, for collecting firmware type on x86 (EFI vs. BIOS-compatible) and in that I also mentioned the possibility of collection more details like firmware versions. So this RFE is really the successor to that one.
*** Bug 1195344 has been marked as a duplicate of this bug. ***
Paul gave some good hints about how to capture the version info using dmidecode: https://bugzilla.redhat.com/show_bug.cgi?id=1195344#c0
Dan, Is this still on the radar? Best, -pbunyan
We haven't made any progress on this yet. We are still working towards switching beaker-system-scan to using lshw, once that is done we can start looking at what new data we can collect. Lshw already reports some info about firmware version from DMI (and device tree on ppc).
*** Bug 1331385 has been marked as a duplicate of this bug. ***
*** Bug 1509794 has been marked as a duplicate of this bug. ***
Shawn Doherty and Jonathan Toppins have contributed patches to have Beaker track the firmware version (of both the system firmware itself, as well the firmware of any other devices that can report their version like NICs): https://gerrit.beaker-project.org/c/5808/ https://gerrit.beaker-project.org/c/5807/ The original request in this bz also mentions tracking the *previous* firmware version, but I would like to tackle that separately because it's (surprisingly) a fair bit harder.
I forgot that this also needs a testing build of beaker-system-scan...
The patched build is beaker-system-scan-2.2-1.git.3.eb30042 and it is now available here: https://beaker-project.org/yum/harness-testing/ and I've synced it down to beaker-devel as well.
Verified that after running a hardware scan on hp-dl160gen9-04.rhts.eng.bos.redhat.com the firmware version for its BIOS is updated
Beaker 25.0 has been released. Release notes are available upstream: https://beaker-project.org/docs/whats-new/release-25.html