Add support for specifying the squashfs compression method for ISOTree
pipelines from the caller.
Build Fedora ISOs with lz4 compression and RHEL with xz.
- Add a list of image type names to skip with explanations.
- Run the test in two configurations: empty blueprint and blueprint with
named kernel (kernel, kernel-debug).
- Count only unique kernel names. Specifying the same kernel twice
isn't an issue. We might change this in the future, but for now the
kernel selection logic is a bit messy.
- Temporarily skip the image-installer until we settle on a common rule
for both Fedora and RHEL.
Similar to 194351e681 and
9ae47b6843cace3c9bef55d40a33fa11d8de391a.
Manifest initialisation during package collection uses options and
customizations to determine build root packages. Just like adding a
fake ostree checksum and an unresolved container list, we also need to
add the ostree ref, which is used to determine if a pipeline is being
generated for an ostree-based image type.
This fixes manifest generation when an ostree commit or container is
being built with an embedded container through the cloud API. Without
this change, the python toml module is not installed in the build root
and the container storage stage fails.
Adding support for container embedding.
The containers need to be specified in the image function (imageFunc)
arguments and when specified, propagate down to the OS pipeline
generator to add the necessary stages.
Support is added for RHEL 9.x and Fedora.
Requires a temporary container spec array with the info from the
blueprint for the first initialization of the manifest that's needed
when collecting required packages.
This should be simplified in the future.
OSCustomizations defined firewall options as blueprint firewall
customizations. Changed it to instead be osbuild firewall stage
options.
This is swapping out one messy thing for another, but at least now we're
consistent in our mess.
The org.osbuild.chrony stage was extended to allow additional directives
alongside time servers [1]. The old Timeservers string slice was kept
for backwards compatibility. Removing support for it in
osbuild-composer makes working with the stage's options simpler. Using
the new struct slice Servers field and only specifying a Hostname for
each element is equivalent to the old behaviour, so no functionality is
lost.
This simplifies the chrony stage since no validation is required
anymore.
It also simplifies the propagation of configuration options through the
pipeline generation code which doesn't need to check for both types of
stage options.
[1] https://github.com/osbuild/osbuild/pull/692
This adds the `fedora-image-installer` and
`fedora-image-installer-preview` images.
The image installer type installs anaconda-webui on Fedora >= 38 to use
the new UI. It also writes its setting to
`/usr/share/anaconda/interactive-defaults.ks` as the current
anaconda-webui has not yet been tested in kickstart mode.
To do so manifest.Anaconda was expanded to take a (subset) of options
for a KickstartStage which is will write into interactive-defaults.ks.
And to take a list of additional modules to enable, so we can set up
Anaconda with all default modules.
F37 no longer ships sil-scheherazade-fonts, but
sil-scheherazade-new-fonts instead. Let's change this. The repos for
test manifests must have been updated in order to get the new package.
Co-authored-by: Ondřej Budai <ondrej@budai.cz>
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Previously, this just happened silently and let to extremely odd errors. Let's
just print the error to simplify debugging the next time.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
8fdd158799 modified the Cloud API to resolve
ostree commits using a separate job. This change caused the API handler
to call PackageSets without any ostree options (because they are not resolved
yet).
Unfortunately, the new implementation of PackageSets initializes the manifest.
The initialization checks the options and if the type is iot-installer and
it doesn't have the fetch checksum for IoT, it just returns an error.
To work around this (we need an initialized manifest to create the chains),
this commit just gives the initialization method a dummy checksum. The ostree
options currently don't have any effect on the package sets, so this should
be fine.
In order to make this workaround at least slightly sane, a warning is printed,
there's a new test just for this behaviour and a long comment to remember to
delete these lines.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Make the ostree commit spec mandatory in the OSTreeRawImage by adding it
to the constructor.
Use the ostree.CommitSpec to specify parameters in the OSTreeRawImage
ImageKind and the OSTreeDeployment Pipeline.
Make the ostree commit spec mandatory in the OSTreeInstaller ImageKind.
The installer image type is not just for ostree types so make the ostree
parameters optional for the ISOTree Pipeline.
Use the ostree.CommitSpec to specify commits parameters.
In the OS pipeline, the parent configuration was used to detect if the
pipeline's setup was meant for an ostree commit or not. Also, the
pipeline used a new type to specify the ostree parameters.
- Use the ostree.CommitSpec for the parent configuration.
- Add a new attribute, OSTreeRef, that defines the ref for the ostree
commit being built. An empty string indicates that the tree is not
for an ostree commit.
Additionally, in the ImageKind configurations for the ostree archive and
container, separate the ostree ref from the parent spec, make the parent
spec optional (pointer) and the ostree ref mandatory, by requiring it in
the constructor of the ImageKind.
Instead of using the ostree.RequestParams in the OSTReeImageOptions,
define a new struct specific to ImageOptions for the ostree parameters.
This is almost identical to the new ostree.CommitSpec but the meaning of
the parameters changes based on image type and it would not be clear if
the CommitSpec was used in all cases. For example, the parameters of
the new OSTreeImageOptions do not always refer to the same commit. The
URL and Checksum may point to a parent commit to be pulled in to base
the new commit on, while the Ref refers to the new commit that will be
built (which may have a different ref from the parent).
The ostree.ResolveParams() function now returns two strings, the
resolved ref, which is replaced by the defaultRef if it's not specified
in the request, and the resolved parent checksum if a URL is specified.
The URL does not need to be returned since it's always the same as the
one specified in the request.
The function has been rewritten to make the logic more clear.
The docstring for the function has been rewritten to cover all use cases
and error conditions.
Don't pass blueprint Users and Groups options all the way down to the
osbuild stage bindings. Instead, convert them to the internal
users.User and users.Group structs.
Ideally we would do this even higher up in the code path, before
reaching the distro, but this is the first step towards that.
Remove the 'fedora' prefix from the canonical name for fedora-iot image
types. Make the previous names aliases.
This has little functional change since we're simply swapping the
canonical name with an existing alias.
Don't redefine the storage unit multiples in each distro, but use the
constants defined in the `common` package. This will make it easier to
split related image type definitions into separate files.
A new struct in ostree can be used to define configuration options for
the ostree remote of an image. So far remotes were always set up with
the remote URL used to pull the commit. Now we support setting a
different remote with extra configuration options.
This is used by the fedora-iot-raw-image to set up the remote
configuration of the final image, separately from the source of the
commit.
Test manifests updated.
Adding support for config options to OSTreeDeployment that are required
by the IoT raw image:
- Kernel command line options
- Keyboard layout
- Locale
Test manifests updated.
Include the platform packages when getting the build packages for the
RawOSTreeImage.
rpm-ostree is explicitly added for this image type.
dracut-config-generic and efibootmgr are temporarily added here, but we
should define a platform that includes them instead (some cleanup
required in general).
Add the new image type to the list in each architecture and update
tests.
Ignore ostree raw images in Kernel count test in distro_test_common:
Edge and IoT raw images don't need a kernel specified in their OS
pipeline. The kernel (and the OS in general, including all packages)
come from the commit that is pulled and deployed in the image.
This test passes on RHEL (for edge-raw-image types) because the
blueprint defaults to returning the main kernel, but this isn't
necessary and is likely to change in the near future.
Co-Authored-By: Ondřej Budai <ondrej@budai.cz>
The most interesting change is the removal of smc-meera-fonts in 37. As
suggested, rit-meera-new-fonts is used instead.
Existing F35 and F36 manifests updated with package changes.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
These are just super-simple to construct using a small helper.
It would be great if we can make `distro.go` totally version-agnostic but
that's something for the future.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Using basic types as values in the `ImageConfig` structure makes it
impossible to distinguish if the empty value for the type was set
intentionally or if it is just the value the variable was initialized
to. This is very bad especially for `bool` type.
While working on unifying `vhd` and `azure-rhui` image types I found
out, that some newly added variables in the `ImageConfig` structure
were forgotten in the `InheritFrom()` method. This makes it impossible
to inherit their values from a parent configuration. This is however
required for the unification of `vhd` and `azure-rhui` image types. As
described above, it would be impossible to decide whether a `bool` value
should be inherited from the parent configuration or not. The only
solution is to use a pointer to the type. For consistency, use pointer
for all basic types.
Adjust distro implementations accordingly.
Since the LVM support was added to all distros, our disk
related code is adaptive, i.e. we will set the correct BLS
and grub2 prefix if there a `boot` partiton is present in
the layout after all customizations happen, which includes
LVMification.
One thing that was not yet fully working was layouts that
do not yet have a `/boot` partition but allow LVMification.
In that case `NewPartitionTable` and if `/boot` was the
first (or only) customization, would LVMify the partition
which in turn would create the `/boot` partition; but after
`newPT.ensureLVM()` the call to `newPT.createFilesystem`
with `/boot` would try to create another `/boot` mountpoint.
In order to deal with this situation correctly we are now
using a two phase approach: 1) enlarge existing mountpoints
and collect new ones. 2) if there are new ones and LMVify
was allowed, switch to LVM layout. Do a second pass and now
create or enlarge existing partitions, handling `/boot` in
the process.
Add basic validation to ensure that the oscap
customizations are valid and required fields
have been provided. The validation also ensures
that the manifest generation errors out if
oscap customization has been enabled for older
or unsupported distros.
Implement all of Fedora in terms of this new abstraction. What used to be the
manifest functions (and before that the pipeline functions) are now the image
functions, whose purpose is to instantiate the right image kind structs from the
image type definitions we currently have in the distro definition.
This is meant to encapsulate the tweaks we do to the OS tree
orthogonally to anything else. For now it still contains some
configuration that only sometimes applies, but this should
continue being reworked until all the fields in this struct
always apply to any artefact that is using it.
At the same time, stop instantiating with default values, as the
empty values should work. This is not a functional change as the
caller always sets these now.
This is the first step to support embedding container images. Here
we add the `containers []container.Spec` argument to supply images
with resolved container specifications. For now all distros will
return an error in case a container is actually supplied since none
of them currently support embedding containers. NB: also no apis or
tools will actually resolve containers.
