Show a warning when deploying chromeos-bsp-{BOARD} leaves incomplete /etc/lsb-release |
|
Issue description
I found deploying chromeos-bsp-{BOARD} leaves incomplete /etc/lsb-release on DUT. This may be working as intended. But it will be nice if there's a warning when deploying chromeos-bsp-{BOARD}.
chroot$ emerge-samus chromeos-bsp-samus
chroot$ cros deploy xx.xx.xx.xx chromeos-bsp-samus
After deploy, /etc/lsb-release on DUT becomes
CHROMEOS_RELEASE_APPID={F67500C1-C6D8-5287-E4EC-F9BBB4AEE5C5}
CHROMEOS_BOARD_APPID={F67500C1-C6D8-5287-E4EC-F9BBB4AEE5C5}
CHROMEOS_CANARY_APPID={90F229CE-83E2-4FAF-8479-E368A34938B1}
DEVICETYPE=CHROMEBOOK
Then many things won't work because /etc/lsb-release is incomplete.
,
Aug 15 2017
i imagine "always clobber" or "never clobber" will end up with people trying to do validation in either scenario and it doesn't work for them. like when they're trying to test changes to the bsp package related to lsb-release (appid), or when they're trying to test unrelated changes. so it's a lose/lose situation. the final /etc/lsb-release file is actually generated/stamped by multiple sources. build_images sets up some fields, and the signer sets up other. i think the only sane route is to never allow cros deploy to make changes to the file, and if you attempt to deploy a package that would modify it (like a bsp), cros deploy should issue a warning that your changes have been ignored and if you want to test things, you need to manually edit the file yourself.
,
Aug 16 2017
That would be nice if 'cros deploy' could show a warning and not overwrite /etc/lsb-release.
,
Sep 28
Triage nag: This Chrome OS bug has an owner but no component. Please add a component so that this can be tracked by the relevant team.
,
Nov 8
<UI triage> Bug owners, please add the appropriate component to your bug. Thanks! |
|
►
Sign in to add a comment |
|
Comment 1 by wuchengli@chromium.org
, Aug 15 2017Or deploying chromeos-bsp-{BOARD} shouldn't deploy /etc/lsb-release.