This is required to enable running cros_mark_as_stable from outside
the chroot.
BUG=5258
TEST=Successfully ran outside the chroot and pushed a change.
All unit tests continue to pass.
Change-Id: Ibd23ace6326b8453c132c416d6db6e42c8c2c239
Review URL: http://codereview.chromium.org/2884060
Code was changed to add a CR. Fix tests to accomodate.
BUG=5258
TEST=Unittests pass again.
Change-Id: Iacdbffb14d14f60a43883db3ee12b99a5eeb9f65
Review URL: http://codereview.chromium.org/3014045
Currently, cros_mark_as_stable.py does not add a newline after its
CROS_WORKON_COMMIT="" line. This works fine for 9999 ebuilds that have a newline
after the EAPI="" line, but doesn't work for ebuilds that don't do this.
This should fix the preflight queue build.
TEST=Ran cros_mark_as_stable.py on the update engine and verified that the
CROS_WORKON_COMMIT="" line was not joined together with the next line.
BUG=none
Review URL: http://codereview.chromium.org/3036029
I tried to disable parallel_emerge yesterday, but my change didn't work,
so the buildbots are still running into occasional related issues.
Portage has two flags for doing collision protection: collision-protect
and protect-owned. The protect-owned feature is enabled by default and
is quite useful: it checks to make sure that we don't have multiple
packages that own the same file. The collision-protect feature is more
strict, and less useful: it fails if it finds a conflicting file, even
if that file was created by an earlier ebuild that failed to install.
We want to disable collision-protect here because we don't handle
failures during the merge step very well -- we just leave the old
Unfortunately, we haven't quite figure out the best way to handle
these failures in parallel emerge, so for now we disable the flag.
TEST=Created a fake collision, made sure that packages still merge.
BUG=none
Review URL: http://codereview.chromium.org/2825076
* Let's face it: I broke it in the last second when i renamed the function but not
the place where it's being called, and now cros_workon is dead.
modified: lib/cros_workon_common.sh
Review URL: http://codereview.chromium.org/3052025
This will allow replacement of equery which in cros-workon
Also other ebuild-related operations like grouping workon ebuilds with the same repo
* Find for all ebuilds takes almost no time when cached and up to ~2 secs when not
* equery takes ages just to load
TEST=cros_workon_ebuilds before and after, and diff:
--- list1 2010-07-27 21:22:23.000000000 -0700
+++ list2 2010-07-27 21:22:32.000000000 -0700
@@ -1,6 +1,5 @@
app-crypt/tpm-emulator
app-crypt/trousers
-app-i18n/ibus
app-i18n/ibus-chewing
app-i18n/ibus-hangul
app-i18n/ibus-m17n
(ibus is a mistake, not a workon package, i'll fix that in a separate CL)
modified: lib/cros_workon_common.sh
Review URL: http://codereview.chromium.org/2808072
collision-protect doesn't make sense for parallel_emerge, because
we don't lock around merges. Also, if merge fails part-way through,
it's strange to fail just because some files are lying around.
This fixes an issue with the buildbots.
TEST=Checked that collision-protect feature gets deleted by this.
BUG=none
Review URL: http://codereview.chromium.org/3061029
The fast build is stable enough now that we can enable it for everybody.
I ran the build constantly all weekend on two machines and I only ran into
one (rare) error, which I've fixed in a separate patch.
See <http://codereview.chromium.org/2856048/show>
TEST=Ran lots and lots of fast builds
BUG=none
Review URL: http://codereview.chromium.org/3059001
BUG=chromium-os:1888
TEST=Manual. build_image should run fine when oem_customization flag is not specified.
Review URL: http://codereview.chromium.org/3076009
BUG=4828
TEST=make sure factory image actually builds while chrome ui autotests are included in the build
Review URL: http://codereview.chromium.org/3010035
The DBs are named in the format of qualified_components_${BOARD}_${HWQUALID}.
If only one hwqual id for the board, named in qualified_components_${BOARD}.
Review URL: http://codereview.chromium.org/3038026
* This script should replace the call to ebuild in autotest wrapper, and essentially
duplicates all the test running functions from autotest-0.0.1.ebuild
* duplicate autotest wrapper into autotest_workon to separate conversion and old functionality
* Add a hack into run_remote_tests to allow using autotest_workon instead
new file: autotest_run.sh
new file: autotest_workon
modified: run_remote_tests.sh
Review URL: http://codereview.chromium.org/2854062
The last changes to the installer broke image_to_vm. Since image_to_vm
doesn't need to run postinst, but just change the active image, it
now just calls chromeos-setimage and passes in its needed flags (already
supported by the last installer change). It will also detect whether
the image was built with verification of the rootfs enabled or not
by looking at the default.cfg file.
Also updates the location of where you should run the command in
build_image.
TEST=built a new image with --enable_rootfs_verification and started with qemu -curses -hda [output]; did the same without verification
BUG=chromium-os:2963
Review URL: http://codereview.chromium.org/3034030
Change-Id: I265d6ad8971f9427b78cc07d784fced9cceb5974
With the newest Chrome OS BIOS and bootstub, this will be expanded to the
booted kernel partition's UniqueGuid, so that the kernel device can be
determined with certainty, since the BIOS and kernel may enumerate drives
differently.
You can identify the booted kernel partition at runtime with something like
this:
sudo cgpt find -1 -u \
$(cat /proc/cmdline | sed 's/.*kern_guid=\([0-9a-f-]\+\).*/\1/')
Review URL: http://codereview.chromium.org/3035020
TEST=Ran using default option and then tried -t chromiumorg/master and
saw a correct failure since I don't have that branch to track against.
Review URL: http://codereview.chromium.org/3032019
I'd be OK just setting the defaults in the original command as well.
BUG=4246
TEST=ran it and image booted in normal mode.
Review URL: http://codereview.chromium.org/3008021
This change can land once the kernel support for dm device waiting and
the chromeos-installer changes land and their ebuilds are rev'd.
TEST=build_image --enable_rootfs_verification; booted to a verified image!
BUG=chromium-os:2963
Change-Id: Ia68f90a59ab1360da01d5f422c16178af16cbaeb
Review URL: http://codereview.chromium.org/3013028
mod_image_for_test.sh now passes the target architecture to the subscripts
mod_for_test_scripts/710enableAuthTesting generates the /etc/fake_root_cert
databases by running nsscertutil under QEMU.
BUG=3310
TEST=Built autotest enabled images for x86 and arm. On arm, the browser no
longer crashes trying to read the fake root certs.
Review URL: http://codereview.chromium.org/2878033
A file name changed which breaks the factory test phase on the builders.
This change was LGTM'd but not submitted.
Patch from Tom Wai-Hong Tam <waihong@chromium.org>.
Change-Id: I961515ba4667891d82833035f2d312a653f746fd
Our package graph is cyclic, so parallel_emerge needs to handle cycles
correctly in all cases. PrebuiltsReady should only need to check each package
once, so we should set cache[pkg] to True if we found the package in the cache.
TEST=Ran build_packages --fast
BUG=none
Review URL: http://codereview.chromium.org/3047009
Instead of resizing the loop device after adding padding for the
hash tree data. Just ensure that the mkfs.ext3 call doesn't exceed
the rootfs size.
TEST=reran build_image on my lucid machine and checked the rootfs size; asked someone with hardy machine to test.
BUG=none
Change-Id: I59f95e1d17e35aca265bd44bb863da6069c05bd2
Review URL: http://codereview.chromium.org/3048009
This change adds
- --rootfs_hash_pad to specify the MBs reserved for the pad
- the implementation of the above flag
- check if total fs size + pad size exceeds the partition size
- hash appending in make_image_bootable()
Fixes:
- a style for ROOT_FS_HASH usage
- bad mount|grep
- bad bash subst for root devices in all boot paths
- fixed a typo in the update_bootloaders table creation
- disables verified usb for now
Adding the padding argument ensures that the generated hash tree for the root filesystem is appended to the image. Assuming the rootfs is _never_ mounted read-write
again, that hash tree will be valid and vboot will be able to proceed.
BUG=chromium-os:2693
TEST=manual build_image
Review URL: http://codereview.chromium.org/3043011
Change-Id: I67d9b0f91cacdefa309c0cc2dd7fed1d2eddd7a7
Added the flags required for mounted images to the postinst call.
Scripts no longer need to fixup postinst hence that code is removed.
Review URL: http://codereview.chromium.org/3027012
Instead of loosely wrapping emerge, parallel_emerge now integrates tightly with emerge. This boosts performance while allowing us to map dependencies more accurately.
With this change, build_image --fast can clock under 4 minutes, and build_packages --fast now clocks as low as 4:30. With the --rebuild option, build_packages takes 5:30, but it has the big benefit of producing actually-correct results.
Note that this change also depends on us updating the various build scripts to prefix
calls to parallel_emerge with sudo -E.
TEST=Ran several parallel_emerge test cases, build_packages --fast, and
build_image --fast
BUG=none
Review URL: http://codereview.chromium.org/2891013
Added --fast option. Updated the one place that wasn't using sudo when calling
emerge to use sudo like the others. This is safe because we're merging with
--usepkgonly.
TEST=Ran mod_image_for_test.sh with and without the --fast options
BUG=none
Review URL: http://codereview.chromium.org/2834055
The "[[ ... ]]" syntax is bash-specific. Reflect this by changing shbang to "#!/bin/bash". Many of our dev systems symlink "/bin/sh" to "/bin/bash" which has masked this problem for a long time, but "real" sh fails on "[[".
BUG=none
TEST=rerun
Review URL: http://codereview.chromium.org/2825050
