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.
The OEM sysext image file in the OEM partition had the version variable
name being part of the filename instead of the substituted version value
because of wrong quoting when the fixed string got replaced by ${…}.
The vendor tools on the OEM partition weren't updated. We now want to
ship them as systemd-sysext images which we can easily update. This
change extends the Flatcar A/B update mechanism to cover the OEM
systemd-sysext images. The same mechanism is also able to support
"official" Flatcar extensions, e.g., a ZFS extension.
This change improves build_sysext by sourcing a missing lib dependency,
adding a number of comfort / quality-of-life options, and updating the
output of '--help' accordingly.
The OEM sysext finction in build_library/vm_image_util.sh is also
updated to use new command line format.
1. Include missing dependency toolchain_util.sh to fix an error in
board_options.sh (get_board_arch undefined).
2. Use positional parameters for mandatory arguments.
build_dir and sysext_name are mandatory and are now positional
arguments instead of options.
binary_package is the third positional argument but can be omitted
if --metapkgs was specified.
3. --squashfs_base is now guessed better and will use the most recent
build by default.
4. A new boolean flag --ignore_version_mismatch for the more daring
developer was added. The flag will cause the script to continue if a
version mismatch between SDK board packages and squashfs base is
detected.
5. Error messages were improved for when mandatory parameters were not
provided.
6. The '--help' message was improved and adjusted to the new parameters.
Signed-off-by: Thilo Fromm <thilofromm@microsoft.com>
For release tests and updating a machine to a dev build we already have
the dev-key-signed generic update payload but not yet the OEM sysext
update payload.
Generate the dev-key-signed OEM sysext update payload during build and
upload it.
The initial MVP of the OEM sysext usage we release won't have updates
for the sysext image and, therefore, it is not bound to the OS version.
The special name suffix instead of the version hints bootengine at using
it if no matching version is found. The name will also be used at hint
for update-engine to clean it up when versioned sysext images arrive.
We don't have an update process of the OEM sysexts implemented yet, so
use a fake "initial" version for them and make them independent from
OS version.
It isn't doing much as nothing QEMU-specific was being installed into
the OEM partition.
With that done, we opt into building an OEM sysext image for QEMU
platform.
This package will be used for the sysext image, instead of for
installing files into /usr/share/oem. This means that we can drop some
files or move them elsewhere. The systemd service file is not needed,
because it is installed by the app-emulation/wa-linux-agent package
now. This also means that the ignition file as lost its purpose. The
grub.cfg and oem-release must be installed in /usr/share/oem, next to
the sysext raw image file, so handling of these files is moved to the
newly added coreos-base/common-oem-files package. `eject` symlink to
`/usr/bin/true` is installed in the newly added manglefs.sh script.
With this done, we also opt into building an OEM sysext image for
Azure platform.
That way we can see a report of what emerge is going to do and the
status of the use flags for the installed packages. The downside is
that we are going to have reports about using deprecated and
unsupported profile in even more places.
Emerge flags are cryptic in general, but short flags even more so, so
expand them. While at it, I noticed some places where bash arrays
could be used, so convert those places too.
There is some cruft left after grub hashes generation. After the
contents are zipped into archive, they don't need to be around any
more.
Try to remove the rootfs directory after unmounting the
image. disk_util can recreate it again if there is a need for it.
Remove the build directory used for generating ACI images - it's not
needed after successful installation.
This change adds a new flag called --image_compression_format which
allows us to output the final VM image as one of the supported formats:
bz2 (default), gz, zip or none
if the compression format is "none" or "", the image will not be compressed.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Azure requires disks to be fixed-size VHD files when uploading to blob storage
in order to create image/gallery objects from them. This is documented here[1].
To prevent mistakes from happening create disks in that format directly so that
any azure compatible tool can upload them, though azcopy is recommend because
it handles their sparseness best.
This has not been an issue for us so far because kola uses code from an older
utility that transparently handled the dynamic-to-fixed-size conversion for VHD
files (azure-vhd-utils). But people working with these things for the first
time fall into this trap.
[1]: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-generic#resizing-vhds.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
The vmlinuz kernel image gets installed to /usr/boot/ but isn't usable
for dm-verity until it gets copied over to /boot/flatcar/ and the hash
gets embedded at a particular offset. The file in /usr/boot/ uses space
while it's not having a real purpose as long as dm-verity is used.
Delete the vmlinuz file under /usr/boot/ to free up space. When
generating the ISO image we use the vmlinuz file from /boot/flatcar/
which also has the advantage that we only distribute a single vmlinuz
file with one particular checksum.
The `--jobs` parameter that some scripts defined was not used anywhere
in jenkins or mantle. So the value of the parameter always ended up
being equal to `${NUM_JOBS}` set by `common.sh`. Also, even if the
`--jobs` parameter was used for some script, that script usually
didn't forward the jobs value to other scripts, so the other scripts
ended up using `${NUM_JOBS}` again. Also, the `${FLAGS_jobs}` variable
was used by some functions in the build library, and those functions
were sometimes invoked by scripts that didn't define the
`${FLAGS_jobs}` variable. It is tedious to track which script should
actually define the parameter, and where it should be forwarded.
Just get rid of this half-working pretense. If you want to affect how
many jobs `emerge` uses, export the `NUM_JOBS` environment variable
before calling any script.
For `EMERGE_FLAGS` and `REBUILD_FLAGS` we unconditionally specify the
`--jobs` flag's value to `${NUM_JOBS}` because they are passed to
`emerge`. On the other hand we drop the `--jobs` parameter from the
`UPDATE_ARGS` variable, because this variable passed to `setup_board`
or `update_chroot`, which don't have this flag any more.
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.
The custom sys-firmware/edk2 package has been replaced by Gentoo's
sys-firmware/edk2-ovmf package now that only amd64 is supported.
This partially reverts 1761d9d071 .
