Fixed a grammar based line at `Line 47`:
`echo "$0: Target path (${DEST}) do not exists." >&2` -> `echo "$0: Target path (${DEST}) does not exist." >&2`
systemd and sudo are already fixed. Git was fixed by updating to 2.23.2,
not 2.24.1. Samba is 2 years old and customized, thus difficult to update.
file, Python, and gdb are only in the SDK.
If a user or old software creates the flag file on the old CoreOS location,
nothing would happen.
Check the old location, too, so that Ignition is rerun.
The dev build SDKs are not in $FLATCAR_DEV_BUILDS/sdk but published under
$FLATCAR_DEV_BUILDS/developer/sdk.
Add an environment variable to specify where the SDK is to be found
but default to $FLATCAR_DEV_BUILDS/sdk if it is not specified.
From Jenkins this variable is exported as DOWNLOAD_ROOT_SDK.
The Rust arm64 crossdev toolchain package was uploaded to
toolchain-arm64/rust… instead of toolchain-arm64/dev-lang/rust….
Upload the complete dev-lang folder as only Rust will be fetched
from there anyway.
When the ebuild file changed but not its version nor its cross-workon
commit, the binary package would be used. Also some dependencies are not
encoded to trigger a rebuild of depending packages.
Allow to exclude some binary packages so that we can be sure that they
are rebuilt.
Two Flatcar versions were used in /etc/portage/make.conf both in the SDK
and in the boards.
Use only a single version by default to get the expected results and not
something else when using binary packages.
The Rust crossdev package was never uploaded to /sdk/ and always
had to be compiled again.
Upload it in a separate toolchain-arm64 directory because /Packages in /crossdev/
doesn't refer to the Rust package and its use flags.
The BINHOST was still configured to be the CoreOS CL upstream location
which does not work for independent Flatcar CL releases. This broke
binary package installation in the development container.
Use the correct BINHOST to fix installation of binary packages in the
development container.
The configuration variables for the Ignition configuration also serve as
data source for coreos-cloudinit config data (which includes plain scripts).
Document them properly and also call out that the networking variables only
work if coreos-cloudinit data is used.
For some use cases, too few networking variables were available. Add secondary
routing variables for the main network interface and add a second interface.
There was a logical mistake in Ignition that caused ignition.config.*
only to work when it was part of the ovfenv. Thus they were added but
the old CoreOS variables marked deprecated and kept. With both as OVF
variables each of them worked but directly specifying ignition.config.*
as guest variable still didn't because of the logical mistake.
Now there is a fix and both work well when specified directly as guest
variable (https://github.com/flatcar-linux/ignition/pull/11).
Delete the old CoreOS OVF variables because they just clutter the UI
and only the Ignition variables should be used in the UI.
Write out an iPXE script file for Packet.
The script uses relative URLs to refer to
the other PXE files and thus can be copied
along with the files to any server.
This is useful because it saves the creation
of an iPXE script for a release/channel on a
third-party service. For CI testing it is
also helpful because the script does not only
end up on the release server but also already
on the Google buckets, refering to unpublished
PXE payloads.
For the Ignition variables to be usable they need to be
specified in the OVF.
Call out that the CoreOS variables are deprecated to
reduce confusion when both are displayed besides each other.
Create a tar ball with the contents of the / and /usr partitions
to be used as follows with systemd-nspawn (via machinectl):
machinectl import-tar flatcar-container.tar.gz flatcar-container
machinectl start flatcar-container
machinectl shell flatcar-container
or with docker by converting it to an OCI image:
docker import -c "CMD /bin/bash" flatcar-container.tar.gz flatcar-container
Since the new "prodtar" command relies on the results of the "prod" command,
it bundles it so that "prod prodtar" and "prodtar" is the same.
The `image-matrix.groovy` script reads the list of image formats for ARM,
from `formats-arm64-usr.txt`
So we need to also add ami_vmdk to the list to publish AWS ARM images.
The `image-matrix.groovy` script reads the list of image formats for ARM,
from `formats-arm64-usr.txt`
So we need to also add ami_vmdk to the list to publish AWS ARM images.
To make packages-matrix build rust sources for arm64-usr,
we need to make toolchain include the rust target for arm.
Unfortunately, catalyst does not support the cross-build rust target
by default. We also cannot add `dev-lang/rust` to `$TOOLCHAIN_PKGS`,
because then catalyst would tries to build a `cross-*/rust` package,
which does not exist.
So we need to manually run emerge for rust, without `--newuse -u`
options. If the `--newuse -u` options are given, the rust will not
be installed at all.
