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
SUSE Linux Enterprise Server (SLES) has KIWI as a package.
However, some KIWI plugins and their dependencies can
be unavailable.
This commit introduces a new section which deals with this
aspect.
Fixes bsc#1209302
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
Fix and update the information how to contribute. Due to
the latest changes in tox.ini some requirements regarding
the tox and python versions came up. This commit updates
the docs in this regard
submenu+source should be preferred over menuentry+configfile:
- submenu creates a new context, menuentry does not. As a result, changes made
to vars inside menuentry's braces pollute the current scope. In this particular
case what is notably wrong is root=loop happens in the current scope. If we
activate the "Boot from openSUSE ISO" menu entry and then press Esc to return
back to explore other menu entries, $root would still be set to 'loop'. Instead
of manually saving and restoring $root value it is better to wrap the whole
thing in a new context with submenu
- configfile is not just 'source in a new context', it has as least one side
effect. For details look for grub_err_printed_errors usage in [1] and [2] in
grub sources
[1] grub-core/normal/menu.c
[2] grub-core/normal/menu_entry.c
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
So far the last partition (typically root) in the partition table
takes all the rest space of the partition table in the image file.
At deployment/boot time users had several options to let that
partition grow to a custom size. However, during build time of the
image it was not possible to specify a specific fixed size for the
root partition as we don't wanted to produce gaps of unpartitioned
space in the image file. It has turned out that there is hardware
available which requires a partition to be an exact multiple of
some blocksize. As kiwi supports size constraints for all other
partitions but not for root this commit now allows for it. The
oem-systemsize element is now also taken into account at build
time of the image if the oem-resize which would do that at
deployment/boot time is switched off like the following example
shows:
```xml
<oemconfig>
<!-- set root partition to 2048MB -->
<oem-systemsize>2048</oem-systemsize>
<oem-resize>false</oem-resize>
</oemconfig>
```
This Fixes#2203
The integration test unfortunately never got tested anywhere
is outdated and I have no PPC hardware here to run any tests.
Let's add a real test if there is demand for it
Specifying a repository as part of the image description
allows for credentials via the username and password attributes.
Howver, repositories can also be specified on the commandline
via the --set-repo / --add-repo options. The options on the
commandline did not allow to specify credentials so far.
This commit adds the commandline options --set-repo-credentials
and --add-repo-credentials to support them
