Make it possible for other scripts to share the same value for our
release repository and equally easy to override with a custom value.
Also allow setting the root from the command line in addition to the
environment. Usually --upload_root is better to use than --upload_path.
Switch from naming DIGESTS based in disk image name to a common prefix.
old: coreos_production_qemu_image.img.DIGESTS ->
new: coreos_production_qemu.DIGESTS
The old behavior wasn't very consistent since plain disk images aren't
used by all types and the code implementing that was easy to brake,
namely by mistake coreos_production_pxe_image.cpio.gz.DIGESTS became
coreos_production_pxe.vmlinuz.DIGESTS a couple releases ago.
The old names will continue to exist as well for the time being to avoid
breaking existing install/download scripts and the original pxe DIGESTS
name is back.
For multi-file uploads we should explicitly declare what the name of the
.DIGESTS file should be instead of using the first file name. Relying on
the ordering was subtle and easy to break.
To avoid having to sync directory creation and tmpfiles installed by
ebuilds just require ebuilds to do `keepdir /etc/path` and this script
will handle the rest. A possible extension would be to update to handle
symlinks in addition to directories in gen_tmpfiles.py
The funky UUID and other special settings should only be applied to
coreos-rootfs and coreos-usr partitions which will never be fscked. When
STATE becomes ROOT in -usr images it gets fsked while mounted read-only
and fsck updates the filesystem's UUID if it is blank. Turns out this
causes disagreement between the kernel and the disk leading to bad
things. A related issue was fixed in a newer version of tune2fs but
unless I missed it the same bugfix didn't make it into e2fsck so
updating wouldn't resolve the issue.
http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42.9
Check if the disk layout is a /usr layout and if so hack the USR-A
partition, not whatever is mounted to /. Also use the new functionality
in disk_util for this as it can look up partitions by label.
The basic infrastructure to support this is now in place. Add a new
board that uses the experimental coreos/amd64/usr profile /usr based
disk layouts. This is just enough to successfully build images, they
aren't bootable yet.
The boot kernel parameters change depending on whether the new /usr
scheme is in use. Pass the disk layout to the bootloader config script
and adjust generated configs accordingly.
Nothing from chromeos-common.sh is needed for image building now. Also
kill off build_common.sh which was just a weird way of sourcing
common.sh. The two piddly functions it provided fit better in
build_image_util.sh
Now disk_util is aware of the weird ext2 read-only hack, both by
providing a command to manipulate it and support in the mount command to
automatically set the 'ro' mount option for filesystems with it.
Making mount aware of the hack makes it much easier to mount prod
images with a mix read-only and read-write filesystems.
write_gpt --update <img> will read an existing image and make sure all
existing partitions will not get moved or truncated in the new layout.
This is mostly useful for resizing the final partition or just rewriting
metadata like partition types and labels.
cros_make_image_bootable now only is relevant for prod images, so move
the remaining code to prod_image_util in a similar scheme that base and
dev images use.
