As-is catalyst and cros-workon's live ebuilds don't mix since the
catalyst chroot does not provide /mnt/host like the sdk chroot does.
Besides, only people actively working on a project should use the live
versions since anyone else will install it one time and then never
upgrade after that, even when the version marked stable is actually
newer than their old live build.
For SDK builds this means not accepting ~amd64 for core-admin and
update_engine and adding a stable ebuild for core-admin. (update_engine
already has a stable ebuild which is even up-to-date)
Despite the big scary warning saying otherwise upstream Gentoo has
actually included shadow in this list since 2011 (while also forgetting
to delete the warning, cute!). Not having it here runs the risk of
causing a failure during catalyst builds if something tries to add a
system user or group before shadow gets installed.
Upstream commit:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/default/linux/packages.build?r1=1.5&r2=1.6
This version of efunctions does not depend on cros workon and git to
install and thus is suitable for bootstrapping. It also uses the
original author as the upstream rather than a coreos mirror. Since it is
not coreos specific any more I've moved it to sys-apps.
Added to both system and bootstrap package sets.
For extra fun it is also in my new systemd-only Gentoo overlay:
https://github.com/marineam/systemd-only-overlay
The old-style virtual/portage is gone and replaced by a new-style
virtual/package-manager in Gentoo. For now just use sys-apps/portage
since that's all we want anyway.
Enable:
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_VETH=m
Docker needs VETH, and might use MACVLAN in the future, it can't hurt to
enable them, they take up no running space if not used.
This feature forces emerge to only fetch sources from mirrors, never the
SRC_URI provided in actual ebuilds. Disabling this should fix our issues
with portage tarballs vanishing. :-D
Build in a few ACPI drivers, and remove some hardware-specific drivers
that the boot kernel will never see.
Also disable CONFIG_WATCHDOG, as the boot kernel should never be alive
long enough for a watchdog to need to kick in.
The bootkernel doesn't need netfilter, and some other networking kernel
modules to be enabled, as all this kernel needs to do is to find the
root partitions and then boot them. So disable those kernel options
entirely.
The boot kernel shouldn't have kernel modules, otherwise it will be a
two-step build process for the whole kernel/initrd package, so just
build in the Xen modules to the kernel image itself.
This is a separate kernel package, and configuration, for the "boot"
kernel. It reuses the same eclass for kernel builds, but does two
things differently for boot kernels:
- no boot/vmlinuz symlink
- picks the boot version of the kernel configuration.
This adds ACPI support to the kernel, which Azure needs in order to
properly boot. Also added is the needed disk drivers, and other hyper-v
drivers.
Bonus is that the shutdown problem is fixed for kvm images, they no
longer hang forever.
The kernel package should not be building any firmware files, as they
are not needed in virtual machines, _and_ the firmware file locations
are not versioned, preventing multiple kernels to be installed at the
same time.
This change adds a patch to the kernel to not traverse into the firmware
directory at all, and patches the eclass to not do the firmare_install
build process.
