into mod_image_for_test.sh rather than slightly different versions
of the same in image_to_usb.sh and image_to_vm.sh
Added a function to get a test image into common.sh
Added --inplace option to mod_image_for_test, which is the default,
and preserves the original behaviour. But using --noinplace it will
now do the copy for you.
Found that chromiumos_image.bin appears throughout the scripts, so added it and the test variant to common.sh
BUG=chromiumos-10126
TEST=run mod_image_for_test.sh with and without --noinplace
run image_to_usb.sh and image_to_vm.sh with both options
test on Seaboard that correct image is provided
Really we should have automated testing for these scripts
Change-Id: I5cfa91792c7fded35e7f4ca8f8f27c6b270817fb
Review URL: http://codereview.chromium.org/5271010
BUG=chromium-os:9877
TEST=ran bin/cros_workon_now, cros_workon, set_shared_user_password
Note---this introduces another bashism to common.sh. However, despite
comments to the contrary, common.sh does not actually parse under dash
without this change
Change-Id: I1e6b9751afa8341c100f3b8e0b96284835a53d17
Review URL: http://codereview.chromium.org/5444002
The --fast support for build_packages is stable now, and should significantly
improve the speed of our official builders. We should turn it on so that
builders can finish their builds in less than 8 hours.
BUG=chromium-os:6706
TEST=Run ./enter_chroot.sh --official_build and verify that --fast is on by
default now
Change-Id: I6ad126b9b6ce16ffc9887a7af22c2e3f85afbf42
Review URL: http://codereview.chromium.org/3418001
Change-Id: Ifc47ed28dc3efc0e7ebd018f6703b36913ffd39c
BUG=8716
TEST=Ran the script inside the chroot to makesure it is generating the package.
Review URL: http://codereview.chromium.org/4425004
BUG=8544
TEST=build image with --factory_install, ensure that image does not have data in /usr/local/autotest-pkgs
Change-Id: I5ed17d794392ec654bc122fa15f7ab8a7abbba2d
Review URL: http://codereview.chromium.org/4756001
2. Source shflags, if they are in the current directory
Change-Id: Id22e597a6fb71905f2d0ca5c4a1d94ce5a8a931f
Review URL: http://codereview.chromium.org/4177005
echo -ne isn't portable but printf with octals is so this
makes the switch.
In addition, the current offset is off by 3 and is updating the UUID space.
This was from style cleanup and all functional test passed - of course.
This change fixes that too.
TEST=built and installed and checked ro enforcement works
BUG=chromium-os:7972
Change-Id: Ifb3cb2c6f3219af819baff5750453439e1ba6edf
Review URL: http://codereview.chromium.org/3997001
This change makes more of the root filesyste metadata static across builds, but
more can be done there. It also changes the root filesystem to use ext2 as
we don't need journaling in normal mode. Optionally we could use ext3 for
non-verified if desired (it's an easy change).
In particular, this change cleans up the following:
- clears the rootfs uuid
- labels it C-ROOT (instead of C-KEYFOB)
- removes reserved inodes and blocks
The major feature of this change, however, is that it adds two simple
helpers to common.sh: disable_rw_mount and enable_rw_mount. They will
set high order byte (le) in the ro compat field to be 0xff. This will
tell the kernel that the filesystem uses features R24-R31 which are safe
for use on the running kernel iff the filesystem is mounted read-only.
These functions are called in cros_make_image_bootable and
mount_gpt_image, respectively. mount_gpt_image will always
enable_rw_mount and cros_make_image_bootable will disable_rw_mount if
--enable_rootfs_verification is true.
The approach is ugly but reasonably well contained. If ext2 ever gets a
new revision and new features in the same range are introduced, then we
would be getting inconsistent behavior. That said, it is unlikely that
that churmn will happen and if the impact is negative, it will ideally
show up during testing.
N.B., this will likely result in changes needing to be made to the
signing scripts in vboot_reference to ensure that rw mounting is
enabled/disabled in the same way (E.g., during stamping).
BUG=chromium-os:7468
TEST=- built x86-generic, imaged to usb stick, attempted to mount rw /dev/sdc3 on the host and was properly bounced.
- booted to the image just fine on a dogfood device.
- mod'd for recovery, then installed and booted.
- mod_image_for_test runs with no errors; booted the resulting image as well
- booted a factory_install with the pending dm changes
- BVT passed with build_image x86-generic (vboot enabled)
- [in progress] autotest that checks if the rootdev = /dev/dm-0 and
then does a dumpe2fs | grep -q FEATURE_R31
Review URL: http://codereview.chromium.org/3916002
Change-Id: If4dcba7568a110f4e32627c916d9e5741e5e5414
This function is now called by enter_chroot.sh. A separate change
will call the function from make_chroot
Change-Id: I4fc07c413e56db3e5e7617428f20f2ffc02790d7
BUG=chromium-os:7072
TEST=Took root out of sudoers and ran enter_chroot.sh script; saw that it was re-added.
Review URL: http://codereview.chromium.org/3909001
It's sometimes useful to run a command in chroot and redirect/pipe stdout. Any objections to having enter_chroot send its chatter to stderr?
Review URL: http://codereview.chromium.org/3160024
Autotest installs stuff to the image via ssh, so there's no need to include
all of this stuff to the image. This saves disk space. Note that
/usr/local/autotest-chrome is currently already excluded from the image
because of a hack in the chrome ebuild, and that /usr/local/autotest is
usually also excluded from the image because autotest is not included
as a dependency of any packages that are installed.
In the factory setting, it looks like the factory has its own code for
installing autotests via rsync. Presumbably, if the factory tests are
managing the autotest directly, they won't want emerge mucking with the
directory as well on the image. Currently, emerge doesn't muck with the same
directory, but we probably want to ensure that it doesn't start doing that in
future to ensure sanity.
TEST=Built images. Modded for factory test. Verified that (a) build directory contains autotests, (b) regular images do not contain autotests; and (c) images modified for factory test do contain autotests
Review URL: http://codereview.chromium.org/3124010
BUG=none
TEST=run build_image, happen to finish on a time with less than 10 seconds in it, watch the missing 0-padding
Review URL: http://codereview.chromium.org/3050047
This change checks for and sources shflags from /usr/lib before
depending on the gclient-style path.
TEST=None
BUG=4230
Review URL: http://codereview.chromium.org/3010045
Change-Id: I3085c2356c40c691a2a72bf79c1d9167162d6dca
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
parallel_emerge prints a message every 30 seconds now so that buildbot doesn't
kill us early. Per discussion with cmasone, reverting the revert.
This reverts commit debaa3d8cf.
This reverts commit f0fb864e8d.
This change needs to be reverted because it suppresses logging output
from the build process. Thus, when something goes wrong...the
sherriff is left completely helpless in terms of debugging the issue.
TBR: davidjames@chromium.org
Also update eretry to not pass in $EMERGE_JOBS anymore, in coordination with my previous change, which passed it in directly instead of depending on eretry to do so: http://codereview.chromium.org/2944004/show
TEST=Ran build_image --jobs 2 and build_packages --jobs 2
BUG=none
Review URL: http://codereview.chromium.org/2914004
TEST=Ran unittests with 2 test failures (powerd and update engine).
Will check with authors to fix these before moving the default over
to this.
Review URL: http://codereview.chromium.org/2837004
TEST=Tested with building a new image, looking in the output directory, running
the image and running vi.
Review URL: http://codereview.chromium.org/2075019
I verified that if I whack /usr/lib/debug folder and run build_image, it works fine. This is important since I plan to check in this issue first and then the fix to add debug flags.
Review URL: http://codereview.chromium.org/2113007
Temporary approach to using INSTALL_MASK to suppress some non-relevant paths.
It reduces the size from ~426MB to ~163MB. Eventually, will remove it and
create a clean and separated ebuild for chromeos-factoryinstall.
Review URL: http://codereview.chromium.org/2084001
In addition unifies changes in mount_gpt_image and one-offs in mod_image_for_test
to consolidate gpt / var mounting.
Review URL: http://codereview.chromium.org/2064001
Since we're using upstart, don't let packages drop startup scripts into
/etc/init.d.
BUG=none
TEST=Build image, inspect contents of /etc/init.d (or lack thereof, after this patch)
Review URL: http://codereview.chromium.org/2023006
Add restart_in_chroot_if_needed to common.sh, and modify the build scripts which referred to assert_inside_chroot to use it instead. The effect is that you don't ever have to explicitly enter_chroot.sh to build (still can, it work's fine).
Update mod_image_for_test.sh to use restart_in_chroot_if_needed
Review URL: http://codereview.chromium.org/1736025
The safe_unmount function first tries a regular unmount, If that
fails it warns and tries a lazy unmount. If the lazy unmount fails
it dies.
Both unmounts take the -d option in case the mount is a loop device.
BUG=None
TEST=Entered and exited multiple chroots
Review URL: http://codereview.chromium.org/1593021
and "cat" stuff and pipe it to something that can write to a
file as root. For example:
echo "foo" | sudo_append /tmp/bar
will append "foo" to the file /tmp/bar as root. While
echo "foo" | sudo_clobber /tmp/bar
will truncate /tmp/bar and then write "foo" to the file.
Review URL: http://codereview.chromium.org/1610021
This is necessary for two reasons:
1) It's nice to get an error message when mount/unmount fails
2) set -e mode doesn't have any effect when you're in a subshell
Note that these mount/unmount failures do happen regularly in development,
so folks who depended on mount/umount failing silently will no longer be
able to rely on this and will have to kill the mounts manually.
Also fix subtle bugs in regexes for matching mount paths. (E.g. where the
regex for $HOME/chroot also matches $HOME/chroot2).
TEST=Tested mount/unmount with concurrently open shells.
Tested mount/unmount when mount is being used by a process but the
lock file does not reflect this.
BUG=none
Review URL: http://codereview.chromium.org/1211001
Use our karmic mirror for creating the build chroot, removing the need for
make_local_repo.sh and the repo_list_*.txt files. If a local repo exists
when build_chroot.sh is run it will be used, but it's no longer necessary.
This change does not remove make_local_repo.sh or the repo_list_*.txt files.
Review URL: http://codereview.chromium.org/548083
This change switches to mastering an image without using debootstrap.
We turn on the previously experimental bits that install a small
set of packages manually before handing things over to apt. In both
cases we use apt to download the packages so that it can populate
it's local package cache.
With this change we will no longer depend on the local_repo when
mastering an image. Developers will not have to rebuild their
local repo when repo_list_image.txt changes. Instead we will use
and lazy-fill the local apt-cache. The first time you build_image.sh
it will be slow since it needs to download the packages. Subsequent
runs should be as before since it will use the local cache. If
packages are added they should be lazily fetched in the next image
build.
Until we have a fully populated external mirror, developers will
still have to add packages to repo_list_image.txt. Also, until
make_chroot is switched over to use the external repo then
developers will have to redo their local repo when the
repo_list_dev.txt changes.
Review URL: http://codereview.chromium.org/521073
