Open PavamanSubramaniyam opened 6 years ago
------------------------------------------------------------------------------------------------------------------------
TEST PROCEDURE:
------------------------------------------------------------------------------------------------------------------------
1. Clone the op-build repository and cd to the directory:
$ git clone --recursive https://github.com/open-power/op-build.git
$ cd op-build/
2. Source the op-build environment file and load the platform configuration to test (e.g. witherspoon)
$ source op-build-env
$ op-build witherspoon_defconfig
3. If running the test non-interactively, unencrypt your SSH key and patch the signframework client to use the unencrypted key, as shown in SETUP. ONLY DO THIS FOR TEST OR DEVELOPMENT KEYS, *NEVER* DO THIS WITH PRODUCTION KEYS OR PRODUCTION SIGNING OPERATIONS.
4. Set the location of the project INI file:
$ export SB_PROJECT_INI=/path/to/project.ini
5. Run op-build in Production mode. The signtool will connect to the signframework as needed, to retrieve the required keys and signatures. If not running with the unencrypted SSH key, you will be prompted for your password on each signframework request.
$ op-build BR2_OPENPOWER_SECUREBOOT_SIGN_MODE=production
@bofferdn @hellerda Could you please have a look on this issue.
This is probably due to your CI system pointing to the latest head of sb-signing-utils master instead of the tagged version v0.5. (see openpower/package/sb-signing-utils/sb-signing-utils.mk). While I know you have been pointing to the latest instead of the tagged version because it is helpful for CI, at the moment, the latest sb-signing-utils won't work with some machine configs (e.g. witherspoon_defconfig) until their BR2_HOSTBOOT_STABLE_VERSION is advanced to commit adc91be44 or later.
Sorry for the trouble but it is currently out of my control. I am blocked from advancing the SB_SIGNING_UTILS_VERSION in op-build to my next tagged version, for the same reason.
You can revert your SB_SIGNING_UTILS_VERSION to "v0.5" in the interim, as workaround. If you see a failure with v0.5 of course let me know. Thx -DaveH
@hellerda Yes, it is failed due to upstream sb-signing-utils master one. We made that as a default in the CI. Let me re-trigger with default op-build tagged version v0.5.
This should be fixed now with the acceptance of sb-signing-utils v0.6 into op-build, with PR #2371.
You should be able to point to the new op-build default (v0.6), or point again to "master" of sb-signing-utils, which I would prefer. That way I can see when things break. ;- ) At the moment there is no difference.
Sorry for the trouble, I got caught between versions of hostboot, on which sb-sigining-utils relies. (the buildpnor scripts, anyway).
We are using our Jenkins CI to generate Secure container creation production mode PNOR using the upstream op-build git tree.