<HTML>
<HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META content="OPENWEBMAIL" name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>

<font size="2"><font size="3">Hi Lars, thanks for the reply. 
<br />
<br />I am still completely confused as to what is going on here. This is a standard CentOS 4.6 install. I have not done anything out of place. I have even completely reinstalled the OS, and DRBD on both of my nodes and still have this issue. Yes, if I remove the 65-drbd.rules from /etc/udev/rules.d things go back to normal. How could it be that udev in RHEL4/CentOS4 could be this broken and yet it is not a known issue? The drbd0 device I manually created does not survive a reboot - should I be creating a boot script to recreate the device at each bootup since udev seems to have a problem?
<br />It seems that this an old older udev (version 039), I see that CentOS 5.X uses udev 095 - that's a pretty huge leap! By what I am seeing it would seem that ANY RHEL4 system should should be suffering from the same problem. Judging by your response I have to assume this is NOT the case.
<br />
<br />Since I have ruled out something &quot;funny&quot; going on by complete reload of the OS and DRBD on both node machines, which direction should I head in next? Is there ANY known issue with the older 039 version of udev? Why is it that anything else which uses udev works perfectly fine? (USB modems, other hard drives, ect).
<br />
<br />I really need some advice on what to do next!
<br />
<br />-Thanks!
<br />
<br />
<br />
<br /></font></font><font face="Arial, Helvetica">&gt; if it was only DRBD, I'd say sorry and promise to not do it again. 
<br />
&gt; but apparently none of your udev rules work, 
<br />
&gt; your complete udev setup seems to be broken. 
<br />
&gt; I mean, even par0, ram, cdrom and so on are affected by this 
<br />
&gt; &quot;non-expanding&quot; of udev environment variables. 
<br />&gt;
<br />
&gt;of coure, you can just remove the udev rules file, 
<br />
&gt;and &quot;all should be as before&quot;.  if udev does not find a rule, it 
<br />
&gt;&quot;defaults&quot; to generate what the kernel asked for. 
<br />
 &gt;
<br />
&gt;but you should really look into why your udev stuff breaks in this 
<br />
&gt;&quot;interessting&quot; way. </font>
<br /><font face="Arial, Helvetica">
<br />On Mon, May 18, 2009 at 05:02:16PM -0400, Ken Dechick wrote: 
<br />
<font color="#009900">&gt; Hello all, 
<br /></font>
<font color="#009900">&gt;  
<br /></font>
<font color="#009900">&gt; I am new to DRBD, and have so far found it
very easy to use. I am having an issue however with udev. Running
CentOS 4.6 on 2.6.9-67.0.22 kernel - my /dev/drbd0 device is not being
created. Everything else seems to be working correctly. Running DRBD
8.3.1 built from source. In looking at my /dev directory there are odd
entires: 
<br /></font>
<font color="#009900">&gt;  
<br /></font>
<font color="#009900">&gt; lrwxrwxrwx? 1 root root?????? 17 May 19 01:50 cd0 -&gt; /dev/$env{DEVICE} 
<br /></font>
<font color="#009900">&gt; lrwxrwxrwx? 1 root root?????? 12 May 18 21:50 cdrom -&gt; $env{DEVICE} 
<br /></font>
<font color="#009900">&gt; lrwxrwxrwx? 1 root root?????? 12 May 18 21:50 dvd -&gt; $env{DEVICE} 
<br /></font>
<font color="#009900">&gt; brw-------? 1 root root 147,?? 0 May 19 02:05 $env{DEVICE} 
<br /></font>
<font color="#009900">&gt; lrwxrwxrwx? 1 root root?????? 12 May 19 01:50 par0 -&gt; $env{DEVICE} 
<br /></font>
<font color="#009900">&gt; lrwxrwxrwx? 1 root root?????? 12 May 18 21:50 ram -&gt; $env{DEVICE} 
<br /></font>
<font color="#009900">&gt;  
<br /></font>
<font color="#009900">&gt; I have configured hundreds of servers with
CentOS 4.4-4.5 and never seen entries like this before.? I was sure the
$ was not a valid character to use in a device (or file) name. After
some looking I found a co-incidence: this same odd-ball string exists
in the udev script for drbd: 
<br /></font>
<font color="#009900">&gt;  
<br /></font>
<font color="#009900">&gt; KERNEL==&quot;drbd*&quot;, \ 
<br /></font>
<font color="#009900">&gt; ????????IMPORT{program}=&quot;/sbin/drbdadm sh-udev minor-%m&quot;, \ 
<br /></font>
<font color="#009900">&gt; ????????NAME=&quot;$env{DEVICE}&quot;, \ 
<br /></font>
<font color="#009900">&gt; ????????SYMLINK=&quot;drbd/by-res/$env{RESOURCE} drbd/by-disk/$env{DISK}&quot; 
<br /></font>
<font color="#009900">&gt;  
<br /></font>
<font color="#009900">&gt; I appears to me that this udev script (came from the 8.3.1 source 
<br /></font>
<font color="#009900">&gt; code) does not work properly with my distribution/kernel. Can anyone 
<br /></font>
<font color="#009900">&gt; help me out here? I can of course create the /dev/drbd0 manually 
<br /></font>
<font color="#009900">&gt; (mknod -m 0660 /dev/drbd0 b 147 0) but I would like to get to the 
<br /></font>
<font color="#009900">&gt; bottom of what the problem is here. I am far from a udev expert never 
<br /></font>
<font color="#009900">&gt; having had an issue with it in the past. Is this a udev rule issue or 
<br /></font>
<font color="#009900">&gt; is my udev version simply too old?? I am running udev: 039-10.19.el4. 
<br /></font>
<font color="#009900">&gt;  
<br /></font>
 
<br />

<br />
 </font>
<br /><font size="2">
<br />
<br />Kenneth M 
DeChick

<br />Linux Systems 
Administrator

<br />Community Computer Service, 
Inc.

<br />(315)-255-1751  
ext154

<br />http://www.medent.com

<br />kend@medent.com

<br />-- -- -- -- -- -- -- -- -- -- 
--
<br />
&quot;You canna change the laws of physics, Captain; I've got to have 
thirty
minutes! 
&quot;
<br />

<br />.
<center><img src="https://www.medent.com/openwebmail/images/defmailsig.jpg" /></center>
<br />
</font>
</BODY>
</HTML>

This message has been scanned for viruses and dangerous content by MailScanner &amp; ClamAV. <BR>
 <BR>
This message and any attachments may contain information that is protected by law as privileged and confidential, and is transmitted for the sole use <BR>
of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, copying or retention of this e-mail <BR>
or the information contained herein is strictly prohibited. If you received this e-mail in error, please immediately notify the sender by e-mail, and permanently <BR>
delete this e-mail. <BR>