<div dir="ltr">Thanks, finally got around to rebooting, and udev now starts properly. However, when the cleanuphook calls "udevadm control --exit", it takes quite a while (though the system later boots normally). With --debug enabled, I see:<div><br></div><div>> udevd message (EXIT) received</div><div>> [10-20 seconds pass]</div><div>> timeout, giving up waiting for workers to finish</div><div><br></div><div>I tried running it manually from the initramfs shell, and udev had no workers at all at that point.<br><div><br></div><div>This is with the latest 185abfc3d6b build.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 24, 2015 at 4:30 PM, Tom Gundersen <span dir="ltr"><<a href="mailto:teg@jklm.no" target="_blank">teg@jklm.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mantas,<br>
<div><div class="h5"><br>
<br>
<br>
On Sun, May 24, 2015 at 11:40 AM, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> wrote:<br>
> So, udev v220 crashes in my initramfs with the following message:<br>
><br>
>> starting version v220<br>
>> Assertion 'manager->pid == getpid()' failed at src/udev/udevd.c:568,<br>
>> function ev<br>
>> Aborting.<br>
><br>
> It seems main calls manager_new() before forking, so the parent PID is<br>
> stored instead of child PID.<br>
><br>
> (I'm using Arch Linux with the traditional mkinitcpio-based initramfs, which<br>
> starts udev using "systemd-udevd --daemon --resolve-names=never".)<br>
<br>
</div></div>Thanks for the report. This should be fixed now in git, please let me<br>
know if that is not the case.<br>
<br>
Cheers,<br>
<br>
Tom<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div>