Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-54612

Supermicro Redfish quirk does not jive with Baremetal Host BIOS fetching

XMLWordPrintable

    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Description of problem:

          Trying to deploy this SuperMicro system via ACM/BMH, but it immediately nearly immediately goes to 'inspection failed'

      Version-Release number of selected component (if applicable):

          

      How reproducible:

          100%

      Steps to Reproduce:

          1. Attempt to deploy the system
          2. Watch bmh state say "inspection failed"
          3.
          

      Actual results:

          "inspection failed"

      Expected results:

          "provisioning"

      Additional info:

          I talked with Iury Gregory Melo Ferreira on slack about this somewhat. Here's what we found:
      
      -- The metal3-baremetal-operator pod has errors like this:
      {"level":"info","ts":1743707053.88956,"logger":"controllers.HostFirmwareSettings","msg":"start","hostfirmwaresettings":{"name":"cnfdf38.telco5gran.eng.rdu2.redhat.com","namespace":"cnfdf38"}}
      {"level":"info","ts":1743707053.9079528,"logger":"controllers.HostFirmwareSettings","msg":"retrieving firmware settings and saving to resource","hostfirmwaresettings":{"name":"cnfdf38.telco5gran.eng.rdu2.redhat.com","namespace":"cnfdf38"},"node":"ffa70e33-f691-4385-9f72-2a0bc8c1263c"}
      {"level":"info","ts":1743707053.9826992,"logger":"controllers.HostFirmwareSettings","msg":"provisioner returns error","hostfirmwaresettings":{"name":"cnfdf38.telco5gran.eng.rdu2.redhat.com","namespace":"cnfdf38"},"Error":"could not get BIOS settings for node ffa70e33-f691-4385-9f72-2a0bc8c1263c: json: cannot unmarshal number 9223372036854776000 into Go struct field BIOSSetting.bios.upper_bound of type int","RequeueAfter":30}
      
      Diving into the actual redfish, we found that the location of the BiosAttributeRegistry is NOT relative to /redfish/v1 as is normally expected, but relative to the BMC's document root:
      
      $ curl -kse $user:$pw https://10.8.35.71//redfish/v1/Registries/BiosAttributeRegistry
      
      {
        "@odata.type": "#MessageRegistryFile.v1_1_5.MessageRegistryFile",
        "@odata.id": "/redfish/v1/Registries/BiosAttributeRegistry",
        "Id": "BiosAttributeRegistry",
        "Name": "BIOS Attribute Registry File",
        "Description": "BIOS Attribute Registry File locations",
        "Languages": [
          "en"
        ],
        "Registry": "BiosAttributeRegistry.1.0.0",
        "Location": [
          {
            "Language": "en",
            "Uri": "/registries/BiosAttributeRegistry.1.0.0.json"
          }
        ],
        "Oem": {},
        "@odata.etag": "\"cec288cb5df842d60adb3a83fbe5cc97\""
      }
      
      Fetching '/redfish/v1/registries/BiosAttributeRegistry.1.0.0.json' and '/redfish/v1/Registries/BiosAttributeRegistry/registries/BiosAttributeRegistry.1.0.0.json' both fail (404), but fetching 'https://10.8.35.71/registries/BiosAttributeRegistry.1.0.0.json' succeeds

              imelofer Iury Gregory Melo Ferreira
              jramsay1@redhat.com Jim Ramsay
              None
              None
              Jad Haj Yahya Jad Haj Yahya
              None
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: