There's no need to store to a temporary file when updating the kernel
partition. Just stream straight to the right partition. This appears
to save about .5 seconds.
BUG=None
TEST=Time update_kernel and see savings; verify that kernel still gets
updated.
Change-Id: I5afead3e70720ee6dc9e6a822ef1a98032d93b79
Reviewed-on: https://gerrit.chromium.org/gerrit/39783
Commit-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
If possible, we now uses rsync to copy elements from the host to the
device. Using rsync to copy sped my "no-op" update kernel from 30
seconds down to ~5 seconds.
If rsync isn't available (a non-test build), speed up the fallback
case to:
- Never write tar to disk (on either host or target)--just stream
straight to/from the network.
- Don't use bzip2 compression. It's assumed that we've got a fast
connection to the device so this is overkill and slower.
In this case we're at ~15 seconds for a "no-op" update kernel.
BUG=None
TEST=With old code, run this:
time ./update_kernel.sh --remote=${REMOTE} --novboot --noreboot
...and see 30 seconds with old code and 4 seconds with new code.
TEST=Use update_kernel for updating kernel. See that kernel / modules
get updated.
Change-Id: Iafad68221bd459fce5a4c661e07cd649b058d7b9
Reviewed-on: https://gerrit.chromium.org/gerrit/39393
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
This option avoids updating the vboot kernel partition on the target.
This might be useful if you've done something tricky like put a
nv-U-Boot into the vboot kernel partition.
BUG=None
TEST=Put nv-U-Boot in kernel partition and see that ./update_kernel.sh
--novboot doesn't clobber it. Then try without --novboot and see it
clobbered.
TEST=Run update_kernel --novboot on a system with verity and see
error.
Change-Id: I7c25a7e2ab64a136e427952bb0ac04686fbca805
Reviewed-on: https://gerrit.chromium.org/gerrit/39390
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
These style nits are in preexisting code but are similar to style
comments that vapier found on
<https://gerrit.chromium.org/gerrit/#/c/39390/2>.
BUG=None
TEST=Use update_kernel.sh
Change-Id: I26cf133a0f0495feee715e934bf819e90c0a688d
Reviewed-on: https://gerrit.chromium.org/gerrit/39432
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
On ARM we were copying the kernel twice: one next to the "copying
kernel" message and once in copy_kernelimage() where we just copied
vmlinux.uimg. Avoid the second copy.
BUG=None
TEST=On ARM with no verity, still found that the kernel got copied.
Change-Id: I2a8124b47d018195c7e4b1657d6caf961d3d4d0b
Reviewed-on: https://gerrit.chromium.org/gerrit/39391
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Ready: Doug Anderson <dianders@chromium.org>
Changed update_kernel.sh to use /dev/dm* to mean verity
is being used instead of /dev/dm-0.
BUG=chromium-os:25441
TEST=Used update_kernel.sh to update kernel on stumpy
Change-Id: I187fe0b43c65a6bfa7a689d31ae2cfd86fda558f
Reviewed-on: https://gerrit.chromium.org/gerrit/33797
Tested-by: Paul Taysom <taysom@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
Commit-Ready: Paul Taysom <taysom@chromium.org>
Otherwise if you switch architectures during the update (32/64-bit), the
module load that's needed to mount the FAT filesystem can't happen (the
module has been replaced with the other binary format).
BUG=none
TEST=run update_kernel on a 32-bit-kernel target after having changed
the overlay to use 64-bit kernel.
Change-Id: I9f302e777a563cbdab2ec636f9a3b35e39ef9c24
Reviewed-on: https://gerrit.chromium.org/gerrit/30681
Tested-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
update_kernel will silently run and report no errors if the user
runs cros_workon_make instead of cros_workon_make --install. As
there are times where the 'uname -a' output doesn't change between
builds (modifying modules or devicetree entries), its not always
obvious that the most recently modified kernel wasn't what was deployed.
This doesn't catch the case where the user first cros_workon's a package
but hasn't done an install (either through emerge or cros_workon_make).
BUG=None
TEST=While cros_workon:
cros_workon_make chromeos-kernel
- observe update_kernel warns
cros_workon_make --install chromeos-kernel
- no warning
cros_workon stop chromeos-kernel
emerge-${BOARD} -g chromeos-kernel
- no warning
emerge-${BOARD} chromeos-kernel
- no warning
Change-Id: I25caa44dc82e00c9bf8703b72d09f76df3db1251
Reviewed-on: https://gerrit.chromium.org/gerrit/30214
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>
Tested-by: Jon Kliegman <kliegs@chromium.org>
If the kernel panics early during reboot then
the filesystem hasn't been synced yet. This can lead
to corrupted images and other bad things.
BUG=None
TEST=Ran update_kernel, saw sync call run on device
Change-Id: Iea079ba13fef19c1fa30163935d85e4dd5b0f905
Reviewed-on: https://gerrit.chromium.org/gerrit/27288
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Jon Kliegman <kliegs@chromium.org>
Tested-by: Jon Kliegman <kliegs@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>
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>
"new_kern.bin" was being generated in the current directory and not
being cleaned up. Additionally, without this change, it is not safe to
run update_kernel.sh concurrently to separate devices.
BUG=None
TEST=Updated a kernel on a running VM, verified /tmp/update_kernel.* was
created and used for generated outputs.
Change-Id: I27cd236ee9d38263dcca361ce063078a13b11864
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10240
Reviewed-by: Olof Johansson <olofj@chromium.org>
The KVM examples boot from the syslinux partiton, so update the kernel
that lives there too.
BUG=None
TEST=correctly updated a kernel in a VM
Change-Id: I1526064f85d6c9233696590e9e746bc91bcd6d2a
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10239
Reviewed-by: Mandeep Singh Baines <msb@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>
This 'update_kernel.sh' script gratuitiously broke on ARM targets
because the bootloader file has been changed to 'bootloader.bin' from
its previous name.
TEST=Used the script with a small kernel change to my Arthur board.
BUG=none
Change-Id: I146f08256543ffe2c4c52995625b26a1b3f28318
Reviewed-on: http://gerrit.chromium.org/gerrit/1989
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Taylor Hutt <thutt@chromium.org>
Tested-by: Taylor Hutt <thutt@chromium.org>
The script used to assume that you were running it from src/scripts.
That assumption has now been removed.
BUG=none
TEST=After this change I can run update_kernel.sh from anywhere.
Change-Id: I2676e1c16f5682d06be48e99c915660e4cb35be8
Reviewed-on: http://gerrit.chromium.org/gerrit/1933
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Mandeep Singh Baines <msb@chromium.org>
This CL is separated from http://gerrit.chromium.org/gerrit/#change,1104 which
is depends on the UUID replacement. In order to make update_kernel not break on
officail ChromeOS firmware, this CL just signs the kernel and use the original
cmdline approach, i.e. /dev/${devname}${rootpart}.
TEST=./update_kernel --remote IP
BUG=none
Change-Id: I6a194da0ebb0b3f5a442b62ffb76186909eb4321
Reviewed-on: http://gerrit.chromium.org/gerrit/1538
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Auto-detect use of verity, and if verity is not used, copy over modules and firmware.
Also, while I was at it, I added a --noreboot argument.
And also copy over vmlinux.uimg on ARM if on non-verity.
Change-Id: Ida9d3fbf4f342db65ebd0002a8b1a528440ea7fe
BUG=chromium-os:13321
TEST=Build kernel, try updating on x86 and ARM, both with and without verity
Review URL: http://codereview.chromium.org/6881029
This script recently stopped working when we changed the kernel cmdline.
Fix to be more robust by using rootdev instead.
BUG=12780
TEST=Updated my kernel.
Change-Id: I033f670c5db821863441ea1546c382fce3436c01
Review URL: http://codereview.chromium.org/6628027
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
Change-Id: I5dc22223559d3cdad357530af66c14115da63c89
BUG=n0ne
TEST=update_kernel to seaboard (and mario for regression test)
Review URL: http://codereview.chromium.org/6031005
Change-Id: I7b38b5f9656bd21f6c88c5385c1aa0c526f48294
Signed-off-by: Olof Johansson <olofj@chromium.org>
BUG=n0ne
TEST=build kernel and firmware, update a mario
Review URL: http://codereview.chromium.org/5974003
This change is in preparation for the new sudo, which corrects how
parameters are passed to subcommands.
Change-Id: I34d09d2716fbef137d02748a2934459a8a10d693
BUG=chromium-os:7072
TEST=Ran modified "update_kernel.sh" w/ old sudo and new sudo.
Review URL: http://codereview.chromium.org/5859002
This command can be used to update the kernel of a ChromiumOS target.
Much thanks to snanda for the inspiration and instructions.
BUG=9864
TEST=Verified that it works.
Change-Id: I66f7d940e0dc59b0e1a50409a7155fe0ba7157fe
Review URL: http://codereview.chromium.org/5550001
