Oss/Firmware Tools/Admin Guide
Purpose of this document
The purpose of this page is to describe the firmware-tools project from the point of view of a system administrator.
Purpose of Firmware-Tools
The firmware-tools project is an infrastructure umbrella project. The purpose of the project is to facilitate easy BIOS and Firmware updates and to integrate BIOS and Firmware more closely into the native Linux change-management framework, be that RPM/YUM, RPM/APT, DEB/APT, etc. The intention is that vendors distribute packages (DEBs, RPMs, etc) containing their BIOS updates, along with packages containing the tools to install those updates. Then, using repository management software, such as yum or apt, the administrator can easily keep their firmware up-to-date as easily as they can keep the rest of the software on their system up-to-date.
This document will use RPM and YUM for all of its examples. This is what is currently implemented. We have plans to incorporate DEB and other formats with community support.
The firmware-tools software comes packaged (currently) in RPM format, and is installable via the unofficial Dell YUM repository. The main functionality of firmware-tools is exposed via a plugin framework. To fully take advantage of firmware-tools, you will need to install a vendor plugin for your system. The vendor plugin will normally have a package dependency on the firmware-tools infrastructure package, therefore, it is usually only necessary to specify the vendor plugin to install and all of the correct RPMs will be installed.
For example, on Dell systems, the vendor plugin package is called firmware-addon-dell. For specific instructions on installing the firmware-addon-dell RPM from the unofficial Dell yum repository, please see Firmware-tools_announcement#HOW_do_I_get_going
Note for multi-vendor sites: The Dell vendor plugin is designed to be safe to install on any system, even non-Dell systems. It should be possible for any vendor to create a safe plugin to install on any other vendor's systems. This should help multi-vendor sites easily standardize on a set of vendor plugins to install across all systems, easing maintenance.
The purpose of the vendor plugins is to provide enough information to properly bootstrap your system. That is to say, vendor plugins do not provide all of the actual tools to update BIOS, Firmware, or PCI cards on your system, rather, they provide a way to detect if those are needed, and then add them to the bootstrap list, which is discussed in the next section.
Bootstrap is the process where all of the latest BIOS/Firmware update RPMs for your system are installed from the package repository, along with all of the utilities necessary to inventory your system and to apply the updates. Bootstrap works by generating a list of names of everything on the system that might need to be updated. The command to generate this list is
bootstrap_firmware. Here is an (edited) sample:
[root@computer ~]# bootstrap_firmware system_bios(ven_0x1028_dev_0x0152) bmc_firmware(ven_0x1028_dev_0x0152) pci_firmware(ven_0x8086_dev_0x3580_subven_0x1028_subdev_0x0152)/system(ven_0x1028_dev_0x0152) ... pci_firmware(ven_0x8086_dev_0x3580_subven_0x1028_subdev_0x0152) pci_firmware(ven_0x8086_dev_0x3584_subven_0x1028_subdev_0x0152)
There are RPMs in the repository which have "Provide:" tags matching the names generated. If you feed the list generated by bootstrap into your repository tool, it will automatically download the correct RPMS. For example:
[root@meb-laptop ~]# yum install $(bootstrap_firmware)
Or, for RHEL systems, use the
up2date utility. Up2date requires a slightly different format input, so use the
-u switch to
inventory_firmware and the
--solvedeps switch to up2date:
[root@meb-laptop ~]# up2date --solvedeps $(bootstrap_firmware -u)
Once you have the firmware-tools infrastructure and vendor tools installed, you can run the system inventory.
[root@meb-laptop ~]# inventory_firmware system_bios(ven_0x1028_dev_0x0152) = a09
The purpose of the system inventory is informational. It will list each inventoriable component and the existing firmware version.
There are several options for application of updates. The default option is that updates must be manually applied by running the
update_firmware utility. This utility will inventory the system, then scan the repository to see if newer components exist. It will then install the update. To do a test run:
[root@meb-laptop ~]# update_firmware Searching storage directory for available BIOS updates... Checking system_bios(ven_0x1028_dev_0x0152) - a09 Found Update: system_bios(ven_0x1028_dev_0x0152) - a10 Found out of date packages. Please run the program with the '--yes' switch to enable BIOS update. UPDATE NOT COMPLETED!
There is a configuration file, /etc/firmware/firmware.conf, where the repository location is specified. By default, that location is /usr/share/firmware/, and all BIOS/Firmware RPMs store their files here. But, there are other use cases, notably, the case where one might want a central NFS server that contains all updates, where one might want to specify an alternate location. The setting to change is:
update_firmware utility will do a recursive scan of all subdirectories to find applicable updates.
Automatic Firmware Updates
By default, installing a Firmware or BIOS update RPM will call the
update_firmware utility in "RPM Mode". In this mode,
update_firmware will look in the config file, /etc/firmware/firmware.conf to see if it should automatically install the updates at RPM install time, or wait for the administrator to manually run
update_firmware. The setting to change for this is:
[main] # Automatically install BIOS updates when an RPM BIOS Update file is installed # values: 'auto', 'manual' # default: 'manual' rpm_mode=manual