The qemu and qemu_uefi_secure images have the same contents as the
qemu_uefi image which wastes space on the release server. A similar
case is the PXE vmlinuz which is the same as the regular one, too.
Set up symlinks for same images, and also detect this when compressing
to set up symlinks there as well. To reduce complexity, the qemu and
qemu_uefi_secure images are not supported anymore and the Jenkins or
GitHub CI will skip over them if specified. Users that build their own
images need to adapt, though.
This pulls in https://github.com/flatcar/init/pull/114 to
support a flag to skip providing OEM payloads, with the goal of easing
downgrades to non-sysext-OEM releases or, when backported to LTS with
the default behavior switched, to opt-in to OEM payloads for airgapped
updates that can't use the fallback download.
Old versions didn't pass the Omaha XML response to the update-engine
postinst action, thus triggering the fallback download which doesn't
work for clients on a restricted network.
Backport the XML passing to make it possible to use this LTS version as
jump version because it doesn't require OEM payloads.
The special Brightbox image uses the OpenStack userdata in Ignition but
lacked Afterburn usage. It actually works to use the OpenStack image and
directly which also enables Afterburn, thus we can drop the special
image.
Don't build a special image for Brightbox but recommend to use OpenStack
images directly. A symlink is added to help with the download of
hardcoded user scripts.
In the past user had to customize Kubernetes or use a bind mount to make
writing the default /usr/libexec/kubernetes/ path work. With
systemd-sysext on by default the bind mount doesn't work anymore because
it can get lost. A newer workaround is to use a systemd-sysext image
that creates a symlink in /usr/libexec/... to redirect to somewhere
under /var/.
Instead of relying on workarounds, make Kubernetes work by default on
Flatcar by having the symlink be part of the generic image. The target
folder will be created through a tmpfiles rule.
Sysext images have a compatibility matching mechanism that searches for
the matching OS version or custom sysext level setting. On Flatcar
there is just the OS version set in /etc/os-release until now which
means that sysext images can't easily be used together with autoupdates
that change the OS version.
Define a sysext level for Flatcar so that users can refer to it instead
of the OS version when they have images that don't rely on a particular
Flatcar version.
Here an example of the now possible metadata:
/etc/extensions/NAME/usr/lib64/extension-release.d/extension-release.NAME
ID=flatcar
SYSEXT_LEVEL=1.0
and a symlink /etc/extensions/NAME/usr/lib → /etc/extensions/NAME/usr/lib64
to work around the problem that using lib/ as path destroys Flatcar's
lib → lib64 symlink.
In the future the matching logic hopefully gets more flexible because
now it is just a string comparison. Also, the architecture is not
matched either for now - we should work with upstream to improve this.
Closes: https://github.com/flatcar-linux/Flatcar/issues/643
Rename sztd to zst and amend the changelog. The zstd binary generates a
compressed file with the .zst extension by default.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
This change makes the Jenkins job output openstack images using gzip
compression format. This allows OpenStack users to directly consume images
by simply specifying the URL to the image. Glance will then download the
image, unarchive it and add it to it's catalogue.
Fixes#575
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
The default image group is already encoded in
/usr/share/flatcar/update.conf but it was written to
/etc/flatcar/update.conf as well. This can cause problems when the user
switches channels by forcing an update to a specific release from the
different channel (e.g., through the flatcar-update tool) as it leaves
the file under /etc/flatcar/update.conf out of sync with the new
channel version in /usr/share/flatcar/update.conf.
Since we don't really need to write a specific channel to /etc on new
images as we can rely on the value from /usr, we now leave any possible
overwriting of the value in /etc entirely to the user.
