Redfish implementation does not supply SoftwareId

Redfish implementation does not supply SoftwareId

[Richard Hughes]

Hi all,

My name is Richard Hughes and I'm the upstream maintainer of fwupd
which is a linux program that allows flashing hardware. It's used by a
few million people already and there's recently been a lot of interest
about getting fwupd to run on the actual BMC chip, rather than on the
host OS. That's not really what this email is about, but might explain
the bigger picture. I'll come back to this in a few weeks time :)

At the moment fwupd runs on the host OS and uses a plugin to
communicate with various Redfish implementations, for example iDRAC
for Dell or XClarity for Lenovo. Teddy Reed kindly donated (loaned?)
me some hardware so I could test the fwupd plugin against the Redfish
implementation of OpenBMC, more specifically git master on a
evb-ast2500 board.

With a small patch to fwupd (setting CURLOPT_SSL_VERIFYHOST=0) it
seems to load and enumerate correctly, but doesn't add any devices.
The reason I found was that the SoftwareId property is missing from
the /redfish/v1/UpdateService/FirmwareInventory/7d021ade path. The
SoftwareId is the "key" that maps the hardware to a specific firmware
*stream*, so for instance it could be something like
"USB\VID_17EF&PID_3083" for a peripheral or some other kind of
vendor-specific string, e.g. "SAMSUNG MZVLB2T0HALB-000L7". The idea is
that vendors then upload firmware to the LVFS website with a defined
*stream* and updates get deployed onto matching hardware
automatically. I'm not so sure that makes a huge amount of sense for
the OpenBMC BMC image itself. Or maybe it does; getting new official
OpenBMC images from the LVFS would be way cool, but I don't think we
want to flash the entire MTD image. Anyway, I digress.

I guess my question is if I could get a SoftwareId set for 7d021ade --
e.g. "evb-ast2500" -- that at least allows the device to enumerate in
fwupd and gives me something to test against. I guess my next question
is how a OpenBMC distributor adds a new device into
/redfish/v1/UpdateService/FirmwareInventory.Members -- and if there's
a way to set SoftwareId for that new device too.

Sorry if all these are newbie questions, and I appreciate any
pointers; I'm happy to send patches. Thanks.

Richard.

Re: Redfish implementation does not supply SoftwareId

[Joseph Reynolds]

On 11/11/21 8:16 AM, Richard Hughes wrote:
> Hi all,
>
> My name is Richard Hughes and I'm the upstream maintainer of fwupd
> which is a linux program that allows flashing hardware. It's used by a
> few million people already and there's recently been a lot of interest
> about getting fwupd to run on the actual BMC chip, rather than on the
> host OS. That's not really what this email is about, but might explain
> the bigger picture. I'll come back to this in a few weeks time :)

Richard,

Thanks for your email!  I don't have any answers, and my intention for 
this email is to stir up some discussion.  There was some previous work 
in this area described here: 
https://lists.ozlabs.org/pipermail/openbmc/2020-May/021573.html

Where can we learn more about the interest in getting `fwupd` to run on 
the BMC?  Links to chat room, email archive, etc?

Background: OpenBMC's current documented [features][] for [firmware 
update][] is given here:
[features]: https://github.com/openbmc/docs/blob/master/features.md
[firmware update]: 
https://github.com/openbmc/docs/blob/master/architecture/code-update/code-update.md

In this context, I understand you are interested in either (A) adding 
support for a new fwupd method or (B) creating a new OpenBMC function to 
update the firmware for various host components, or (C) both.  That 
seems to me like a good fit with OpenBMC.

And please note I am not familiar with [fwupd][].
[fwupd]: https://github.com/fwupd/fwupd


> At the moment fwupd runs on the host OS and uses a plugin to
> communicate with various Redfish implementations, for example iDRAC
> for Dell or XClarity for Lenovo. Teddy Reed kindly donated (loaned?)
> me some hardware so I could test the fwupd plugin against the Redfish
> implementation of OpenBMC, more specifically git master on a
> evb-ast2500 board.
>
> With a small patch to fwupd (setting CURLOPT_SSL_VERIFYHOST=0) it
> seems to load and enumerate correctly, but doesn't add any devices.

Do I infer correctly that you got `fwupd` running on the BMC, for 
example having a working `fwupdmgr` command?

> The reason I found was that the SoftwareId property is missing from
> the /redfish/v1/UpdateService/FirmwareInventory/7d021ade path. The
> SoftwareId is the "key" that maps the hardware to a specific firmware
> *stream*, so for instance it could be something like
> "USB\VID_17EF&PID_3083" for a peripheral or some other kind of
> vendor-specific string, e.g. "SAMSUNG MZVLB2T0HALB-000L7". The idea is
> that vendors then upload firmware to the LVFS website with a defined
> *stream* and updates get deployed onto matching hardware
> automatically. I'm not so sure that makes a huge amount of sense for
> the OpenBMC BMC image itself. Or maybe it does; getting new official
> OpenBMC images from the LVFS would be way cool, but I don't think we
> want to flash the entire MTD image. Anyway, I digress.

Use cases:

I understand OpenPOWER system firmware has two firmware packages which 
are typically packaged together: (1) the BMC firmware image and (2) the 
host firmware image.  The host image itself contains multiple parts but 
the BMC does not handle them separately.  Given this, firmware updates 
are monoliotic and are not done to individual components.  (But note my 
understanding is limited.)

I understand the other systems (mentioned above) support updating the 
firmware for various individual host components.

> I guess my question is if I could get a SoftwareId set for 7d021ade --
> e.g. "evb-ast2500" -- that at least allows the device to enumerate in
> fwupd and gives me something to test against. I guess my next question
> is how a OpenBMC distributor adds a new device into
> /redfish/v1/UpdateService/FirmwareInventory.Members -- and if there's
> a way to set SoftwareId for that new device too.

I don't understand enough background in this area.  OpenBMC's [BMCWeb][] 
has pulled in the Redfish [SoftwareInventory schema][] and has an 
[update service implementation][] but has not yet implemented the 
`SoftwareId` property.  I think you want that.  But I don't know if that 
will give you what you need.

[BMCWeb]: https://github.com/openbmc/bmcweb
[SoftwareInventory schema]: 
https://github.com/openbmc/bmcweb/blob/master/static/redfish/v1/JsonSchemas/SoftwareInventory/SoftwareInventory.json
[update service implementation]: 
https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/update_service.hpp

One more thing I don't know... :-) Where is the right place (via 
Yocto/bitbake recipes) to set the SoftwareId?  Somewhere around here?:
- Base OpenBMC support: 
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/images/obmc-phosphor-image.bb
- Customization for IBM machines: 
https://github.com/openbmc/openbmc/blob/master/meta-ibm/recipes-phosphor/images/obmc-phosphor-image.bbappend
- In the class for the above: 
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/classes/image_types_phosphor.bbclass

I hope this helps.

Joseph

>
> Sorry if all these are newbie questions, and I appreciate any
> pointers; I'm happy to send patches. Thanks.
>
> Richard.

Re: Redfish implementation does not supply SoftwareId

[Richard Hughes]

On Wed, 17 Nov 2021 at 19:36, Joseph Reynolds <jrey@linux.ibm.com> wrote:
> Where can we learn more about the interest in getting `fwupd` to run on
> the BMC?  Links to chat room, email archive, etc?

I don't have much public information I'm afraid. It's a very big
company using OpenBMC that suggested this just a few weeks ago. I'm
still not sure if it's a genius or insane idea to be honest. I
initially thought the latter, but people cleverer than me say the
former.

> [firmware update]:
> https://github.com/openbmc/docs/blob/master/architecture/code-update/code-update.md

Super useful, thanks.

> In this context, I understand you are interested in either (A) adding
> support for a new fwupd method or (B) creating a new OpenBMC function to
> update the firmware for various host components, or (C) both.  That
> seems to me like a good fit with OpenBMC.

I think the idea is that fwupd already knows how to install updates on
an insane number of devices (~32 different update protocols supported,
everything from DFU, to NVME, to UEFI capsule, Redfish, ATA, Logitech
HID++, and even MTD) and those could be *used* by OpenBMC saying
"install *this* on *that*" or even plumbing in OpenBMC to query fwupd
to say "what updatable devices can you tell me about". For both
actions there's a DBus interface or a JSON data dump available, either
as an in-process query or just by running the daemon in the
background. e.g. "fwupdmgr get-devices" is a thin wrapper around the
GetUpdates DBus call that returns a 'aasv' array of dictionaries blob.

> Do I infer correctly that you got `fwupd` running on the BMC, for
> example having a working `fwupdmgr` command?

Yes, actually more crazy than that, I got fwupd downloading and
deploying updates from the LVFS... https://fwupd.org/

See https://twitter.com/hughsient/status/1458922790690635780 for the
obligatory screenshot. I think the idea is that vendors can use the
same code in fwupd to deploy firmware onto COTS hardware without
OpenBMC and onto custom hardware with OpenBMC. i.e. they teach one
thing how to update the hardware and get to use it in both places.

> I understand OpenPOWER system firmware has two firmware packages which
> are typically packaged together: (1) the BMC firmware image and (2) the
> host firmware image.  The host image itself contains multiple parts but
> the BMC does not handle them separately.  Given this, firmware updates
> are monoliotic and are not done to individual components.  (But note my
> understanding is limited.)

In some cases the host UEFI firmware is behind some kind of MUX so
that fwupd needs to know the GPIO to poke to make the MTD device
appear to the BMC, and then the other GPIO to poke to return control
back to the host. We have a plugin for that now. I didn't plan to
update the BMC firmware using fwupd, but I guess if the BMC partitions
are exposed as MTD devices there's nothing stopping you actually doing
that. Intererstingly that would also mean that you could ship OpenBMC
kernel or ro updates via the LVFS, for instance.

I saw some of the code deploying OpenPOWER firmware updates; I could
totally see that being a fwupd plugin. Being somewhat biased of course
:)

> I don't understand enough background in this area.  OpenBMC's [BMCWeb][]
> has pulled in the Redfish [SoftwareInventory schema][] and has an
> [update service implementation][] but has not yet implemented the
> `SoftwareId` property.  I think you want that.  But I don't know if that
> will give you what you need.

Yes, SoftwareId is what fwupd uses to say "use this firmware for that
hardware" i.e. the firmware declares "I'll install on the SoftwareId
that matches" and then other requirements (like tool+OS version, CHIDs
etc) get layered on top.

> One more thing I don't know... :-) Where is the right place (via
> Yocto/bitbake recipes) to set the SoftwareId?  Somewhere around here?:
> - Base OpenBMC support:
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/images/obmc-phosphor-image.bb
> - Customization for IBM machines:
> https://github.com/openbmc/openbmc/blob/master/meta-ibm/recipes-phosphor/images/obmc-phosphor-image.bbappend
> - In the class for the above:
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/classes/image_types_phosphor.bbclass

I'm not sure, to be honest. In my naive example where fwupd was
running on the host and talking to the BMC using Redfish I just used
the board name, eg. evb-ast2500 -- but obviously any vendor
customization would want to override that. So maybe the answer to your
question is "both"?

In the case where fwupd is running on the BMC, I just used the MTD
name (as you can see on the screenshot) and then you'd layer on some
other requirement like "DMI must match this HWID"

Many thanks for your help.

Richard.

Re: Redfish implementation does not supply SoftwareId

[Ed Tanous]

On Thu, Nov 11, 2021 at 6:18 AM Richard Hughes <hughsient@gmail.com> wrote:
>
> Hi all,
>
> My name is Richard Hughes and I'm the upstream maintainer of fwupd
> which is a linux program that allows flashing hardware. It's used by a
> few million people already and there's recently been a lot of interest
> about getting fwupd to run on the actual BMC chip, rather than on the
> host OS. That's not really what this email is about, but might explain
> the bigger picture. I'll come back to this in a few weeks time :)
>
> At the moment fwupd runs on the host OS and uses a plugin to
> communicate with various Redfish implementations, for example iDRAC
> for Dell or XClarity for Lenovo. Teddy Reed kindly donated (loaned?)
> me some hardware so I could test the fwupd plugin against the Redfish
> implementation of OpenBMC, more specifically git master on a
> evb-ast2500 board.
>
> With a small patch to fwupd (setting CURLOPT_SSL_VERIFYHOST=0) it
> seems to load and enumerate correctly, but doesn't add any devices.
> The reason I found was that the SoftwareId property is missing from
> the /redfish/v1/UpdateService/FirmwareInventory/7d021ade path. The
> SoftwareId is the "key" that maps the hardware to a specific firmware
> *stream*, so for instance it could be something like
> "USB\VID_17EF&PID_3083" for a peripheral or some other kind of
> vendor-specific string, e.g. "SAMSUNG MZVLB2T0HALB-000L7". The idea is
> that vendors then upload firmware to the LVFS website with a defined
> *stream* and updates get deployed onto matching hardware
> automatically. I'm not so sure that makes a huge amount of sense for
> the OpenBMC BMC image itself. Or maybe it does; getting new official
> OpenBMC images from the LVFS would be way cool, but I don't think we
> want to flash the entire MTD image. Anyway, I digress.
>
> I guess my question is if I could get a SoftwareId set for 7d021ade --
> e.g. "evb-ast2500" -- that at least allows the device to enumerate in
> fwupd and gives me something to test against. I guess my next question
> is how a OpenBMC distributor adds a new device into
> /redfish/v1/UpdateService/FirmwareInventory.Members -- and if there's
> a way to set SoftwareId for that new device too.

This seems like a reasonable thing to do.  We probably want to
namespace SoftwareId with OpenBMC-<machine name> just to make sure we
don't have the possibility of conflicting with the manufacturer
firmwares for these boards.  I'm not sure this information is
available on dbus today, so we'd need to get something that can
publish that to bmcweb, then get bmcweb to consume it to publish the
Redfish property.  Considering that we're very likely to be adding
updates of PSUs/drives/other components in the future, we'll likely
need a SoftwareId interface anyway.

If the above is something you're interested in tackling, you might
consider hopping on discord in the bmcweb-and-redfish channel to
hammer out the details if you're unsure;  These days it tends to get
faster responses to quick-turnaround support stuff.  If this isn't
something you're wanting to tackle, I think it's important enough that
I can add it to my plate, but my cup runneth over these days, so I'm
not sure when I can get there.

>
> Sorry if all these are newbie questions, and I appreciate any
> pointers; I'm happy to send patches. Thanks.
>
> Richard.

Re: Redfish implementation does not supply SoftwareId

[Ed Tanous]

On Wed, Nov 17, 2021 at 1:26 PM Richard Hughes <hughsient@gmail.com> wrote:
>
> On Wed, 17 Nov 2021 at 19:36, Joseph Reynolds <jrey@linux.ibm.com> wrote:
> > Where can we learn more about the interest in getting `fwupd` to run on
> > the BMC?  Links to chat room, email archive, etc?
>
> I don't have much public information I'm afraid. It's a very big
> company using OpenBMC that suggested this just a few weeks ago. I'm
> still not sure if it's a genius or insane idea to be honest. I
> initially thought the latter, but people cleverer than me say the
> former.

The line between insane and genius is more of a venn diagram rather
than a hard line.

>
> > [firmware update]:
> > https://github.com/openbmc/docs/blob/master/architecture/code-update/code-update.md
>
> Super useful, thanks.
>
> > In this context, I understand you are interested in either (A) adding
> > support for a new fwupd method or (B) creating a new OpenBMC function to
> > update the firmware for various host components, or (C) both.  That
> > seems to me like a good fit with OpenBMC.
>
> I think the idea is that fwupd already knows how to install updates on
> an insane number of devices (~32 different update protocols supported,
> everything from DFU, to NVME, to UEFI capsule, Redfish, ATA, Logitech
> HID++, and even MTD) and those could be *used* by OpenBMC saying
> "install *this* on *that*" or even plumbing in OpenBMC to query fwupd
> to say "what updatable devices can you tell me about".

In my dream world (where software is easy):
1. fwupd would compile small enough to be put on every BMC, with
compile options to compile out the modes (and therefore binary size)
that doesn't make sense in a BMC context.
2. We'd write a dbus service (or extend fwupd), and make its data
available to dbus, such that we can hook it up directly to Redfish
FirmwareInventory schemas
3. When we start tackling in-system update use cases (power supplies,
CPLDs, BIOS, ect) fwupd would be the "default" go to, such that we
could share the bmc-specific and in-band update mechanisms in the same
application.  For example, updating a VR or NVMe drive should be
similar whether you're updating from a host-based OS, or from the BMC.

> For both
> actions there's a DBus interface or a JSON data dump available, either
> as an in-process query or just by running the daemon in the
> background. e.g. "fwupdmgr get-devices" is a thin wrapper around the
> GetUpdates DBus call that returns a 'aasv' array of dictionaries blob.
>
> > Do I infer correctly that you got `fwupd` running on the BMC, for
> > example having a working `fwupdmgr` command?
>
> Yes, actually more crazy than that, I got fwupd downloading and
> deploying updates from the LVFS... https://fwupd.org/
>
> See https://twitter.com/hughsient/status/1458922790690635780 for the
> obligatory screenshot. I think the idea is that vendors can use the
> same code in fwupd to deploy firmware onto COTS hardware without
> OpenBMC and onto custom hardware with OpenBMC. i.e. they teach one
> thing how to update the hardware and get to use it in both places.

Any chance you posted the recipe file somewhere for others to hack on
this along with you?

>
> > I understand OpenPOWER system firmware has two firmware packages which
> > are typically packaged together: (1) the BMC firmware image and (2) the
> > host firmware image.  The host image itself contains multiple parts but
> > the BMC does not handle them separately.  Given this, firmware updates
> > are monoliotic and are not done to individual components.  (But note my
> > understanding is limited.)
>
> In some cases the host UEFI firmware is behind some kind of MUX so
> that fwupd needs to know the GPIO to poke to make the MTD device
> appear to the BMC, and then the other GPIO to poke to return control
> back to the host. We have a plugin for that now. I didn't plan to
> update the BMC firmware using fwupd, but I guess if the BMC partitions
> are exposed as MTD devices there's nothing stopping you actually doing
> that. Intererstingly that would also mean that you could ship OpenBMC
> kernel or ro updates via the LVFS, for instance.

YES! ! ! ! !  In a perfect world, we could also have OpenBMC CI
automatically post to LVFS when we cut major/minor firmware revisions,
and give OpenBMC users a "check for updates" button/api that could
automatically invoke fwupd locally to check for updates.

>
> I saw some of the code deploying OpenPOWER firmware updates; I could
> totally see that being a fwupd plugin. Being somewhat biased of course
> :)
>
> > I don't understand enough background in this area.  OpenBMC's [BMCWeb][]
> > has pulled in the Redfish [SoftwareInventory schema][] and has an
> > [update service implementation][] but has not yet implemented the
> > `SoftwareId` property.  I think you want that.  But I don't know if that
> > will give you what you need.
>
> Yes, SoftwareId is what fwupd uses to say "use this firmware for that
> hardware" i.e. the firmware declares "I'll install on the SoftwareId
> that matches" and then other requirements (like tool+OS version, CHIDs
> etc) get layered on top.
>
> > One more thing I don't know... :-) Where is the right place (via
> > Yocto/bitbake recipes) to set the SoftwareId?  Somewhere around here?:
> > - Base OpenBMC support:
> > https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/images/obmc-phosphor-image.bb
> > - Customization for IBM machines:
> > https://github.com/openbmc/openbmc/blob/master/meta-ibm/recipes-phosphor/images/obmc-phosphor-image.bbappend
> > - In the class for the above:
> > https://github.com/openbmc/openbmc/blob/master/meta-phosphor/classes/image_types_phosphor.bbclass
>
> I'm not sure, to be honest. In my naive example where fwupd was
> running on the host and talking to the BMC using Redfish I just used
> the board name, eg. evb-ast2500 -- but obviously any vendor
> customization would want to override that. So maybe the answer to your
> question is "both"?
>
> In the case where fwupd is running on the BMC, I just used the MTD
> name (as you can see on the screenshot) and then you'd layer on some
> other requirement like "DMI must match this HWID"
>
> Many thanks for your help.
>
> Richard.

Re: Redfish implementation does not supply SoftwareId

[Richard Hughes]

On Wed, 17 Nov 2021 at 21:50, Ed Tanous <ed@tanous.net> wrote:
> > I guess my question is if I could get a SoftwareId set for 7d021ade --
> > e.g. "evb-ast2500" -- that at least allows the device to enumerate in
>
> This seems like a reasonable thing to do.  We probably want to
> namespace SoftwareId with OpenBMC-<machine name>

Yes, a good idea. Perhaps as a first step we could just hardcode
"OpenBMC-{machine-name}" in the SoftwareId? It gets a bit icky as
there appears to only be one component exposed on Redfish, when in
reality you probably want multiple components for things like ro,
kernel etc.

> If the above is something you're interested in tackling, you might
> consider hopping on discord in the bmcweb-and-redfish channel

I'm not sure how many cycles I have for this personally, but I'd be
amazed if that big vendor didn't want to get things moving. :)

> The line between insane and genius is more of a venn diagram rather
> than a hard line.

It would seem that way indeed.

> In my dream world (where software is easy):

Dude, software is easy. It's the "making people work together" bit
that's hard :)

> 1. fwupd would compile small enough to be put on every BMC, with
> compile options to compile out the modes (and therefore binary size)
> that doesn't make sense in a BMC context.

Yes, there are a huge number of configure options and we've just added
a few more for the next release to shave the binary distribution size
down. e.g. https://github.com/fwupd/fwupd/pull/3981 and a few more.
I'm not completely sure how to measure the effect of adding fwupd (and
the couple of additional deps) other than looking at the size of the
compressed image. I did two builds, and included a ton of protocols
into fwupd (and we could disable a lot more) and the rootfs went up
4MB so there's probably a lot more needed to trim down. If there's any
clever way to debug size increases (.e. a specific library increased
the size x MB) please let me know.

> 2. We'd write a dbus service (or extend fwupd), and make its data
> available to dbus, such that we can hook it up directly to Redfish
> FirmwareInventory schemas

Ohh, we've already got a dbus interface. e.g.

gdbus call --system --dest org.freedesktop.fwupd --object-path /
--method org.freedesktop.fwupd.GetDevices

gives you the aasv array-of-dictionaries where all the data lives.

> 3. When we start tackling in-system update use cases (power supplies,
> CPLDs, BIOS, ect) fwupd would be the "default" go to, such that we
> could share the bmc-specific and in-band update mechanisms in the same
> application.  For example, updating a VR or NVMe drive should be
> similar whether you're updating from a host-based OS, or from the BMC.

Yes, I think that makes total sense.

> Any chance you posted the recipe file somewhere for others to hack on
> this along with you?

Sure, Ross has been awesome in getting all this upstream:
https://github.com/openembedded/meta-openembedded/tree/master/meta-oe/recipes-bsp/fwupd

...in the next few days I'll do a new upstream release which includes
the patches listed there, and will also include the ~300kb reduction
in installed size. Perhaps give it a few days to pick up the new
release and the new options before trying it yourself. If you really
can't wait there's
https://people.freedesktop.org/~hughsient/temp/fwupd_1.7.1.bb

In the meantime, I (perhaps incorrectly) added it in the OpenBMC image using:

BBFILES += "../meta-openembedded/meta-oe/recipes-bsp/fwupd/*.bb"
CORE_IMAGE_EXTRA_INSTALL += "fwupd"
PACKAGECONFIG:remove = " vala gpg bluez polkit tests consolekit
firmware-packager manpages lzma plugin_altos plugin_dell
plugin_logitech_bulkcontroller plugin_modem_manager
plugin_parade_lspcon plugin_platform_integrity plugin_realtek_mst
plugin_synaptics_mst plugin_synaptics_rmi plugin_tpm"

We did ponder putting the .bb file into fwupd upstream and building it
as part of the CI, but building OpenBMC for each PR would really chew
through our CI minutes.

> > Intererstingly that would also mean that you could ship OpenBMC
> > kernel or ro updates via the LVFS, for instance.
>
> YES! ! ! ! !  In a perfect world, we could also have OpenBMC CI
> automatically post to LVFS when we cut major/minor firmware revisions,

So let's do that. Could someone from the OpenBSD team who could sign
some "legal paperwork" apply for an LVFS account, and then we can set
up a robot user with a token that can automatically upload to the
LVFS. If nothing else it's some really good publicity, and lets me
keep the evb I have here up to date without a SPI programmer. See
https://lvfs.readthedocs.io/en/latest/apply.html and we can create a
test account and do some tests.

> and give OpenBMC users a "check for updates" button/api that could
> automatically invoke fwupd locally to check for updates.

Well, "fwupdmgr update" would basically do the right thing and ask the
user what needs to be updated. Of course, wiring it into OpenBMD would
be even more awesome, and there are tons of DBus APIs to make it all
magic.

Richard.