This module provides a `Disk` class that can be used
to read in LVM images and explore and manipulate its
metadata directly, i.e. it reads and writes the data
and headers directly. This allows one to rename an
volume group without having to involve the kernel,
which does not like to have two active LVM volume
groups with the same name.
Normally `DeviceService.close` would be called when the connection
was closed on the other end. Expose that close method via RPC so
that clients can call it explicitly. This should be mostly useful
in testing.
Implement a new `lock` option (default: False), which will lock
the device by passing `lock=True` to `LoopControl.loop_for_fd`.
The main purpose for this is to block udev from probing the device
while the stage is run.
NB: some tools might also try to lock the device and fail.
Explicitly clear the fd. There might be a race with udev or some
other process that still as a reference to the loop device so we
might not be able to immediately clear it. Thus wait for it with
a timeout of 30 seconds which should hopefully be enough. If the
device does not clear then any consecutive action that involves
it might not be safe to execute so we let the timeout exception
be reported to osbuild.
Add support for locking the loopback block device via `flock(2)`.
The main use case for this is to prevent systemd-udevd from
proben the device while any modification is done to it. See the
systemd page, https://www.freedesktop.org/software/systemd, for
more details.
Add the corresponding tests to it.
Add a helper method that clears the fd for a given loop device but
also ensures that the loop device is not bound to the supplied fd
anymore. Check the function documentation for more information.
Add a corresponding test.
Add a `Loop.is_bound_to` helper that checks if the looback device is
bound if is so if the backing file refers to the same file as `fd`.
The latter is done by comparing the device and inode information.
Add a helper that will check if the loop devices is backed by
the file identified via the stat(2) result, i.e. the inode on
the correspoding device.
Add a correspoding test for the new helper.
Implement a `Loop.get_status` method, to get the properties of the
loop device, corresponding to LOOP_GET_STATUS64, and counterpart
to the existing `Loop.set_status` method. Use the new `get_status`
call in the `set_status` call, replacing the existing code that
does the same thing.
Add a basic test for the `get_status` method. Also fix an actual
leak, where the loop device was closed but the fd was not cleared
inside the test.
Add a new helper, `loop_for_fd` that will get (or create) an
unbounded loop device, bind it to an fd and then set its
status. Since this is racy and can fail the method does these
steps in a retry-loop.
Add a `close` method to the loop controller class `LoopControl` since
it actually opens a file descriptor, which should be closed once the
loop controller is no longer needed.
Assert that the controlling file descriptor is open for all methods
that require this.
When the partition layout is `dos` or `mbr`, the correct name for
it in the prefix is `msdos`. The function to convert the option
to the label already existed but was not used. Fix it by actually
using said function.
Reported-by: Achilleas Koutsou <achilleas@koutsou.net>
The location property is required, otherwise the stage will fail due to
KeyError at line 261:
location = options["location"]
This commit adds the property to the list of required ones.
Getting unbound loop devices is racy, so we do it in a retry loop:
in case of a recoverable error, like when the loop device signals
it is busy, we close the it and try another one. Indeed the code,
closed the loop device but did in fact not open a new one and we
would therefore see file descriptor cannot be a negative integer
errors when trying in `lo.set_fd(fd)` since `lo` is in fact closed
now and thus indeed '-1'.
Open a new loop device at the beginning of the retry-loop to fix
this issue.
Add back a schema constrain, that at least one configuration must be
specified for the configuration file.
This has been forgotten/missed as part of
https://github.com/osbuild/osbuild/pull/739.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Show the file descriptor that was opened for the file passed to
the device. Recently, in CI, we have seen errors opening the
loop device with `fd` being `-1` and this ensures that at least
the file itself could be opened.
Include a simple test for the `tar` stage that does basic checks,
i.e. that a tarball was successfully created, but also checks
that we do not create entries with a `./` prefix.
When building the tar archive, the command that is used normally
includes the root node as `./` and also leads to all files having
a "./" prefix. On the other hand, the oci stage as well as the
old ostree.commit assembler, with the tarball option, would
enumerate the contents instead of passing `.`, thus not including
the rood node and also avoiding the `./` prefix.
Add a new option `root-node` that controls whether the rood node
is included or node.
mkdir test
touch test/file
tar -c -C test file | tar tv
-rw-r--r-- root/root 0 2021-07-22 10:39 file
tar -c -C test . | tar tv
drwxr-xr-x root/root 0 2021-07-22 10:39 ./
-rw-r--r-- root/root 0 2021-07-22 10:39 ./file
Create a new `org.osbuild.systemd.unit` stage with the code for
create systemd drop-ins extracted from `org.osbuild.systemd`.
In contrast to the old code the new stage can only handle one
drop-in file. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top level comment.
The file is called `org.osbuild.systemd.unit` since in the future
it could also support creating unit files (not just drop-ins).
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top level comment.
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top level comment.
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top-level comment.
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify the directory, `/etc` vs `/usr` via a new
top level `directory` key.
