Re: On /dev/disk/by-id/ata-...-part2 missing, again

["Alexander E. Patrakov" <patrakov@gmail.com>]

27.10.2014 22:13, Lennart Poettering wrote:
> On Mon, 27.10.14 21:57, Alexander E. Patrakov (patrakov@gmail.com) wrote:
>
>> 27.10.2014 21:49, Lennart Poettering wrote:
>>> On Mon, 27.10.14 21:46, Alexander E. Patrakov (patrakov@gmail.com) wrote:
>>>
>>>> Some time ago, I have complained that some boots are unsuccessful, because
>>>> the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which
>>>> should point to /dev/sda2) is not created by udev in the initramfs (which
>>>> uses dracut). Thankfully, people on IRC have suggested some useful debugging
>>>> options:
>>>>
>>>> systemd.log_level=debug rd.udev.log-priority=debug
>>>>
>>>> So now I have a SOS report. It is over 1 MB, so not attached. The useful
>>>> lines are:
>>>>
>>>> [    3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda),
>>>> skipping event handling: Resource temporarily unavailable
>>>> [    3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda),
>>>> skipping event handling: Resource temporarily unavailable
>>>>
>>>> Let me complain here that these error messages still don't contain the
>>>> complete picture. How am I supposed to know which program in my
>>>> dracut-created initramfs locks /dev/sda and interferes with udev event
>>>> handling?
>>>
>>> Most likely you are either using a too old util-linux, whose use of
>>> BSD locks conflict's with udev's use of it. (fsck -l)
>>>
>>> Please always check README, it will let you know precisely which
>>> release of util-linux you need at least.
>>
>> I use fsck from util-linux 2.25.1. Verified by extracting the initramfs.
>> According to the README, this version should be OK, so it must be something
>> else.
>
> Hmm, please use "lslocks" or /proc/locks to figure out which process
> might have the device nodes locked.

OK, after playing with /etc/ld.so.preload and shared libraries, I found 
the bad guy. It is multipathd from multipath-tools-0.5.0. I don't use 
multipath-tools on this desktop, but know why they are here (kpartx was 
needed at one time in order to debug a partition table issue with a disk 
image, but now I would probably use a partitioned loop device for the 
same task). Now they are definitely unneeded.

Removed them, but please consider putting a warning in the systemd 
README file on the incompatibility. As there are no locking-related 
commits in the multipath-tools repository since 0.5.0, this is 
definitely not a packaging bug.

-- 
Alexander E. Patrakov
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel