Undoes a change from 5c3b457f. Hardcoding "--yes" in the
call to mod_image_for_test.sh instead of inheriting
image_to_usb.sh's "yes" was intentional. The user may not
pass --yes to image_to_usb.sh since they want to confirm
that they're writing to the correct device, but they already
told us that they want the image to be modified for test
with --test_image, so there's no reason to ask about it
again.
BUG=none
TEST=ran it
Review URL: http://codereview.chromium.org/1736005
Migrate only issues that are open or that are already in the
spreadsheet. This way, the spreadsheet doesn't get cluttered w/ closed
tasks.
Review URL: http://codereview.chromium.org/1734001
After discussing with drewry, we can't come up with a better way to inject these root certs. We considered putting them on the stateful partition, but that opens up an avenue of attack (if you can get a root cert into the magic directory, then you can MITM login). Thus, we put it on the rootfs instead. The script that sets up the hashes for vboot will verify that this directory is not present in production images. That work is tracked here: http://code.google.com/p/chromium-os/issues/detail?id=2693
Review URL: http://codereview.chromium.org/1566055
Add feature to mod_image_for_test to patch rootfs.
Change initctl path to get network but no chrome.
./image_to_usb.sh --install_mfg --install_autotest --test_image
which calls ./mod_image_for_test.sh --manuf
Review URL: http://codereview.chromium.org/1542011
As with build_packages, only retries by default if you passed --jobs
even though build_image will indeed spuriously fail with only one job.
sync_build_test now uses jobs=#cores by default for both package and
image building. Eventually will also use this for gclient sync'ing
once that is better vetted.
Review URL: http://codereview.chromium.org/1564035
This can be useful for working with issues in a spreadsheet and making
bulk updates to tracker issues.
See known issues in the file for important known issues.
Review URL: http://codereview.chromium.org/1566037
now we could install to mmcblk0.
for vogue, we even change the uboot environment.
on Samsung, you had to use 'chromeos-install --skip_src_removable' because mmcblk1 is not removable somehow.
Review URL: http://codereview.chromium.org/1618013
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
sosa@'s statefuldev change, which installs all developer packages on
the stateful partition and has put /var there as well, means that we
can no longer just mount the rootfs on a usb stick and emerge packages
onto/off of the removeable device. We now need to mount the stateful
partition as well, and also bindmount from /var on the rootfs to /var
on the stateful partition. All portage state is stored there, among
other things.
Review URL: http://codereview.chromium.org/1644001
No point in asking the user if they're sure they want
to modify the image for testing when they asked us to
modify it for testing in the first place.
BUG=none
TEST=tried it
Review URL: http://codereview.chromium.org/1520031
The old format was: gzip(root filesystem). The new format is:
gzip(kernel parition length + kernel partition + root filesystem). The
length is 8 bytes (uint64 big endian).
This CL fixes the updater and the update generator to support the new
format.
Review URL: http://codereview.chromium.org/1520028
move mkimage to hard-host-depends and remove dependency from u-boot to kernel.
this will make use of mkimage on target possible in the future.
Review URL: http://codereview.chromium.org/1613008
This fixes the loop device leak. The problem is that inside the chroot, we
have /etc/mtab as a symlink to /proc/mounts. That works most of the time,
but if you mount something using "-o loop", it isn't cleaned up correctly
when you umount it. To avoid that, we either have to replace the /etc/mtab
symlink with an empty file when we create the chroot, or we have to make
sure that we never execute a "mount -o loop" command from within the chroot.
If we use an empty /etc/mtab file, the builds work fine, but then we can't
see any mounted partitions that the host creates outside the chroot (such as
USB keys), which causes other problems. Bleah.
Review URL: http://codereview.chromium.org/1594020
Change build_image to support building a factory install image. Also,
a shell script and startup script to run the factory installer.
Change software_update startup script to detect if it's a factory
install and abort if so.
BUG=2378,2379,2380
TEST=Tested factory install worked on device.
Wrapper script to perform factory install at boot.
AU: New arg to install on non-boot device partition. This is used to
install in the factory. Also, switch to shflags for argument parsing.
Review URL: http://codereview.chromium.org/1556022
The EFI System Partition is a special disk partition where EFI BIOS expects
to find the platform-specific bootloader. We need this in order to work on
the BIOS/kernel handoff. It's not needed for the final ChromeOS image and it
isn't useful for legacy BIOS systems, so right now it only makes any difference on x86
devices with development BIOSes.
This change creates the partition for ARM builds as well; it has no effect
there, either.
Review URL: http://codereview.chromium.org/1513019
This is one less thing to change when setting up a Voguev210 and if
we need to change anything later we won't have to reconnect all of
them to debug boards.
BUG=None
TEST=Build and boot a Voguev210 image.
Review URL: http://codereview.chromium.org/1596010
I need a couple extra tools for testing purposes (about 10MB). I'd love to not add space to the rootfs for these. But...talking to sosa, it doesn't seem there's any other way.
Review URL: http://codereview.chromium.org/1576018
For Example:
# run the 32 bit binary located ad ../platform/foo/a.out
$ run_32bit.sh ../platform/foo/a.out
# run a.out from the current directory, and pass it the --verbose=3 command line option
$ ../../scripts/run_32bit.sh -- a.out --verbose=3
# debug a.out from the current directory, include ../v8 in the library search path
$ LIB_PATHS='../v8/' ../../scripts/debug_32bit.sh a.out
run_32bit.sh runs a 32bit executable, debug_32bit.sh starts up gdb so that it's ready to
debug a 32bit target. Both scripts work from in or out of the chroot.
If you're running from outside the chroot, you can pass a --chroot command line option to
locate the chroot, otherwise a default is computed through the normal mechanism.
Pass the 32 bit target as the parameter to either of these scripts. If you need to provide
additional parameters to your command, then you should use -- to signify the end of *_32bit.sh
parameters.
These could be useful to people developing parts of chromeos that can be easily isolated
from the rest of the system. If your code doesn't NEED to run on a chromeos device it
can be a bit easier to try it out on your owm machine during dev/test.
Review URL: http://codereview.chromium.org/1131002
