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
Change the LoopDevice class to be a context manager.
All code using LoopDevice was updated to the following
with statement:
with LoopDevice(...) as loop_provider:
loop_provider.some_member()
This is related to Issue #2412
Create proper EFI FAT image via bootctl to be used as
alt loader in xorriso. This allows to boot the ISO
via EFI e.g kvm -bios /usr/share/qemu/ovmf-x86_64.bin -cdrom file.iso
Please note, hybrid boot is done via grub's hybrid MBR and
as systemd-boot does not provide one, hybrid boot is out
of scope yet. This Fixes#2281
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
As consequence of using the "source" grub command instead
of the "configfile" command to load the grub config we now
see double loading of the same file on ISO media. The reason
here is that kiwi ISO media is always hybrid which means it
embeds an MBR into the ISO for which the "source" command now
can read the same file through two different device paths.
This does not happen with the "configfile" grub command.
Thus this patch uses "configfile" if we produce an ISO image
and "source" for all other image types. The commit also fixes
the custom grub template used for ISO images in a way that
we only set the "serial" command if there is a serial
configuration provided along with the image description.
In case of btrfs and if btrfs_set_default_volume is explicitly
switched off, we create the correct rootflags= kernel cmdline
entry to tell the system about the root volume for booting
The keyfile path was not correctly set in etc/crypttab which
caused systemd not being able to read the keyfile, consequently
asking for a passphrase. This commit fixes the writing of the
crypttab and also fixes a python name clash with the "os"
namespace.
In some configuration (eg on a transactional system), the root
file system is read-only, which means we will not be able to remove
the stale .root.keyfile after firstboot.
This patch changes the location of the keyfile and places it in
/root/.root.keyfile instead, because root's home directory is much
more likely to be read/write.
Also fixed the associated unit test (thanks to schaefi).
Signed-off-by: Olaf Kirch <okir@suse.com>
In case an alternative partition table start sector is
configured, the check to effectively apply it should be
based on the partition table type not on the firmware
name
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.
The device selection for the read-only and read-write devices
in an overlayroot setup was implicitly done in the kiwi-overlay
dracut module by reading the root= information. This is a
concept which barely works and should be refactored in a way
that the root= information always points to the root device
and that an eventually existing write location is explicitly
provided via the existing rd.root.overlay.write parameter
which is allowed to be overwritten for providing an alternative
write location. Making this information consistent and explicit
on the kernel commandline simplifies the dracut code to
consume this information correctly. This Fixes#2251
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
In kiwi we support handling of the container archive compression
via a runtime configuration setting of the following form, eg
in /etc/kiwi.yml
```yaml
container:
# Specify compression for container images
# Possible values are true, false, xz or none.
- compress: true
```
However, this setting was only taken into account in the kiwi
bundler. Meaning if the user calls 'kiwi result bundle ...'
after the container image has been created the result bundler
will take the compression setting into account. From my perspective
this behavior is misleading and also prevents users from
creating compressed container archives without a subsequent
result bundler call. Therefore this commit moves the place to
handle the compression setting into the container classes.
The bundler code for containers will no longer operate on it
and just takes what it gets, which can be either compressed
or not. The default setting was "No compression" and this
was not changed. This Fixes#2217
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!
In case a clone should be created from a partition we need
to make sure to umount the device after sync and prior cloning.
Otherwise the clone operation is not safe because the rsynced
data might still be in memory and not synced out to the block
device.
The attribute disk_start_sector allows to specify a custom
start sector for the first partition of the disk. On GPT
tables everything works nicely, on DOS tables the used tools
fdisk/sfdisk are not able to manage the start/end values of
subsequent partitions if the first partition doesn't start
with the tooling default. This patch allows to set the
start sector after the partition table has been created
When using squashfs in a custom partitions setup like the following:
<partitions>
<partition ... filesystem="squashfs"/>
</partitions>
The build fails because the filesystem needs to be created
using the create_on_file() API and not the create_on_device()
API. In addition the size estimation is bogus when using
squashfs and cannot be pre-calculated because we only know
how much space the filesystem really needs after mksquashfs
as worked on the data and the compression. Thus this commit
also relaxes the required size check in case of squashfs.
Last but not least a squashfs filesystem does not provide
label or UUID and can only be referenced by the PARTUUID
it gets dumped on or by the native unix device node. As
the unix node is a loop during build time of the image and
meaningless this commit also forces by-partuuid mapping in
fstab when mounting the squashfs based device.
isolinux-config is called to update the search path inside
of the isolinux binary. isolinux/syslinux is exclusive to
the ix86 architecture and to BIOS firmware. Therefore the
condition to actually call it should reflect this.
Support creating block level clones of certain partitions
used in the image. Clones can be created from the root, boot
and any partition listed in the <partitions> element.
There is a method called setup_isolinux_boot_path which is
encoded in the Iso class. The method allows to change the
boot path in the isolinux binary and makes sense when the
bootloader is selected to be isolinux. However, the method
was called in the scope of the FileSystemIsoFs class which
responsibility is to create an ISO filesystem. The creation
of an ISO filesystem has no direct connection to a bootloader.
Thus calling this method in the scope of the FileSystemIsoFs
implementation is wrong and can lead to unexpected side
effects. This commit moves the call of the method to the
places where isolinux as a bootloader can still be used.
This Fixes#2117
There is support in kiwi to use dm_integrity in combination
with the LUKS header and dm_crypt. However there is also the
use case to setup dm_integrity in standalone mode. This commit
allows to create the dm_integrity layer outside of LUKS using
/etc/integritytab to activate the map through a systemd
generator if systemd is used.
Regarding systemd it's required to use a version of system which
provides: system-generators/systemd-integritysetup-generator.
If this generator does not exist in the distribution it will
also be missing in the dracut generated initrd and the boot
will not be able to succeed. It's mentioned here because even
newer distributions might be missing the generator
Along with the implementation there are two new optional
attributes in the <type> section:
standalone_integrity="true|false"
embed_integrity_metadata="true|false"
standalone_integrity activates/deactivates the dm_integrity map
on top of the root filesystem. Similar to the veritysetup support
there is the opportunity to create an embedded magic metadata
block at the end of the device containing the root
filesystem via embed_integrity_metadata
The Disk class provides methods to create partition(s)
and map names according to its scope and independent of
the actual partition tools. For example: create_root_partition().
This commit adds an additional optional clone parameter to
all methods for which we want to allow partition clones
Since #1759 was merged, the contents of /run/ and /tmp/ are excluded from
built images. This causes problems for some containers, notably Ceph when
deployed in a Rook/k8s environment, which needs to have certain directories
present inside /run/. This commit adds the ability to return to the previous
behaviour and *not* empty those temporary directories, if you specify
<image><preferences><type [...] ensure_empty_tmpdirs="false">.
Fixes: https://github.com/OSInside/kiwi/issues/2093
Signed-off-by: Tim Serong <tserong@suse.com>
Specifies to write a binary block at the end of the
partition serving the root filesystem, containing information
for dm_verity verification and to construct the device map
In addition to by-label and by-uuid also support mounting
by PARTUUID. Please note kiwi also makes sure that the grub
generated config file uses the root=PARTUUID= notation and it's
not clear if grub-mkconfig will persist making use of it.
Nevertheless there are also systems which uses different
methods to boot and it makes sense to support partuuid
mappings as well
