vgchange will create the device mapper table entries before exiting, so that part should be taken care of. After it's finished, udev will create the device nodes and symlinks as it gets the information about the new dm nodes from the kernel.
From the vgchange manpage:
--noudevsync Disable udev synchronisation. The process will not wait for notification from udev. It will continue irrespective of any possible udev processing in the background. You should only use
this if udev is not running or has rules that ignore the devices
LVM2 creates.
Note that the above snippet doesn't say anything about udev waiting on vgchange, just the reverse. And I agree udev is the "user" here, as I already noted in #19. ;)
All failure modes I've seen (missing device nodes, 60 second boot times, etc) were variations on either udev killing vgchange after a timeout, udev getting killed before it could kill vgchange, handover issues between the initramfs udev instance and the main udev instance with vgchange interupted or still deadlocked, etc. All of them were solved by removing the vgchange deadlock.
The only remaining issue I see is that udevcomplete_all can't function reliably in this scenario (as you say) because the events that result from vgchange's actions are handled asynchronously. It might be that vgchange passes some udev cookies to solve that issue, but that seems unrelated to the above option.
vgchange will create the device mapper table entries before exiting, so that part should be taken care of. After it's finished, udev will create the device nodes and symlinks as it gets the information about the new dm nodes from the kernel.
From the vgchange manpage:
--noudevsync
Disable udev synchronisation. The process will not wait for
notification from udev. It will continue irrespective of any
possible udev processing in the background. You should only use
this if udev is not running or has rules that ignore the devices
LVM2 creates.
Note that the above snippet doesn't say anything about udev waiting on vgchange, just the reverse. And I agree udev is the "user" here, as I already noted in #19. ;)
All failure modes I've seen (missing device nodes, 60 second boot times, etc) were variations on either udev killing vgchange after a timeout, udev getting killed before it could kill vgchange, handover issues between the initramfs udev instance and the main udev instance with vgchange interupted or still deadlocked, etc. All of them were solved by removing the vgchange deadlock.
The only remaining issue I see is that udevcomplete_all can't function reliably in this scenario (as you say) because the events that result from vgchange's actions are handled asynchronously. It might be that vgchange passes some udev cookies to solve that issue, but that seems unrelated to the above option.