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
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
A vmx image is the same disk as an oem just without the dracut
repart/resize feature. This difference is better handled with
an oemconfig parameter <oem-resize> which allows to switch resize
on or off. The extra image type vmx will be dropped and an XSLT
stylesheet automatically transforms a vmx description to be a
oem image with the resize feature switched off.
This Fixes#1425
Before this commit an oem image still had the kiwi initrd_system
set as default. As we are decommission the custom kiwi initrd
concept the default should be changed. It is still possible to
use a custom kiwi initrd but it needs to be explicitly requested
via the initrd_system="kiwi" attribute. In addition to the
changed default a runtime check was introduced that checks
the presence of the boot= attribute which only makes sense
in combination with the kiwi initrd_system. If boot= is
set but initrd_system="kiwi" is not, a message is raised that
explains the situation and either requests setting initrd_system
properly or deleting the boot attribute. The change only
affects people who still use oem with a boot="oemboot/..."
setting and no explicit selection of kiwi as the initrd_system.
As these image type configurations should not be in use anyway
because this is all legacy and announced to go away, we
need to make the next step and enforce a new default in
code. This is related to Issue #1299
The bootloader settings are handled through attributes in the
type element. Over the years some attributes were added and
there are requests for more settings. Therefore the bootloader
setup deservers its own section. With this commit the schema
changes from v7.1 to v7.2 and moves bootloader, bootloader_console
boottimeout and zipl_targettype into a new bootloader subsection
below type. The commit also adds an auto transformation template
such that customers don't have to change their image descriptions.
This is related to Issue #1401
In an OEM deployment that requested the creation of a swap
partition via <oem-swap> that swap partition was created
at first boot and was always the last partition on the disk.
This was required because it could not be placed before
any other partition without destroying those partition
contents. This process leaves the system in an inflexible
condition if the storage device can change its geometry
dynamicly as it's the case for SAN systems. The typical
deployment target for OEM images are SAN storage clusters
and it's cumbersome to resize the root partition if swap
is last.
This commit Fixes#1231 and changes the handling of swap if
requested via <oem-swap> as follows:
1. The swap space is created as part of the image build process
and no longer on first boot of the image via dracut code.
This increases the size of the non compressed .raw disk image
by the configured swap space size or the default. The
compressed versions are not affected since zero initialized
swap space compresses to almost no space. Deployment of
the image however also deploys the swap partition which
increases deployment time. For big swap configurations
it's advisable to switch off image verification via
oem-skip-verify. For very big swap configurations it's
also recommended to prevent kiwi from adding them as part
of the image and let them be created on first boot via
a systemd service that e.g places a swap file, or creates
a swap volume when possible such that the fexibility to
resize the rootfs is still available.
2. The setup of the swap space is now explicit. It's no longer
calculated by twice times RAM size because on newer machines
this could lead to huge numbers. Either the kiwi encoded
default swap size applies or the user configured value.
3. LVM based oem disks creates the swap space as logical volume.
The volume is created as part of the image build process
and no longer on first boot. The swap volume at build time
of the image is of a minimal size and gets resized on first
boot.
4. The move of the swap creation into the builder code also
handles swap per configured device persistency schema like
any other devices. This means by default swap is mounted
via by-uuid name and thus also Fixes#1259
Updates all XML descriptions to latest schema version and
also includes adaptions to the test XML descriptions for
testing the new Xen guest and server setup
At the moment there is no class to build the pxe client config
file from information provided with the optional pxedeploy
section. However this is not fatal to the build because the file
could be created manually too. Thus a warning message is shown
which will go away when the pxe client config file creation
has been ported