Hence, the payload of the request must contain the URI of a firmware file that will be fetched from the network location and flashed instantaneously (iLO firmware) or staged and flashed during next reboot (UEFI/Bios firmware).
#Hp ilo 4 firmware bin update#
The SimpleUpdate action is a “pull” update, which means that the Redfish server has to pull the firmware update image from the provided URI. The Redfish implementation of the server used in this article contains only one action: the SimpleUpdate action that can be performed by issuing an HTTP or HTTPS POST request toward the following endpoint: /redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate The Redfish update service provides the list of actions that a Redfish client can perform against a server. OData query, you can retrieve all the details of installed firmware on your server.Ī Python example to retrieve the firmware inventory of a server (using Redfish) can be found in the HPE Python ilorest library on GitHub. The exact endpoint is /redfish/v1/UpdateService/FirmwareUpdate and, with a single ?$expand=. Similar to the SoftwareInventory resource, the FirmwareInventory endpoint contains the collection of all installed firmware in a server.
#Hp ilo 4 firmware bin software#
Details concerning the support of OData queries can be found in the ProtocolFeaturesSupported property of the Redfish Service root endpoint ( /redfish/v1).Ī Python example for fetching the software inventory of a server without hard coding its location can be found in the HPE Python ilorest library on GitHub. The dot (“.”) sign of this OData query indicates that only the current level of the hierarchy has to be expanded, not the lower levels. OData query as shown in the next screenshot (note that this screenshot has been truncated to display only the first item of the collection). To avoid issuing multiple GET requests for retrieving the details of each installed software, you can append the $expand=. Note that the list of running and installed software present in the iLO GUI is not returned by Redfish. The next picture shows the five URIs that correspond to the same HPE software present in the above screenshot. This gives you the collection of URIs pointing to the details of each HPE installed software. To retrieve the above collection using the SoftwareInventory endpoint of the Redfish update service, you have to perform a GET request toward /redfish/v1/UpdateService/SoftwareInventory. You can see three applications ( amsd, ilorest and sut) and two deployed firmware packages ( firmware-iegen10 and firmware-ilo5). The following screenshot shows the list of HPE software displayed by the iLO Graphical User Interface (GUI) of a Linux server.
#Hp ilo 4 firmware bin series#
Refer to Part 2 of this series for more information about the chif driver. Moreover, the HPE Agentless Management Service (AMS) must be present and started in the OS in order to have a communication link with the iLO through the chif driver. Since this list comes from the OS, it is mandatory to have the system booted. This collection contains the items listed in the iLO 5 Graphical User Interface (GUI), which are shown in the screenshot below. Software inventoryįrom the SoftwareInventory endpoint, you can retrieve the collection of HPE software installed in the Operating System (OS).
In this article, I will cover these five endpoints in the following order: SoftwareInventory, FirmwareInventory, Actions, HttpPushUri and finally the Oem.Hpe extension.
Later schemas may have different content. Note that this picture shows the output of a request performed against an iLO 5 (version 2.18) implementing schema version 1.1.1 of the Redfish update service. Located at /redfish/v1/UpdateService, this ServiceRoot resource is populated with five endpoints, which are highlighted in the next screenshot. The Redfish update service contains software and firmware information as well as methods for updating these resources. “Well written” public examples in Python and PowerShell can be found on the Internet. Writing Redfish scripts with hard-coded locations is definitively a bad practice as explained in this article and demonstrated in these Jupyter Notebooks. This third article describes the standard Redfish® update service, including its simple update and Original Equipment Manufacturer (OEM) extension actions, and offers numerous examples and screenshots.įor didactic reasons, cases described in this blog post have been performed with the Postman platform for API development with hard-coded resource locations. In the first two blogs of this three part series regarding HPE firmware updates, I explained the different objects involved in firmware updates and how they are packaged, as well as the interaction between these objects when used in different operating modes.