* Re: On /dev/disk/by-id/ata-...-part2 missing, again
[not found] ` <20141027171335.GV16250@gardel-login>
@ 2014-10-27 18:49 ` Alexander E. Patrakov
0 siblings, 0 replies; only message in thread
From: Alexander E. Patrakov @ 2014-10-27 18:49 UTC (permalink / raw)
To: Lennart Poettering; +Cc: dm-devel, systemd Mailing List
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
^ permalink raw reply [flat|nested] only message in thread