Zbigniew Jędrzejewski-Szmek
a8040b6d0a
Fixes #10526. Even if we waited for the root device to appear, the mount could still fail if we didn't wait for udev to initalize the device. In particular, the /dev/block/n:m path used to mount the device is created by udev, and nspawn would sometimes win the race and the mount would fail with -ENOENT. The same wait is done for partitions, since if we try to mount them, the same considerations apply. Note: I first implemented a version which just does a loop (with a short wait). In that approach, udev takes on average ~800 µs to initialize the loopback device. The approach where we set up a monitor and avoid the loop is a bit nicer. There doesn't seem to be a significant difference in speed. With 1000 invocations of 'systemd-nspawn -i image.squashfs echo': loop (previous approach): real 4m52.625s user 0m37.094s sys 2m14.705s monitor (this patch): real 4m50.791s user 0m36.619s sys 2m14.039s
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.