This script should be called before running build_image when generating
official production images. Images built with official key will not
accept updates signed with the default development signing key.
Recently added to systemd, configure is detecting elfutils as present
but compilation fails, perhaps a version mismatch. Need to report this
to Gentoo so they can add a proper use flag and dependency.
Attempting to work around an apparent race in mtools, the command
'extlinux' these days is just the install tool for mounted partitions
while 'syslinux' is for unmounted devices.
This includes new bnx2x firmware required by linux 3.15:
* Missing firmware: bnx2x/bnx2x-e2-7.8.19.0.fw (bnx2x.ko)
* Missing firmware: bnx2x/bnx2x-e1h-7.8.19.0.fw (bnx2x.ko)
* Missing firmware: bnx2x/bnx2x-e1-7.8.19.0.fw (bnx2x.ko)
Commits 24cdca8e and 9d2c0169 added options only in 1.6 and later,
breaking compatibility with older versions. Update the minimum version
to make the resulting error more obvious. :)
The coreos-vagrant project already required 1.6 (although not
explicitly, probably should fix that) so most uses probably won't notice.
Evaluating this as a user config causes it to block on
coreos-environment-setup.service which will wait on networking. This
makes it hard to add extra tricks for testing/debugging situations where
networking is failing. For example, to trigger dhcpcd if networkd dies:
#cloud-config
write_files:
- path: /etc/systemd/system/systemd-networkd.service.d/dhcpcd.conf
content: |
[Unit]
OnFailure=dhcpcd.service
[Service]
Restart=no
Only important thing here is that xattr support is now enabled by
default and the libattr dependency is gone. Previously CoreOS didn't
have the feature enabled.
Fix some issues for booting without using tmpfiles to setup the root
filesystem in advance. For example this now works reliably:
mkdir -p c/etc
cp /etc/os-release c/etc
ln -s usr/lib64 c/lib
ln -s usr/lib64 c/lib64
ln -s usr/bin c/bin
ln -s usr/sbin c/sbin
systemd-nspawn --directory=c --bind=/usr --boot
This kills the massive time-waster we currently have during boot to
cleanup/refresh OpenSSL's certificate directory in /etc/ssl/certs.
System provided certs are now hashed at build time and tempfiles is used
to install the proper links. The certificate bundle is also created at
build time and provided as a symlink. Since tempfiles does not help us
clean up broken links to certs that have been removed that task has been
moved to clean-ca-certificates.service which is still run on every boot.
The update-ca-certificates.service is now only responsible for
recreating the certificate bundle if required. On systems where the user
has never run update-ca-certificates the certificate bundle is just a
symlink to the copy in /usr and update-ca-certificates.service never
runs on boot. If the user does run update-ca-certificates then
update-ca-certificates.service will rewrite the bundle only if the
directory has not been modified since the last time it ran.
There are a few edge cases where if stale hash links may be left if a
system provided cert was replaced a subject that is different enough to
change the hash but not change the file name. I don't expect that to
ever happen though. Also hash collisions between the system certs and
each other or user provided certs are not handled gracefully but should
be rare. tempfiles will report wrong symlink errors in that case.
