Bug 690308
Summary: | error: "should had been created by udev but it was not found" | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | G. Michael Carter <mikey> | ||||
Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 15 | CC: | agk, bmarzins, bmr, dwysocha, harald, heinzm, jonathan, lvm-team, mbroz, moli, msnitzer, prajnoha, prockai | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-04-11 15:21:13 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
G. Michael Carter
2011-03-23 20:40:12 UTC
This may be related to by dbus not starting as well in bug: 689861. Not sure. are you sure udevd is running? I'm assuming it is: [root@liandra ~]# ps -ef | grep udev root 488 1 0 Mar23 ? 00:00:00 /sbin/udevd root 18778 18319 0 09:12 pts/1 00:00:00 grep --color=auto udev [root@liandra ~]# lvcreate -L 10G -n Test LiandraStore /dev/mapper/LiandraStore-Test not set up by udev: Falling back to direct node creation. The link /dev/LiandraStore/Test should had been created by udev but it was not found. Falling back to direct link creation. Logical volume "Test" created [root@liandra ~]# lvremove LiandraStore/Test Do you really want to remove active logical volume Test? [y/n]: y Logical volume "Test" successfully removed semid 98304: semop failed for cookie 0xd4d613a: incorrect semaphore state Failed to set a proper state for notification semaphore identified by cookie value 223174970 (0xd4d613a) to initialize waiting for incoming notifications. Any further tests I ran run to verify it is running correctly? any ideas from the lvm team, what's going wrong here? This usually means, that you are using udev-enabled lvm (default in Fedora) but there are missing lvm udev rules (explicitly rule with "dmsetup udevcomplete" call, 95-dm-notify.rules). lvm will fallback to manual node removal (I think that the warning is about semaphore state is some minor bug in lvm code but it is just consequence - if udev rules missing, your system is simply misconfigured.) Verify, that device-mapper is properly installed. To diagnose it, please run the lvm command with -vvvv and add output here. Created attachment 488442 [details]
Verbose lvcreate command
Also verified the /lib/udev/rules.d/95-dm-notify.rules is the same in F15 as it is in other releases. What's the kernel version used? Is this a stock Fedora kernel? Yes it's stock. 2.6.38-1.fc15.x86_64 Well, based on the log, uevent was not generated correctly: " Uevent not generated! Calling udev_complete internally to avoid process lock-up." This decrements the value of the semaphore used for synchronization. However, if the event (for some reason) *is* generated despite the fact that the kernel function responsible for sending the uevent reports a failure and then we decrement the value once again from within the udev rules based on the generated event (/lib/udev/rules.d/95-dm-notify.rules), we can end up with that: "semid 32768: semop failed for cookie 0xd4d83af: incorrect semaphore state..." The other messages about "... not set up by udev. Falling back to direct node creation" is just a consequence of failed synchronisation with udev (since we decremented semaphore value prematurely). However I'm not quite sure now why this happens. It could be a bug in kernel code as well... (but I can't reproduce that) you might also try the new udev version in F15 New version in F15 seems to have solved the problems. |