Add new overlayroot_readonly_filesystem attribute which allows
to select for either squashfs or erofs as the read-only filesystem
in an OEM overlay disk setup.
So far it was only possible to specify the size of the ramdisk
via the kernel commandline option: ramdisk_size. In a remote
deployment it was therefore required to carry this size as a
mandatory information to the deployment server. With this commit
we allow to specify the size for the ramdisk to be configured as
part of the image configuration which makes this information
also available inside of the initrd. If provided the ramdisk_size
kernel commandline option still takes precedence over the
<oem-ramdisk-size> setting to avoid any behavior change and to
still allow dynamic overrides of the ramdisk size.
Rename btrfs_root_is_snapshot to btrfs_root_is_snapper_snapshot.
This happens in preparation for the changes suggested in #2697
where we want to get rid of snapper specific btrfs code which
will be available in snapper natively soon. To make sure a btrfs
layout specific to snapper(and SUSE), the implicitly used attribute
named btrfs_root_is_snapshot now becomes explicit and its new
name will indicate that snapper sits behind it. Along with the
rename a XSLT stylesheet to automatically convert the old name
into the new name for schema v8.3 will be performed.
Added the attributes provide_system_files and require_system_files
to control the provider and requester of system files in
container image builds. systemfiles is a metadata file which
contains all files from the package database at call time.
It is used in flake-pilot to provision the systemfiles data
from the host into the container instance. One possible use
case for this data is a flake registration which uses a
base container that is derived from a runtime container but
all data from the runtime should be provisioned from the
host. Using this feature tightly couples the flake to the
host OS distribution and version.
IBM SEL(Secure Execution for Linux) is supported for s390
KVM guests. SEL images used to start a confidential computing
protected guest contain an encrypted boot image which encapsulates
the kernel the initrd and the bootparams. The encrypted Image is
provided by the KVM/hypervisor to the Embedded zFirmware of the
system (the ultravisor device). The decryption keys are hardware
based and each system has an individual keypool unique to that
system. The root filesystem is LUKS encrypted with a random key
produced by kiwi at build time and kept inside of the initrd which
exists only inside of the encrypted boot image and the encrypted
rootfs to allow kernel updates. The commit to support secure
execution also comes with an integration test that provides
profiled image builds to target SUSE's LinuxONE as well
as IBM Cloud systems.
Allow to specify references to OCI containers in the
image description like in the following example:
<containers source="registry.suse.com" backend="podman">
<container name="some" tag="some" path="/some/path"/>
</containers>
During the kiwi process the containers are fetched into a
temporary location and a systemd service is configured to
one time load the containers into the local registry at
first boot of the system. This Fixes#2663
When apt resolves packages on a multiarch repo it can happen
that dependencies for packages from other architectures are
pulled into the solver process but are not provided by any
repository. To overcome this behavior the repository can
be setup to serve packages only for a specified architecture
or list of architectures. This is related to
OSInside/kiwi-descriptions#102
Add new EnclaveBuilder class which allows to build initrd-only
image types. The first enclave implementation covers aws-nitro
images produced via the eif_build tooling.
Usually custom files are managed by placing them as overlay
files or archives. However, overlay files must be structured
inside of a root/ subdirectory and archive files are binary
data. It is therefore not straight forward to just reference
one or more files as source files to the image description
to be placed into the image. This commit adds a new <file>
element which allows to do this. This Fixes#1953
Add new <type ... application_id="..."/> attribute to be set in
the ISO header main block. The application ID was used as identifier
in the legacy initrd code from former kiwi versions. Because of
this there is still the compat layer which sets an App ID as MBR
identifier string unless the new application_id overwrites it.
This Fixes#1810
The optional <volume ... arch=""/> attribute allows to create
the volume only if it matches the specified host architecture.
Multiple architecture names can be specified as comma separated
list.
Allow to specify the stopsignal via the containerconfig
element as the following example shows
<type image="docker">
<containerconfig ...>
<stopsignal>SIGINT</stopsignal>
</containerconfig>
</type>
This Fixes#2543
With the switch to schema v8.x we allow for non compatible
changes in regards to the v7.x stream. Thus this commit also
deletes the support for clicfs from the schema
The grub terminal setup is divided into the setting for the output
and the input console. For both settings different parameters exists.
So far kiwi did not differentiate between the two parts of the
console setup and that could lead to a wrong setting if only one
value is provided in kiwi's console= attribute which lead to the
grub setting, GRUB_TERMINAL=value. If value is set to e.g gfxterm
grub takes this for both input and output and it's obviously
wrong for the input. To make this less error prune the kiwi code
changes with this commit to set GRUB_TERMINAL_INPUT and
GRUB_TERMINAL_OUTPUT rather than GRUB_TERMINAL and also runs sanity
checks on the provided values if they are applicable. The information
for setting up the console in the schema stays untouched though.
That's because it's used for all bootloaders and also because grub
supports multiple values for the console in/out setting in one
GRUB_TERMINAL variable even though kiwi does no longer use it.
To make this clear for the users also the documentation for the
console attribute setup has been updated. If we want to wish two
distinct attributes for input and output console settings a schema
change and also differentiation between bootloaders is needed and
that I only see for the kiwi-10 branch if at all. This Fixes#2419
allow value of GRUB_TERMINAL to be empty. When setting grub_console="none"
this now leads to an empty setting of GRUB_TERMINAL in the /etc/default/grub
system configuration file. This Fixes#2261
By default kiwi runs btrfs set-default on the volume that is
considered the default volume according to the btrfs settings
and defaults. btrfs_set_default_volume="false" allows
to deactivate this action. Along with the change also the
misleading name of the btrfs_create_toplevel_subvolume has
been changed to root_is_subvolume
For the btrfs volume management, allow to put a volume into a specific
parent volume. If not specified the volume is below the default volume
This Fixes#2316
Allow to explicitly select if a toplevel subvolume should
be created or not. To avoid a behavior change, kiwi will
create a toplevel based btrfs structure if this attribute
is not specified. However, a deprecation message to inform
about future behavior change will be printed. This is
related to Issue #2316
This commit adds more flexibility when using LUKS
encrypted images. In addition support for key derivation
on user provided passwords has been added. The following
new attributes were added to the schema:
type.luks_randomize
allow to enable/disable the data randomizing if luks
encryption is used
type.luks_pbkdf
When LUKS unlocks a key slot using a user provided
password, it uses a so-called key derivation function
to derive a symmetric encryption key from the password.
Not all boot loaders support all KDF algorithms, hence
this attribute can be used to select a specific algorithm
bootloader.use_disk_password
When /boot is encrypted, make the boot loader store the
password in its configuration file (in cleartext). This
is useful for full disk encryption images
Signed-off-by: Olaf Kirch <okir@suse.com>
With dnf5 there is a successor for dnf but there will also
be a transition period where there will be both, the former
dnf and the new dnf5 available. For a clear distinction
between the two we got the recommendation from the RedHat
team to support both in different namespaces. This commit
now implements a backward compatible change for kiwi which
includes the following modifications:
* XSL stylesheet for automatic schema transformation from
<packagemanager>dnf</packagemanager> to
<packagemanager>dnf4</packagemanager>
* Code copy of dnf API interface from
PackageManagerDnf -> PackageManagerDnf4
RepositoryDnf -> RepositoryDnf4
* Deprecation of former Dnf API interface
The code change here will force developers to adapt
their code if they used RepositoryDnf / PackageManagerDnf
classes in their python code. After this change developers
will be dropped into a raise condition which exits kiwi
at the time of the call. Related to Issue #2300
and Issue #2262
dnf5 is the next generation of the dnf package manager.
dnf5 is not a drop in replacement to dnf which is the reason
why this commit adds a new interface class for package and
repository management under a new name: dnf5. Beginning with
Fedora >= 39 dnf5 will be the standard. Thus the requirements
on the packaging level were adapted too.
This Fixes#2300
This Fixes#2262
Add new attribute delta_root="true|false" which in combination with
derived_from="OCI-base-image" allows to create a delta root tree
only containing the differences between the OCI-base-image and the
actions taken by the kiwi prepare step. Based on the delta root tree
the subsequent image creation process starts. Such an incomplete
root tree is only useful under certain circumstances which is also
the reason why the feature is only available to the oci and docker
image types.
Allow to specify an optional <bootloadersettings> element
inside of the <bootloader> section. The information is used to
specify custom arguments for the tools called in a bootloader
setup procedure, e.g shim-install, grub-install or grub-mkconfig.
kiwi does not judge on the given parameters and if the provided
data is effectively used depends on the individual bootloader
implementation. In this commit the data will be effectively
handled if bootloader="grub2" is configured. More precisely
the custom additions to support SUSE's TPM model with grub2
can be configured as follows:
<bootloadersettings>
<shimoption name="--suse-enable-tpm"/>
<installoption name="--suse-enable-tpm"/>
<configoption name="--set-trusted-boot"/>
</bootloadersettings>
This Fixes#2224
Add a new attribute integrity_legacy_hmac="true|false" which
allows to use old flawed HMAC calculation (does not protect superblock).
Add a new attribute integrity_legacy_padding="true|false" which
allows to use inefficient legacy padding. Do not use these attributes
until compatibility with a specific old kernel is required!
Characters like spaces or other symbols used in repo alias names
can cause the package manager to fail setting up the repo. Thus
this patch changes the schema to only allow for safe POSIX names
matching: {pattern = "[a-zA-Z0-9_\-\.]+"}. This Fixes#2170
For ISO images (live and install) the EFI boot requires an embedded
FAT image. As of now a fixed size of 20M was used which leads to a
problem if the EFI image or the initrd or the kernel is bigger than
20M. With the new attribute:
efifatimagesize="nonNegativeInteger"
we can now set a different value for the FAT image. Please note the
value must be aligned to the also customizable efipartsize value
which allows to configure the size of the EFI partition
This change was inspired by a change done on Fedora's livecd-tools
from here: livecd-tools/livecd-tools#236. The patch corrects issues
with the setfiles SELinux relabel command. The issues become apparent
when the host and guest policies differ. Thus it becomes required
to explicitly set the policy to decouple from eventual unwanted
host settings.
Allow to specify the group id in the groups list a user
should belong to. The group id can be placed as part of
the group name separated by a colon like in the following
example:
<users>
<user groups="kiwi,admin:42,users" password="..." name="kiwi"/>
</users>
Please note kiwi checks if the provided group already
exists and only creates a group if it is not already present in
the system. As default groups are usually provided by the OS
itself including its preferred group id, you will intentionally
not be able to overwrite group id for existing groups.
This Fixes#2064
When using the apt packagemanager kiwi required the use of
debootstrap to create the initial rootfs. This works as long
as there is always a main distribution repository available
which follows the structure of the official debian mirrors.
However if such a main distribution is not present or an
alternative layout like e.g OBS repos is used, debootstrap
will refuse to work. To allow for an alternative and without
the dependency to debootstrap kiwi supports using a prebuilt
bootstrap package providing the mini rootfs to serve as
the bootstrap result. As all other package managers properly
supports installation into an empty new root, this feature
was only added when using the apt packagemanager
Support creating block level clones of certain partitions
used in the image. Clones can be created from the root, boot
and any partition listed in the <partitions> element.
Allow to protect the opening of the integrity data map and
journal through a keyfile. For setting the key file two new
optional type attributes were added:
* integrity_keyfile
* integrity_metadata_key_description
The key file format must be correct according to the selected
integrity algorithm. As of now the kiwi default hmac-sha256
algorithm is used with the selected keyfile
The optional integrity_metadata_key_description attribute
allows to specify a custom description of an integrity key
as it is expected to be present in the kernel keyring. The
information is placed in the integrity metadata block. If
not specified kiwi creates a key argument string instead
which is based on the given integrity_keyfile filename.
The format of this key argument is:
:BASENAME_OF_integrity_keyfile_WITHOUT_FILE_EXTENSION
Add option to set LUKS type to luks1
So far the LUKS type could be set to luks and luks2. However, what luks
version the value 'luks' evaluates to depends on how the distributor has
packaged luks. Thus it's possible that 'luks' is either luks1 or luks2. To
also have the opportunity to explicitly specify luks1 this commit adds
the opportunity in the schema.
There is support in kiwi to use dm_integrity in combination
with the LUKS header and dm_crypt. However there is also the
use case to setup dm_integrity in standalone mode. This commit
allows to create the dm_integrity layer outside of LUKS using
/etc/integritytab to activate the map through a systemd
generator if systemd is used.
Regarding systemd it's required to use a version of system which
provides: system-generators/systemd-integritysetup-generator.
If this generator does not exist in the distribution it will
also be missing in the dracut generated initrd and the boot
will not be able to succeed. It's mentioned here because even
newer distributions might be missing the generator
Along with the implementation there are two new optional
attributes in the <type> section:
standalone_integrity="true|false"
embed_integrity_metadata="true|false"
standalone_integrity activates/deactivates the dm_integrity map
on top of the root filesystem. Similar to the veritysetup support
there is the opportunity to create an embedded magic metadata
block at the end of the device containing the root
filesystem via embed_integrity_metadata
Since #1759 was merged, the contents of /run/ and /tmp/ are excluded from
built images. This causes problems for some containers, notably Ceph when
deployed in a Rook/k8s environment, which needs to have certain directories
present inside /run/. This commit adds the ability to return to the previous
behaviour and *not* empty those temporary directories, if you specify
<image><preferences><type [...] ensure_empty_tmpdirs="false">.
Fixes: https://github.com/OSInside/kiwi/issues/2093
Signed-off-by: Tim Serong <tserong@suse.com>
Specifies to write a binary block at the end of the
partition serving the root filesystem, containing information
for dm_verity verification and to construct the device map
Added new luksformat element which allows to pass
along options to the luksFormat call. This allows users to
switch between LUKS and LUKS2 via e.g
<luksformat>
<option name="--type" value="luks2"/>
</luksformat>
It also allows to pass along a set of options only available
to LUKS2, e.g
<luksformat>
<option name="--type" value="luks2"/>
<option name="--cipher" value="aes-gcm-random"/>
<option name="--integrity" value="aead"/>
</luksformat>
In addition to the new attribute the existing luks attribute
can also be specified to read credentials from a keyfile by
using the file:// source locator, e.g
<type ... luks="file:///path/to/a/keyfile"/>
This Fixes#1898
So far the verity support was only available with the
overlayroot layout and the read-only squashfs root. This
commit adds a new attribute: verity_blocks="number|all"
which allows to create the verity setup also on the
standard root partition
In addition to the change it was needed to extend the
Filesystem API with an additional optional paramter to
allow setup of the filesystem UUID. Having the opportunity
to set the UUID at filesystem creation is generally useful
and with regards to this particular change it became also
required
Docker containers used to support the attribute `additionaltags` which
was used to provide multiple tags for the same image. Since only tags
were supported this commit renames the attribute to `additionalnames`
and now supports tags and names witht he following syntax:
* '<name>:<tag>' -> adds a full docker image reference including name
and tag
* ':<tag>' -> adds an additional tag while reusing the former name
* '<name>' -> adds an additional name while reusing the former tag
Fixes#2045
Signed-off-by: David Cassany <dcassany@suse.com>
