Bug#728486: Current patch for resolving lvm/systemd compatibility
Le Sat, 18 Jan 2014 10:43:30 +0100,
Laurent Bigonville <bigon@debian.org> a écrit :
> Hi,
After a small discussion with Bastian I realized that I was confused
with the generator and lvmetad (I should have done my homework a bit
more carefully).
> Just came here to add my 2¢ about this in the light of my recent
> experience I had with an other package (nut) where devices were not
> present when the daemon was starting.
>
> My initial solution was also to depends against udev-settle.service
> service. This was ensuring that the devices were present in /dev in
> some, but certainly, not all the cases, especially if the device was
> slow to initialize.
>
> After some discussion on #udev, it turns out that "udevadm settle" is
> merely flushing the queue of already generated events and it, of
> course, cannot guarantee in anyway that all the events have been
> generated by the kernel.
>
> So IMHO, adding udev-settle.service shouldn't be the long term
> solution, it will make things work in more case, but not all. And the
> correct solution is to have something like the generator that will
> allow to handle events when they are generated and not at one
> synchronization point during boot.
My concern of devices not being present in the /dev during boot is still
valid IMHO but can only be solved with the introduction of lvmetad (see:
#704759) and not the generator, but this is outside of the scope of this
issue. Sorry for the confusion.
But I still think that installing the generator has an added value when
lvmetad will be used. In this case the central volume group activation
will not be needed anymore as the job will be delegated to the daemon.
The generator will detect this and the .service will not be created,
that means that in this condition the call to udevadm trigger will be
omitted leading to a faster boot.
I unfortunately still doesn't understand on which technical ground the
installation of the generator is being refused and why debian should
diverge on what upstream is proposing.
Anyway I'm happy that this situation will be resolved and that our users
will have a more reliable boot when using LVM. I still think this is
not the optimal solution.
>
> My 2¢
>
> Laurent Bigonville
Reply to: