cros flash depends on chroot before creating it. |
||||||||
Issue descriptionUsability issue: We've had a few users experiencing problems using xbuddy paths in cros flash. It turned out that this was because their /root/.boto file was out of sync with ~/.boto (b/30946717). Example: in the cros_sdk chroot, run cros flash ssh://192.168.231.105 xbuddy://remote/whirlwind-release/R54-8708.0.0/test Initially, cros flash checks that it can find the build using GetImagePathWithXbuddy. This uses the user's ~/.boto credentials and works fine, it finds the build. Next, it spins up a local devserver to serve the update payload. This devserver is started using sudo, so it uses boto credentials from /root/.boto. If the user has changed their ~/.boto credentials to find the build, but did not update /root/.boto, the initial check using GetImagePathWithXbuddy succeeds, but the local devserver that cros flash starts up is unable to find the build. The command fails with: [18/Aug/2016:15:35:56] HTTP Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/cherrypy/_cprequest.py", line 656, in respond response.body = self.handler() File "/usr/lib64/python2.7/site-packages/cherrypy/lib/encoding.py", line 188, in __call__ self.body = self.oldhandler(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/cherrypy/_cpdispatch.py", line 34, in __call__ return self.callable(*self.args, **self.kwargs) File "/usr/lib/devserver/devserver.py", line 1105, in xbuddy build_id = self._xbuddy.StageTestArtifactsForUpdate(args) File "/usr/lib64/devserver/xbuddy.py", line 844, in StageTestArtifactsForUpdate build_id, file_name = self.Translate(path_list) File "/usr/lib64/devserver/xbuddy.py", line 831, in Translate image_dir=image_dir) File "/usr/lib64/devserver/xbuddy.py", line 776, in _GetArtifact image_dir=image_dir) File "/usr/lib64/devserver/xbuddy.py", line 456, in _ResolveVersionToBuildId return self._RemoteBuildId(board, suffix, version) File "/usr/lib64/devserver/xbuddy.py", line 413, in _RemoteBuildId board, version)) XBuddyException: Could not find remote build_id for whirlwind-release R54-8708.0.0 This can be confusing since the user is able to fetch the build using gsutil. It is easy to fix by copying ~/.boto to /root/.boto, but maybe there is a way to avoid this issue cropping up?
,
Jan 26 2017
Is this still happening? The /root in question SHOULD be inside the chroot, and thus should be automatically populated from the users .boto. Possibly related, xbuddy is referencing things inside the chroot without explicitly entering it. That means the chroot contents might be missing or out of date. That can be reproduced with: cros clean --chroot cros flash ssh://192.168.231.105 xbuddy://remote/whirlwind-release/R54-8708.0.0/test
,
Jan 26 2017
Error message is no chroot exists: clean$cros flash ssh://100.107.151.225 xbuddy://remote/lumpy-release/R54-8708.0.0/test 14:02:09: NOTICE: Preparing to update the remote device 100.107.151.225 14:02:13: ERROR: Device update failed. 14:02:13: ERROR: cros flash failed before completing. 14:02:13: ERROR: [Errno 2] No such file or directory: '/usr/local/google/home/dgarrett/sand/clean/chroot/tmp/devserver_wrappern97tll'
,
Jan 26 2017
,
Jan 26 2017
,
Jan 27 2017
It is happening less now that people are aware of the issue and it has been documented a few places. The issue seems to come up when the user changes their credentials in ~/.boto inside the chroot without making the same change to /root/.boto in the chroot. When this happens, cros flash to a usb: or file: target works, but flashing directly to a host fails because the local devserver spun up to stage the artifacts is run as root, which has invalid boto credentials.
,
Jan 27 2017
When entering the chroot, I would expect both inside .boto's to be auto-updated based on the user's external .boto. But cros flash appears to be using files inside the chroot directory when it hasn't entered the chroot proper, which is just weird. We need some cleanup in the devserver code used by cros flash anyway, this is probably related to that.
,
Jan 27 2017
on a side note, if there is some devserver cleanup happening, consider adding https://bugs.chromium.org/p/chromium/issues/detail?id=482297
,
Mar 9 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 9 2018
,
Apr 17 2018
,
Jun 8 2018
,
Jul 13
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by aut...@google.com
, Aug 23 2016Labels: -current-issue
Owner: dgarr...@chromium.org