Fujitsu PRIMERGY: iRMC Redfish sample Python scripts

In the following Blog post, I showed some Redfish examples using the curl command.

Fujitsu iRMC Redfish Examples

I created some sample Python scripts for iRMC Redfish that perform the following operations:

  • Power on/off/reset
  • Reset iRMC
  • Check the current firmware versions
  • Backup BIOS/iRMC configuration
  • Change boot device
  • Get/Clear SEL/iEL
  • Get/Set iRMC time configuration
  • Get/Set System ID LED status
  • iRMC Auto Discovery

The scripts are available on GitHub.

Fujitsu iRMC Redfish samples scripts

I will add more samples later.

Fujitsu PRIMERGY: Configuring the initial iRMC network using iRMC auto discovery and Redfish

As you probably know, iRMC S5 supports auto discovery. Fujitsu has management software like Infrastructure Manager (ISM) that supports iRMC auto discovery, so when a new iRMC S5 based system like PRIMERGY M4 or M5 is installed in a rack, and power and network cables are attached to the server, management software automatically sees the new server on the network, and you can configure the iRMC network without bringing up BIOS Setup to set the management IP address to iRMC on a crash cart or a KVM.

iRMC S5 auto discovery feature is based on SSDP (Simple Service Discovery Protocol). It's a standard protocol, so you don't have to use proprietary software to use the auto discovery feature in fact.

To show how to use auto discovery feature, I created a sample small script in Python that lists discovered systems on the network using SSDP, and configure iRMC network for a new system. You can get the script on GitHub.

In the 'show' mode, it lists all 'auto discovered' systems on the network. If the address shows '0.0.0.0', it does not have an address yet. It's like the initial state just after it's racked and cabled. In the following example, two RX2540 M5 servers are newly installed in a rack, and both don't have iRMC addresses configured. Others already have iRMC configured, so the IP addresses are shown.

$ python irmc-auto-discovery.py show
Model: PRIMERGY CX2560 M5, S/N: MAAG001111, IPv4: 192.168.71.59
Model: PRIMERGY CX2550 M5, S/N: MAAF002222, IPv4: 192.168.71.63
Model: PRIMERGY RX2540 M5, S/N: MASQ001234, IPv4: 0.0.0.0
Model: PRIMERGY RX2540 M5, S/N: MASQ002345, IPv4: 0.0.0.0
Model: PRIMERGY RX2530 M5, S/N: MALU005432, IPv4: 192.168.71.27
Model: PRIMERGY RX4770 M5, S/N: MATJ006543, IPv4: 192.168.71.37

In the 'configure' mode with the network information specified, the script assigns the supplied address to iRMC. In the example, it assigns 192.168.71.29/24 and gateway 192.168.71.1 to the RX2540 M5 S/N: MASQ001234. After the script completes the configuration, it will take a few minutes for iRMC to update the network settings. Once iRMC completes the update, you can access the iRMC with the IP address you set.

$ python irmc-auto-discovery.py configure -s MASQ001234 -a 192.168.71.29 -m 255.255.255.0 -g 192.168.71.1 
The iRMC network has been configured successfully. Please wait for a few minutes for iRMC to activate the new configuration.

Fujitsu PRIMERGY: Change the boot device via Redfish

This post will explain how to change the boot device with the next boot only option enabled through iRMC Redfish interface. This is equivalent to the IPMI command like "ipmitool chassis bootdev <bootdevice>".
For example, if you want to do a PXE boot to perform an OS installation, you probably execute "ipmitool -H <iRMC address> -U <iRMC username> -P <iRMC password> chassis bootdev pxe". You can request the same to iRMC via Redfish in case you can't use IPMI like for security reasons.

To do this, first you need to check the current settings and the etag information, and then send a request in JSON to iRMC. See below for the steps.

  1. Send a GET request to the "Systems/0/Oem/ts_fujitsu/BootConfig" endpoint to see the current options and the Etag information.
  2. $ curl -s -k -u admin:admin -H"Content-Type: application/json" https://irmc address/redfish/v1/Systems/0/Oem/ts_fujitsu/BootConfig |jq '{BootDevice, BootType, NextBootOnlyEnabled, "@odata.etag"}'
    {
      "BootDevice": "None",
      "BootType": "UEFI",
      "NextBootOnlyEnabled": false,
      "@odata.etag": "1595025885"
    }
    
    As you can see, the BootDevice option shows None, so the system is currently booting from the device that is in the top of the boot device list like a local drive.
    The reason why I displayed the @odata.etag option is that changing the boot device is a PATCH request, so the Etag information needs to be included in the request header. See the next step for details.

  3. Send a PATCH request to the same endpoint. In this example, I use "PXE" as the boot device for the next boot.
    $ curl -s -k -u admin:admin -H"Content-Type: application/json" -H"If-Match: 1595025885" -X PATCH https://irmc address/redfish/v1/Systems/0/Oem/ts_fujitsu/BootConfig -d '{"BootDevice": "Pxe", "BootType": "UEFI", "NextBootOnlyEnabled": true}' |jq .
    {
      "@odata.context": "/redfish/v1/$metadata#Systems/Members/0/Oem/ts_fujitsu/BootConfig(Name,BootDevice,BootType,NextBootOnlyEnabled)",
      "@odata.id": "/redfish/v1/Systems/0/Oem/ts_fujitsu/BootConfig",
      "@odata.type": "http://ts.fujitsu.com/redfish-schemas/v1/FTSSchema.v1_0_0#FTSBootConfig.v1_0_0.FTSBootConfig",
      "Name": "Boot Configuration",
      "BootDevice": "Pxe",
      "BootType": "UEFI",
      "NextBootOnlyEnabled": true,
      "@Redfish.Copyright": "Copyright 2017-2018 FUJITSU LIMITED",
      "@odata.etag": "1595025925"
    }
    
  4. Note that I included the "If-Match: <etag data>" option in the request. iRMC will change the boot device if the etag information in the request matches the current value.
    If you want to change the boot device to CDROM or bring up BIOS Setup during the next boot, you can just use "Cd" or "BiosSetup" respectively for the BootDevice option.

If you would like to use "BootSourceOverrideTarget" in the Systems/0 endpoint instead of "Systems/0/Oem/ts_fujitsu/BootConfig", send a PATCH request with the data like this to Systems/0.

$ curl -s -k -u admin:admin -H"Content-Type: application/json" -H"If-Match: <etag data>" -X PATCH https://irmc address/redfish/v1/Systems/0 -d '{ "Boot": {"BootSourceOverrideTarget": "Pxe",  "BootSourceOverrideEnabled":"Once"}}' |jq '{Boot}'
{
  "Boot": {
    "BootSourceOverrideTarget": "Pxe",
    "BootSourceOverrideTarget@Redfish.AllowableValues": [
      "None",
      "Pxe",
      "Floppy",
      "Cd",
      "Hdd",
      "BiosSetup"
    ],
    "BootSourceOverrideEnabled": "Once",
    "BootSourceOverrideEnabled@Redfish.AllowableValues": [
      "Once",
      "Continuous"
    ],
    "BootSourceOverrideMode": "UEFI"
  }
}

Fujitsu PRIMERGY RX2530 M4 BIOS ASP for Ubuntu (BIOS R1.43.0)

This is related to the iRMC ASP for Ubuntu blog post. I've created RX2530 M4 BIOS R1.43.0 ASP for Ubuntu just to show that it's technically possible to create a BIOS ASP package for Ubuntu if in-band update is required/preferred.

The default package does not support Ubuntu, so you need to run the ASP with the "-nos" option to bypass the OS check.

$ sudo ./RX2530M4_D3383_A1_BiosV50012_R1430.scexe -e -nos

***************** PRIMERGY Autonomous Support Package ***************

Description: Flash BIOS RX2530 M4
VersionMajor: V5.0.0.12
VersionMinor: R1.43.0
VersionBuild: 1.0.0
Software Class - Category: Flash - BIOS
Software Class - Name: (SV) Flash Bios
Vendor: Fujitsu

*********************************************************************

Continue processing this ASP?
Please answer: yes/y or no/n
y
Extracting data into /tmp/sctmpdir6541 ...
done

Like I did for the iRMC ASP, change the shell in the scripts in the package (do_deskflash.sh and do_SelectTool.sh) from sh to bash. For the do_deskflash.sh, some changes are required as this is for RPM-based distributions, so you need to change rpm commands to dpkg, and adjust RPM package names to DEB package names.

You will also need to add Ubuntu statement in the DF_Packages.txt file like this:

$  diff -Nau work_bios_r1.43.0.orig/DF_Packages.txt work_bios_r1.43.0/DF_Packages.txt
--- work_bios_r1.43.0.orig/DF_Packages.txt      2020-05-28 04:22:41.882733700 -0700
+++ work_bios_r1.43.0/DF_Packages.txt   2020-07-06 18:00:37.689422065 -0700
@@ -8,3 +8,4 @@
 RHEL6.10            DeskFlash_Linux_01.75-0064_old.zip
 RHEL7.5%RHEL7.7     DeskFlash_Linux_01.80-0083.zip
 RHEL8.0%RHEL8.1     DeskFlash_Linux_01.80-0083.zip
+UBUN16.04%UBUN20.04 DeskFlash_Linux_01.80-0083.zip

DeskFlash_Linux_01.80-0083.zip is in the DeskFlash_Linux.zip archive. In DeskFlash_Linux_01.80-0083.zip, the deskflash RPM is included, so this needs to be changed to a DEB file (I created deskflash_1.80-0083_amd64.deb), and zip up all files to DeskFlash_Linux.zip.

The startup script does not support Ubuntu, so you need to add Ubuntu to the OS list so that you don't need to run the ASP with the "-nos" option.

diff -Nau RX2530M4_D3383_A1_BiosV50012_R1430.sh.orig RX2530M4_D3383_A1_BiosV50012_R1430.sh
--- RX2530M4_D3383_A1_BiosV50012_R1430.sh.orig  2020-07-10 17:41:00.597159834 -0700
+++ RX2530M4_D3383_A1_BiosV50012_R1430.sh       2020-07-02 12:36:03.151041117 -0700
@@ -152,6 +152,7 @@
 OS_CHECKLIST[4]="RHEL6.10"
 OS_CHECKLIST[5]="RHEL7.5%RHEL7.7"
 OS_CHECKLIST[6]="RHEL8.0%RHEL8.1"
+OS_CHECKLIST[7]="UBUN16.04%UBUN20.04"
 OS_CHECKLIST_END=""

 _EXCLUDE_32BIT_OS=false;

Once all the changes are made, you can package everything up to the SCEXE file, and run it.

Here are the screenshots when I run the modified/hacked BIOS R1.43.0 ASP for RX2530 M4 on Ubuntu.

Once it is run successfully, you need to reboot the server to enable the new BIOS.

Fujitsu PRIMERGY: How to check BIOS Version through IPMI

This is related to the previous post (How to check iRMC Firmware Version through IPMI). In this post, I explain how to check the BIOS version via IPMI.

If you are in the OS, you can easily get the BIOS version information by a command like dmidecode.

$ dmidecode -t0 |grep Version
        Version: V5.0.0.12 R1.42.0 for D3384-A1x
Remotely, you can use SSH or PowerShell to get the BIOS version, but this requires a running OS on the remote machine, so using iRMC to get the BIOS version is good when an OS is not running or an OS is not yet installed.

To retrieve the BIOS version via IPMI, you can use the "0x2e 0xe0 0x80 0x28 0x00 0x01 0x00 0x02 0x02" command. Below is an example from RX2540 M4.

$ ipmitool -I lanplus -H 192.168.10.10 -U admin -P admin raw 0x2e 0xe0 0x80 0x28 0x00 0x01 0x00 0x02 0x02 |tr '\n' ' '
 80 28 00 1f 56 35 2e 30 2e 30 2e 31 32 20 52 31
 2e 34 32 2e 30 20 66 6f 72 20 44 33 33 38 34 2d
 41 31 78
The BIOS version string can be decoded from the 5th byte. In the above case, it's "56 35 2e 30 2e 30 2e 31 32 20 52 31 2e 34 32 2e 30 20 66 6f 72 20 44 33 33 38 34 2d 41 31 78". You just need to convert the hex values to ascii characters to see the actual string.

Here is an example.

$ for c in $(ipmitool -I lanplus -H 192.168.10.10 -U admin -P admin raw 0x2e 0xe0 0x80 0x28 0x00 0x01 0x00 0x02 0x02 |tr '\n' ' ' | cut -d' ' -f6-); do echo -n $c |xxd -r -p; done; echo ""
V5.0.0.12 R1.42.0 for D3383-A1x
In the above example, as you can see, the response shows the BIOS version is "V5.0.0.12 R1.42.0 for D3383-A1x".

Fujitsu PRIMERGY: How to check iRMC Firmware Version through IPMI

You can check what iRMC firmware version is used via standard IPMI commands like "ipmitool mc info".

$ ipmitool mc info
Device ID                 : 5
Device Revision           : 2
Firmware Revision         : 1.00
IPMI Version              : 2.0
Manufacturer ID           : 10368
Manufacturer Name         : Fujitsu Technology Solutions GmbH (formerly 'Fujitsu Siemens Computers')
Product ID                : 1300 (0x0514)
Product Name              : Unknown (0x514)
Device Available          : yes
Provides Device SDRs      : no
Additional Device Support :
    Sensor Device
    SDR Repository Device
    SEL Device
    FRU Inventory Device
    IPMB Event Receiver
    IPMB Event Generator
    Chassis Device
Aux Firmware Rev Info     :
    0x02
    0x31
    0x00
    0x50

To get the information remotely, add "-H <irmc address>", "-U <irmc user>", and "-P <irmc password>" options.

$ ipmitool -H <irmc address> -U <irmc user> -P <irmc password> mc info

You can see 0x02 0x31 0x00 0x50 under "Aux Firmware Rev Info", and you can convert 0x02 0x31 to decimal and you get 2.49. 0x50 is the suffix character, and can be converted to 'P'. Therefore 0x02 0x31 0x00 0x50 means 2.49P.
You can also get the same by sending "0x06 0x01" to iRMC like this:

$ ipmitool -I lanplus -H 192.168.10.10 -U admin -P admin raw 0x06 0x01
 05 02 01 00 02 bf 80 28 00 14 05 02 31 00 50
The last four fields "02 31 00 50" are the firmware version. You can format the response so that you can easily see the version like this.
$ ipmitool -I lanplus -H 192.168.10.10 -U admin -P admin raw 0x06 0x01 |while read line; do printf "%d.%d\x${line[0]:42:2}\n" ${line[0]:33:2} "0x${line[0]:36:2}"; done
2.49P

As you probably know, iRMC has two images, one active and one backup, or high firmware and low firmware, or EEPROM1 and EEPROM2. You can get the firmware version for each image via IPMI.
To get the high firmware image version or the EEPROM1 version, use "0x2e 0xf5 0x80 0x28 0x00 0x12 00". To get the low firmware image or EEPROM2 version, use "0x2e 0xf5 0x80 0x28 0x00 0x12 01".

Here is an example from RX2540 M4.

EEPROM1
$ ipmitool -I lanplus -H 192.168.182.97 -U admin -P admin raw 0x2e 0xf5 0x80 0x28 0x00 0x12 00 |while read line; do printf "%d.%d\x${line[0]:27:2} SDR %d.%d\n" ${line[0]:18:2} "0x${line[0]:21:2}" ${line[0]:30:2} ${line[0]:33:2}; break; done
2.42P SDR 3.80
EEPROM2
$ ipmitool -I lanplus -H 192.168.182.97 -U admin -P admin raw 0x2e 0xf5 0x80 0x28 0x00 0x12 01 |while read line; do printf "%d.%d\x${line[0]:27:2} SDR %d.%d\n" ${line[0]:18:2} "0x${line[0]:21:2}" ${line[0]:30:2} ${line[0]:33:2}; break; done
2.46P SDR 3.82

You can also check which image (high or low, or EEPROM1 or EEPROM2) is active via IPMI. For iRMC S4/S5 (PRIMERGY S8 or later), use "0x2e 0xf5 0x80 0x28 0x00 0x07 0x07". For iRMC S2/S3 (PRIMERGY S7 or earlier), use "0x08 0x05".

Here are examples.

iRMC S4/S5
$  ipmitool -I lanplus -H 192.168.182.97 -U admin -P admin raw 0x2e 0xf5 0x80 0x28 0x00 0x07 0x07
 80 28 00 02
The last field (in the above example, it's "02") indicates high or low (or EEPROM1 or EEPROM2). If it's "01", it's high (EEPROM1), and if it's "02", it's low (EEPROM2). iRMC S2/S3
$  ipmitool -I lanplus -H 192.168.182.175 -U admin -P admin raw 0x08 0x05
 00 01
Same as iRMC S4/S5. The last field (in the above example, it's "01") indicates high or low (or EEPROM1 or EEPROM2). If it's "01", it's high (EEPROM1), and if it's "02", it's low (EEPROM2).

Fujitsu PRIMERGY RX2530 M4 iRMC ASP for Ubuntu

Although Fujitsu does not officially support iRMC Firmware Update ASP for Linux on Ubuntu, you can use ASP to update iRMC firmware. I know some customers prefer using in-band firmware update method over using iRMC (or out-of-band), so having an ASP to update iRMC on Ubuntu would be helpful for those customers.

By default, do_SelectTool.sh in the ASP is using /bin/sh. On Ubuntu, /bin/sh is dash by default, so the script will fail. To avoid this, you just need to change the script shell from /bin/sh to /bin/bash. Then repackage it to scexe.

To extract the contents from an ASP file, use the '-e' option

$ ./RX2530M4_MangtCtr_FW0263P_SDR352.scexe -e

Then modify do_SelectTool.sh, and package it again to scexe. The only difference between the original and the modified is as follows:

$ diff -Naur work_irmc_2.63p_asp.orig/ work_irmc_2.63p_asp/
diff -Naur work_irmc_2.63p_asp.orig/do_SelectTool.sh work_irmc_2.63p_asp/do_SelectTool.sh
--- work_irmc_2.63p_asp.orig/do_SelectTool.sh   2020-07-08 16:33:06.731898828 -0700
+++ work_irmc_2.63p_asp/do_SelectTool.sh        2020-07-08 16:34:18.320056431 -0700
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash

 # ==============================================================================
 # Copyright 2017 FUJITSU LIMITED

I tested iRMC ASP for Linux 2.49P and 2.63P for RX2530 M4 running Ubuntu. Below is an example for RX2530 M4 iRMC ASP 2.63P for Linux on Ubuntu 16.04. The scexe file is a modified version of RX2530M4_MangtCtr_FW0263P_SDR352.scexe.

Good Bye, Folks!

As you may have heard, Fujitsu has completely discontinued Data Center Products and Solutions business in North America on April 1st, 2021. ...