Bug 667710
| Summary: | Incorrect rule matching in dlm udev rules | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Whitehouse <swhiteho> |
| Component: | cluster | Assignee: | Fabio Massimo Di Nitto <fdinitto> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | agk, cfeist, fdinitto, harald, jonathan, lhh, swhiteho, teigland |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-08 15:42:29 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: | |||
|
Description
Steve Whitehouse
2011-01-06 15:22:13 UTC
Nothing has changed in the dlm as far as I know. Maybe this is a udev problem? (In reply to comment #1) > Nothing has changed in the dlm as far as I know. Maybe this is a udev problem? This message is shown, because you should not rename the kernel device name, but create a symbolic link to the kernel provided device node. Thus using SYMLINK+= is encouraged over NAME=. Some rules file is renaming dlm-monitor to :-) "misc/dlm-monitor" :) To find the rpm package: # rpm -qf $(fgrep -lr dlm-monitor /{lib,etc}/udev/rules.d) clusterlib-3.1.0-6.fc14.x86_64 "/dev/misc" is not a very good directory name, btw... Would /dev/dlm/ be a better directory? or just under /dev? if you have gazillions of devices, then a subdirectory would make sense, which you also could encode in the kernel driver via "!", which gets replaced by "/". So the kernel driver would announce the "dlm!dlm-monitor" device. (In reply to comment #1) > Nothing has changed in the dlm as far as I know. Maybe this is a udev problem? There has been indeed a change in udev because Fedora13 does not show this error and does not behave like Fedora 14 and higher at all. In fedora 13, udev creates /dev/misc/dlm* as we know and expect due to our rules overriding/setting NAME for the device. In fedora 14, udev creates /dev/dlm* and our rules/libdlm create /dev/misc/dlm*. This is confusing at best, since the devices are duplicated and the ones generated by udev do not carry the correct permissions as set by libdlm dlm_create_lockspace. My suggestion is as follow: - change udev rules to retain creation of dlm* devices in /dev _and_ create a symlink in /dev/misc to avoid any possible breakage of applications using and/or monitoring those devices (this will also avoid a huge mess during libdlm upgrade). tested on fedora13/14/rawhide with upgrades and downgrades + rgmanager and clvmd and it appears to work fine. diff --git a/dlm/libdlm/51-dlm.rules b/dlm/libdlm/51-dlm.rules index f71e79d..0f22134 100644 --- a/dlm/libdlm/51-dlm.rules +++ b/dlm/libdlm/51-dlm.rules @@ -1,5 +1,2 @@ -KERNEL=="dlm-control", NAME="misc/dlm-control", MODE="0666" -KERNEL=="dlm-monitor", NAME="misc/dlm-monitor", MODE="0666" -KERNEL=="dlm_default", NAME="misc/dlm_default", MODE="0666" -KERNEL=="dlm_*", NAME="misc/%k", MODE="0660" - +KERNEL=="dlm-control|dlm-monitor|dlm_default", MODE="0666", SYMLINK+="misc/%k" +KERNEL=="dlm_*", MODE="0660", SYMLINK+="misc/%k" - change libdlm to look in /dev/ for devices (optional/unrequired change since symlinks will exist in /dev/misc) but we can keep it consistent with kernel. diff --git a/dlm/libdlm/libdlm.c b/dlm/libdlm/libdlm.c index dadf1d2..7e511bf 100644 --- a/dlm/libdlm/libdlm.c +++ b/dlm/libdlm/libdlm.c @@ -24,7 +24,7 @@ #include "libdlm.h" #include <linux/dlm_device.h> -#define MISC_PREFIX "/dev/misc/" +#define MISC_PREFIX "/dev/" #define DLM_PREFIX "dlm_" #define DLM_MISC_PREFIX MISC_PREFIX DLM_PREFIX #define DLM_CONTROL_NAME "dlm-control" Objections? That sounds like a good way forward to me. fix will be part of next release |