This is useful for debugging, e.g. --to /dev/null. The user will have to
use --force_non_usb to allow this, in which case all bets are off and we
should let her do this. Also note that, before this fix, using --to
/dev/null would have given a strange error message (target device does
not exist); with it, we're handling all devices in a more comprehensive
way, spitting the right error message when appropriate.
BUG=None
TEST=--to /dev/null dies as expected; works with --force_non_usb
Change-Id: I514e14e1f7cc49b3d6172a2a53aa6da33ef5ecfd
Reviewed-on: https://gerrit.chromium.org/gerrit/41133
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
By default, pv automatically infers and uses the full width of the
terminal. This generally makes sense for a console application, but in
the case of pv it just causes the progress bar to be ridiculously wide
when run on wide terminals, to the point it's hard to read. This CL is
setting it to 80 characters, the widely accepted standard width for
a terminal, in cases where the terminal appears to be larger than
80 columns. Note that:
* Even with -w, pv appears to be resizing the progress bar as the
terminal width changes midway through the run. This means that if
a user widens the window, then the progress bar will go wide again and
there's nothing to be done about it.
* Theoretically, in very rare cases this may lead to a progress bar the
exceeds the width of the terminal (i.e. set to 80 columns on
a terminal that has just shrunk to fewer columns). The odds for such
timing are close to nil and even then the damage is minimal.
* This will work for non-terminal runs, or otherwise runs where stty
does not produce any output.
* To avoid the initialization overhead for all common.sh inclusion,
replacing the variable with a function that prints the pv/cat command.
BUG=None
TEST=Ran ./image_to_usb on wide and narrow terminal windows, it works.
Change-Id: I549df1dd29e93909ea646ae9b9e09d9a588ad382
Reviewed-on: https://gerrit.chromium.org/gerrit/40937
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
mod_image_for_test.sh doesn't work anymore so nobody should be using it.
There are a few places where scripts try to use mod_image_for_test.sh,
and these are timebombs because they fail if a test image needs to actually
be produced.
BUG=chromium-os:31183
TEST=Tested that this script doesn't produce any images anymore, so
it should be fine to delete it.
Change-Id: If80337407023d62f76117dc44cadfa46801ca236
Reviewed-on: https://gerrit.chromium.org/gerrit/40955
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
BUG=none
TEST=Build image for board that requires hybrid MBR without this flag and
verify it boots
Change-Id: Idfb7886c28bb887f5fca4607824a5bbf5255fb98
Reviewed-on: https://gerrit.chromium.org/gerrit/36248
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Liam McLoughlin <lmcloughlin@chromium.org>
Tested-by: Liam McLoughlin <lmcloughlin@chromium.org>
Specifically, detect if the umount failed due to current access, if so,
give it up to 9 more runs (w/ 1s pauses) continuing only if it's still
failing due to currently open files.
Via this, it should suppress the race of gvfs/trashd looking at
quick mounted/umounted pathways.
This CL is a two parter; this adds the script, and converts common.sh
consumers over to using the override.
The next CL will modify the chroot itself to ensure our script gets
picked up/used.
BUG=chromium-os:23443
TEST=trybot, manul validation.
Change-Id: I92dedd91d6133c2063b1e5dbbc1a68366844801d
Reviewed-on: https://gerrit.chromium.org/gerrit/32087
Commit-Ready: Brian Harring <ferringb@chromium.org>
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
Rather than forcing all consumers of DEFAULT_BOARD to remember to call
get_default_board, just do it for them automatically.
BUG=None
TEST=`cbuildbot {arm,amd64,x86}-generic-full` works
TEST=`./build_packages --help` shows correct default
Change-Id: I8d6ccb83babb2764a50692318eb9193c45fb3b39
Reviewed-on: https://gerrit.chromium.org/gerrit/17868
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Currently, the scripts in src/scripts have multiple implementations
for handling when common.sh fails to load, some of which are buggy.
To simplify the boilerplate, these scripts now just exit if common.sh
fails to load. The shell itself will print the following message if
common.sh is not found:
/usr/lib/crosutils/common.sh: No such file or directory
BUG=chromium-os:32442
TEST=Run these scripts with and without common.sh installed.
Change-Id: Ie54420b6c649774f9cb039c14c80f4cf6c6ebc07
Reviewed-on: https://gerrit.chromium.org/gerrit/27058
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Commit-Ready: David James <davidjames@chromium.org>
This is part of some user's workflow and should be deprecated with
proper advance notice.
- Added a deprecation warning when --to=/dev/sdX is used in
image_to_usb.sh.
- Removed mention of /dev/sdX from the output of build_image. Also
simplified this output a bit (it should be obvious to a user who just
invoked build_image that the other scripts should be invoked
similarly, from inside the chroot's scripts directory).
BUG=chromium-os:32023
TEST=Invoked image_to_usb.sh with different --to values
Change-Id: Ib93d1b55f425b0978c4a9680be7755ae031c46e6
Reviewed-on: https://gerrit.chromium.org/gerrit/25819
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
This should prevent situations where a wrongfully detected target device
(e.g. a hard drive) is being written to without any prompt. With this
change, the semantics of --yes changes to "don't ask me if I'm sure,
just write to the target device in --to". The help line was changed to
reflect this semantics.
Minor changes:
- Replaced die calls with die_notrace.
- Changed the default value for --to into an empty string (why should it
be /dev/sdX anyway?).
- Fixed an unmount warning message so it's more descriptive (and fits in
80 columns).
- Check that --install is only used inside the chroot earlier in the
script.
BUG=None
TEST=Ran the script with different combinations of -y and --to.
Change-Id: I7a4d6eac9697f25d7e1eddb6c34f3c1725a83ef4
Reviewed-on: https://gerrit.chromium.org/gerrit/25404
Reviewed-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
The "function" keyword is superfluous, not in POSIX, is inconsistent
between bash files, and generally makes me angry. So convert every
instance to the form:
foo() {
BUG=None
TEST=`cbuildbot x86-generic-paladin` works
Change-Id: I97f5ca30a3edfef7222b1e08ac23917dc613b556
Reviewed-on: https://gerrit.chromium.org/gerrit/22467
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Currently, if set -e spots a nonzero exit we basically have
no real debug information- it just stops immediately without stating
where or why. This forces our scripts to be stupidly verbose so
we can track roughly where they were, thus when they fail we can
use that information to localize the rough exit point.
Instead we should be traping that set -e induced exit and
outputing necessary debug information to run it down. This includes
outputing the relevant stack trace, or at least what we can get of
it.
The 'die' function is now enhanced to automatically dump the trace
that lead to it. For most consumers this is desired- however for
commandline parsing induced dies ("--board is missing" for example),
the trace is noise. For those cases, a 'die_notrace' function was
added that retains the original non-backtrace behaviour.
Example output via instrumenting cros_generate_breakpad_symbols
w/ the failing command '/bin/false' (nonzero exit code).
Before:
./cros_generate_breakpad_symbols monkeys --board=x86-alex
<no output at all, just exit code 1>
With this CL:
./cros_generate_breakpad_symbols monkeys --board=x86-alex
ERROR : script called: ./cros_generate_breakpad_symbols 'monkeys' '--board=x86-alex'
ERROR : Backtrace: (most recent call is last)
ERROR : file cros_generate_breakpad_symbols, line 207, called: main 'monkeys' '--board=x86-alex'
ERROR : file cros_generate_breakpad_symbols, line 163, called: die_err_trap '/bin/false' '1'
ERROR :
ERROR : Command failed:
ERROR : Command '/bin/false' exited with nonzero code: 1
BUG=chromium-os:30598
TEST=inject a failing command into a script, verify the output.
TEST=inject a 'command not found', verify the output
TEST=cbuildbot x86-generic-full --remote
TEST=cbuildbot arm-tegra2-full --remote
TEST=cbuildbot chromiumos-sdk --remote
Change-Id: I517ffde4d1bb7e2310a74f5a6455b53ba2dea86c
Reviewed-on: https://gerrit.chromium.org/gerrit/17225
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
Rather than trying to use an old/stale common.sh, use the common.sh
from the invocation point- if invoked via /usr/lib/crosutils, use that
common.sh. If invoked via src/scripts/, use that, etc.
Trying to intermix it just introduces potential for bugs and invalidly
freezes common.sh api, thus the efforts to revert this and ultimately
revert the existing of a crosutils ebuild.
BUG=chromium-os:27201
TEST=cbuildbot x86-generic-full
Change-Id: I4c6c5fbade3d28c71752bd4c44dccad49af52ec0
Reviewed-on: https://gerrit.chromium.org/gerrit/18303
Reviewed-by: David James <davidjames@chromium.org>
Commit-Ready: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
For all scripts, --build_root defaults to /build and is never used. To
remove option clutter, I've deleted this option.
The only script which still references build_root in src/scripts is
mod_image_for_pyauto.sh, which seems to support it for grabbing pyauto
dependencies from a location other than /build/*. This might conceivably
be useful, so I haven't touched that script.
BUG=chromium-os:27364
TEST=Remote trybot run. git grep for references to build_root.
Change-Id: I502f7df0123a598fc62a4ef4ed847ceb182f65b8
Reviewed-on: https://gerrit.chromium.org/gerrit/18283
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: David James <davidjames@chromium.org>
Commit-Ready: David James <davidjames@chromium.org>
build_image interface now only support arg arguments rather than
flags. This might be confusing for users who might expect something
to happen when they run image_to_usb dev.
BUG=chromium-os:27362
TEST=Tested with/without args.
Change-Id: If521cb612fa1fa5716fc1557038780a5366e8bab
Reviewed-on: https://gerrit.chromium.org/gerrit/17625
Commit-Ready: Chris Sosa <sosa@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Sosa <sosa@chromium.org>
Having introduced autodetection and autoselection of images, some users
may be surprised to find that the script will happily choose to copy an
image other than chromiumos_image.bin when only one image is present.
Since this is substantially different from the previous behavior, we now
present a menu (with a single choice) in this case as well.
Also fixing the list of images to be detected and properly prioritizing
a default image over others. The code should already work with the
future image naming scheme, where chromiumos_image.bin will be a symlink
to one of six concrete images (with unique names).
BUG=None
TEST=Ran script with different image configurations and flags.
Change-Id: I5d448c5425754496d256258281694cd7ec2554d2
Reviewed-on: https://gerrit.chromium.org/gerrit/15982
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Without this fix, when the script is invoked with (say) --to=/dev/sdk
but /dev/sdk is not a valid block device, we will interpret it as if the
user intended to copy the image to a file of the same name. However, it
is more likely that the user specified the wrong device name. Hence,
this fix catches this type of error and will fail the operation with
a corresponding error message.
Also includes minor changes to printed messages.
BUG=None
TEST=Ran the script with different values of --to
Change-Id: Ie060ff2be77b8c065ba95f635455049e034d4bbc
Reviewed-on: https://gerrit.chromium.org/gerrit/15822
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
The recent changes to image_to_usb.sh assumed that chromiumos_image.bin
is always used for generating a test image. This wasn't the case before
these changes were applied, where a preexisting test image would have
sufficed. This fix eliminates image autodetection entirely when
--test_image it used and falls back to the old behavior: if a test image
exists, it will use it; otherwise, it will generate it from the image
specified by --image_name, or from the default chromiumos_image.bin.
This is not to say that I like this behavior: it is subtle, may lead to
errors (e.g. using a stale test image whereas the user assumes a new one
should be generated), and inconsistent with other behaviors (e.g.
installing a recovery image, where no image generation takes place at
all). I believe that long term we should eliminate the generation of
test images from image_to_usb.sh and have users invoke the necessary
scripts (like mod_image_for_test.sh) explicitly.
BUG=chromium-os:26239
TEST=Ran script with different combinations of --test_image,
--image_name and image files present.
Change-Id: Ib2491a7e45e23eb51ced6ef31d3f129ec7863a25
Reviewed-on: https://gerrit.chromium.org/gerrit/15764
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
This both fixes an incorrect behavior where --to_product would unsafely
lead to using a target device not intended to by the user; and reuses
the existing logic for device autodetection to work with provided
product strings. As a result, it is easier to find devices, and the
script's behavior is more consistent as far as device detection and
selection. This preserves the pattern matching on product string (now
properly highlighted in usage text and inline comments).
BUG=None
TEST=Ran script with various flag combinations (--to, --to_product),
product strings, and devices connected.
Change-Id: I80bfca086029555853a680e7c97251b11adc912e
Reviewed-on: https://gerrit.chromium.org/gerrit/15757
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
The script does not assume a single source image (chromiumos_image.bin)
but detects which images of a list of candidate images are present, and
lets the user select one. The default choice is the first image in the
list to be detected. If only one image was detected, it will be
automatically selected. The list contains the aforementioned standard
image, as well as the default names for recovery, test, factory and
factory install images. If the script is invoked with --test, --factory
or --factory_install flags, it will only seek for the standard image
(and attempt to generate the desired image from it, as was previously
done).
Also fixed some log messages; option strings; and improved the logic for
unmounting the target device, eliminating an unnecessary message and
a 3 second delay.
BUG=chromium-os:26010
TEST=Tested image_to_usb.sh with different images and flags.
CQ-DEPEND=I53a42a46a3c90fd486fead578bfbae248f64cfc2
Change-Id: I0d2f20dc8d62ce5fa18c10d9f8b51a46b2ddca5d
Reviewed-on: https://gerrit.chromium.org/gerrit/15528
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Migrated function definition to the beginning of the code; some minor
cosmetics. This is a preliminary fix to the actual feature mentioned in
the cited issue.
BUG=chromium-os:26010
TEST=Executed in chroot environment with various combinations of flags
and connected devices
Change-Id: Ib73328e738ebecc38e6faafbd4feb33ced8804ad
Reviewed-on: https://gerrit.chromium.org/gerrit/15438
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
If no target device is provided, image_to_usb.sh will let the user
select one out of a list of autodetected devices. If only one device is
detected, it will be automatically selected. Also improves the
descriptors shown for candidate/chosen target device(s), and prints
a noticeable warning when the target device does not appear to be
a USB/MMC one.
Also changed all fail/warning messages to use 'die' and 'warn',
respectively, for compliance with other scripts. Slightly massaged
error/warning strings to be more compact and to-the-point.
BUG=chromium-os:25878
TEST=Executed in chroot environment with various combinations of flags
and connected devices
Change-Id: If248993b8e6f3bc8654c2c8f25f1e54e7899330d
Reviewed-on: https://gerrit.chromium.org/gerrit/15270
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Add a clearer error message if the source image was not found.
This can occur if the --from directory exists, but the selected
image within it does not. An easy case is --from'ing a directory
from a chromeos-images zip.
Previously image_to_usb would copy zero bytes and return success.
BUG=None
TEST=Ran image_to_usb.sh for default, directory and .bin --froms.
Change-Id: I826f2bbc8effd9554f558e517b51cc03b4f832d5
Reviewed-on: https://gerrit.chromium.org/gerrit/15120
Tested-by: Chris Wolfe <cwolfe@chromium.org>
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Commit-Ready: Chris Wolfe <cwolfe@chromium.org>
The variable setup is "FLAGS_force_non_usb", not "FLAGS_force_non".
Trying to run this currently results in:
./image_to_usb.sh: line 189: [: -ne: unary operator expected
Copying USB image .../chromiumos_image.bin to device /dev/sdb...
This should have instead errored out:
Error: Device /dev/sdb does not appear to be a USB or MMC disk!
Without this fix, image_to_usb.sh proceeds to corrupt the non-usb
disk (which in my case happened to be a backing store for lvm where
all my source was stored and ext4 not surprisingly barfed).
BUG=None
TEST=`./image_to_usb.sh --board=x86-alex -y --to=/dev/sdb` (where /dev/sdb is a disk) now errors out instead of clobbering data
TEST=`./image_to_usb.sh --board=x86-alex -y --to=/dev/sdc` (where /dev/sdc is USB) still works
Change-Id: Id691846393c02cf199309495ae2080b15626e684
Reviewed-on: https://gerrit.chromium.org/gerrit/14334
Reviewed-by: Zdenek Behan <zbehan@chromium.org>
Reviewed-by: Chris Wolfe <cwolfe@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
This adds a --to_product flag which chooses the destination
disk with a product value matching the specified pattern.
For the case where a developer is regularly writing to an
external USB drive, the product name may be more stable than
the raw device name.
Also added a help string for the --to flag. This was
accidentally deleted during some refactoring in 2010.
Tested with local cbuildbot internal pfq and manually:
./image_to_usb.sh
./image_to_usb.sh --to=/dev/sde
./image_to_usb.sh --to_product=\*Memory
./image_to_usb.sh --to_product=\* # errors on multiple
BUG=chromium-os:22674
TEST=None
Change-Id: Ie7137e8c605217a3202c46d75896170fc6b7c4a5
Reviewed-on: https://gerrit.chromium.org/gerrit/11322
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Wolfe <cwolfe@chromium.org>
Commit-Ready: Chris Wolfe <cwolfe@chromium.org>
Convert image_to_usb.sh, mod_image_for_recovery.sh, and
mod_image_for_test.sh to use get_latest image; previously these
scripts wouldn't honor the 'latest' symlink.
BUG=None
TEST=re-link 'latest' to an alternate directory; test scripts
Change-Id: Ibb56bb993eae9b6ff9dbfea5090c7cae46f2c133
Reviewed-on: http://gerrit.chromium.org/gerrit/10267
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Commit-Ready: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
The problem here is that most were doing their exiting w/in a subshell;
exit within a subshell kills the subshell, not the parent. Not all scripts
were using set -e (which would pick up the failing subshell); as such
just rewriting them to remove the potential via eliminateing the subshelling.
Beyond that, removed a couple of custom (working, although non-standard)
approaches, and removed a duplicate common.sh sourc'ing w/in mk_memento_images.sh
TEST=force 'find_common_sh' to fail, note the scripts fails to exit
BUG=none
Change-Id: Ia1108a091a6399ad6aedd3cade4a107f4411686c
Reviewed-on: http://gerrit.chromium.org/gerrit/3905
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
BUG=None
TEST=run with a "--to" path that is the default location where the image is generated.
Verify the final image is not 0 bytes.
Change-Id: Ib9a7feceb17054362f00a813c369564e753cd3ab
Reviewed-on: http://gerrit.chromium.org/gerrit/2988
Tested-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
BUG=none
TEST=Write an image to an SD card
Change-Id: I79f2ab4a30c424ab2fbeee8f2636a4900338bcd8
Reviewed-on: http://gerrit.chromium.org/gerrit/1440
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: Mario Limonciello <mario_limonciello@dell.com>
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
Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=4fc5227
Review URL: http://codereview.chromium.org/5271010
from within the chroot.
It also fixes a number of style issues.
It changes the meaning of cros_workon "list-all" to list all available
packages, and adds "list-live" to list all live packages.
It changes things that load chromeos-common.sh from the installer to
load it from /usr/lib/installer.
BUG=chromium-os:4230
TEST=synced, rebuilt chroot, made packages, made images, built chrome
from source, and wrote an image to a USB stick.
Review URL: http://codereview.chromium.org/6240018
Change-Id: I90c34420af1a64020402bafef8e9e77f56837c02
Adding "-B 4m" to balance pipe (+10% speed on some SD) and -b to make progress more readable.
Since the size report from pv (k=1024) and dd(k=1000) are different, we also disable dd's summary report to prevent confusion.
BUG=none
TEST=executed: ./image_to_usb.sh --from=... --to=/dev/sdX (ok)
Change-Id: I184c4ce2d9a8274079ddb26f0420ccf8f2a674dd
Review URL: http://codereview.chromium.org/3608013
image_to_usb has been made to work inside chroot for quite some time
(maybe since http://codereview.chromium.org/1991006), and some special
modes may even require it to be executed inside chroot.
However the output messages were not fixed, so we should remove the
"OUTSIDE CHROOT" alerts.
BUG=none
TEST=manually:
1. executed build_image and verified that output messages is correct, and the image is really built successfully.
2. executed image_to_usb.sh --from=... --to=/dev/sde and verified output messages is correct, and the USB device is really imaged by the given target
Change-Id: I8f4274c5f59a0aa585471469ac285e91c0cead13
Review URL: http://codereview.chromium.org/3519003
1. add oflags=sync to allow interrupting dd without hanging system I/O for a long time
(since bs=4M, the speed is almost the same)
2. use pv to provide progress report if available.
(add pv into host-depends in http://codereview.chromium.org/3608004)
BUG=none
TEST=manually:
1. install pv in chroot, then execute image_to_usb.sh --to /dev/sdX and verified there's progress bar
2. ctrl-c to break the dd process and verified it can stop immediately
3. remove pv from chroot, then execute image_to_usb.sh and verify that it still works
Change-Id: I62fc373a4feee6d7e61897325d9e1e6d84a74d63
Review URL: http://codereview.chromium.org/3581007
- I looked at all of the x86 and ARM paths through out build image scripts,
these changes clean up stale comments, stale code, and unforks some small
things.
BUG=none
TEST=Built images for x86-generic, arm-generic and tegra2-seaboard, booted tegra2-seaboard image.
Review URL: http://codereview.chromium.org/3448022
Change-Id: Ibad2774ff2cbf5f15528454506542b87e43e24a2
- This is needed for devices which use a USB stick or MMC card as their
primary storage.
BUG=1150
TEST=Installed an image to a MMC card, and copied an image to a MMC card.
Review URL: http://codereview.chromium.org/3337020
Change-Id: Ieb7f7cf7b8f9c608a23c55176c49b6805e08d382
I'm lazy and sometimes copy and paste the output at the end of build_image
verbatim and accidentally include the newline at the end. This gives a
more useful output for that case.
Change-Id: I1a4abefa884a91cb75dfe2779c79b3ef4b60e807
BUG=none
TEST=./image_to_usb --from=../build/images/x86-generic/latest --to=/dev/sdX (and /dev/sde)
Review URL: http://codereview.chromium.org/3212012
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
