my expectation is that udev should be running (somewhere, not sure if it needs to be both the host and the lxd guest) and that it should process the device using locks https://systemd.io/BLOCK_DEVICE_LOCKING/.
After that is done, the device should be safe to operate on, in a consistent manner.
After all,
-P, --partscan
Force the kernel to scan the partition table on a newly created
loop device. Note that the partition table parsing depends on
sector sizes. The default is sector size is 512 bytes, otherwise
you need to use the option --sector-size together with --partscan.
Is only asking kernel to scan the device; to then generate "kernel udev" events; for then udev to wakeup and process/emit "udev udev" events; and create the required device nodes.
We have always been fixing and supporting running udev inside the lxd containers, because of such things (in contexts of priviledged containers, but outside of lp-buildd) to make all of this work.
my expectation is that udev should be running (somewhere, not sure if it needs to be both the host and the lxd guest) and that it should process the device using locks https:/ /systemd. io/BLOCK_ DEVICE_ LOCKING/.
After that is done, the device should be safe to operate on, in a consistent manner.
After all,
-P, --partscan
Force the kernel to scan the partition table on a newly created
loop device. Note that the partition table parsing depends on
sector sizes. The default is sector size is 512 bytes, otherwise
you need to use the option --sector-size together with --partscan.
Is only asking kernel to scan the device; to then generate "kernel udev" events; for then udev to wakeup and process/emit "udev udev" events; and create the required device nodes.
We have always been fixing and supporting running udev inside the lxd containers, because of such things (in contexts of priviledged containers, but outside of lp-buildd) to make all of this work.