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
The content of autotest.py is copied into autotest and I am leaving autotest.py inside the CL for now since its much easier to review the diff.
After got LGTM, I will git rm autotest.py and only submit autotest.
Review URL: http://codereview.chromium.org/1584013
That way we can directly build an image onto a usb stick/sd card without a separate step.
Also, add mounting of /sys into the chroot that is needed by build_gpt on a block device.
Review URL: http://codereview.chromium.org/1521012
Fully automated test that uses vmplayer to test updating from
dev-channel -> image-under-test -> rollback to dev-channel.
Also, change to vmware image generation so that vmware images are
generated with two 1-GiB sized root partitions
Review URL: http://codereview.chromium.org/1512001
Remove the temporary rootfs.image file and others that are left by build_image and related scripts. Also added tool to emit scripts that can pack and unpack the combined disk image.
Review URL: http://codereview.chromium.org/1567013
A new command line script was introduced in this CL named autotest, which is intend to replace both build_autotest.sh and run_remote_tests.sh in the future.
This change list should be reviewed with
http://codereview.chromium.org/1513006http://codereview.chromium.org/1595001
all together.
autotest --board x86-generic --build=all will build all client tests.
autotest --board x86-generic --build=unioxbench,ltp will build enlisted client tests.
autotest --board x86-generic -c client/tests/sleeptest/control -m 12.34.56.78 ...
will invoke autoserv inside emerge-x86-generic cross-compiling env, and do a prebuild of the client test before it got pushed onto client host.
you could also:
1. bash complete the directory/file name from autotest directory after -c or -s args.
2. supply any autoserv commandline args transparently.
Note: replace build_autotest.sh/run_remotes_test.sh is only a future plan. When all the three CLs got pushed, no existing use cases should be broken.
I need to change:
1. build_packages script from third_party/chromiumos-overlay/chromeos/scripts/build_packages.
2. add "enable_server_precompile: False " to third_party/autotest/files/global_config.ini
to activate it.
Review URL: http://codereview.chromium.org/1595001
This changes the disk image for both USB keys and hard-drive installs to use
the EFI GUID Partition Tables. This is a prequisite for booting with an EFI
BIOS. This change does not use the EFI Boot protocol; it still boots using
Legacy BIOS. The PMBR contains syslinux' gptmbr.bin, which searches the GPT
for a specified partition's GUID to boot.
I've tested it on my EeePC. The USB image works, chromeos-install works, and
the reimaged hard drive works. I have not yet tested the memento_updater.sh
script, but I wanted to start the review without waiting until it's all perfect.
I will also be refactoring build_gpt.sh and chromeos-install to share common
logic.
It's almost certain that all existing dogfood machines will need to be
reimaged from a USB key. We could probably figure out a way to upgrade
automatically, but not quickly or without risk.
In addition to the GPT formatting, the build_image script has changed to
emit a single usb.bin file. This can be copied directly onto a USB key and
booted. Installation of dev tools needs to happen with build_image, not
image_to_usb. I have not yet looked at the other image_to_* scripts.
Review URL: http://codereview.chromium.org/1100001
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
Make this script's output better formatted. Better describe how
to disambiguate control files when multiple match. Get rid of
the output_file concept since it's not needed. Don't output
a results directory if there's an ambiguity.
Review URL: http://codereview.chromium.org/1090005
It worked when all mod for test script works inside chroot. But not anymore since "df /" now report the host disk space, not the rootfs.
Review URL: http://codereview.chromium.org/1130005
