At some point, mod_image_for_test started using emerge, but when we
call it from image_to_usb, we don't pass a --board flag...we just
assume the user is using the default_board magic file mechanism.
Review URL: http://codereview.chromium.org/2807028
Fix the bug happened to me that the script completed but the data haven't completely been written to disk.
Review URL: http://codereview.chromium.org/2831001
I've updated the CL to remove the space in the "] ;". I'm not sure I understand your "size != 0" comment as if the device is just attached for charging, it won't go through the trouble of becoming a USB storage device. Will chat in person.
Review URL: http://codereview.chromium.org/2269003
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
Talked to kmixter, and we felt that bindmounting the directory in
which the host os creates mount points for automounted external
devices is the cleanest solution to the inside/outside the chroot problem.
By doing this, image_to_usb can be run from inside the chroot without concern.
That means that (as far as I understand) the factory install flow can all be
done inside the chroot, as well as modding images for test and everything else.
Review URL: http://codereview.chromium.org/1991006
Make standalone package for factory install, so it can be overlayed on top of an existing image.
Modify mod_image_for_test to do the overlay.
Review URL: http://codereview.chromium.org/1945004
Dropping caches (writing back all dirty pages to disk and clearing all the caches) is not necessary for factory tests. It can reduce the latency significantly. The scale is about 27s -> 3s, for running 2 empty tests.
Review URL: http://codereview.chromium.org/1780011
Choosing a default device is no good; the user should
tell us where the image should be written.
BUG=none
TEST=wrote an image
Review URL: http://codereview.chromium.org/1730012
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
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
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
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
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 a short term fix for machines that can't boot a kernel from
the root file system of an SDCard.
This issue depends on issue 602027.
Review URL: http://codereview.chromium.org/600074
image_to_usb.sh didn't handle the case where the devices were being
automounted.
build_image.sh didn't handle the case where the version string > ~14
characters.
Review URL: http://chromereview.prom.corp.google.com/1173161
git-svn-id: svn://chrome-svn/chromeos/trunk@108 06c00378-0e64-4dae-be16-12b19f9950a1
USB image:
- have a stateful partition
- use a read-only system partition
Installer:
- copy read-only system partition from USB to hard drive, skip fsck check
- make stateful partition empty
System:
- Change to tolerate empty stateful partition on bootup
- Don't keep so much of /var on stateful partition (var/lib should be in system
image)
Autoupdate:
- Fix a couple checks to allow partitions 3 and 4 to be system partitions
- Fix a misnomer in mk_memento_images.sh
Review URL: http://chromereview.prom.corp.google.com/1175102
git-svn-id: svn://chrome-svn/chromeos/trunk@87 06c00378-0e64-4dae-be16-12b19f9950a1
