On Wed, Jul 28, 2021 at 10:17:56PM +0200, Michael Biebl wrote: > On Wed, 28 Jul 2021 18:09:58 +0200 Dennis Filder <d.fil...@web.de> wrote: > > X-Debbugs-CC: Martin-Éric Racine <martin-eric.rac...@iki.fi> > > > > A couple of observations: > > > > * You have tpm2-abrmd installed, and its systemd unit is the only one > > defining a Requires=systemd-udev-settle.service. 2.1.0-1 under > > Buster didn't do that yet, so this could be the breaking change. As > > its manpage states systemd-udev-settle.service as a unit is > > conceptually problematic because udev events are never really > > settled; the unit is also deprecated, so tpm2-abrmd should correct > > its systemd/udev definitions. > > Just a general remark that using Requires/After=systemd-udev-settle.service > is a really bad idea. > > Whenever possible, you should avoid using it. > > Quoting from the systemd-udev-settle.service man page > > "Using this service is not recommended. There can be no guarantee that > hardware is fully discovered at any specific time, because the kernel does > hardware detection asynchronously, and certain buses and devices take a very > long time to become ready, and also additional hardware may be plugged in at > any time. Instead, services should subscribe to udev events and react to any > new hardware as it is discovered. Services that, based on configuration, > expect certain devices to appear, may warn or report failure after a > timeout. This timeout should be tailored to the hardware type. Waiting for > systemd-udev-settle.service usually slows boot significantly, because it > means waiting for all unrelated events too."
Here is what upstream did for this issue: https://github.com/tpm2-software/tpm2-abrmd/pull/755 cu Adrian