openbmc / phosphor-bmc-code-mgmt

Manage the BMC's code versions.

phosphor-bmc-code-mgmt

Phosphor BMC Code Management provides a set of system software management applications. More information can be found at Software Architecture

To Build

To build this package, do the following steps:

1. meson build
2. ninja -C build

To clean the repository run rm -r build.

phosphor-bmc-code-mgmt's Issues

How to upgrade alt-bios via redfish?

The question as stated in the title. Does anyone know?

Need a better way to enforce sequence of code update steps

Some code update functions use systemd service files to execute scripts and perform Delete and Write operations. But these systemd service files aren't been monitored for completion so race conditions can occur. As a workaround, sleep() have been added to some of the functions.

Opening this issue to explore better options than arbitrary sleep calls, since they still not guaranteed that the service has finished, it's just a value based on observation.

Some ideas in no particular order:

• Use targets that contain all needed services and monitor the single target status.
• Codify the script logic in c++.
• Have a function that monitors systemd service files (reference an earlier attempt with openbmc/openbmc#2857)

VersionAlreadyExists error and throw back to client

Can we create a VersionAlreadyExists error?

And throw that back in bmcweb

Would add to file:

phosphor-bmc-code-mgmt/xyz/openbmc_project/Software/Image.errors.yaml

Line 11 in ebcc194

phosphor-bmc-code-mgmt/image_manager.cpp

Line 212 in d148b4f

log<level::INFO>("Software Object with the same version already exists",

https://github.com/openbmc/bmcweb/blob/3a17e02873fdf53898a2cfce894dcb36223d76d4/redfish-core/lib/update_service.hpp#L352

@anoo1 FYI

Broken firmware image is not verified before upgrading

Issue:
Partially downloaded BMC image through TFTP is not verified before applying it on next reset.

Steps:
1.Check "ApplyTime" is "OnReset":
HTTP Get from https://<bmc_ip>/redfish/v1/UpdateService

Response:

"FirmwareInventory": {
    "@odata.id": "/redfish/v1/UpdateService/FirmwareInventory"
},
"HttpPushUri": "/redfish/v1/UpdateService",
"HttpPushUriOptions": {
    "HttpPushUriApplyTime": {
        "ApplyTime": "OnReset"
    }
},

2. Download Image
   curl -k -H "X-Auth-Token: $token" -X POST https://${bmc}/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate -d '{"ImageURI":"tftp://<tftp_ip>/obmc-phosphor-image-transformers-20210330173445.static.mtd.all.tar"}'

3. When first time download tar image from tftp server completes around 85%, then submit Redfish POST command to download same image again. Redfish POST shows "Base.1.8.1.ServiceTemporarilyUnavailable" error but it still downloads after this error message show up.
   I used windows tftp server, so I can check download progress bar on window; There are "2" download progress bars popping up.

4. Do "ipmitool mc reset cold" when the second time download progress gets to 25% to 35%.

5. The bmc reboot (mc reset cold) crashes.

Please see the video for steps followed :
https://www.youtube.com/watch?v=0UfPNmw0X70&list=PLjZxgm7U9UoxGIMPnH_-FOHxDjtWDTyzM&index=9

Test case SignatureTest.TestSignatureVerify() fails when `verify-full-signature` is enabled

The unit test case SignatureTest.TestSignatureVerify() passes with default config.
But when verify-full-signature is enabled, the test case fails.

It looks like the test case needs to be updated to support both cases.

Redfish Property BMC version populated incorrectly : "Version": "VERSION_ID=2.8.0-dev-1777-g4b740dc9f"

$ redfishtool -r xx.xx.xx.xx -u root -p 0penBmc -S Always raw GET /redfish/v1/UpdateService/FirmwareInventory/4261ebb7
{
    "@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/4261ebb7",
    "@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
    "Description": "BMC image",
    "Id": "4261ebb7",
    "[email protected]": 1,
    "Name": "Software Inventory",
    "RelatedItem": [
        {
            "@odata.id": "/redfish/v1/Managers/bmc"
        }
    ],
    "Status": {
        "Health": "OK",
        "HealthRollup": "OK",
        "State": "Enabled"
    },
    "Updateable": true,
    "Version": "VERSION_ID=2.8.0-dev-1777-g4b740dc9f"
}

 "Version": "VERSION_ID=2.8.0-dev-1777-g4b740dc9f"

/xyz/openbmc_project/software/4261ebb7/attr/Version
{
    "data": "VERSION_ID=2.8.0-dev-1777-g4b740dc9f",
    "message": "200 OK",
    "status": "ok"
}

p10bmc: phosphor-image-updater: terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'

In the rainier machine, after the BMC is booted frequently, the phosphor-image-updater process fails to start due to the following reasons:

p10bmc phosphor-image-updater[571]: terminate called after throwing an instance of `std::filesystem::__cxx11::filesystem_error`
p10bmc phosphor-image-updater[571]: what(): filesystem error: status: Bad message [/media/rofs-a/etc/os-release]

Refactor reboot guard services

Reference: https://gerrit.openbmc.org/c/openbmc/phosphor-bmc-code-mgmt/+/56998

Can the reboot guard services be refactored into one?

Also need to address the scenario where the updater app crashes and the reboot guard is left enabled. Could the reboot guard be disabled automatically if the updater service restarts via systemd dependencies?

Incorrect/Spurious BMC firmware functional state

$ redfishtool -r xx.xx.xx.xx -u root -p 0penBmc -S Always raw GET  /xyz/openbmc_project/software/
{
    "data": [
        "/xyz/openbmc_project/software/224cd310",
        "/xyz/openbmc_project/software/active",
        "/xyz/openbmc_project/software/apply_time",
        "/xyz/openbmc_project/software/c99256c0",
        "/xyz/openbmc_project/software/f7510fc8",
        "/xyz/openbmc_project/software/functional",
        "/xyz/openbmc_project/software/updateable"
    ],
    "message": "200 OK",
    "status": "ok"
}

$ redfishtool -r xx.xx.xx.xx -u root -p 0penBmc -S Always raw GET  /xyz/openbmc_project/software/f7510fc8
{
    "data": {
        "Activation": "xyz.openbmc_project.Software.Activation.Activations.Active",
        "Associations": [
            [
                "inventory",
                "activation",
                "/xyz/openbmc_project/inventory/system/chassis/motherboard/boxelder/bmc"
            ]
        ],
        "Path": "",
        "Priority": 0,
        "Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.BMC",
        "RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
        "Version": "2.9.0-dev-181-g2ef09ea51"
    },
    "message": "200 OK",
    "status": "ok"
}

$ redfishtool -r xx.xx.xx.xx -u root -p 0penBmc -S Always raw GET  /xyz/openbmc_project/software/c99256c0
{
    "data": {
        "Activation": "xyz.openbmc_project.Software.Activation.Activations.Active",
        "Associations": [
            [
                "inventory",
                "activation",
                "/xyz/openbmc_project/inventory/system/chassis/motherboard/boxelder/bmc"
            ]
        ],
        "Path": "",
        "Priority": 1,
        "Purpose": "xyz.openbmc_project.Software.Version.VersionPurpose.BMC",
        "RequestedActivation": "xyz.openbmc_project.Software.Activation.RequestedActivations.None",
        "Version": "2.9.0-dev-181-g2ef09ea51"
    },
    "message": "200 OK",
    "status": "ok"

static flash layout: version id not updated after code update

The version id is generated by BMC's version sha512sum | cut -b 1-8.

However, on static flash layout systems, the version id is not updated after code update.
Steps to reproduce:

1. Do factory reset to ensure the environment is clean;
2. Check the current BMC version id, e.g. 26ec4dcd;
3. Do a code update with new BMC version id, e.g. 0e7213e4;
4. After update and BMC reboot, check the BMC version id, it's still 26ec4dcd.

static flash layout: Old priority is not removed during code update

@mine260309 commented on Mon Aug 20 2018

phosphor-software-manager now supports flashing tarball of static flash layout build, and it saves the priority file in persistent storage (e.g. /var/lib/obmc/phosphor-bmc-code-mgmt).
When doing code update, the old priority file is expected to be removed.
However, due to the current code logic (ItemUpdater::freeSpace())only applying to the case that the BMC has two flash chips, it does not have a chance to remove the old priority file.

So eventually the old priority files are left on persistent storage and never get removed, e.g. on a Romulus machine:

# ls -l /var/lib/obmc/phosphor-bmc-code-mgmt
-rw-r--r--    1 root     root            21 Aug 20 07:21 0e7213e4
-rw-r--r--    1 root     root            21 Aug 16 05:40 37e01d35
-rw-r--r--    1 root     root            21 Aug  8 08:42 4565fb1e
-rw-r--r--    1 root     root            21 Aug 20 07:32 542bff4e
-rw-r--r--    1 root     root            21 Aug 20 07:35 693a4383
-rw-r--r--    1 root     root            21 Aug  8 08:18 cfeb6eb8
-rw-r--r--    1 root     root            21 Aug  8 08:51 f0f5f56c

---

@mine260309 commented on Mon Aug 20 2018

The existing code in ItemUpdater::freeSpace() makes sure:

1. It does not remove the BMC version which is functional;
2. It keeps at most ACTIVE_BMC_MAX_ALLOWED versions.

For witherspoon, it has two BMC flash chips, and ACTIVE_BMC_MAX_ALLOWED is configured to 2, so it works fine:

1. There are two BMC images, one is functional with high priority, and the other is backup with low priority;
2. When update BMC, ItemUpdater::freeSpace() it removes the backup version, and added the updated version.

For static flash layout with only one flash chip, there is always only one BMC image which is functional.
So it will not have a chance to remove it, see code below:

    for (const auto& iter : activations)
    {
        if (...)
        {
            count++;
            // Don't put the functional version on the queue since we can't
            // remove the "running" BMC version.
            if (versions.find(iter.second->versionId)->second->isFunctional())
            {
                continue;
            }
            versionsPQ.push(std::make_pair(
                iter.second->redundancyPriority.get()->priority(),
                iter.second->versionId));
        }
    }

A possible fix could be changing the logic, if ACTIVE_BMC_MAX_ALLOWED is 1, then remove functional BMC version as well.

---

@geissonator commented on Mon Aug 20 2018

Per some recent community discussions, we're looking to have bugs assigned directly to the repo responsible.

Verify failure on static.mtd.all.tar

Build this repo with verify_signature package config, and try to update static.mtd.all.tar via RestAPI or Redfish, we could see below errors:

phosphor-version-software-manager[314]: Untaring
phosphor-image-updater[216]: Failed to find the Data or signature file.
phosphor-image-updater[216]: The operation failed internally.
phosphor-image-updater[216]: Error occurred during image validation
phosphor-image-updater[216]: The operation failed internally.

This is because the function Signature::verify() does not support static.mtd.all.tar yet.

While BMC is updating image, firmware inventory will generate redundant ID

Issue:
Redundant values returned by Redfish GET request from /redfish/v1/UpdateService/FirmwareInventory

Description:
The Redfish GET request from /redfish/v1/UpdateService/FirmwareInventory is returning redundant values. This issue seems to be related to the phosphor-bmc-code-mgmt functionality.

During a BMC firmware update, a new object is created that includes the xyz.openbmc_project.Software.Version interface. This interface plays a crucial role in listing all the firmware inventory using the Redfish GET request.

However, when performing a firmware update and calling the GET request, the result list includes the new BMC firmware object, even though it should not be part of the firmware inventory list since the image is not yet active.

Related Code:

• phosphor-bmc-code-mgmt image_manager.cpp
• bmcweb update_service.hpp

This issue is not BMCWEB issue , seems to me that the the fix should be at the phosphor-bmc-code-mgmt.

Redfish output Example:
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
"@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
"Members": [
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/bd850aa9" (This is the running BMC)
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/e2960819" (The new BMC FW, not running )
}
],
"[email protected]": 2,
"Name": "Software Inventory Collection"
}
Questions:

1. Is this issue already known?
2. What are your suggestions for an acceptable fix?

How to upgrade alt-bmc via redfish

The question as stated in the title. Does anyone know?