Is there any way to customize HWIDs for factory installations?

[Jie Fan]

Hi,

There is an option --hwid_updater which (I believe) can be used to generate hwids, but I don't really know what the file should look like, where it's writing to (I guess it writes to /sys/platform/devices/chromeos_acpi/HWID, since update engine reads from there), what the file it writes should look like. Is there an example out there I can follow?

I didn't find the the source code of chromeos-hwid package either, is it open sourced?

Thanks.

[Mike Frysinger]

the chromeos-hwid repo is not open source.  it largely contains data files about specific pieces of hardware.  there are a few scripts to create the bundles, but they aren't large.

the package itself isn't included in the base image.  things exposed by chromeos_acpi are there via the firmware/ACPI logic, and those come from the flash storage (where the firmware lives).

Hung-Te can probably point to more details (or correct anything wrong i've said)

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Hung-Te Lin]

2015-07-16 2:09 GMT+08:00 Jie Fan <ustc.fl...@gmail.com>:

There is an option --hwid_updater which (I believe) can be used to generate hwids,

   It's for specifying the HWID database you want to use, not to generate.

 

but I don't really know what the file should look like, where it's writing to (I guess it writes to /sys/platform/devices/chromeos_acpi/HWID, since update engine reads from there),

    That's not how it works. Usually you have to first create a HWID database,  probe your hardware configuration, decide HWID, then write into system.

 

what the file it writes should look like. Is there an example out there I can follow?

    

     There're few examples in factory repo, for example factory/py/factory_flow/templates/FAKE_HWID

  

I didn't find the the source code of chromeos-hwid package either, is it open sourced?

     All the source that probes, generates, and verifies HWID database are in the public factory repository. You can find good tools in factory/bin/hwid and bin/gooftool.

     To write (after probed) HWID try factory/py/test/pytests/hwid*.

     The only thing not open sourced is the database of each shipping device - because it contains the real hardware information,

     but you can generate something similar by the public tools if you'd like to play with it :)

[Jie Fan]

Thanks, I'll come back with more questions:)

[Jie Fan]

I find HWID is not really something I was looking for. What I want is some unique identifier which a client can use to identify itself to the devserver. It seems that Omaha protocol itself supports sessionid, requestid and userid which could potentially be used as unique identifiers, but I cannot find any mention in update_engine package, there is no such ids in the update checks currently either. I wonder if there is any existing way of embedding such an identifier in the update check requests? Thanks.

[Alex Deymo]

Hi!
Nope, by design, we don't uniquely identify our users in the update process in chrome os. You can download and apply and update automatically without any unique id and there is no support for the tags you mentioned in the update_engine client.

deymo.

--

[Jie Fan]

I see. 

I kind of understand why you are doing this (probably privacy concerns). But just out of curiosity, do you have any kind of A/B testing then? Do you have "staged rollout" for new versions? I ask because I suppose the number of clients is pretty large that the server may not be able to handle all the request at the same time. Also, from my perspective, it might be a good idea to rollout gradually to minimize the impact of a broken update (which requires unique identifiers).

[Mike Frysinger]

we don't have A/B testing at the OS level, but we def have staged rollouts.  our update server allows you to say things like "for device X, give out update Y to Z% of requests".  this way if we know there's a problem with the new version for a specific device (hardware/kernel issue), we can hold it back while still updating the rest.  further, we can trickle it out at like 10% and then watch crash rates from the new version ... if things look good, we can ramp up to 20% then 50% then 100%.

it does mean that for a specific device, you can kind of bypass this check -- just keep asking the server for an update until it responds "yes" :).  but that's not really a "problem" in our scenario as it doesn't statistically disturb the results.

when it comes to doing A/B tests for specific features in the OS/browser, we have a different system for that, and it doesn't require an OS update to toggle it.  we have Finch experiments which allow for controlling such things independently.

-mike

[Jie Fan]

Thanks for the detailed explanation, really helpful!