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
Earlier we used to reuse the recovery kernel data key in the installer, however now we make them different, and so installer keyblock nolonger corresponds to the recovery kernel data key. This CL fixes that.
BUG=7202
TEST=manually tested by using the new key generation scripts, and verifying that the old install signing no longer worked. Making the fix again makes the image verify only in dev mode.
Change-Id: Ic83e90397132da9f88b36e69198773350eb3691f
Review URL: http://codereview.chromium.org/4527004
This adds an optional --force argument which is needed if one attempts to change the password on an image where it is already set.
BUG=chrome-os-partner:1460
TEST=manually tested
Change-Id: I56a95fe4d699ce02c7a68e5be14cc7dce0609a54
Review URL: http://codereview.chromium.org/4480001
BUG=chromium-os:8686
TEST=manual
Follow all the steps to validate
http://code.google.com/p/chromium-os/issues/detail?id=8679
While booted from the USB image, open a shell and run (as chronos)
/usr/sbin/chromeos-install
Reboot, and the device should boot the image installed from the USB.
Change-Id: Iedd595de8dbafabb3e9c8b638cb7e75eea02f165
Review URL: http://codereview.chromium.org/4457001
We still need a way to re-sign non-installer images so that they can be
booted directly from USB.
BUG=chromium-os:8679
TEST=manual, from within the build chroot
Obtain a chromiumos_base_image from buildbot or your own build. Ensure that
it's signed with the dev-keys (it should be).
Modify it somehow. For example:
(cros-chroot)$ cd src/platform/vboot_reference/scripts/image_signing
(cros-chroot)$ ./set_chronos_password.sh chromiumos_base_image.bin mypassword
Now resign the image:
(cros-chroot)$ cd src/platform/vboot_reference/scripts/image_signing
(cros-chroot)$ ./sign_official_build.sh usb chromiumos_base_image.bin \
/usr/share/vboot/devkeys usb_image.bin
Then copy the usb_image to a USB stick:
sudo dd if=usb_image of=/dev/WHATEVER
The resulting USB stick should boot in recovery mode, and assuming you
changed the password as shown above, should let you use that password to get
a shell.
Change-Id: I3aaa2b8787c52940249fd15007e075de7e017d78
Review URL: http://codereview.chromium.org/4424003
BUG=chrome-os-partner:1573
TEST=Manually tested with the latest signed release build. Recovery installer successfully completed and installed the image on the SSD.
Change-Id: I92706e957a1d339db516600ef0d86141d914b0d2
Review URL: http://codereview.chromium.org/4262004
This CL modifies the bitmap generation script as follows:
- allow to specify required geometry of the images and to
generate a single set per FWID instead of generating all
geometries for all FWIDs
- store the images and the zip archive in a directory with
the name derived from FWID.
The CL also adds a wrapper, which given the path to the tree
containing already released GBB firmware volumes would find
all valid (as verified by the CRC in the file name) FWIDs
and generate new images for all detected FWIDs.
The geometry of the generated images is based on the FWID
contents, Marios get 1280x800 and ZGAs - 1366x768.
Once this script stops running, the scripts/bitmaps
directory contains a set of subdirectories, one per
generated set of images.
Another script ran by cygwin on a windows machine was used
to pick up all image sets and regenerate GBB firmware
volumes, will be published under a separate CL.
BUG=chrome-os-partner:792
TEST=see below:
Ran the following command:
./process_all_targets.sh ../../../chromeos-internal/third_party/autotest/files/client/site_tests/
After command completed, the following out_* directories showed up:
(bitmaps 144) ls -1d out*
out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_DEV_0393/
out_ACER_ASPIREONE_002_0710/
out_ACER_ASPIREONE_002_DEV_1017/
out_IEC_MARIO_FISH_2330/
out_IEC_MARIO_PONY_6101/
out_IEC_MARIO_PONY_DEV_3342/
out_IEC_MARIO_PONY_DVT_8784/
out_IEC_MARIO_PONY_EVT_3495/
out_IEC_MARIO_PONY_PREDVT_6766/
with typical directory contents as follows:
(bitmaps 145) tree out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_8012/
|-- 1366x768.zip
|-- BlankBmp
| `-- BlankBmp.bmp
|-- DeveloperBmp
| `-- DeveloperBmp.bmp
|-- RecoveryBmp
| `-- RecoveryBmp.bmp
|-- RecoveryMissingOSBmp
| `-- RecoveryMissingOSBmp.bmp
`-- RecoveryNoOSBmp
`-- RecoveryNoOSBmp.bmp
5 directories, 6 files
Review URL: http://codereview.chromium.org/4147008
Change-Id: I4620966554ca26ea91b01e65fd441c9c09db2a83
BUG=chrome-os-parter:792
TEST=none
As with every previous change to the BIOS bitmaps, you'll have to
1) get a new factory-install shim with the bitmaps embedded
2) run the factory-install shim to change the screens on the device
3) boot in developer and/or recovery mode to see the screens
There is no direct test for this particular bug alone.
Review URL: http://codereview.chromium.org/4158003
The rootfs offset was not converted to bytes. This changes fixes that.
BUG=none
TEST=ran it on an image and it found the ext2 magic
Change-Id: I814c3b89bf5246e3ceab851f80c4a4d4d7e63919
Review URL: http://codereview.chromium.org/4071002
Copies the helpers from crosutils.git/common.sh but uses
printf with octals for portability. This should update all
locations where we mount root rw and disable_rw_mounts just before
a final sign.
TEST= in progres; plz help :)
BUG=chromium-os:7972
Change-Id: Ibdd23cb30335942c36d537663aabea605a2f8704
Review URL: http://codereview.chromium.org/3987001
Provide more clear instruction on how to use the backup files,
and to try more effort to store backup files
BUG=none
TEST=emerge-x86-generic vboot-reference; executed make_dev_firmware and got correct message
Change-Id: I2062f45dd3019d0e56adc18bdd1861991aafe5ed
Review URL: http://codereview.chromium.org/3785014
