Bug#786942: upgrade-reports: wheezy -> jessie boot lock up "A start job is running for udev wait for Complete Device Initialization"

[Niels Thykier]

reassign 786942 systemd,udev
retitle 786942 systemd,udev: Long boot-time with systemd-udev-settle
thanks

Dear systemd maintainers,

I am reassigning this upgrade report to you, in the hopes that you can
solve it (or point us in the right direction).  Please be sure to notify
me explicitly if you reassign it back to "upgrade-reports".

Quick summary:

 * Karl (CC'ed) reported really long boot times (+10 minutes) after
   upgrade. He had already found a work around by masking the service
   systemd-udev-settle.service
 * I advised Karl to purge acpid based on the recommendation in the
   release-notes plus [archbug#43023], which suggested that acpid with
   systemd-udev-settle.service caused this (and other) issue(s).
 * Karl unmasked the service and purged acpid.  The boot time is now
   reasonable, but we still see two services with a questionable long
   boot time:
   - systemd-udev-settle.service: 18+ seconds
   - nut-driver.service: 11+ seconds

[archbug#43023]: https://bugs.archlinux.org/task/43023

The following is a quote of Karl's lasted reply to this bug.

On 2015-05-27 22:14, Karl Schmidt wrote:
> On 05/27/2015 12:18 AM, Niels Thykier wrote:
>> On 2015-05-27 04:26, Karl Schmidt wrote:
>>> Package: upgrade-reports
>>> Severity: important
>>>
>>> I was able to boot by selecting an older kernel - I then was able to
>>> run:
>>> # systemctl mask systemd-udev-settle
>>>
>>> and 3.16.0-4-amd64 now boots.
>>>
>>> This apparently is related to Intel + ssd (drive details below)
>>>
>>> I found bread crumbs here -
>>> https://bbs.archlinux.org/viewtopic.php?id=189106
>>>
>>> But in this case it just hung for over 10min.  I would be glad to
>>> provide more
>>> information if needed and test fixes. Please be specific.
>>>
>>> [...]
>>>
>>>
>>
>> Hi Karl,
>>
>> Thanks for taking the time to report an upgrade report.
>>
>> I can see that the archlinux report (link found in the forum posts)
>> suggests this is a problem between ACPI and systemd/udev.  If you have
>> acpid installed, have you tried to uninstall acpid and unmask
>> systemd-udev-settle?
>>
>> Note we have a issue between acpid and logind noted in our release
>> notes[1].
> 
> OK - I did the following
> 
> # systemctl unask systemd-udev-settle
> # dpkg --purge acpid
> 
> This lets it boot - but there is now a long delay as seen here from
> the top of # systemd-analyze blame
> 
>         18.124s systemd-udev-settle.service
>          11.393s nut-driver.service
>           4.151s systemd-fsck at dev-md6.service
>           3.508s accounts-daemon.service
> <snip>
> 
> verses with systemd-udev-settle masked
> 
>          16.651s nut-driver.service
>            351ms dphys-swapfile.service
> 
> (the nut-driver should not be so slow either ..)
> 
> My searches on systemd-udev-settle masked tell me it is about "fake
> block device storage technology" (in my case mdadm - the raid)
> 
> 
> I don't really need acpid on this system - it would be nice if it booted
> faster like it did.
> 
> Something is still broken - I suspect it has to do with the boot from a
> pair of raid-1 solid state drives (acpid gets confused by trying to
> monitor the fake block device?) .
> 
> Hope this has been helpful anyway.
> 
> 
> 
> --------------------------------------------------------------------------------
> 
> Link to our website and get free US-48 shipping on your next order.
> 
> Karl Schmidt                                  EMail Karl at xtronics.com
> Transtronics, Inc.                              WEB
> https://secure.transtronics.com
> 3209 West 9th Street                             Ph (785) 841-3089
> Lawrence, KS 66049                              FAX (785) 841-3089
> 
> Ignorance is not an opinion!
> - Dilbert
> --------------------------------------------------------------------------------
> 
> 
>