commit | 2c5cb5120349490aff5a0d5240528f6803003e26 | [log] [tgz] |
---|---|---|
author | Gunnar Mills <gmills@us.ibm.com> | Fri Jun 03 13:01:43 2022 -0600 |
committer | Gunnar Mills <gmills@us.ibm.com> | Tue Jun 07 19:40:23 2022 +0000 |
tree | d6480a3a310d89268a1dc4b3efe7a05d6a810cb1 | |
parent | c127a0f4d49fd2152e8c25615aedc53aa8ded1d5 [diff] |
Leave off firmware properties if EBADR Have seen where between the mapper call and the inner call here to phosphor-bmc-code-mgmt, phosphor-bmc-code-mgmt deleted the image. This was during code update and phosphor-bmc-code-mgmt was deleting the backup image. Redfish lists all associated images under the manager resource: "SoftwareImages": { "description": "The images that are associated with this manager.", ... See https://redfish.dmtf.org/schemas/Manager.v1_15_0.json. bmcweb needs to look at the image purpose hence the call to the backup image. EBADR is the resource not found error code. If EBADR is returned when populating the firmware properties just leave off the firmware properties. These properties aren't required. Discussed in discord here: https://discord.com/channels/775381525260664832/981260009256140852/981263933442785290 We do similar checks for an EBADR return code other places in bmcweb. Tested: Everything looked the same. To actually test this code path had to be creative. Made this call look at a bad path: *version; } }, - obj.second[0].first, obj.first, + obj.second[0].first, obj.first + "badid", "org.freedesktop.DBus.Properties", "GetAll", "xyz.openbmc_project.Software.Version"); When doing so I saw the following traces but no internal error: (2022-06-01 20:29:41) [ERROR "fw_utils.hpp":139] error_code = generic:53 (2022-06-01 20:29:41) [ERROR "fw_utils.hpp":140] error msg = Invalid request descriptor The firmware version and software links were left off. The GUI handled this missing information well. The validator passed. Signed-off-by: Gunnar Mills <gmills@us.ibm.com> Change-Id: I9d8cd8b04acadfdd10f660cf9b7ca5dc6f36b4d0
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D
flags that correspond to options in bmcweb/meson_options.txt
and then compiling. For example, meson <builddir> -Dkvm=disabled ...
followed by ninja
in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects
.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja -C builddir test ninja -C builddir coverage
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1
algorithm. The certificate
C=US, O=OpenBMC, CN=testhost
,SHA-256
algorithm.