linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [OFFTOPIC] udev question
@ 2005-06-18  5:18 John Gatewood Ham
  2005-06-18  8:24 ` Kay Sievers
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: John Gatewood Ham @ 2005-06-18  5:18 UTC (permalink / raw)
  To: linux-hotplug

linux-hotplug-devel list,

The listed maintainer of udev requires I use this mailing list
for questions, even though my problem is with udev and not hotplug.
If you reply please cc: me since I am not a member of this list.
Here is the original message I sent to him:
--------------------8<  snip   8<-----------------------------
Hello,

     I upgraded from udev 0.54 to udev 0.58 and had many problems.
I finally tracked it down to my rules for /dev/null and /dev/zero.
These rules worked for 0.54:

SYSFS{dev}="1:3", NAME="null", OWNER="root", GROUP="root", MODE="0666"
SYSFS{dev}="1:5", NAME="zero", OWNER="root", GROUP="root", MODE="0666"

In 0.58 they create block mode device nodes, not character mode device
nodes, and that breaks many things, include portmapd and sshd.  After
much trail and error I came up with these rules that work with 0.58:

KERNEL="null", NAME="%k", OWNER="root", GROUP="root", MODE="0666"
KERNEL="zero", NAME="%k", OWNER="root", GROUP="root", MODE="0666"

I believe that somehow using SYSFS{dev} now assumes anything is
a block device instead of looking it up somehow (like KERNEL does).
Perhaps if the lookup is difficult or expensive, you could have
a way to specify block or character device?  Maybe there is a way to
sneak that into the MODE specification?  Or maybe not, but add this
to the FAQ?  Kernel 2.6.11.12 + gcc 3.3.6 + glibc-2.3.5/NPTL(no tls).
I use a custom distribution compiled from source and I mount a
ramdisk /dev on top of the real thing while running rc.S and
populate it with udevstart.  I did the upgrade to try and get xterm
working (later learned I have to manually set ptmx permissions in
the rules file and solved that issue).

I report this not as an error but as an issue that might be added
to the FAQ so other people don't suffer an entire night on this like I 
did.  Then again, maybe everybody else is smarter and finds these
answers faster.

Thanks,

JGH
-------------8<  snip 8<------------------------------------


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [OFFTOPIC] udev question
  2005-06-18  5:18 [OFFTOPIC] udev question John Gatewood Ham
@ 2005-06-18  8:24 ` Kay Sievers
  2005-06-18  8:55 ` John Gatewood Ham
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Kay Sievers @ 2005-06-18  8:24 UTC (permalink / raw)
  To: linux-hotplug

On Sat, Jun 18, 2005 at 12:18:14PM +0700, John Gatewood Ham wrote:
> Hello,
> 
>     I upgraded from udev 0.54 to udev 0.58 and had many problems.
> I finally tracked it down to my rules for /dev/null and /dev/zero.
> These rules worked for 0.54:
> 
> SYSFS{dev}="1:3", NAME="null", OWNER="root", GROUP="root", MODE="0666"
> SYSFS{dev}="1:5", NAME="zero", OWNER="root", GROUP="root", MODE="0666"

I can't reproduce this. These rules work perfectly on my box. According
to the code I can't see how udev can create block devices here.

> I believe that somehow using SYSFS{dev} now assumes anything is
> a block device instead of looking it up somehow (like KERNEL does).
> Perhaps if the lookup is difficult or expensive, you could have
> a way to specify block or character device?  Maybe there is a way to
> sneak that into the MODE specification?

No, the type of device is determined by the sysfs path. /dev/zero comes from
DEVPATH=/class/mem/zero. All DEVPATH's starting with /class/* will be
created as char devices.

No idea what is going wrong on your box.

Kay


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [OFFTOPIC] udev question
  2005-06-18  5:18 [OFFTOPIC] udev question John Gatewood Ham
  2005-06-18  8:24 ` Kay Sievers
@ 2005-06-18  8:55 ` John Gatewood Ham
  2005-06-18  9:11 ` Kay Sievers
  2005-06-19  5:17 ` Greg KH
  3 siblings, 0 replies; 5+ messages in thread
From: John Gatewood Ham @ 2005-06-18  8:55 UTC (permalink / raw)
  To: linux-hotplug

Is there some kind of 'trace' mode I can turn on that shows
how udev makes the decisions?

JGH

On Sat, 18 Jun 2005, Kay Sievers wrote:

> On Sat, Jun 18, 2005 at 12:18:14PM +0700, John Gatewood Ham wrote:
>> Hello,
>>
>>     I upgraded from udev 0.54 to udev 0.58 and had many problems.
>> I finally tracked it down to my rules for /dev/null and /dev/zero.
>> These rules worked for 0.54:
>>
>> SYSFS{dev}="1:3", NAME="null", OWNER="root", GROUP="root", MODE="0666"
>> SYSFS{dev}="1:5", NAME="zero", OWNER="root", GROUP="root", MODE="0666"
>
> I can't reproduce this. These rules work perfectly on my box. According
> to the code I can't see how udev can create block devices here.
>
>> I believe that somehow using SYSFS{dev} now assumes anything is
>> a block device instead of looking it up somehow (like KERNEL does).
>> Perhaps if the lookup is difficult or expensive, you could have
>> a way to specify block or character device?  Maybe there is a way to
>> sneak that into the MODE specification?
>
> No, the type of device is determined by the sysfs path. /dev/zero comes from
> DEVPATH=/class/mem/zero. All DEVPATH's starting with /class/* will be
> created as char devices.
>
> No idea what is going wrong on your box.
>
> Kay
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [OFFTOPIC] udev question
  2005-06-18  5:18 [OFFTOPIC] udev question John Gatewood Ham
  2005-06-18  8:24 ` Kay Sievers
  2005-06-18  8:55 ` John Gatewood Ham
@ 2005-06-18  9:11 ` Kay Sievers
  2005-06-19  5:17 ` Greg KH
  3 siblings, 0 replies; 5+ messages in thread
From: Kay Sievers @ 2005-06-18  9:11 UTC (permalink / raw)
  To: linux-hotplug

On Sat, Jun 18, 2005 at 04:01:28PM +0700, John Gatewood Ham wrote:
> Is there some kind of 'trace' mode I can turn on that shows
> how udev makes the decisions?

Sure, do:
  make clean all DEBUG=true
  make install

and set udev_log="debug" in /etc/udev/udev.conf

If you call udevstart on bootup, which is normally the one that creates
/dev/null, you need to pass invoke it with:
  UDEV_LOG=8 /sbin/udevstart

cause it does not follow the settings of the config, cause it may take
minutes for it to finish cause of a slow syslog...

You can also simply do (with the DEBUG compiled in):
  ACTION­d DEVPATH=/class/mem/zero UDEV_LOG=8 /sbin/udev mem

and watch syslog to see what your rule does.

Kay


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [OFFTOPIC] udev question
  2005-06-18  5:18 [OFFTOPIC] udev question John Gatewood Ham
                   ` (2 preceding siblings ...)
  2005-06-18  9:11 ` Kay Sievers
@ 2005-06-19  5:17 ` Greg KH
  3 siblings, 0 replies; 5+ messages in thread
From: Greg KH @ 2005-06-19  5:17 UTC (permalink / raw)
  To: linux-hotplug

On Sat, Jun 18, 2005 at 12:18:14PM +0700, John Gatewood Ham wrote:
> linux-hotplug-devel list,
> 
> The listed maintainer of udev requires I use this mailing list
> for questions, even though my problem is with udev and not hotplug.

No, this is not off-topic for this list.  Man, how many times do I have
to say this...

Also, as I said before, see the README file for verification of this
(the bottom of the file...)

> 
>     I upgraded from udev 0.54 to udev 0.58 and had many problems.
> I finally tracked it down to my rules for /dev/null and /dev/zero.
> These rules worked for 0.54:
> 
> SYSFS{dev}="1:3", NAME="null", OWNER="root", GROUP="root", MODE="0666"
> SYSFS{dev}="1:5", NAME="zero", OWNER="root", GROUP="root", MODE="0666"

This would pick up the ram disk devices, that's why it is not a good
idea to use this rule, as you have found out.  You were just lucky
before that it was working.

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-06-19  5:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-18  5:18 [OFFTOPIC] udev question John Gatewood Ham
2005-06-18  8:24 ` Kay Sievers
2005-06-18  8:55 ` John Gatewood Ham
2005-06-18  9:11 ` Kay Sievers
2005-06-19  5:17 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).