ARM (kernel-next) should now be in sync with kernel.git so that we get similar
error handling behavior on all targeted platforms (with our partition layout).
This change makes that the default.
BUG=chromium-os:9697
TEST=manual build_image with kernel-next profile; booted and validated failover error behavior
Change-Id: I281302adb3cbc96aa5770630898f103b0d3639ca
Review URL: http://codereview.chromium.org/6220002
Change-Id: Ib9fcc078d8e0223cd1b1376db91d8e71ae8359a6
BUG=cp file to itself fails in case of nostatefuldev
TEST=ran build_image with and without statefuldev
Review URL: http://codereview.chromium.org/4959001
Patch from Trevor Bourget <tbourget@codeaurora.org>.
Change-Id: Id4ed6af96e0b621f4ad36966fad45c887b991373
BUG=None
TEST=Ran a fresh build_packages and build_image for x86-generic.
Review URL: http://codereview.chromium.org/5689004
BUG=n0ne
TEST=Ran the following command to test:
USE="-compat_wireless" ./build_image
Change-Id: I4b3fd12c1f62e1b2551045a5831a63d848fe2a3f
Review URL: http://codereview.chromium.org/5139003
kernel-next lacks error mode 3. Rolling back until merged.
TEST=none: rolling back to old value
BUG=chromium-os:8442
Change-Id: I0c1a89dc3e00fe5f315b3c15c5070209b0fd79d0
Review URL: http://codereview.chromium.org/4512004
A new error mode for dm-verity exists which can be called as
"cros" or "3". This change enables that mode in builds by default.
TEST=build_image had the correct argument; functionality was there [in progress]
BUG=chromium-os:8442
Change-Id: I3eb3f4a662c5d36011542af4e50718db50ab63bd
Review URL: http://codereview.chromium.org/4530003
BUG=not sure, but this is CL 2/2 to fix broken L13 build
TEST=tested usb intall/auto update
Change-Id: I14cdd1ec941a0653ac25ec7ef72f69f2ec8f64c9
Review URL: http://codereview.chromium.org/4270002
Change-Id: Iecdea822e9600249a9596c059e4db980b409c0a0
BUG=8082
TEST=Built a vm image and ran sudo gmerge metrics
Review URL: http://codereview.chromium.org/4118001
Change-Id: I05370137dbe9f9adc7b18f2ff77d1b7680275c37
BUG=7973
TEST=Ran with/without current blacklist file. Also, added chromeos-base/chromeos-chrome
to test it actually dies correctly.
Review URL: http://codereview.chromium.org/4005002
This change makes more of the root filesyste metadata static across builds, but
more can be done there. It also changes the root filesystem to use ext2 as
we don't need journaling in normal mode. Optionally we could use ext3 for
non-verified if desired (it's an easy change).
In particular, this change cleans up the following:
- clears the rootfs uuid
- labels it C-ROOT (instead of C-KEYFOB)
- removes reserved inodes and blocks
The major feature of this change, however, is that it adds two simple
helpers to common.sh: disable_rw_mount and enable_rw_mount. They will
set high order byte (le) in the ro compat field to be 0xff. This will
tell the kernel that the filesystem uses features R24-R31 which are safe
for use on the running kernel iff the filesystem is mounted read-only.
These functions are called in cros_make_image_bootable and
mount_gpt_image, respectively. mount_gpt_image will always
enable_rw_mount and cros_make_image_bootable will disable_rw_mount if
--enable_rootfs_verification is true.
The approach is ugly but reasonably well contained. If ext2 ever gets a
new revision and new features in the same range are introduced, then we
would be getting inconsistent behavior. That said, it is unlikely that
that churmn will happen and if the impact is negative, it will ideally
show up during testing.
N.B., this will likely result in changes needing to be made to the
signing scripts in vboot_reference to ensure that rw mounting is
enabled/disabled in the same way (E.g., during stamping).
BUG=chromium-os:7468
TEST=- built x86-generic, imaged to usb stick, attempted to mount rw /dev/sdc3 on the host and was properly bounced.
- booted to the image just fine on a dogfood device.
- mod'd for recovery, then installed and booted.
- mod_image_for_test runs with no errors; booted the resulting image as well
- booted a factory_install with the pending dm changes
- BVT passed with build_image x86-generic (vboot enabled)
- [in progress] autotest that checks if the rootdev = /dev/dm-0 and
then does a dumpe2fs | grep -q FEATURE_R31
Review URL: http://codereview.chromium.org/3916002
Change-Id: If4dcba7568a110f4e32627c916d9e5741e5e5414
Change-Id: Ifbfbd3b55ae97ea94ea5bba40a001c6a1ddbf7a0
BUG=720
TEST=Ran suite_Smoke in a VM and ran python from command line and checked
to see if I could import packages from /usr/local/site-packages.
Review URL: http://codereview.chromium.org/3972001
In order to more easily test kernel commandline tweaks, ensure that
--boot_args is propagated to all kernel cmdline sinks.
This is useful for changing default schedulers and any other kernel argument
tweaks we may want to quickly test out.
TEST=build and tested x86-generic
BUG=none
Change-Id: I5138755aa8c5e32e7f117f18291d2ae197e95bef
Review URL: http://codereview.chromium.org/3644004
This changes defaults failure to a panic/recovery reboot and
disables the debugging max_bios argument to ensure that we don't
trigger race conditions in the kernel during un-protected
pending_bio count decrements. (Can lead to a hung-system.)
TEST=built x86-generic; ensured -1 and the panic changes worked
BUG=chromium-os:6956
Review URL: http://codereview.chromium.org/3595015
Change-Id: I81c9e1a7f406e551cd528d5226902c89165b30f9
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
- 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
- Build a "kernel image" which contains a uboot script and a uboot kernel
image.
- Fix some sd* assumptions.
- Remove cruft that has never done anything usefull from update_bootloaders
BUG=none
TEST=Built, booted, and updated on tegra2_dev-board
Review URL: http://codereview.chromium.org/3396011
Change-Id: I00ecf57faa5fe64c8e33dd4c042f1dbed806c10a
Some mod_for_test images don't have the files necessary to run
emerge. Install them.
BUG=none
TEST=Rerun package install
Review URL: http://codereview.chromium.org/3351016
Change-Id: Ib19986121a8988c6cae23527148a7b5d4a58663e
BUG=chromium-os:6577
TEST=(inside chroot) run 4 test cases from src/scripts/, using Ctrl+C to force abort (hence triggering "delete_prompt")
a.) (stdin tty) "./build_image --board=x86-generic < /dev/null", expected = no prompt and delete output dir; actual == expected
b.) (stdout tty) "./build_image --board=x86-generic > foo.txt", expected = no prompt and delete output dir; actual == expected
c.) (normal user case) "./build_image --board=x86-generic",
expected = prompt to delete output dir, if y, output dir is removed; actual == expected
d.) (normal user case) "./build_image --board=x86-generic", expected = prompt to delete output dir, if N, output dir is NOT removed; actual == expected
Review URL: http://codereview.chromium.org/3373003
Historically, we used --usepkgonly in build_image to ensure that packages
were not accidentally built during this step. Recently, build_image was
updated to use --usepkg. The benefit of using --usepkg was that it would not
install obsolete binary packages to your image. It was counter-intuitive that
--usepkgonly would install packages to your image that are not actually
installed to your board root. The disadvantage, however, of --usepkg, was that
it sometimes tried to build packages afresh using the image as your build root,
and this failed with strange errors because you're not supposed to do that.
This change fixes build_image to give useful errors by switching back to
--usepkgonly. To fix the problem where --usepkgonly installs packages that are
not installed, we first run eclean-<board> to clean all unused packages from
the board root.
This change is a big improvement because a number of people have run into
strange issues with build_image due to this problem and have had trouble
debugging them.
This change was actually written by Sean Paul, and I am shepherding his change
through for him because he doesn't have a Chromium account yet.
BUG=chromium-os:6437
TEST=
1) build_packages && build_image should still work
2) build_packages && ./cros_workon start power_manager && build_image should
fail with an error that all versions of the power manager are masked. This
happens because you started working on the power manager, but did not build
the version of the power manager you were working on before installing it.
3) Assuming you are working on the power manager, build_packages && build_image
should succeed because your cros_workon'd version of the package is built.
4) ( ./cros_workon start power_manager && build_packages &&
./cros_workon stop power_manager && build_image ) should fail with the
same error message as case 2 for similar reasons.
5) ( ./cros_workon start power_manager && build_packages &&
./cros_workon stop power_manager && build_packages && build_image )
should work because you've built your new version of the stable package.
Change-Id: Ia3858c70997bc6f0ec0b6d1bfaede8d3272a0976
Review URL: http://codereview.chromium.org/3305010
USB/SDCard boot devices typicaly don't run software updater,
and won't have success ever set. We never want to try to
fall back to the empty B partition either. The workaround
for this is to set the successful bit regardless of actual
boot success.
bug=6395
Change-Id: I67c625804203b13be9a0c626c404fa38bafb5445
Review URL: http://codereview.chromium.org/3344008
* Add dev-rec key to factory installer
* rename factory_install_shim output to be consistent with dev install shim
Change-Id: Ibf8f027edda67626af5c319b4daa164cb53ccfe7
BUG=4382
TEST=Build factory install, build dev install, build normal
Review URL: http://codereview.chromium.org/3286002
BUG=none
TEST=build_image + cut and paste image_to_vm in the output
Change-Id: I9def13a56d796c1f034c834a8429e909b45afa02
Review URL: http://codereview.chromium.org/3181038
Change-Id: I7722848872b1712b26c38ac8f163d450c5a08f6d
BUG=chromium-os:5183
TEST=manually built a dev install shim and verified it's bootable on agz device
Review URL: http://codereview.chromium.org/3158021
This change enables root filesystem integrity checking for all x86
builds by default. All mod_image_for_* work with this and the
factory_install. In addition, the BVT tests all pass running on
a dm-verity root.
[I will send a mail to the chromium-os-dev once this lands with instructions on how to build with it and how to turn it off (chromeos-setimage) on an installed machine.]
Once this is functioning, I will start migrating the build/install process over to use the UUID-based boot.
TEST=built x86-generic, mod'd for test, installed, ran suite_BuildVerify
BUG=chromium-os:5100
Review URL: http://codereview.chromium.org/3143025
Change-Id: Ib23962b7a5e034ef6aea31b4361944ba894700c6
Verified rootfs-based factory installers fail because the ROOT_SIZE_BYTES is
updated, but the information is not propagated to the boot.desc which
cros_make_image_bootable uses. The result is that mod_image_for_test
incorrectly appends the rootfs hash even though it is correctly computed.
Random note:
build_kernel_image uses dumpe2fs to compute the size, but
cros_make_image_bootable uses the supplied size. These shouldn't
diverge though the partition size should accomodate the addition of the
hashes.
TODO(wad) Add checking of sizes in cros_make_image_bootable
TEST=x86-generic build image with --enable_rootfs_verification and --factory_install; then put in a machine and it no longer spewed dm-verity hash errors and the root hash checked successfully!
BUG=chromium-os:5100
Review URL: http://codereview.chromium.org/3155025
Change-Id: I174e3661b80d83b25f3af95ff1eb77f634a7e797
Change-Id: I14cd9dc365093c0450210d7853ad5f67ffa0ddd0
BUG=chromium-os:5183
TEST=1) manually built a dev install shim and verified it's only bootable when dev switch is ON
Review URL: http://codereview.chromium.org/3153001
Adds arm_extra_bootargs to boot.desc and to cros_make_image_bootable.
TEST=tegra2 dev-board build_packages, build_image --fast worked
BUG=broken tree
Change-Id: Ifdfeda66f1eb5e5b1e618706eeba269f31fa9913
Review URL: http://codereview.chromium.org/3069031
Breaks make_image_bootable out of build_image into a separate
script. In addition, it make a helper .sh in the OUTPUT_DIR
to let make_image_bootable be re-run on an image with the same
arguments that were passed in via build_image.
This change also removes the use of the boot/ directory in
OUTPUT_DIR.
TEST=build_image verified; image_to_usb --test_image; booted l13
build_image; image_to_vm; qemu booted
build_image verified; image_to_usb; booted l13
BUG=chromium-os:5081
Review URL: http://codereview.chromium.org/3066037
Change-Id: I627d678089aa71c353347f387ad5b14063fd4e7b
build_image creates it after a successful build, and get_latest_image
can use it if it exists. Fall back to old behavior for now when there
are directories without a link.
BUG=none
TEST=Try building an image, check link. Rebuild, check new link.
Review URL: http://codereview.chromium.org/3014051
The fast build is stable enough now that we can enable it for everybody.
I ran the build constantly all weekend on two machines and I only ran into
one (rare) error, which I've fixed in a separate patch.
See <http://codereview.chromium.org/2856048/show>
TEST=Ran lots and lots of fast builds
BUG=none
Review URL: http://codereview.chromium.org/3059001
BUG=chromium-os:1888
TEST=Manual. build_image should run fine when oem_customization flag is not specified.
Review URL: http://codereview.chromium.org/3076009
The last changes to the installer broke image_to_vm. Since image_to_vm
doesn't need to run postinst, but just change the active image, it
now just calls chromeos-setimage and passes in its needed flags (already
supported by the last installer change). It will also detect whether
the image was built with verification of the rootfs enabled or not
by looking at the default.cfg file.
Also updates the location of where you should run the command in
build_image.
TEST=built a new image with --enable_rootfs_verification and started with qemu -curses -hda [output]; did the same without verification
BUG=chromium-os:2963
Review URL: http://codereview.chromium.org/3034030
Change-Id: I265d6ad8971f9427b78cc07d784fced9cceb5974
Instead of resizing the loop device after adding padding for the
hash tree data. Just ensure that the mkfs.ext3 call doesn't exceed
the rootfs size.
TEST=reran build_image on my lucid machine and checked the rootfs size; asked someone with hardy machine to test.
BUG=none
Change-Id: I59f95e1d17e35aca265bd44bb863da6069c05bd2
Review URL: http://codereview.chromium.org/3048009
This change adds
- --rootfs_hash_pad to specify the MBs reserved for the pad
- the implementation of the above flag
- check if total fs size + pad size exceeds the partition size
- hash appending in make_image_bootable()
Fixes:
- a style for ROOT_FS_HASH usage
- bad mount|grep
- bad bash subst for root devices in all boot paths
- fixed a typo in the update_bootloaders table creation
- disables verified usb for now
Adding the padding argument ensures that the generated hash tree for the root filesystem is appended to the image. Assuming the rootfs is _never_ mounted read-write
again, that hash tree will be valid and vboot will be able to proceed.
BUG=chromium-os:2693
TEST=manual build_image
Review URL: http://codereview.chromium.org/3043011
Change-Id: I67d9b0f91cacdefa309c0cc2dd7fed1d2eddd7a7
Instead of playing mount and loop device games, this change adds support for
update_bootloaders.sh to directly update the EFI system partition living in the
image if a file, offset, and size is supplied.
TEST=build_image for x86-generic; booted resulting image
BUG=broken build
Change-Id: I3d891fd965df6fb4abfc63d660e314c497a4184d
Review URL: http://codereview.chromium.org/3006006
Will Drewry is working on the proper fix, but this unblocks people who
build images that boot w/ syslinux.
Review URL: http://codereview.chromium.org/3009003
Added populating OEM partner partition with content.
Added creating flag file .consider_oobe for OEM partition to get mounted on OOBE.
BUG=http://crosbug.com/3828
TEST=Install Chrome OS on the device from USB stick. /mnt/partner_partition contains etc/... directory with customization manifests on first boot.
Review URL: http://codereview.chromium.org/2938003
An earlier CL modifies the vboot_reference ebuild to install the
keys into /usr/share/vboot.
TEST=verified that build_image fails without this change and no
vboot_reference checkout but succeeds with this change and no
vboot_reference checkout
Change-Id: Ie2bc1091b52c36fd56cd5f763ee275afc91765c3
Review URL: http://codereview.chromium.org/2896008
Adds the --install_syslinux to the update_bootloaders call for x86.
BUG=chromium-os:2693
TEST=build_image with both tegra2 and x86-generic in progress. Doesn't affect actual booting until we change the active gpt boot partition.
Review URL: http://codereview.chromium.org/2911003
The use_vboot and vboot_ flags were confusing from a functionality perspective
since verified boot as a feature encompasses firmware and kernel functionality.
The firmware bits are always enabled, but use_vboot enabled the image-integrity
portion of vboot. It is not called
--enable_rootfs_verification
and all options for the kernel functionality is under --verity_* given that
verity/dm-verity is the current working name for the module and userspace tool.
TEST=ran x86-generic build_image & tegra2-dev-board build_image and checked the resulting boot.config files (with and without --enable_rootfs_verification).
BUG=chromium-os:2693
Review URL: http://codereview.chromium.org/2917008
parallel_emerge prints a message every 30 seconds now so that buildbot doesn't
kill us early. Per discussion with cmasone, reverting the revert.
This reverts commit debaa3d8cf.
This reverts commit f0fb864e8d.
This change needs to be reverted because it suppresses logging output
from the build process. Thus, when something goes wrong...the
sherriff is left completely helpless in terms of debugging the issue.
TBR: davidjames@chromium.org
Also update eretry to not pass in $EMERGE_JOBS anymore, in coordination with my previous change, which passed it in directly instead of depending on eretry to do so: http://codereview.chromium.org/2944004/show
TEST=Ran build_image --jobs 2 and build_packages --jobs 2
BUG=none
Review URL: http://codereview.chromium.org/2914004
Right now, the created arm.mbr is the size of the ESP
partition. It should be truncated though to just the mbr size.
In addition, dm= doesnt do anything on arm yet so replacing use with a todo and adding a check if it isn't there.
TEST=manually ran
BUG=none
TBR=fes
This should fix the bad parsing and the failed archiving.
EMphasis on should. I'll keep monitoring.
TEST=in progress
BUG=none
Review URL: http://codereview.chromium.org/2812044
This change adds make_image_bootable which combines the
prior changes to make ARM, x86-legacy, x86-efi, and x86-fw
share kernel commandlines (where possible) and not rely on
keeping data stored on the rootfs to do so.
It does not enable a cut over to syslinux yet, though.
TEST=manually built image and tested boot and install (in progress)
BUG=chromium-os:327
Review URL: http://codereview.chromium.org/2834038
This change unifies the creation of extlinux.conf,
syslinux cfgs, and grub efi files. It shouldn't change the
existing behavior but does add support for further arguments
and future use of syslinux (once it is properly rewritten by
an installer or other script).
TEST=in progress; manual run
BUG=chromium-os:327
Review URL: http://codereview.chromium.org/2829038
Include checked in parallel emerge,
with an optional (default false) argument
in build_image to turn it on.
Review URL: http://codereview.chromium.org/2827037
Other changes:
- Added update_base_packages() method.
- Fix a get_latest_image.sh problem when the image does not already exist.
- Cleanup method invocations, and remove OUTPUT_IMG global variable.
- Add kernel testing logic back (it was accidentally deleted in an earlier patch.)
TEST=Built regular image. Updated old image to contain new packages.
BUG=none
Patch by: Don Garrett <dgarrett@chromium.org>
(Tweaked by me to address review feedback.)
Review URL: http://codereview.chromium.org/2857020
We want build_image to honour the configuration in PORTDIR and only use
the latest stable version as known by portage and the overlays.
We get these semantics with --usepkg. We do not get them with --usepkgonly.
The one downside is that instead of failing when you forget to run
build_packages before build_image, build_image will try to build
packages from source.
From "man emerge":
--usepkg[=n] (-k)
Tells emerge to use binary packages (from $PKGDIR) if they
are available, thus possibly avoiding some time-consuming
compiles. This option is useful for CD installs; you can
export PKGDIR=/mnt/cdrom/packages and then use this option
to have emerge "pull" binary packages from the CD in order
to satisfy dependencies.
--usepkgonly[=n] (-K)
Tells emerge to only use binary packages (from $PKGDIR).
All the binary packages must be available at the time of
dependency calculation or emerge will simply abort.
Portage does not use $PORTDIR when calculating dependency
information so all masking information is ignored.
Change-Id: I267dad8992ac683d0ff4db0d0c72baba61ecbccf
Review URL: http://codereview.chromium.org/2874013
Makes kernel partition creation standalone. This is motivated
both by the ability to build test kernel partitions easily as well
the need to create all kernel command line configuration after the
rootfs has been completely created.
Instead of a massive overhaul, I'll do this refactor in pieces.
TEST=manually rebuilt the image
BUG=chromium-os:327
Review URL: http://codereview.chromium.org/2825021
update_dev_packages, and update_recovery_packages created.
Moved assorted global variables up to the top section, since they are global.
TEST=Ran build_image.
BUG=none
Review URL: http://codereview.chromium.org/2823010
This does nothing, except provide a way to determine which of the three
possible boot methods was used to boot the running image. Handy for
debugging BIOS issues on experimental and dogfood machines.
Review URL: http://codereview.chromium.org/2868010
aterm will be going back into every build for now, so we can revert these dev-mode only changes
BUG=chromium-os:3884
TEST=none yet
Review URL: http://codereview.chromium.org/2669004
The signing work is being tested and developed on x86, and ARM isn't ready
to use it. Signing the ARM kernel is disruptive. We'll enable it for ARM
later.
Review URL: http://codereview.chromium.org/2599001
- add recovery installer config file (which invokes chromeos-install with
--recovery flag)
- update build_image to install recovery_installer pkg and changed base image
name to recovery_image.bin
Review URL: http://codereview.chromium.org/2081018
Modify build_image to use the create_blob utility and the inline bootloader
to generate a bootable (but still unsigned) kernel partition.
Review URL: http://codereview.chromium.org/2112013
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
- add back in RECOVERY variable since we can't specify value "0" in place
of boolean flag "--recovery"
- for recovery image, make ROOT-B 1GB, KERN-B 16MB and stateful partition 1GB
Review URL: http://codereview.chromium.org/2133006
- Don't run test image when building factory_image.
- Bump the size for factory_install image to 300MB, as the existing build_image
overfills the current size. The size does not really matter, as our SD card
copying time depends on the size of the contents, not the disk size.
Review URL: http://codereview.chromium.org/2113013
TEST=Tested build process. Tested dev image, test image and base image by booting all three and logging in.
Review URL: http://codereview.chromium.org/2106009
Temporary approach to using INSTALL_MASK to suppress some non-relevant paths.
It reduces the size from ~426MB to ~163MB. Eventually, will remove it and
create a clean and separated ebuild for chromeos-factoryinstall.
Review URL: http://codereview.chromium.org/2084001
In addition unifies changes in mount_gpt_image and one-offs in mod_image_for_test
to consolidate gpt / var mounting.
Review URL: http://codereview.chromium.org/2064001
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
Add restart_in_chroot_if_needed to common.sh, and modify the build scripts which referred to assert_inside_chroot to use it instead. The effect is that you don't ever have to explicitly enter_chroot.sh to build (still can, it work's fine).
Update mod_image_for_test.sh to use restart_in_chroot_if_needed
Review URL: http://codereview.chromium.org/1736025
TEST=Tested with image_to_live, memento_updater without image_to_live
This mimics the update process of the real image for the stateful partition.
By moving this the update into a separate script, I can add it to the gmerge
package such that developers will not have to use image_to_live. This change
also removes the dependency on tar.
Review URL: http://codereview.chromium.org/1774021
This allows appending extra kernel command line parameters to
the ARM kernel command line on the Voguev210 boards.
BUG=None
TEST=Built image
Review URL: http://codereview.chromium.org/1694021
This adds some '/dev/sdb' options to the grub2 menu, so that we can keep the
default boot partition /dev/sda3 while still using the USB key as a recovery
image. This is work in progress for EFI BIOS development.
Review URL: http://codereview.chromium.org/1706014
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
As with build_packages, only retries by default if you passed --jobs
even though build_image will indeed spuriously fail with only one job.
sync_build_test now uses jobs=#cores by default for both package and
image building. Eventually will also use this for gclient sync'ing
once that is better vetted.
Review URL: http://codereview.chromium.org/1564035
move mkimage to hard-host-depends and remove dependency from u-boot to kernel.
this will make use of mkimage on target possible in the future.
Review URL: http://codereview.chromium.org/1613008
This fixes the loop device leak. The problem is that inside the chroot, we
have /etc/mtab as a symlink to /proc/mounts. That works most of the time,
but if you mount something using "-o loop", it isn't cleaned up correctly
when you umount it. To avoid that, we either have to replace the /etc/mtab
symlink with an empty file when we create the chroot, or we have to make
sure that we never execute a "mount -o loop" command from within the chroot.
If we use an empty /etc/mtab file, the builds work fine, but then we can't
see any mounted partitions that the host creates outside the chroot (such as
USB keys), which causes other problems. Bleah.
Review URL: http://codereview.chromium.org/1594020
Change build_image to support building a factory install image. Also,
a shell script and startup script to run the factory installer.
Change software_update startup script to detect if it's a factory
install and abort if so.
BUG=2378,2379,2380
TEST=Tested factory install worked on device.
Wrapper script to perform factory install at boot.
AU: New arg to install on non-boot device partition. This is used to
install in the factory. Also, switch to shflags for argument parsing.
Review URL: http://codereview.chromium.org/1556022
The EFI System Partition is a special disk partition where EFI BIOS expects
to find the platform-specific bootloader. We need this in order to work on
the BIOS/kernel handoff. It's not needed for the final ChromeOS image and it
isn't useful for legacy BIOS systems, so right now it only makes any difference on x86
devices with development BIOSes.
This change creates the partition for ARM builds as well; it has no effect
there, either.
Review URL: http://codereview.chromium.org/1513019
I need a couple extra tools for testing purposes (about 10MB). I'd love to not add space to the rootfs for these. But...talking to sosa, it doesn't seem there's any other way.
Review URL: http://codereview.chromium.org/1576018
That way we can directly build an image onto a usb stick/sd card without a separate step.
Also, add mounting of /sys into the chroot that is needed by build_gpt on a block device.
Review URL: http://codereview.chromium.org/1521012
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