New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 852390 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jul 17
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

cros_sdk failing on branch firmware-glados-7820.B

Reported by vpalatin@chromium.org, Jun 13 2018

Issue description

Today I tried to do a new chroot on firmware branch firmware-glados-7820.B and it seems to be failing when cros_sdk creates/downloads the stage 3

Both for external checkout:
mkdir glados-public && cd glados-public/
repo init -u https://chromium.googlesource.com/chromiumos/manifest.git -b firmware-glados-7820.B
repo sync
cros_sdk 

$ cros_sdk 
16:05:22: NOTICE: Downloading SDK tarball...
cros_sdk: Unhandled exception:
Traceback (most recent call last):
  File "/usr/local/google/home/vpalatin/glados-public/chromite/bin/cros_sdk", line 164, in <module>
    commandline.ScriptWrapperMain(FindTarget)
  File "/usr/local/google/home/vpalatin/glados-public/chromite/lib/commandline.py", line 834, in ScriptWrapperMain
    ret = target(argv[1:])
  File "/usr/local/google/home/vpalatin/glados-public/chromite/scripts/cros_sdk.py", line 705, in main
    sdk_cache, urls, 'stage3' if options.bootstrap else 'SDK')
  File "/usr/local/google/home/vpalatin/glados-public/chromite/scripts/cros_sdk.py", line 152, in FetchRemoteTarballs
    raise ValueError('No valid URLs found!')
ValueError: No valid URLs found!


And internal checkout:
mkdir glados-internal && cd glados-internal/
repo init -u https://chrome-internal.googlesource.com/chromeos/manifest-internal.git --repo-url='https://chromium.googlesource.com/external/repo.git' -b firmware-glados-7820.B
repo sync
cros_sdk 


Trying bootstrap too :
$ cros_sdk --bootstrap
16:06:40: NOTICE: Downloading stage3 tarball...
cros_sdk: Unhandled exception:
Traceback (most recent call last):
  File "/usr/local/google/home/vpalatin/glados-public/chromite/bin/cros_sdk", line 164, in <module>
    commandline.ScriptWrapperMain(FindTarget)
  File "/usr/local/google/home/vpalatin/glados-public/chromite/lib/commandline.py", line 834, in ScriptWrapperMain
    ret = target(argv[1:])
  File "/usr/local/google/home/vpalatin/glados-public/chromite/scripts/cros_sdk.py", line 705, in main
    sdk_cache, urls, 'stage3' if options.bootstrap else 'SDK')
  File "/usr/local/google/home/vpalatin/glados-public/chromite/scripts/cros_sdk.py", line 152, in FetchRemoteTarballs
    raise ValueError('No valid URLs found!')
ValueError: No valid URLs found!


As we have builders... I must be doing something wrong, but I cannot see it right now.

 
Cc: derat@chromium.org briannorris@chromium.org
Digging into it:
the SDK URLs are:
https://commondatastorage.googleapis.com/chromiumos-sdk/cros-sdk-2016.01.10.232406.tar.xz
https://commondatastorage.googleapis.com/chromiumos-sdk/cros-sdk-2016.01.10.232406.tbz2

cros_sdk definitely runs:
curl -I https://commondatastorage.googleapis.com/chromiumos-sdk/cros-sdk-2016.01.10.232406.tar.xz
curl -I https://commondatastorage.googleapis.com/chromiumos-sdk/cros-sdk-2016.01.10.232406.tbz2


the .tbz returns status 404
the .xz returns status 200

the full output is :
$ curl -I https://commondatastorage.googleapis.com/chromiumos-sdk/cros-sdk-2016.01.10.232406.tar.xz
HTTP/2 200 
x-guploader-customer: cloud-storage
x-guploader-uploadid: AEnB2Uokg-_L2G5tVGq8mJr8ZwOVGolmltZ1x-uS_Y7L9vr-qthDxQNcC5nn1sWEA37RKXRo6aVQ40EYGt1YjsnSFJdasgUnlQ
expires: Wed, 13 Jun 2018 16:03:20 GMT
date: Wed, 13 Jun 2018 15:03:20 GMT
cache-control: public, max-age=3600
x-google-storage-location: US
last-modified: Mon, 11 Jan 2016 18:57:23 GMT
etag: "67116a532e1c333a249fece72aabae12"
x-goog-generation: 1452538643462000
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 1293463404
content-type: application/x-xz
x-goog-hash: crc32c=4Pba0A==
x-goog-hash: md5=ZxFqUy4cMzokn+znKquuEg==
x-goog-storage-class: STANDARD
accept-ranges: bytes
content-length: 1293463404
x-guploader-request-result: success
x-guploader-upload-result: success
x-google-gfe-cloud-project-number: 134157665460
x-google-gfe-backend-request-info: eid=ODIhW-nbDKjrhAWDromoBw
server: UploadServer
x-google-netmon-label: /bns/xk/borg/xk/bns/blobstore2/bitpusher/95:caf3
x-google-backends: /bns/xk/borg/xk/bns/cloud-storage/prod-cloud-storage-frontend.frontend/7,/bns/xk/borg/xk/bns/blobstore2/bitpusher/95.scotty,acmila18:443
x-google-gfe-request-trace: acmila18:443,/bns/xk/borg/xk/bns/blobstore2/bitpusher/95.scotty,acmila18:443
x-google-dos-service-trace: main:apps-upload-cloud-storage-unified
x-google-service: bitpusher-cloud-storage
x-google-gfe-response-code-details-trace: response_code_set_by_backend
x-google-shellfish-status: CA0gBEBG
alt-svc: quic=":443"; ma=2592000; v="43,42,41,39,35"
x-google-gfe-service-trace: bitpusher-cloud-storage

it returns "HTTP/2 200" rather than "200 OK" as expected by cros_sdk ?

Now I have found the missing fix for this branch:
https://chromium-review.googlesource.com/c/chromiumos/chromite/+/389815


Cc: dgarr...@chromium.org
With those 2 cherry-picks in chromite:
d37e2f74e cros_sdk: improve curl output parsing
cf8aef446 cros_sdk: fix more quirks and corner cases in parsing curl HTTP responses

~/glados-public/chromite$ git cherry-pick -x d37e2f74e
~/glados-public/chromite$ git cherry-pick -x cf8aef446

My cros_sdk now works...
but what is the story for firmware branches then ?

the trigger of the badness on my side seems to be the switch from the older Ubuntu host distro (e.g. with  curl 7.47.0 without HTTP2.0) to the Debian with curl 7.58.0 with 'HTTP2' features

e.g.
$ curl -V
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets 

vs 

$ curl -V
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.0.2n zlib/1.2.8 libidn2/2.0.2 libpsl/0.19.1 (+libidn2/2.0.2) libssh2/1.8.0 nghttp2/1.28.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL 

Status: Started (was: Untriaged)
If cherry-picking to the firmware-glados-7820.B branch is right answer, I have prepared:
https://chromium-review.googlesource.com/#/c/chromiumos/chromite/+/1099172 cros_sdk: improve curl output parsing        
https://chromium-review.googlesource.com/#/c/chromiumos/chromite/+/1099173 cros_sdk: fix more quirks and corner cases in parsing curl HTTP responses   

Comment 5 by gkihumba@google.com, Jun 13 2018

Cc: gkihumba@chromium.org
Project Member

Comment 6 by bugdroid1@chromium.org, Jun 14 2018

Labels: merge-merged-firmware-glados-7820.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/ab2cead3c2eebb1faa40ceae93f1ee2f8d7a0187

commit ab2cead3c2eebb1faa40ceae93f1ee2f8d7a0187
Author: Brian Norris <briannorris@chromium.org>
Date: Thu Jun 14 06:48:42 2018

cros_sdk: improve curl output parsing

Derived from CoreOS commit add4c2e24ca7e23bb3895fdea8fa58eab950f9dc
https://github.com/coreos/chromite/pull/21

    """
    Blindly searching for '200 OK' doesn't work with HTTP/2 which doesn't
    include a text description in the response. Match the status line by
    prefix instead. Seems less foolish anyway.
    """

Might as well future-proof against HTTP revisions up to 9.9 ;)

BUG= chromium:852390 
TEST=`cros_sdk`; set up new chroot; trybots

Inspired-by: Michael Marineau <michael.marineau@coreos.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373685
Tested-by: Harry Pan <gs0622@gmail.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
(cherry picked from commit d37e2f74eb684ff97f566ca3ca85daf20a1938df)

Change-Id: I5e88a4b38f357bb08449de302a5c813f572136d2
Reviewed-on: https://chromium-review.googlesource.com/1099236
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>

[modify] https://crrev.com/ab2cead3c2eebb1faa40ceae93f1ee2f8d7a0187/scripts/cros_sdk.py

Project Member

Comment 7 by bugdroid1@chromium.org, Jun 14 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/c54f32ba4e447c69d6777d79706c333a5bc4d5f1

commit c54f32ba4e447c69d6777d79706c333a5bc4d5f1
Author: Brian Norris <briannorris@chromium.org>
Date: Thu Jun 14 06:48:42 2018

cros_sdk: fix more quirks and corner cases in parsing curl HTTP responses

See section 3.1 here:

https://www.ietf.org/rfc/rfc2616.txt

that says:

"""
   The version of an HTTP message is indicated by an HTTP-Version field
   in the first line of the message.

       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
"""

However, we've seen reports in the wild of (potentially non-conforming?)
HTTP/2 implementations returning 'HTTP/2 200 OK'. Rather than being
unnecessarily pedantic here, let's just accept the not-so-standard
format.

While we're at it, I noticed that the HTTP standard allows for these
major/minor revisions to roll over to 2+ digits.

And finally, note that '.' is a regex wildcard. Let's escape it
properly.

So, a few representative examples of prefixes we accept:

  'HTTP/1.0 200'
  'HTTP/1.1 200'
  'HTTP/1 200'
  'HTTP/2.0 200'
  'HTTP/2 200'
  'HTTP/99999 200'
  'HTTP/1337.987654321 200'

But we no longer allow:

  'HTTP/1a0 200'

BUG= chromium:852390 
TEST=trybots; download a new checkout / build the cros_sdk chroot

Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389815
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
(cherry picked from commit cf8aef44686e40e4899a332587ca0ca0b8c58a51)

Change-Id: I804a0bd13f50ddaec1f6a6b7fe0fd16f5aa9167d
Reviewed-on: https://chromium-review.googlesource.com/1099237
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>

[modify] https://crrev.com/c54f32ba4e447c69d6777d79706c333a5bc4d5f1/scripts/cros_sdk.py

Cc: la...@chromium.org
Components: -Infra>Client>ChromeOS>Build Infra>Client>ChromeOS>CI
Status: Untriaged (was: Started)
so firmware-glados-7820.B should be fixed now.

but AFAICT they are plenty of other firmware/factory branches affected [1]
I sent a PSA to chromeos-firmware@ to avoid wasting other people time on this :
https://groups.google.com/a/google.com/d/msg/chromeos-firmware/1K7a3DIF3Rw/28iaaoSTBgAJ


our automated branch builders currently works properly but AFAICT likely only by the virtue of running an older host version.
so tentatively moving this to Infra>Client>ChromeOS>CI to let the CI team decides the appropriate resolution (+CC CI bobby).


[1] the fix went in at version 8862.0.0, so all older branches might be affected.
 the following ones are already fixed:
  factory-rambi-6420.B / firmware-veyron-6588.B / firmware-glados-7820.B / firmware-gru-8785.B

Comment 9 by la...@chromium.org, Jun 14 2018

Owner: dgarr...@chromium.org
dgarrett: This looks like host migration fallout?
Labels: -Type-Bug Type-Feature
Owner: ----
Status: Available (was: Untriaged)
I think it's more along the lines of an observation of what we'll have to do when we upgrade distros. AFAIK, we haven't upgraded distros anywhere, yet. Thanks for doing the investigation, Vincent. Going to keep this as a feature request that will eventually get added to a distro upgrade hotlist.
Owner: vapier@chromium.org
Status: Fixed (was: Available)
i just cherry picked a metric crap ton of patches.  assuming resolved.

Sign in to add a comment