With this changeset one can build a kernel module out-of-tree in a dev
image in the usual fashion:
```
~# cat Makefile
obj-m := noop.o
~# make -C /lib/modules/4.3.0-coreos-r1/build M=$PWD
make: Entering directory '/usr/lib64/modules/4.3.0-coreos-r1/build'
CC [M] /tmp/noop/noop.o
Building modules, stage 2.
MODPOST 1 modules
CC /tmp/noop/noop.mod.o
LD [M] /tmp/noop/noop.ko
make: Leaving directory '/usr/lib64/modules/4.3.0-coreos-r1/build'
~#
```
/lib/modules/$(uname -r)/source is now populated with a stripped source
tree (headers, scripts, Makefiles...), prod images may build out-of-tree
modules by simply bind mounting these directories into a toolchain
container without needing kernel source.
Note that this build directory is being populated from the _actual_
$KBUILD_OUTPUT used in producing the kernel in the image, which has simply
been `make clean`ed and stripped down:
```
/lib/modules/4.3.0-coreos-r1/build# ls -la
drwxr-xr-x 5 root root 4096 Nov 25 11:56 .
drwxr-xr-x 4 root root 4096 Nov 25 11:56 ..
-rw-r--r-- 1 root root 108265 Nov 25 11:52 .config
-rw-r--r-- 1 root root 2 Nov 25 11:55 .version
-rw-r--r-- 1 root root 578 Nov 25 11:54 Makefile
-rw-r--r-- 1 root root 617170 Nov 25 11:55 Module.symvers
drwxr-xr-x 3 root root 4096 Nov 25 11:23 arch
-rw-r--r-- 1 root root 23280 Nov 25 11:52 defconfig
drwxr-xr-x 4 root root 4096 Nov 25 11:23 include
drwxr-xr-x 6 root root 4096 Nov 25 11:56 scripts
lrwxrwxrwx 1 root root 9 Nov 25 11:56 source -> ../source
/lib/modules/4.3.0-coreos-r1/build#
```
Rather than building the initramfs in the postinst of bootengine, this
moves it to the setup of coreos-kernel. This has the advantage of
failing a build if dracut fails and ensuring that the latest initramfs
makes it into every kernel build.
in https://github.com/coreos/coreos-overlay/pull/1639, the script would
set USE_SELINUX to the blank string, causing an extra blank argument to
be passed to docker daemon, resulting in it not starting when docker
runs on btrfs.
For some reason the arm64 build (intended only for generating a
pre-built std library) is leaking into the amd64 build, leaving the
installed `go` binary with the arm64 defaults compiled in.
Until this is resolved disable building the arm64 std library.
