Comment 14 for bug 625395

So I enabled udev debugging (to info level) and lvm debug and attached the log.

It's a bit difficult to tell because the time skew in the log looks pretty small - certainly not the ~90 seconds I get during a normal boot.

There doesn't look like too much helpful in there, there are a splurge of errors of the form:

Feb 18 16:25:18 major libvirtd: 16:25:18.643: error : udev_device_read_db:251 : no db file to read 0: No such file or directory#012
Feb 18 16:25:18 major libvirtd: 16:25:18.643: error : udev_device_new_from_syspath:445 : device 0x7fff6c002c80 has devpath 'H<85>ÀH<89>Å#017<84>î'#012

Feb 18 16:25:18 major libvirtd: 16:25:18.644: error : udev_device_read_db:295 : device 0x7fff6bffebd0 filled with db file data#012
Feb 18 16:25:18 major libvirtd: 16:25:18.644: error : udev_device_new_from_syspath:445 : device 0x7fff6c002c80 has devpath 'H<85>ÀH<89>Å#017<84>î'#012

There is also a couple of:

Feb 18 16:25:18 major libvirtd: 16:25:18.465: error : virRunWithHook:855 : internal error '/sbin/vgchange -ay main' exited with non-zero status 5 and signal 0:
Feb 18 16:25:18 major libvirtd: 16:25:18.465: error : storageDriverAutostart:86 : Failed to autostart storage pool 'main': internal error '/sbin/vgchange -ay main' exited with non-zero status 5 and signal 0:

it's not obvious to me why libvirtd is getting involved at that point (many of the LVM partitions under main are vm guests - but none of the VMs start at boot).