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
Add rd.kiwi.oem.installdevice=DEVICE. Configures the disk device
that should be used in an OEM installation. This overwrites any
other oem device setting, e.g device filter or maxdisk and just
continues the installation on the given device. However, the
device must exist and must be a block special.
This Fixes jira#PED-7180
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.
