Added new <environment> section to the existing <bootloadersettings>
section which allows to specify environment variables for setting
up an environment blob for the selected loader. With this commit
we add support for grub by using grub2-editenv. Other loaders
do not yet have an implementation or does not support environment
blobs. Settings will be ignored for unsupported loaders.
This Fixes#2922
Co-authored-by: Rhys Oxenham <rhys.oxenham@suse.com>
This commit adds support for providing custom CA certificates
during the build process. It allows a user to specify one ore
more CA file(s) via the new <certificates> section and/or
via the command line. The certificate files will be imported
directly after the image bootstrap has finished (where the
required CA update tools are available), but before any
further packages are retrieved, solving for situations where
the chroot environment needs certificates, e.g. when there's
a proxy server in the build environment.
Co-authored-by: Marcus Schaefer <marcus.schaefer@gmail.com>
The console attribute in the bootloader section was used to
target both, output and input console setup using a space separator.
However, there can be multiple consoles specified for output
and input consoles and that turns the idea to handle both in
one attribute into a mess. This commit drops the console attribute
and offers two new attributes output_console and input_console which
can define multiple consoles each using space as a separator.
For example:
<bootloader ... output_console="console serial" input_console="console"/>
This change comes with a schema version bump to v8.4
An automatic XSL transformation template for the old console
attribute into the new output_console and input_console
attributes is also part of this commit.
This Fixes#2886
Add driver configuration support for dracut initrd
Add support for specifying kernel drivers to be included or omitted
in the dracut initrd configuration. This extends the existing dracut
configuration capabilities like in the following example
<initrd action="add">
<dracut driver="erofs"/>
</initrd>
Extend scope and content of the <initrd> section to be allowed
as part of the <type> section. This allows to specify custom
call options and modules for the dracut tool. In particular
this commit implementes support for passing the uefi option
to dracut to enable building an UKI EFI binary as follows:
<initrd action="setup">
<dracut uefi="true"/>
</initrd>
This Fixes#2809 and Fixes#2408
Add a test case with absolute path in the target_dir
to make sure we never unpack the archive to the host
system. The actual issue was resolved together with
the implementation in #1953 and commit
78238a993c
This Fixes#2701
In reference to commit 760a65558f
the support for iso:// URI types was dropped some time ago.
However, the documentation was not properly updated. This
commit fixes it
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.
In contrast to the documentation, kiwi sets default values
for any gpg setting if not explicitly specified differently.
We want to avoid to inherit a behavior from how the distribution
packages the package manager. This commit fixes the documentation
to be in line with the implementation
This should make the xorriso-based ISO build path respect the
'efiparttable' and 'gpt_hybrid_mbr' settings when building a
UEFI-compatible image, making it write a GPT disk label by default
instead of an MBR (msdos) one. If it's building an image that is not
UEFI-compatible it will always write an MBR label, regardless of
this setting.
If 'gpt_hybrid_mbr' is set, xorriso will write an Ubuntu-style
MBR/GPT hybrid partition table, where the MBR partition table
includes a partition with type 00 and the bootable flag, as well
as the partition with type ee required by the UEFI spec. This
mildly violates the UEFI spec but may make the image bootable on
native BIOS or CSM firmwares which refuse to boot from a disk with
no partition marked 'bootable' in the MBR. If 'gpt_hybrid_mbr' is
not set, xorriso will write a strictly UEFI-spec compliant label,
with just the 'protective MBR' required by the UEFI spec (no
bootable partition) and the correct GPT partition table. Note
this is somewhat different from what gpt_hybrid_mbr does for
disk images.
Also, we now pass -compliance no_emul_toc when building ISOs, as
recommended by upstream in
https://lists.gnu.org/archive/html/bug-xorriso/2024-11/msg00012.html
This tool is generally always going to be building ISOs intended
for write-once use, not multi-session use (and which are rarely,
these days, written to physical discs at all anyway).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Allow to pass luks="random". In random mode use the
generated keyfile as the only key to decrypt. This is
only secure if the generated initrd also gets protected
e.g. through encryption like it is done with the secure
linux execution on zSystems
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
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 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
The behavior documentation regarding the fstab entry when
using the btrfs_set_default_volume attribute was wrong.
This commit fixes the docs to match the code. Related
to Issue #2366
A root (/) entry in fstab for btrfs is only required if no
default volume is configured. This commit adapts the code
path which adds an fstab entry for (/) to be effective only
if btrfs_set_default_volume is set to false.
Additionally, the documentation around btrfs_set_default_volume
was clarified to describe the behavior the switch triggers.
This Fixes#2366
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
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
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.
Fix the option implementation to actually do what it is supposed
to do, boot the system in fll read-only mode. In addition a new
parameter named rd.root.overlay.temporary has been introduced
which allows to boot up in read-write mode but the write area
is a tmpfs. Thus persistency only during runtime. Updated the
documentation accordingly
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
Bootloaders implementing the Boot Loader Spec (BLS) are not
directly compatible with the original Bootloader Class design
in kiwi. Because of that an interface class which translates
the original API into calls following BLS was added. This allows
us to keep the implementations in the Builder classes and the
public BootLoader interface untouched. In addition to the BLS
API an implementation to support the systemd-boot loader is
part of this commit too.
An example type definition to use systemd-boot with an EFI
disk image type looks like the following:
<type image="oem" filesystem="xfs" firmware="efi" bootloader="systemd_boot" efipartsize="200"/>
The implementation uses bootctl and kernel-install tools
provided from systemd and expects a proper integration
of systemd-boot by the distribution maintainers
This Fixes#1935
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.
