Recently, a gcc-4.4.6 has been unmasked in the host, but no effort
has been made to make sure the developers select it with gcc-config.
BUG=chromium-os:19613
TEST=ran the tests below with set -x and observed
1) manually set the MINIMUM version to 4.4.7, see it fail
2) two gccs, current + old, set to old, observed the switch and unmerge
3) above, but set to new, same result
4) only one gcc, the current, observed nothing happening
5) only have old gcc, let the script update&select new one, unmerge old
Change-Id: Id2a285a13f5b27d7531eae4db35e36f6b8cc5f4f
Reviewed-on: http://gerrit.chromium.org/gerrit/6694
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Zdenek Behan <zbehan@chromium.org>
BUG=chromium-os:19868
TEST=build_image --factory # see output as chromiumos_factory_image.bin
build_image --test # see output as chromiumos_test_image.bin
Change-Id: Ice1aa576cfe297db0900e6c42de8d362aa94729a
Reviewed-on: http://gerrit.chromium.org/gerrit/6993
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
The current code will silence stderr when operating in non-verbose mode
because it always turns on shell tracing with `set -x`. Unfortunately,
this also ends up killing error messages from a bunch of places in the
script as well:
- look for all the "1>&2" uses in mod_image_for_recovery.sh
- look at missing error() override
- look at duplication of die() just to undo things
A really simple example:
$ ./mod_image_for_recovery.sh
$
Did it work? Or did I do something wrong? Who knows!
So undo the stderr silencing and simply turn on `set -x` only when
requested (verbose mode).
BUG=None
TEST=forced some errors in non-verbose mode and saw no output before change, but saw it after change; made a working recovery image
Change-Id: I31578fba091e390a56a437af97782a621e2137fb
Reviewed-on: http://gerrit.chromium.org/gerrit/6904
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
BUG=chromium-os:19854
TEST=Ran it
STATUS=Verified
Change-Id: I2fd7d77145e3607c29cfc64500fca8525e9b5992
Reviewed-on: http://gerrit.chromium.org/gerrit/6939
Reviewed-by: Kris Rambish <krisr@chromium.org>
Tested-by: Kris Rambish <krisr@chromium.org>
Reviewed-by: Stanley Wong <stanleyw@chromium.org>
Tested-by: Stanley Wong <stanleyw@chromium.org>
BUG=None
TEST=run the commands in various combinations.
Change-Id: I94fb167d8312a90818910085adebfb1d0396cdbe
Reviewed-on: http://gerrit.chromium.org/gerrit/6866
Reviewed-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: Vince Laviano <vlaviano@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
The process of updating the Portage package status spreadsheet on
buildbots requires a credentials file at ~/.gdata_cred.txt in the
chroot. All buildbot VMs have this file outside the chroot now,
so this change adds that file to the list of things created in
the user's homedir when entering the chroot.
BUG=None
TEST=Run cros_sdk in these scenarios:
~/.gdata_cred.txt exists -> Same file should be at $HOME in chroot
~/.gdata_cred.txt does not exist -> No file created in chroot
Change-Id: I5c0f333a9308f5efa5324ce2e202a7c9e9fdb48b
Reviewed-on: http://gerrit.chromium.org/gerrit/6911
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Tested-by: Matt Tennant <mtennant@chromium.org>
test wi-fi devices.
in http://gerrit.chromium.org/gerrit/6405, we introduced support
for running some WiFi autotests in a VM (running a test image).
for those tests to work, the connection manager must not attempt
to manage the devices used by the APs.
this change adds a mod_for_test script that updates flimflam's
init script, adding command-line arguments that tell flimflam
to ignore the AP devices.
BUG=chromium-os:16348
TEST=manual: built test image, checked flimflam args in /etc/init/flimflam.conf
Change-Id: I7a26d817e78f5743e2922a35c20ad6bee139445d
Reviewed-on: http://gerrit.chromium.org/gerrit/6443
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
This give users the choice to have rootfs formatted with squashfs.
When --squash_image is specified, the rootfs will be formatted to squashfs.
Users can also use --squash_sort_file to specify the file priority when
squashfs is created.
BUG=None
TEST=Manually tested "--squash_image", and the image can be installed
from USB stick. Also tried "--squash_sort_file=sort-prio.list", and files
in squashfs are sorted.
Change-Id: I5fd818ac9d1203598926efa82e94fa105cd86ebc
Reviewed-on: http://gerrit.chromium.org/gerrit/5664
Tested-by: Da Zheng <zhengda@chromium.org>
Reviewed-by: Da Zheng <zhengda@chromium.org>
This fixes a problem with chroots named other than 'chroot', but only
when running inside the chroot.
BUG=chromium-os:19596
TEST=run it inside the chroot
Change-Id: I9532fe7762e2d7e277305fb948e5cabc242a5213
Reviewed-on: http://gerrit.chromium.org/gerrit/6597
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
The functions are shared between build_image and mod_image_for_test.sh.
BUG=None
TEST=build_image
Change-Id: Ib6d860a6818abee380dde97460f57943cc0a070c
Reviewed-on: http://gerrit.chromium.org/gerrit/6444
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
BUG=chromium-os:19210
TEST=Run a few dozen cbuildbot runs.
Change-Id: I276f23135bfe1dfc95575ffd15507cce6fb2461c
Reviewed-on: http://gerrit.chromium.org/gerrit/6383
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: David James <davidjames@chromium.org>
The --hwid and --firmware should be assigned with real files by default.
BUG=chromium-os:16751
TEST=./make_factory_package.sh --release RELEASE --factory FACTORY # see error
./make_factory_package.sh --help # see hints to 'none'
./make_factory_package.sh --release RELEASE --factory FACTORY \
--hwid HWID --firmware FIRMWARE # see mini-omaha configured correctly
Change-Id: Ib797cd66e864bd2105622c989b4b03443f361a69
Reviewed-on: http://gerrit.chromium.org/gerrit/6461
Reviewed-by: Tammo Spalink <tammo@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
BUG=None
TEST=run cros_sdk
Change-Id: I39fafd58c7cc9fd536fe9b75f314f9970766a483
Reviewed-on: http://gerrit.chromium.org/gerrit/6414
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
* This CL deprecates the use of enter_chroot and make_chroot completely,
leaving the functionality exposed only through cros_sdk.
BUG=chromium-os:18750
TEST=run them
Change-Id: I864960b4e25245341431c3a3950638fa569820ed
Reviewed-on: http://gerrit.chromium.org/gerrit/6358
Reviewed-by: Anush Elangovan <anush@chromium.org>
Tested-by: Zdenek Behan <zbehan@chromium.org>
"cros_sdk" is a drop-in replacement of enter_chroot.sh. The only
important difference is in the calling path, specifically that
cros_sdk is in path but has to be called from $(pwd) being inside the
repo checkout, while enter_chroot.sh is called by explicit path.
Invariably, "./enter_chroot.sh" can be replaced, as pwd=src/scripts.
Calling by absolute path can be replaced by first changing directory
anywhere into the repo checkout, and then calling cros_sdk.
BUG=chromium-os:18750
TEST=run them
Change-Id: Ieff91a27bb419e1121361d5b3a11e4c87ff7a087
Reviewed-on: http://gerrit.chromium.org/gerrit/6273
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
The script created etc/enable_chromium_minidumps in the
stateful partition; however that file isn't on the whitelist
of stateful files that chromeos-install will install on dev
and test images.
BUG=None
TEST=install test image from USB with and without the change; observe the file is absent in both cases
Change-Id: I841cf9ed4c819a9f18cbdd11a3d42af196ab87bb
Reviewed-on: http://gerrit.chromium.org/gerrit/6354
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Chris Masone <cmasone@chromium.org>
This CL adds a new option to mod_image_for_recovery that allows a dev to pass
in another recovery image as an option and have mod_image_for_recovery use
the kernel provided in that image when building a new recovery image.
BUG=chromium-os:19189
TEST=Built using option on image signed with non-dev keys using appropriate
recovery image as base.
Change-Id: I02a3c3bf458fb3c9fee556364005d7eaff5acccc
Reviewed-on: http://gerrit.chromium.org/gerrit/6031
Tested-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
The buildbot code forces the en_US.UTF8 locale itself, and does so inside
of the chroot, so our auto-detection code doesn't catch it. Always create
these locales that the buildbot uses.
BUG=None
TEST=cleared out locales, emptied out active locale env vars, ran enter_chroot, saw that en_US{,UTF8} were created
Change-Id: I9ad65007a340333e19743985c9cbeea9403823fa
Reviewed-on: http://gerrit.chromium.org/gerrit/6168
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Whenever perl is upgraded, it is a good idea to clean out any old
modules and recompile them. This check ensures that perl-cleaner is run
once and only once after each major perl upgrade.
BUG=chromium-os:19244
TEST=Run preflight queue with perl upgrade and old sdk. Verify that old
perl modules are removed in the first run. Verify perl-cleaner is
not run again in subsequent runs. Run sdk builder and confirm sdk
builder runs perl-cleaner every time since it starts with an old
version of perl.
Change-Id: Ib14f9d73122d5ff2c7a23afc3f56905e30ff2cbc
Reviewed-on: http://gerrit.chromium.org/gerrit/6149
Reviewed-by: Anush Elangovan <anush@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Since we no longer force LC_ALL=C on everyone, the few times that perl
does get run by people, it spews the expected "Setting locale failed"
warnings. This isn't as big a deal as with Debian systems as perl usage
is uncommon in Gentoo.
This is also highlights the long-existing small issue of only specific
locales being available in the chroot. So for non US english speaking
users, they've been having non-optimal experiences.
So parse the user's active locale and automatically generate the missing
ones in the chroot so that when they do enter, things "just work".
BUG=chromium-os:19139
TEST=set locale to non-existent ones, enter_chroot, & verify locales are created
Change-Id: I43f809a1ee1472e4797edab0f32cecf582ea8b48
Reviewed-on: http://gerrit.chromium.org/gerrit/5986
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
This CL makes --usbimg (RMA shim mode) supporting recovery image as --release
image source, by creating a temporary disk image.
BUG=chromium-os:15050
TEST=./make_factory_package.sh ... --release RECOVERY_IMAGE --usbimg rma.bin
Change-Id: I5295053ac204869616fc82e2c7a514506082426f
Reviewed-on: http://gerrit.chromium.org/gerrit/5982
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
In order to support building arbitrary image, the partition copying scripts has
been changed to support "copying partitions in same size" and "overwriting
partitions in different size", and "copying partition from external file".
We need these APIs to create disk/usb image with release images that is using
partition with different size (ex, recovery images).
Image copying buffer selection and disk image creation time are also improved.
BUG=chromium-os:15050
TEST=./make_factory_package.sh ... --diskimg preimage.bin
./make_factory_package.sh ... --usbimg rma.bin
./make_factory_package.sh ... # omaha mode
Change-Id: I6a4c820abf59e780985c95dc35f9340b347bd952
Reviewed-on: http://gerrit.chromium.org/gerrit/5981
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The release image parameter must be an image signed for SSD booting. This CL
adds detection code and allows on-the-fly conversion from recovery to SSD image.
BUG=chromium-os:15050
TEST=./make_factory_package --release RECOVERY --factory FACTORY # success
# Seeing: INFO : Image type is [recovery]:...
./make_factory_package --release USB --factory FACTORY # success
# Seeing: Image type is [usb]:...
./make_factory_package --release SSD --factory FACTORY # success
# Seeing: Image type is [ssd]:...
./make_factory_package --release GARBAGE --factory FACTORY # failure
# Seeing: Image type is [invalid]:...
./make_factory_package --release GARBAGE --factory FACTORY --nodetect_release_image # success
# No image type messages
Change-Id: I8530b3f58574a4298b4d6d904a12bb92636c7365
Reviewed-on: http://gerrit.chromium.org/gerrit/5965
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
To resize an image, there's no need to use a loop device. We can just operate
on the image directly. This is simpler and avoids doing a sync which can
noticeably delay the build.
BUG=chromium-os:19150
TEST=Run image_to_vm.sh --board=x86-mario
Change-Id: Idbfc99cee9fd890aaad6379fbde511b273cc1d41
Reviewed-on: http://gerrit.chromium.org/gerrit/6036
Reviewed-by: Anush Elangovan <anush@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Renamed the fuction from "test_image" to "test_image_content";
renamed the source file to match.
BUG=None
TEST=build both x86 and arm images
Change-Id: I158f2c5bc0f2fc260d48bd125a1899e6a21d7b79
Reviewed-on: http://gerrit.chromium.org/gerrit/5821
Reviewed-by: Vince Laviano <vlaviano@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Calling sync in build scripts pauses the build unnecessarily, particularly
when other steps are running in parallel.
BUG=chromium-os:19150
TEST=Run cbuildbot release build and watch faster performance.
Change-Id: Ia2469e3be68fdd38474ab4e6f67b06339c04822f
Reviewed-on: http://gerrit.chromium.org/gerrit/5966
Reviewed-by: Thieu Le <thieule@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: <taysom@google.com>
Tested-by: David James <davidjames@chromium.org>
This is part of clean-up in factory related scripts.
Calling mk_memento_images does not need sudo, and some pushd can be removed
because most operations take full path now.
BUG=chromium-os:15050
TEST=./make_factory_package --release RECOVERY --factory FACTORY
Change-Id: I323c9abbc4a98b22736c755669f8ecd18b05cfd5
Reviewed-on: http://gerrit.chromium.org/gerrit/5964
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
When there're more and more advanced features landed into make_factory_package,
supporting the "unpacked mode" (use unpack_partition.sh to extract all
partitions) becomes a problem.
cgpt is mandatory in chroot, and parted is installed by default for most Linux
distributions, so I think it may be safe now to force using partition tools,
which is also more robust than unpack_partition.
BUG=chromium-os:15050
TEST=./make_factory_package --release RECOVERY --factory FACTORY
Change-Id: I865aebdf3ce2cbd21b0fe22fdce8612810ee78f7
Reviewed-on: http://gerrit.chromium.org/gerrit/5963
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
When we want to separate kernel and rootfs, there must be a more flexible syntax
to assign input source.
The partition info parsing code is also improved to detect errors.
BUG=chromium-os:15050
TEST=./make_factory_package --release RECOVERY --factory FACTORY
Change-Id: Ie74b3e23117480a7f503488b39dedceadbfb41e3
Reviewed-on: http://gerrit.chromium.org/gerrit/5962
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
* Removed boilerplate, simplified search code.
* Fixed one too long line
This will unfortunately kill all outstanding CLs into enter_chroot.
BUG=chromium-os:18750
TEST=run it
Change-Id: I39c45fa8163d92487b512e7e8d298ce9231f4bd2
Reviewed-on: http://gerrit.chromium.org/gerrit/5830
Tested-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: Anush Elangovan <anush@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
The main benefit of this change is that it is no longer necessary to specify
custom use flags to build_image because it just merges what you already have
installed in your buildroot. It does not second guess the packages you already
have installed and just installs them, as it should.
1. Packages in the developer image should already be up to date, so there
is no need to specify '-u' for --update or '-D' for --deep.
2. The developer image should have identical use flags to the base image,
so there is no need to specify -N for '--newuse'.
3. The --verbose flag is generally useful, so I've updated all emerges to
use them so you can see what the use flags are used for the emerges.
BUG=chromium-os:19078
TEST=Verify build_image builds same image and installs same packages
with and without change. Verified specifying USE= is not necessary
if a few dev packages were customized.
Change-Id: I4c205c961cca84ca3161b49f59cdd37a5a4ed5b1
Reviewed-on: http://gerrit.chromium.org/gerrit/5816
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Much of this file quotes paths which could possibly contain breaking
chars (e.g. spaces), but a few are missed. In general, this probably
doesn't break as no one is adventurous enough to use spaces, but might
as well do it for the fun of it. And to be consistent. One of those.
BUG=None
TEST=ran make_chroot/enter_chroot/build_packages; seemed to be OK
Change-Id: Ic64d60790f50bb812c87a4672e2a24fafbccd749
Reviewed-on: http://gerrit.chromium.org/gerrit/5759
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
If test image is present already, mod_image_for_test should
succeed, even if the input image is missing.
BUG=chromium-os:19087
TEST=Run x86-mario-release builder and verify it works now.
Change-Id: If9729328120c7bbd9c1fffca26d6b1cddf2e980e
Reviewed-on: http://gerrit.chromium.org/gerrit/5831
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
If you trace any script with `set -x` enabled, bash will dump the color
variables and all of your output will be colored. So move the "reset"
color to last so that the bleeding is localized to a few lines rather
than a few hundred. There should be no functional difference.
BUG=None
TEST=ran setup_board with and w/out -x to create x86-generic to check result
Change-Id: I1e598cc4a38e9f217f2f670a00bd676bf70c2338
Reviewed-on: http://gerrit.chromium.org/gerrit/5804
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
The source of this LANG=C seems to date back to when apt was used as
the package manager [1]. It was further migrated to enter_chroot to
keep noise in the logs buildbot down to a minimal [2]. I've seen the
excess spam apt can spew in a default deb chroot when the active env
locale is not available (in reality it is perl that complains) because
the locale data has not yet been generated.
None of this should apply to Gentoo though as we don't execute perl
anywhere during the build. So hopefully we can simply drop this now
as an artifact of days gone by.
The reason for not hardcoding this in the first place is that it can
easily wreck havoc when the host locale is multibyte (e.g. en_US.UTF8)
but the chroot is forced to narrow (e.g. C). Attempts to use multibyte
chars will usually render correctly, but the apps in the chroot will
just get immensely confused as they will be using narrow functions to
process input.
[1] the code says "Warn less when apt-get installing packqages"
[2] http://codereview.chromium.org/521053
BUG=None
TEST=entered chroot and saw LANG preserved from host env, and ran cbuildbot
Change-Id: I0490b992d5e2d7bfba945f787e65a59943b8d35c
Reviewed-on: http://gerrit.chromium.org/gerrit/5767
Reviewed-by: Anush Elangovan <anush@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
BUG=chromium-os:14127,chromium-os:17184
TEST=Adhoc
Build a regular image (for Alex) and boot it on a Dogfood machine (which uses
legacy boot). Check dmesg for PARTUUID. Unpack partitions, mount partition 12,
and check for root=PARTUUID= in /efi/grub/grub.cfg (it should be there instead
of root=/dev/$linuxpart).
Change-Id: Ie403632f227d514a5876f8338afa4ad80708ed55
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5668
Reviewed-by: Will Drewry <wad@chromium.org>
Both the tests and archive_build read and write the latest symlink.
This CL fixes a race condition in archive_build by moving away from
using the latest symlink in archive_build.
BUG=chromium-os:18967
TEST=Run release cbuildbot archive_build on x86-mario-release.
Verify it completes successfully and that latest symlink
is unchanged now.
Change-Id: Ia32d20903f3ef74e360944fbabdd9834c0edb99a
Reviewed-on: http://gerrit.chromium.org/gerrit/5746
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
This script is short and should run on any Ubuntu system, outside the
chroot. This will help testers and release-engineers see the checksums
that .bin files contain.
BUG=chromium-os:18940
TEST=manually ran outside chroot
Change-Id: Ib742f946d0724c57d67e7bd1236f4a490d996313
Reviewed-on: http://gerrit.chromium.org/gerrit/5613
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
BUG=None
TEST=build regular, test, and recovery images
Change-Id: I2d7d073c27d14fb88be6a63953dcc77fc76a0807
Reviewed-on: http://gerrit.chromium.org/gerrit/5512
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
This command was failing before (and the error getting swamped in log output)
resulting in a later command auto-creating the database and failing to
set the trust settings of the fake SSL cert we use in tests correctly.
BUG=chrome-os-partner:4923
TEST=build arm-generic test image, see that there are no error messages after "Generating a 1024 bit RSA private key" in the output log
Change-Id: I5b0c05d90e528aa5047cb12aa338cef176d233aa
Reviewed-on: http://gerrit.chromium.org/gerrit/5519
Reviewed-by: Chris Masone <cmasone@chromium.org>
Tested-by: Chris Masone <cmasone@chromium.org>