We don't need the default root filesystem fsck and remount targets
provided by systemd since root is read only. The only default one what
was included in this way was tmp.mount but that is now covered by
a dependency in the coreos-init package.
Biggest diff here: coreos-init has a Makefile that supports the usual
'install' and 'test' targets so no file copying is required now.
coreos-c10n has moved to init from etcd and has its own service now.
This version of init also includes support for automounting virtfs
filesystems under qemu for use with an updated version of c10n but for
now c10n remains unchanged. Optionally unit tests are available too!
This adds the following patch: (sent upstream, waiting on response)
"9p: send uevent after adding/removing mount_tag attribute"
Also enable PCI hotplug to take advantage of more qemu fun! Now
adding/removing virtio devices (which are represented as PCI devices)
at runtime via the qemu monitor console works.
This is particularly important for the image availability pre-check
because without it we don't detect that the image is in-fact unavailable
when it doesn't exist and the 404 results in a error from bzip2.
This doesn't currently have any real impact but seems like a better
ordering since update scripts may need to emerge things.
Add some friendly version info logging.
Our current version, 1.2, is quite old. Bump to the latest stable (1.4)
with an eye towards bumping to 1.5 as soon.
Packages updated:
app-emulation/qemu
sys-firmware/ipxe
sys-firmware/seabios
x11-libs/pixman
We don't have a valid kernel (or use-case to have one) for "cros_host"
(the SDK) so just fake it. Also remove some unused flags.
This change prevents the latest kmod ebuild from pulling in
coreos-kernel, bootengine, and friends into the SDK.
The old chroot version system we inherited from Chromium OS always
assumes that a newly unpacked tarball is the latest and greatest but
since we version the SDK in the same way as target builds we can use
that version for these sorts of upgrade scripts and not make assumptions
about how late and great the starting tarball was.
The first upgrade script simply aborts to force the user to recreate
their chroot when moving from python 2.6 to 2.7.
I want to start including version info in SDK builds as an alternative
scheme to the existing "chroot_version_hooks" system which always
assumes freshly unpacked SDKs are the latest regardless of what version
they actually were.
