efipart_id, rootpart_id, bootpart_id in <type> and
part_id in <partition>. Allow to specify a custom partition
number instead of the default numbering schema 1-N
Allow to specify a custom partition ID in the Disk
class interface and API. As of today the new parameter
partition_id in the ptable_entry_type record is not
in use by the current kiwi image description schema.
This change will be a followup to the API change and
needs further conversation upstream first. The code
changes here are based on the work from:
Co-authored-by: Caleb Wolfe <cwolfe651@gmail.com>
Co-authored-by: Caleb Wolfe (Amazon) <xcawolfe@amazon.com>
Assisted-by: Claude Opus 4.5 <noreply@anthropic.com>
This is related to #2917
So far setting the luks= attribute on a live image build had
no impact to the generated ISO image. This commit adds the
encryption capability also for live ISO images. The read-only
part of the rootfs gets encrypted using the provided luks
passphrase. An eventual persistent storage area gets encrypted
at boot time if the rd.live.encrypt kernel cmdline parameters
is passed. encryption/decryption requires to interactively
set/provide passhphrase information at boot time. Please note
due to the read-only restrictions of an ISO image there is no
way to apply the standard re-encryption process as it is
usually performed by kiwi encrypted systems. As such the
specified luks passphrase in the kiwi image descriptions
becomes sensitive information that needs to be protected
To run pvattest perform an attestation request binary as
well as the corresponding attestation key and the secure
execution header is required. This data should be created
as part of the image build. In this commit we are adding
support for creating the attestation data when building
a secure execution enabled image
When specifying a filesystem attribute for a live image build,
the rootfs gets build directly into this filesystem instead of
being a squashfs wraped ext4 which is the default layout for
compatibility reasons. In this direct filesystem mode the
exclude list was not passed along to the filesystem creation
and causes unwanted metadata to be part of the final image.
This Fixes#2873
In case the kiwi-repart module is explicitly requested in a
dracut.conf file and the image is also configured to build an
install ISO image this leads the install ISO to contain the
kiwi-repart module as well which is unwanted. This commit
explicitly omits the kiwi-repart when creating the initrd
for the install image
Allow to specify a filesystem label as part of a <partition>
definition. So far the label was set by the name of the
partition. With the new label attribute, a filesystem label
different from the partition name can be set. This commit
also updates/fixes the documentation in this regard.
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>
In case a spare_part setup is combined with the root_clone feature,
the size calculation for the rootfs did not take the cloning into
account and lead to the wrong value. In addition when requesting
the spare part to be last and no size information was given, the
partition was not created at all. This commit fixes both defects
and Fixes#2831
Make sure the final image rootfs does not contain unneeded
metadata files used during build time. The respective cleanup
call is performed after the root sync and after all initrd/boot
processing has been done. This is because up to that point it's
still possible that the information is required. This means
when building images with a read-only rootfs, it might not be
possible that the metadata can be deleted due to a chicken&egg
situation. Furthermore the cleanup is applied to the disk
builder only as other builders do not really suffer from
this data and for the container builder the metadata can
also be used for the stackbuild feature when building images
derived from containers. This Fixes#2668
In addition to systemd_boot also add support for UKI creation
when grub is used. This includes the creation of a UKI image
via dracut in the same way as it's done for systemd_boot.
In addition an earlyboot grub script chainloads the UKI and
bypasses any written grub configuration. In Theory this should
also allow to use the shim loader for chainloading an UKI.
However I haven't done testing in this direction and I also
expect security issues with this approach because loading
any non signed data by shim is not expected to work. A new
profile named grub_uki_verity_erofs has been added to the
integration test that experiments with UKIs
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
So far no luck with the systemd verity generator. This
commit adds the parsing of /etc/veritytab in the existing
kiwi-verity dracut module and uses it in the overlayroot
integration test.
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.
If the root_clone attribute is specified without providing a
fixed size for the system, kiwi estimates the size needed for
the root part and assigns the rest to the clone. This leads to
different partition sizes for the root clones. As per definition
of a clone the expectation is that the size is the same, this
commit changes the behavior such that the calculated size for
the system is applied to the origin root and all its clones.
As a consequence this can leave unpartitioned space free in
the image. This Fixes#2463
Make sure to use the correct passphrase for the master
key such that it can be decrypted with the same credentials
as before. The credentials reset is a subsequent task
after reencryption.
Depending on the type setup for a luks encrypted image, there
might be one or two key slots available. When kiwi is requested
to perform the reencryption process at least one key-slot and
the proper keyfile/passphrase must be provided. This commit
stores the information about the key-slot number for which
a decryption information exists in the initrd. In addition to
the code change also the corresponding integration test image
was updated.
Installing the same image to different storage disks on the
same machine creates device conflicts with unexpected side
effects. This commit adds a validation based on the PTUUID
of the disk image to check if another device on the system
has the same ID and if yes, does not allow to install the
image again including a message which device takes the same
identifier. This references bsc#1228741
Added rd.kiwi.oem.luks.reencrypt boot option consumed by the
kiwi-repart dracut module. For OEM LUKS2 encrypted disk images.
If set, reencrypts the disk prior an eventual resize and therefore
creates a new key pool and master key. The reencryption is advisable
if the image binary is not protected. With access to the image
binary it's possible to extract the luks header which then allows to
decrypt the data unless it was reencrypted. The reencryption process
only runs if the checksum of the luks header still matches the one
from the original disk image. Be aware that the reencryption will
ask for the passphrase if the image has been built with an initial
luks passphrase.
Decommission the Checksum.md5() method and move all places
in code to sha256(). The md5 digest is considered insecure
and has also been removed from hashlib as a supported digest.
This Fixes#2696
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>
The code in this method does not work correctly if the
firmware is set to 'bios'. In bios only mode the method
returned a false value which is incorrect as it should
return a true value in this case. Without this patch
ISO images will fail to boot because no loader gets
configured.
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.
The existence of this file breaks installers on live media that
sync the full filesystem to disk and are not aware of this configuration
before generating the target system initramfs.
kiwi's initrd modules read a .profile file which gets included
into the initrd produced at build time. To allow rebuild of a
host-only initrd from the booted system this information should
be present such that it is possible to re-use kiwi initrd code.
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
Change the DiskFormat Factory to be a context manager.
All code using DiskFormat was updated to the following
with statement:
with DiskFormat(...).new as disk_format:
disk_format.some_member()
This is related to Issue #2412
Change the VolumeManager Factory to be a context manager.
All code using VolumeManager was updated to the following
with statement:
with VolumeManager(...).new as volume_manager:
volume_manager.some_member()
This is related to Issue #2412
Command.run() currently has a bit of a confusing behavior: if raise_on_error is
False and the executable is not found, then a weird CommandT is returned (return
code is -1 and stdout+stderr is None). This makes it possible to hanlde command
not found errors separately, but it makes that needlessly verbose. So instead,
let's just return None in *this* special case.
That in turn uncovered, that in most cases when we set `raise_on_error=True`, we
actually want an error if the command is not present but no error if the command
fails to execute (e.g. because it returns -1 if you run `$cmd --version`). Hence we
introduce the flag `raise_on_command_not_found`, which causes an exception to
be raised if the command is not found. This makes it independent of the
`raise_on_error` flag.
Additionally, we add a small optimization: if command starts with /, then we
assume it's a full path and we omit the call to which (and just check whether it
exists).
Co-authored-by: Marcus Schäfer <marcus.schaefer@gmail.com>
Allow specifying the filesystem for live image, also direct squashfs
By setting <type image="iso" filesystem="FSTYPE" .../> it's now possible
to specify the filesystem used for live images. By using "squashfs", the
rootfs container is skipped entirely.
Change the Disk class to be a context manager.
All code using Disk was updated to the following
with statement:
with Disk(...) as disk:
disk.some_member()
This is related to Issue #2412
SYSLINUX has been abandoned for several years now, and it does not
even work with modern versions of the filesystems supported in kiwi.
This commit drops it and Fixes#2433
Change the BootLoaderConfig class to be a context manager.
All code using BootLoaderConfig was updated to the following
with statement:
with BootLoaderConfig.new(...) as bootloader_config:
bootloader_config.some_member()
This is related to Issue #2412
In preparation to further context manager related changes
in VolumeManager, LuksDevice, RaidDevice and more the
disk builder code which uses these classes needs to be
refactored beforehand to allow switching to context
manager based cascading of the storage device classes.
This commit does the refactoring and is related to
Issue #2412
Change the FileSystem class to be a context manager. All code using
FileSystem was updated to the following with statement:
with FileSystem.new(...) as filesystem:
filesystem.some_member()
This is related to Issue #2412
