android image signing failing due to lzo compression |
|||||||||
Issue descriptionsigning the android system.img is failing on the signers: 250317 07:43 DEBUG: RunCommand: /cros/vboot_reference/scripts/image_signing/sign_official_build.sh recovery /tmp/signer.LxLoqd/recovery_image.bin /cros/keys/SnappyPreMPKeys /tmp/signer.LxLoqd/chromeos_9334.21.0_snappy_recover y_beta-channel_premp.bin /cros/keys/SnappyPreMPKeys/key.versions ... INFO : Start updating sepolicy /tmp/tmp.qWBCpc129q/mnt/system/etc/security/mac_permissions.xml /tmp/tmp.Qa0MXb2dWm differ: byte 118, line 1 INFO : Replacing OTA cert INFO : Reapplying file security context /sbin/setfiles reset /tmp/tmp.qWBCpc129q/mnt/system/etc/security/mac_permissions.xml context ->u:object_r:system_file:s0 INFO : Repacking squashfs image Parallel mksquashfs: Using 2 processors Creating 4.0 filesystem on /tmp/tmp.k1QLcpX0A1/opt/google/containers/android/system.raw.img, block size 131072. Write failed because No space left on device FATAL ERROR:Failed to write to output filesystem testing this input: gs://chromeos-releases/beta-channel/snappy/9334.21.0/ChromeOS-recovery-R58-9334.21.0-snappy.tar.xz i ran the mksquashfs command by hand (it's the one that lives in the cros-signing repo), and indeed, it produces a larger file. this is the one from the recovery image: -rw-r--r-- 1 root root 484360192 Mar 25 06:55 /tmp/tmp.JwI0GU51sv/opt/google/containers/android/system.raw.img and here's the one i ran by hand: # /cros/signer/signingtools-bin/mksquashfs /tmp/tmp.d7wRZxU4jO/mnt /tmp/system.raw.img -no-progress -comp lzo -noappend -rw-r--r-- 1 root root 525737984 Mar 25 22:51 /tmp/system.raw.img it's because we use lzo but the original is using gzip. and we no longer have the space for an lzo image.
,
Mar 27 2017
comment#1 I don't have code access right now but which part of the script are you referring to? For N images, we should always use gzip.
,
Mar 27 2017
In project-cheets-private, there is get_squashfs_compression_method_for_android in board_specific_setup.sh that always return lzo when we USE nyc container.
,
Mar 27 2017
reading the commit message, it seems like the code is inverted from the intention ? https://chrome-internal-review.googlesource.com/306697
,
Mar 27 2017
So the problem is our sign_android_image.sh is not synced with board_specific_setup.sh :( I'll make the change to add some comments, since they run in different phases.
,
Mar 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/cfbc083efed99bf4edb53013bc5ab7583278691b commit cfbc083efed99bf4edb53013bc5ab7583278691b Author: Victor Hsieh <victorhsieh@chromium.org> Date: Wed Mar 29 00:16:52 2017 Preserve compress method when re-sign Android image TEST=sign_android_image.sh rootfs /path/to/tests/devkeys/android # unsquash -s still shows gzip (previous script always use lzo) BUG= chromium:705247 BRANCH=none Change-Id: If95686d293123a069ce36bc53cbea3a08aa3e7ab Reviewed-on: https://chromium-review.googlesource.com/461205 Commit-Ready: Victor Hsieh <victorhsieh@chromium.org> Tested-by: Victor Hsieh <victorhsieh@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/cfbc083efed99bf4edb53013bc5ab7583278691b/scripts/image_signing/sign_android_image.sh
,
Mar 29 2017
,
Mar 29 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chromeos/cros-signing/+/e0a3f2dd8feef826d45f3fdabfafabe1df35b628 commit e0a3f2dd8feef826d45f3fdabfafabe1df35b628 Author: Victor Hsieh <victorhsieh@chromium.org> Date: Wed Mar 29 21:43:02 2017
,
Mar 29 2017
,
Mar 30 2017
Victor, don't we need this for the m58 branch?
,
Mar 30 2017
Thanks. I missed it and now cherry-picking.
,
Mar 30 2017
Actually, I checked caroline 9334.28.0 mp image, and system.raw.img is indeed compressed by gzip. So the change should not limited to ToT but also applies to all branches.
,
Mar 30 2017
the signers run only on ToT, and they sign all branches. so should be fine here.
,
May 30 2017
,
Aug 1 2017
,
Jan 22 2018
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by victorhsieh@chromium.org
, Mar 27 2017