make_dev_ssd is a powerful command bug may confuse developers by its behavior.
Adding sanity checks can prevent developers throwing their system into
un-bootable ste.
BUG=chromium-os:14219
TEST=./make_dev_ssd.sh -i some_images; # no check, pass
./make_dev_ssd.sh # see alert for live partitions
(with non-developer firmware) ./make_dev_ssd.sh --partitions 2 # seeing firmware warning
(with developer firmware) ./make_dev_ssd.sh --partitions 2 # pass, no warning
(with dev-signed normal firmware) ./make_dev_ssd.sh --partitions 2 # pass, no warning
./make_dev_ssd.sh -f # seeing 5 second condown alert screen and then continue
Change-Id: I7ae134c03899b2dc4a6d95f6d9091c38e6f8cf65
R=rspangler@chromium.org
Review URL: http://codereview.chromium.org/6870026
Also adding support for the xx-YY variants to the make_yaml_from_hwids
script, which required that I rename those directories from xx-YY to xx_YY.
Providing a default locale ordering for all locales, which is roughly
geographical.
Change-Id: I4919728a0a876b649cef9dec3a023d0263efe794
R=rspangler@chromium.org
BUG=chromium-os:13037
TEST=none
Review URL: http://codereview.chromium.org/6878074
Developers may turn on developer switch, enter shell, and then try to run
make_dev_ssd without switching to developer firmware / dev root key.
And that would make the system showing "NO GOOD" or "INSERT" screen
after reboot.
For sanity check, we should check if firmware type is "developer" before running
make_dev_ssd.
BUG=none
TEST=(using normale firmware) make_dev_ssd # seeing the error messages
sudo chromeos-firmwareupdate --mode=todev; sudo reboot
(using developer firmware) make_dev_ssd # not seeing error
Change-Id: Id62959c91c39b0bbcca604c9e83fd087e3727b8b
R=rspangler@chromium.org
Review URL: http://codereview.chromium.org/6840047
Change the boot default option in partition 12 (ESP) when we want to disable
rootfs verification.
BUG=chromium-os:12424
TEST=./make_dev_ssd --remove_rootfs_verification --recovery_key -i USB_IMAGE
# the image is bootable by H2C and H2C BIOS(EFI).
# Not tried on non-EFI (syslinux) firmware, but it should work.
Change-Id: I7533bb73597041bbdc8cc57e4e8baaf6ca242309
R=wfrichar@chromium.org
Review URL: http://codereview.chromium.org/6813109
When we do perform firmware updates, we'd like to change the kernel subkey to ensure that new firmware and Chrome OS image stay in sync. This CL adds a scripts which makes it possible to do this revving in an automated manner.
The current versions rollback versions corresponding to the keyset are stored in key.versions. If we change the kernel subkey (to enforce firmware/Chrome OS lockstep), we must also update the firmware version. Similarly, since we modify the kernel subkey, we also generate a new set of kernel data keys. Thus, we also increment the kernel key version.
Change-Id: I364ab50bda115991dd4f69331d37291f66abbf36
BUG=chrome-os-partner:3274, chromium-os:8016
TEST=Manually tested using a newly generated keyset.
Review URL: http://codereview.chromium.org/6824059
There are lots of new and changed files here, but they're mostly localized
text strings and prerendered bitmaps of them.
There are a few that still need rendering by hand. These locales don't work
with ImageMagick:
ar el fa hi iw ja ko th vi zh-CN zh-TW
Change-Id: I1777f985460d46d5aedbb3fbc2fd3c159439c454
R=rspangler@chromium.org
BUG=chromium-os:13037
TEST=none
Review URL: http://codereview.chromium.org/6825032
Change-Id: Icf9abbff05f9b29664216079b5c008cb7906a4f6
BUG=chrome-os-partner:3229
TEST=manually on an image.
Review URL: http://codereview.chromium.org/6813047
Adding --recovery_key enables make_dev_ssd to process recovery images (including
USB bootable images).
R=gauravsh@chromium.org
BUG=chromium-os:12424
TEST=./make_dev_ssd.sh --remove_rootfs_verification --recovery_key -i /dev/sdd
# then use the USB to boot on a H2C device - success.
Review URL: http://codereview.chromium.org/6799007
Change-Id: Ie983f08ff8eba9472800b2f4097915ce380a0c50
This should let the signer catch errors where there are errors parsing verity output. And failing verification if rootfs hash verification is turned off for whatever reason.
Change-Id: I1e3f239a5b6afab31accdd8f0a737b8685530e8d
BUG=chrome-os-partner:3093, chrome-os-partner:3104
TEST=manually on a badly signed image (verification fails now)
Review URL: http://codereview.chromium.org/6720043
To make the output of kernel_config from make_dev_ssd more close to the original
images, we should eliminate the trailing newline/space.
BUG=chromium-os:13516
TEST=make_dev_ssd.sh # succcess
Change-Id: I17f030f8815dea22b04058456d98db6911888ef6
R=rspangler@chromium.org,clchiou@chromium.org
Review URL: http://codereview.chromium.org/6735009
The script to resign firmware (resign_firmwarefd.sh) has changed its syntax, due to the new "dev
firmware" design.
BUG=chromium-os:13375
TEST=./make_dev_firmware.sh
# seeing the "changed firmware to Developer Keys" message.
Change-Id: Id553f3ce1641f13e732bd5e208cb2fb00ca9c078
R=rspangler@chromium.org,gauravsh@chromium.org
Review URL: http://codereview.chromium.org/6727019
Thought I might as well put this is in the repo since I use it very often.
Change-Id: Iecbb2340dce1522b15aab8eefb3b2c346cb7c24f
BUG=none
TEST=manually signed an image.
Review URL: http://codereview.chromium.org/6698014
BUG=chromium-os:13100
TEST=none (BIOS team will test by using it)
Change-Id: Ifedeac1a0d13d36a069531bfaba4bdb7b3457406
Review URL: http://codereview.chromium.org/6696013
Change-Id: I17e1a5abcc4f2fab970a587b338594a7d51ecb2e
BUG=chromium-os:13026
TEST=manually tested all signing modes(usb, ssd, recovery, install), input image was not modified in each case.
Review URL: http://codereview.chromium.org/6686004
* Just make new "bmp" files as necessary
BUG=chrome-os-partner:2558
TEST=runs as expected
Change-Id: I3046630ea3e3f0a40429bb63a986c6044b83c6a6
Review URL: http://codereview.chromium.org/6623008
make_dev_firmware should trust system firmware blobs instead of using its own
prebuilt binaries.
BUG=chromium-os:12400
TEST=1. make a build with .49+ BIOS, and create the firmware updater
2. install the new BIOS, turn on developer switch and reboot
3. an ugly "DEV" screen (in .49) is shown on screen
4. run the new make_dev_firmware.sh
5. reboot. seeing the ugly DEV instead of the prebuilt blue screen
(verified successfully)
Change-Id: If75d2821170649fa869db6a82d879b697f7588e6
Review URL: http://codereview.chromium.org/6614006
Also re-factor the key generation script to its own directory, including wrappers for generating key pairs and keyblocks without needing to start keyset generation process from scratch. (Useful for generating new kernel keyblocks, and for retroactively adding new keys to an existing keyset - as in this case).
Finally, change hard coded algorithm ids and keyblock modes to bash variables, for each changes and telling keyset configuration from a glance.
BUG=chrome-os-partner:2218
TEST=manually tried the following:
1) Generating an entire new keyset.
2) Generating a new key pair and creating a keyblock from an existing key (for generating dev firmware keyblock for existing PVT keysets)
3) Firmware signing via sign_official_build.sh of an image with a firmware payload/
Change-Id: I4e9bb96ac7e5fe4cc0d95af6162ad6d37bbd4bda
Review URL: http://codereview.chromium.org/6594131
Change-Id: I0b364103e3b93d7fd3deebd72b4cb58239729aeb
BUG=chrome-os-partner:416
TEST=manual
Be sure you're running BIOS 49 or later, including the read-only portion.
Follow the instructions in
src/platform/vboot_reference/scripts/newbitmaps/{README,HWID.txt}
Review URL: http://codereview.chromium.org/6588093
Add bitmap_viewer program (to run OUTSIDE of chroot) and example bitmaps (to
be replaced by the REAL bitmaps for each platform).
BUG=chromium-os:10949
TEST=none
These are just nonessential tools and examples. No regression testing needed.
Change-Id: I7f9aab30809251e4c62d71bfa73293d0b4d97196
Review URL: http://codereview.chromium.org/6598046
Change-Id: I6435a4b0f40a571f8e44830e6d32f42d2d3213ff
BUG=none
TEST=manually tested with a signed image and comparing the kernel, and rootfs partitions.
Review URL: http://codereview.chromium.org/6533015
Change-Id: If51dd4f7d9e84f2f0f30506a3a9c354bc6a4b07b
BUG=chromium-os:7388
TEST=manually tested on an image, verified that the permissions on the copied key were correct.
Review URL: http://codereview.chromium.org/6543027
Change-Id: Ic6dd5a883646103b32cfb58712df7d34725c5f62
BUG=chromium-os:12285
TEST=Ran ./ensure_secure_kernelparams.sh chromiumos_base_image.bin on today's mario build which had repro'd the bug
Review URL: http://codereview.chromium.org/6538034
Change-Id: I1c82426854d48f23bdf7c08ae5e37cd965a08089
BUG=chrome-os-partner:1991
TEST=Run the corresponding test scripts with these config files. Works.
Review URL: http://codereview.chromium.org/6480121
BUG=chrome-os-partner:2316
TEST=tried signing firmware with old style and new style fmap and verified that it works.
Change-Id: I9076fe60308bdb787440486d592c9d5e72602199
Review URL: http://codereview.chromium.org/6516004
Versions are (optionally) read from a file with the format
firmware_version=<firmware version>
kernel_version=<kernel version>
The new scripts and arguments are compatible with older versions of the script.
Change-Id: I502df69d6c02caee75cdf010e61812be408a64e0
BUG=chromium-os:8016
TEST=manually tested all invocations of sign_official_build {verify|usb|ssd|install|recovery} with and without versions.
Review URL: http://codereview.chromium.org/6368064
Change-Id: Ib8061ba35afd9681dc70fe1a1459ff9a00f74c3f
BUG=chrome-os-partner:2181
TEST=./ensure_sane_lsb-release.sh chromiumos_base_image.bin (passes)
Also tested each of the "test fail" possibilities:
* Tested by changing various values in the .config file to force each mismatch/failure
* Tested lsb_syntaxcheck by isolating it and having it check a mock bad lsb-release file
containing each of the possible syntax violations.
Review URL: http://codereview.chromium.org/6246037
Change-Id: Iad5578031e4d62435a27c92651b1c91075987078
BUG=chrome-os-partner:1991
TEST=Ran manually against current mario images, 'base' img passes, 'test' fails, as expected
Review URL: http://codereview.chromium.org/6264023
Also make the script able to run at other directory.
BUG=chromium-os:11384
TEST=as follow:
$ cd /tmp
$ ~/$CHROMEOS/src/platform/vboot_reference/scripts/bitmaps/make_bmp_images.sh 'x86 HWID 1234' '1366x768' true
processing BlankBmp ...
processing DeveloperBmp ...
processing RecoveryBmp ...
processing RecoveryMissingOSBmp ...
processing RecoveryNoOSBmp ...
$ file out_x86_HWID_1234/DeveloperBmp/DeveloperBmp.bmp
out_x86_HWID_1234/DeveloperBmp/DeveloperBmp.bmp: PC bitmap, Windows 3.x format, 800 x 600 x 24
$ ~/$CHROMEOS/src/platform/vboot_reference/scripts/bitmaps/make_bmp_images.sh 'arm HWID 1234' '1366x768' false
processing BlankBmp ...
processing DeveloperBmp ...
processing RecoveryBmp ...
processing RecoveryMissingOSBmp ...
processing RecoveryNoOSBmp ...
$ file out_arm_HWID_1234/DeveloperBmp/DeveloperBmp.bmp out_arm_HWID_1234/DeveloperBmp/DeveloperBmp.bmp: PC bitmap, Windows 3.x format, 1366 x 768 x 8
Change-Id: Ia96a4e64f34350f8bd5fec51657d3cec85c4ab1c
Review URL: http://codereview.chromium.org/6273012
Change-Id: I8ffedf8afa00862d135f80db9350927cc0332979
BUG=chrome-os-partner:1991
TEST=Have run it manually with various config data producing test-pass and the different sources of test-fails
Review URL: http://codereview.chromium.org/6253014
Revert "This change define the data structure of bmp block and implements the create more of bmpblk_utility. It reads a YAML config file, parse the informations, and creates bmpblock file as output."
This reverts commit 95b0ae01ea.
BUG=none
TEST=emerge-x86 vboot_reference
TBR=waihong@chromium.org
Change-Id: If1692ca12ddb61b7814ca7dddccee5a395c8bed1
The list mode and extract mode will be implemented later.
Change-Id: I2b34b323814b1d6b0a369b0e4b2bfa7cf960ff4a
BUG=chromium-os:11017
TEST=build and run, use bvi to check its output.
Review URL: http://codereview.chromium.org/6307007
The current version always fails - and generates false positives. (This is not
the version that is on the live signer, so we are good.)
Change-Id: I7cb14cdcaf4d96bc2911e596224ead9a3738aa18
BUG=chromium-os:1459
TEST=manually tested
Review URL: http://codereview.chromium.org/6322006
Change-Id: I044331dc3558a4f7428b75fe43ef739498d65803
BUG=chromium-os:10836
TEST=scripts that use common.sh seem to work, would appreciate help in testing Chrome OS client scripts!
Review URL: http://codereview.chromium.org/6294002
Complete the missing part of "checking (and disabling) write protection status.
This also helps to prevent erasing RW regions on system with WP enabled and
then causing boot failure.
BUG=chrome-os-partner:1276
TEST=(1) On CR-48 with WP enabled, run make_dev_firmware.sh without turning off WP.
Result: Error message "Write protection is still enabled. Please verify
that hardware write protection is disabled." (as expected)
(2) Disable WP and run again.
Result: firmware has been changed successfully.
Change-Id: Iaf2243cb2cd3c7f83ce4f36543ea3da1e3ca55a1
Review URL: http://codereview.chromium.org/5987010
http://codereview.chromium.org/5878005 modified common.sh but the final checked in CL clobbered some of the variable defintions (most likely due to a manual merge) making the scripts that use it to fail. This CL puts them back.
BUG=chrome-os-partner:1903
TEST=manual; sign_official_build gets hung before, works fine now.
Change-Id: I8d19a086d66b0a0d1e9f7231a14fcf37d42a2f01
Review URL: http://codereview.chromium.org/6104002
Also refactor the other scripts to move more common functions (debug output, etc.) to common.sh.
BUG=chrome-os-partner:1903
TEST=manual; ran on a Chrome notebook, verified the right things got copied.
Review URL: http://codereview.chromium.org/5878005
Change-Id: Ib7131356ecb6f88eee3d529a518f23b94756d0c0
This script preserves the root file system metadata as much as possible
between the specified image and the latest shipping image. It preserves
the metadata by ensuring that the files reuse the same inodes and that they
are located at the same physical location on-disk. This leads to smaller
auto-update delta payload and less disk reshuffling, extending the life
of the SSD.
It is called before the image is signed during the stamping process.
Currently, this only supports x86-mario.
This is a continuation of a previous CL located at:
http://codereview.chromium.org/6058006/
BUG=chromium-os:10188
TEST=Build image, boot image, auto-update to new image, run suite_Smoke
Change-Id: I3270245dc15a074abb3bac250922c30e2e105f92
Review URL: http://codereview.chromium.org/6079004
BUG=chromium-os:10213
TEST=manual
From a shell, run
cd /tmp
/usr/share/vboot/bin/make_dev_ssd.sh --save_config foo
You should see messages about kernel A, kernel B, and kernel C. It doesn't
matter what those messages are (well, it does, but testing that is way too
complicated and only useful for dev-mode hacking).
Change-Id: I32aaeae18fb9dd957ab17a452d1ea6d7cd8fe788
Review URL: http://codereview.chromium.org/5698004
Change-Id: I691e6e62f5d5d9b6671fd05f172829b84d503b77
BUG=9934
TEST=manual
1. From a root shell, on a device signed with developer keys:
make_dev_ssd.sh --save_config=foo
This should create a foo.2 file with a kernel command line. It'll be
similar to the one in /proc/cmdline. It may create a foo.4 file, if
kernel B is also valid.
2. Modify the command line in foo.2 (and foo.4, if it exists).
Suggest adding "blah2" to foo.2, and "blah4" to foo.4 if it
exists.
3. From a root shell:
make_dev_ssd.sh --set_config=foo
4. Reboot.
5. Check the kernel command line.
cat /proc/cmdline
If you booted from kernel A, you should see "blah2" in the command
line. If B, you should see "blah4".
Review URL: http://codereview.chromium.org/5567003
BUG=chromium-os:9578
TEST=manually tested before and after the change (echo $? after running verify on an image)
Change-Id: I7d7e36b63482ef3a447cf07b09abdc6fb37b22c1
Review URL: http://codereview.chromium.org/5273010
This mirrors the change made for cros_make_image_bootable.
BUG=chromium-os:9578
TEST=manually ran verify on signed images including those with known rootfs corruptions.
Change-Id: I5dfdf1bfa975fbbbb4e010cd2adc6a3a7f08da15
Review URL: http://codereview.chromium.org/5367004
The remove_rootfs_verification was corrupted by several issues:
1. enable_rw_mount (ext2 RO bit hack) should be performed on every rootfs
and only after we successfully resigned the kernel.
2. for latest images, we must first resign again before changing
boot parameter, otherwise verification would fail.
Both fixed and verified.
BUG=chromium-os:8629
TEST=(1)built a ToT image, install by USB boot, then
./make_dev_ssd --remove_rootfs_verification; then reboot.
rootdev shows /dev/sda3 and is writable.
(2)install by factory setup and then wipe so that root = sda5
./make_dev_ssd --remove_rootfs_verification; then reboot.
rootdev shows /dev/sda5 and is writable.
Change-Id: I27d92964f3fbe160a207069a39516a879de64245
Review URL: http://codereview.chromium.org/4525002
