Let's use our new path_extract_filename() for extracting the basename
from a path in a safe fashion.
Let's do this for all our three local import calls.
Let's simplify things and drop the logic that /var/lib/machines is setup
as auto-growing btrfs loopback file /var/lib/machines.raw.
THis was done in order to make quota available for machine management,
but quite frankly never really worked properly, as we couldn't grow the
file system in sync with its use properly. Moreover philosophically it's
problematic overriding the admin's choice of file system like this.
Let's hence drop this, and simplify things. Deleting code is a good
feeling.
Now that regular file systems provide project quota we could probably
add per-machine quota support based on that, hence the btrfs quota
argument is not that interesting anymore (though btrfs quota is a bit
more powerful as it allows recursive quota, i.e. that the machine pool
gets an overall quota in addition to per-machine quota).
Let's handle tarball imports nicer that have a single top-level
directory containing the OS tree: let's move everything down during
import, so that the OS tree is ready to use automatically.
Fixes: #2116
Fixes: #2728
This is also supposed to be preparation for doing #10234 eventually,
where a very similar operation is requested: instead of importing a tree
to /var/lib/machines it would need to be imported into
/var/lib/portables/.
This adds two optional functions that may be passed to the various copy
functions. One is invoked whenever we start copying a new file object,
the other while we copy file payload in each loop iteration.
When the caller passes one or both they can get notifications about copy
progress, for example to log where things are.
We invoke this usually on a temporary path before renaming it into
place. This means the log message is quite suprising as it mentions a
weird path with random characters in it. Hence, let's downgrade the
message in order not to confuse the user.
Otherwise a "reboot" or "poweroff" in the initramfs will have to wait
until systemd-fsck-root.service has completed, which might never happen
if the root device never shows up.
This is to startswith() what PATH_STARTSWITH_SET() is to
path_startswith().
Or in other words, checks if the specified string has any of the listed
prefixes, and if so, returns the remainder of the string.
Before c4b69e990f, if the socket fd is
passed from pid1, `udev_monitor_set_receive_buffer_size()` (now it is
a wrapper of `sd_device_monitor_set_receive_buffer_size()`) was not
called. Let's preserve the original logic.
Before c4b69e990f, if the socket fd is
passed from pid1, `udev_monitor_enable_receiving()` (now it is a wrapper
of `device_monitor_enable_receiving`) was not called.
Let's preserve the original logic.
Fixes#10754.
Unfortunately, f5f9a580dd didn't help much and now
the next subtest gets stuck from time to time. Let's skip
test-execute altogether so as not to bother anybody with
spurious failures.
https://github.com/systemd/systemd/issues/10696 is still open.
Everybody is welcome to share ideas :-)