I haven't been able to remove force enrollment / deny dev mode form the soraka I was able to get. will investigate further tomorrow 

+cc sjg as he may have some insight on other things to check, or what to do with this build target.

I don't see anything offhand that breaks user experience.

From a developer standpoint, it's pretty hard to reason about what's happening in a half-unibuild config, and a lot of config is invalid or duplicate. My suggestion would be to revert or fully implement on master to restore maintainability.

I'm not sure whether addressing this in stable would be better or worse. The system is clearly not set up quite right, but changing it this late into the branch is also risky.

Here's some further info:

Accessory signing:
  works as is but would break with multiple models (unibuild not supported)

firmware-update:
  works as is but would break with multiple models (not an LOEM keyset, signature not working)

arc++:
  works as far as I can tell

I don't have any insight into this unfortunately but I'm happy to help if I can.

I wonder if we can fix the config? Does anyone know what is wrong with it?

Also re the firmware update, perhaps we should change the keyset to work with unibuild? That might be as simple as uprevving the keyset to a new version.

I don't actually have one of these boards but there might be one in the office.

> I don't see anything offhand that breaks user experience.

Today, I also tested some features and didn't see any breakage as well:
  
  1. Firmware Update: function is correct.
      - signer side: no loem.ini in the KEYSET so default rootkey under KEYSET DIR is leveraged.
      - DUT side: no keyset folder in chromeos-firmwareupdate so no re-key is performed.

  2. Power Pref: S0iX is enabled.
      - power_pref is not defined in model.yaml.
      - but board_specific config was put in poppy baseboard overlay.

  3. arc: Seems to be ok after playing around it

  4. login_manager: wallpaper and power key position in model.yaml.

  5. Camera (in arc also): seems to be ok after playing around it

  6. Audio: ok.

It seems that the trigger point of supporting uni-build here is just because UI needs a way to know power button position. So the requirement is to have a way for getting power button position not "UNIBUILD".

As the result, if we can deal with the real problem itself then probably we can remove unibuild support here.

  Q1: not sure how does old projects without uni-build get this information? Or how do we support these projects and nautilus also will have this problem.

  Q2: what is the regression if this info can't be got? so we can revert uni-build support first.

Greg, this looks pretty minor. I'd start by getting a pre-unibuild image from xbuddy and running `mosys platform sku` and `mosys platform signature`. If there's a different, we just need to fix the SKU map in the configuration. If the pre-unibuild also errors, then there's nothing to do and we've confirmed that the unibuild migration is sufficiently complete and this bug can be closed.

I'll forward you an email thread that provides the timeline so you know which version to compare to.

I tested several older builds, R68-10718.16.0 from 2018-06-08 and R68-10718.11.0 from 2018-06-03. Both builds fail to provide sku and signature info with the following result:

mosys platform sku: Command not supported on this platform
mosys platform signature: Command not supported on this platform

Builds after https://chrome-internal-review.googlesource.com/c/chromeos/overlays/overlay-soraka-private/+/624248 fail to provide sku and signature info as well but with a different error:

mosys platform sku: Application error: Subcommand execution finished with error -1
mosys platform signature: Application error: Subcommand execution finished with error -1

The change landed before R68 was branched so all versions of R68 include the change. The difference you are seeing at head is the result of the Rust conversion of Mosys.

Compare:
https://chrome-internal.googlesource.com/chromeos/overlays/overlay-soraka-private/+log/release-R68-10718.B
https://chrome-internal.googlesource.com/chromeos/overlays/overlay-soraka-private/+log/release-R67-10575.B

Let's try one version of R67.

R67-10575.54.0 also fails with:

mosys platform sku: Command not supported on this platform
mosys platform signature: Command not supported on this platform

Okay, we're clear to close this bug then: there's no regression.

One little point...if it is using unibuild then 'mosys platform signature' should ideally work.

I do recall someone making a change to stop using it though, in which case perhaps we should delete the command? If so, please file a bug and I'll take a look.