Since udev will probe block devices it is advisable to hold a lock
on the device when modifying its partition table or the superblock
of the filesystem (see [1]). osbuild loopback devices do support
this via the `lock` option. Set this option for all operation that
involve changing block device "metadata" that could potentionally
race with udev, such as sfdisk, mkfs, creating a luks2 container
and creating LVM2 volume groups and logical volumes.
NB: osbuild also has its own device inhibition logic to prevent
udev/lvm2 from auto activating devices and in general to limit the
interaction between the host and devices used by osbuild. See [2]
for more information.
NB: this also locks the loopback device in situation where we the
it is strickly not the right thing to do, e.g. when creating a fs
on a logical voume that is located on a loopback device, since in
this case the device we would need to lock is the logical volume.
Sadly, LVM/DM devices are exempt from block device locking. But,
due to a bug in osbuild < 50, the udev inhibitor does *not* work
for loopback devices and therefore we have to use the actual lock
to preven LVM device auto-activation via `69-dm-lvm-metad.rules`.
The change was implemented by adding a new boolean to `getDevices`
indicating if the loopback device should be locked or not. Once
we depend on osbuild 50 we can change the logic in `getDevices`
to only lock the loopback device if the number of devices is one,
i.e. we are working directly on the loopback device.
[1] https://systemd.io/BLOCK_DEVICE_LOCKING/
[2] /usr/lib/udev/rules.d/10-osbuild-inhibitor.rules
This should be called at the end of the pipeline that creates an
image, to add stages that are needed to finish up the image.
Currently the only stage that will be added is the `lvm2.metadata`
stage in the case the partition layout contains LVM2.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Add a new method to create all necessary stages to create the
devices for a given `PartitionTable`.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Refactor GenMkfsStages to work with entity based methods so that it is
now able to handle all generic cases of arbitrarily nested devices.
Co-Authored-By: Christian Kellner <christian@kellner.me>
osbuild, starting with version 31, supports for nesting of devices,
i.e. any device can have a parent device. See osbuild commit 45d0594
Co-Authored-By: Christian Kellner <christian@kellner.me>
Devices unlike stage options, shouldn't be stage specific.
There is only one type of device so far, the loopback device, which
is already defined as a separate type.
The top level Devices type is simply an alias to a Device map.
The mkfs stages require a single device with a specific key ("device").
These stages accept only one device in their NewStage() function for
convenience and create the Stage struct with the required key.
The zipl.inst stage requires a device labeled 'disk' as well as the rest
of the devices that correspond to each partition. The disk device is
passed to the New stage function separately and added to the Stage
devices with the required key.
Signed-off-by: Achilleas Koutsou <achilleas@koutsou.net>
