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.
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
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.
Although it'd be nice to re-use packages for experimental boards that
may only have a few differences from amd64-generic there is a bug in
some ebuilds and portage that break sharing binary packages between
different values of $ROOT. This prevents that from happening by
accident.
https://bugs.gentoo.org/show_bug.cgi?id=490014
This profile enables the symlink-usr USE flag and target profiles have a
new variable COREOS_DISK_LAYOUT_SUFFIX that allows the profile to switch
to a different set of disk layouts. By default no suffix is used but the
usr profile uses layouts with the suffix "-usr" such as "base-usr".
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.
This provides firmware from linux-firmware but excludes everything not
explicitly required by coreos-kernel. Note that firmware installed by
this will only be available on the root filesystem, the initrd still
uses the smaller set of firmware the linux repo provides.
The current 3.12 kernel wants a few files missing in the July snapshot:
* Missing firmware: ct2fw-3.2.1.1.bin (bna.ko)
* Missing firmware: ctfw-3.2.1.1.bin (bna.ko)
* Missing firmware: cxgb4/t5fw.bin (cxgb4.ko)
These files have been added to the linux-firmware repo so a newer
snapshot will be required but for now I'm sticking with what is already
in Gentoo so I don't have to generate my own tarball or whatever.
In preparation for moving to using firmware provided by the
linux-firmware repository instead of linux the kernel ebuild needs to
stop installing the files to avoid conflicts. Also to better ensure that
the firmware package gets rebuilt every time the kernel does bump to
EAPI=5 and set the subslot to the ebuild version/revision. The firmware
package can then depend on the kernel w/ a special slot operator to make
sure it gets rebuilt when the kernel version changes. The firmware
package can then scan the installed modules and only install the
firmware that is required.
(Portage automatic rebuild behavior often makes this sort of rebuild
happen anyway but using subslots makes it a strict requirement.)
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.
Lots of things are either unused or meaningless. A particularly creative
one is the fact that there are command line flags for mount point
locations that are then overwritten.
The verification flag was being passed through to the bootloader
template script but no longer had any effect.
Force the base image to always remain writable, its only purpose is to
be modified in a later build step anyway.
Merge GetPartitionTable and partition alignment from WritePartitionTable
into LoadPartitionConfig so that all this config manipulation code is in
one place and inheritance from the 'base' layout is more predictable.
This isn't a feature we've been using as far as I know and if someone
needs a custom partition layout it's probably better to just add it to
the json file. Removing this avoids some complexity.
