I updated my livecd-rootfs PPA test package that runs this section of code in a loop to use this pattern, and it survived until the autopkgtest timeout - 304 iterations:
...when it previously was failing reliably within a few iterations.
They `udevadm lock` fix is now in unstable, so the next sync should pull it in.
However, I don't know that we really need any features of `udevadm lock` beyond the actual flock'ing of the device. We could presumably do that with `flock` for older releases. Or we could consider SRU'ing back the udevadm lock command to jammy as a low priority SRU. The way it was introduced looks very non-invasive: https://github.com/systemd/systemd/commit/8b12a516e9304f720e07eeec5d25c5b7f7104bc9
But I haven't gone through the bug fixes since to ensure it remained that way.
I updated my livecd-rootfs PPA test package that runs this section of code in a loop to use this pattern, and it survived until the autopkgtest timeout - 304 iterations:
https:/ /autopkgtest. ubuntu. com/results/ autopkgtest- noble-dannf- loop/noble/ amd64/l/ livecd- rootfs/ 20240128_ 061640_ 5c909@/ log.gz
...when it previously was failing reliably within a few iterations.
They `udevadm lock` fix is now in unstable, so the next sync should pull it in.
However, I don't know that we really need any features of `udevadm lock` beyond the actual flock'ing of the device. We could presumably do that with `flock` for older releases. Or we could consider SRU'ing back the udevadm lock command to jammy as a low priority SRU. The way it was introduced looks very non-invasive: /github. com/systemd/ systemd/ commit/ 8b12a516e9304f7 20e07eeec5d25c5 b7f7104bc9
https:/
But I haven't gone through the bug fixes since to ensure it remained that way.