2.6.6/udev weirdness

2.6.6/udev weirdness

[Russell Neches]

On 2.6.5, I used the following udev rules:

  # Russell's Rules
  BUS="scsi", SYSFS{model}="*JUMPDRIVE*", NAME="%k", SYMLINK="jumpdrive"
  BUS="scsi", SYSFS{model}="*iPod*", NAME="%k", SYMLINK="ipod"

This allowed me to use these entries in /etc/fstab 

  /dev/jumpdrive  /mnt/jump       vfat    noauto,user     0       0
  /dev/ipod       /mnt/ipod       vfat    noauto,user     0       0

This was very convenient, particularly with gnome-volume-manager and
assorted other cool things in Gnome 2.6.  Indeed, this seems to be the
whole point of the hotplug/udev/hal/dbus system, and when it works it's
exceedingly cool. 

On 2.6.5, the symlinks created by the rules point as follows:

  /dev/jumpdrive -> sda1
  /dev/ipod -> sdb2

Depending on attachment order, of course. Now, on 2.6.6, the same rules
with the same hardware end up pointing thusly:

  /dev/jumpdrive -> sg0
  /dev/ipod -> sg1

This is, ah, not particularly useful. I was under the impression that
sysfs and udev were created explicitly to put a stop to the aimless
wandering of devices in /dev. Now, I may have written stupid rules; if
so, please enlighten me. I've tried several permutations, and the above
is the only way I could obtain the desired results under 2.6.5, and
under 2.6.6, I can't get /dev/jumpdrive to point to /dev/sda1 at all. 

The likely stupidity of the above rules notwithstanding, the underlying
behavior of the system changed, and my rules broke. That shouldn't
happen, even if the rules are dumb. This is a Bad Thing. 

Am I off base here, or is it reasonable to assume that 2.6 is ought to
be kinda-sorta stable?

Russell

Random Version Information:

  Debian unstable/experimental 
  udev package: 0.024-7
  hal package: 0.2.90+2004042
  hotplug package: 0.0.20040329-8
  stock Linus 2.6.5 and 2.6.6 (built from source, no patches)

 


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Greg KH]

On Wed, May 12, 2004 at 07:55:09PM -0400, Russell Neches wrote:
> 
> On 2.6.5, I used the following udev rules:
> 
>   # Russell's Rules
>   BUS="scsi", SYSFS{model}="*JUMPDRIVE*", NAME="%k", SYMLINK="jumpdrive"
>   BUS="scsi", SYSFS{model}="*iPod*", NAME="%k", SYMLINK="ipod"
> 
> This allowed me to use these entries in /etc/fstab 
> 
>   /dev/jumpdrive  /mnt/jump       vfat    noauto,user     0       0
>   /dev/ipod       /mnt/ipod       vfat    noauto,user     0       0
> 
> This was very convenient, particularly with gnome-volume-manager and
> assorted other cool things in Gnome 2.6.  Indeed, this seems to be the
> whole point of the hotplug/udev/hal/dbus system, and when it works it's
> exceedingly cool. 
> 
> On 2.6.5, the symlinks created by the rules point as follows:
> 
>   /dev/jumpdrive -> sda1
>   /dev/ipod -> sdb2
> 
> Depending on attachment order, of course. Now, on 2.6.6, the same rules
> with the same hardware end up pointing thusly:
> 
>   /dev/jumpdrive -> sg0
>   /dev/ipod -> sg1
> 
> This is, ah, not particularly useful. I was under the impression that
> sysfs and udev were created explicitly to put a stop to the aimless
> wandering of devices in /dev. Now, I may have written stupid rules; if
> so, please enlighten me.

You wrote stupid rules :)

> I've tried several permutations, and the above
> is the only way I could obtain the desired results under 2.6.5, and
> under 2.6.6, I can't get /dev/jumpdrive to point to /dev/sda1 at all. 

Try disabling sg support if you don't want that.  Or just add the
following to your rules:
	KERNEL="sd*"

That should only make your names bind to the block devices, not the
other scsi devices.

> The likely stupidity of the above rules notwithstanding, the underlying
> behavior of the system changed, and my rules broke. That shouldn't
> happen, even if the rules are dumb. This is a Bad Thing. 

Um, dumb rules are a Bad Thing, nothing we can do here about that :)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Russell Neches]

> You wrote stupid rules :)

So I gather.

> > I've tried several permutations, and the above is the only way I
> > could obtain the desired results under 2.6.5, and under 2.6.6, I
> > can't get /dev/jumpdrive to point to /dev/sda1 at all. 
>
> Try disabling sg support if you don't want that.  Or just add the
> following to your rules: KERNEL="sd*"

Oh, I see. KERNEL="sd*[1-9]" seems to work.

> That should only make your names bind to the block devices, not the
> other scsi devices.
>
> > The likely stupidity of the above rules notwithstanding, the
> > underlying behavior of the system changed, and my rules broke. That
> > shouldn't happen, even if the rules are dumb. This is a Bad Thing. 
>
> Um, dumb rules are a Bad Thing, nothing we can do here about that :)

No doubt about that. My point is that dumb rules should probably
continue to do the same dumb thing, at least if you're only moving
between stable kernels.

I guess this is what I deserve for reading the documentation and
following the examples. The documentation does mention that some values
are stable, and thus worthy of matching against, and others are not.
However, it doesn't give any rational for distinguishing them. I
mistakenly assumed that by matching aginst the serial number the rule
would always do the same thing. And, it does seem to match the same
physical device... it just symlinks the wrong part of it (sometimes).
I'd guess it was a side effect of changing the tree of virtual devices.

So, I think it's a fair question: how, generally, does one write stable
rules? I can see easily enough how to write rules that always _match_
the same thing, but what should I take into account to insure that the
rule will always _do_ the same thing?

Russell




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Kevin P. Fleming]

Russell Neches wrote:

> So, I think it's a fair question: how, generally, does one write stable
> rules? I can see easily enough how to write rules that always _match_
> the same thing, but what should I take into account to insure that the
> rule will always _do_ the same thing?

You need to make your rules as specific as you can without restricting 
your ability to deal with port/slot/etc. changes. Using "scsi" as an 
identifier is far too ambiguous, where "sd" is much better.


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Greg KH]

On Thu, May 13, 2004 at 01:51:38PM -0400, Russell Neches wrote:
> > > The likely stupidity of the above rules notwithstanding, the
> > > underlying behavior of the system changed, and my rules broke. That
> > > shouldn't happen, even if the rules are dumb. This is a Bad Thing. 
> >
> > Um, dumb rules are a Bad Thing, nothing we can do here about that :)
> 
> No doubt about that. My point is that dumb rules should probably
> continue to do the same dumb thing, at least if you're only moving
> between stable kernels.

You didn't answer my question about the sg device.  Did you change your
config between the two kernels?  Perhaps the sg device is bound to the
device before the sd driver is now, which caused the change you saw.

Either way, if you have a very general rule, like you had, expecting it
to work the same way all the time is nothing you can do, sorry.

Again, make the rule a specific as you can to help prevent things like
this happening in the future.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Russell Neches]

On Thu, May 13, 2004 at 02:02:17PM -0700, Greg KH wrote:
> On Thu, May 13, 2004 at 01:51:38PM -0400, Russell Neches wrote:
> > > > The likely stupidity of the above rules notwithstanding, the
> > > > underlying behavior of the system changed, and my rules broke.
> > > > That shouldn't happen, even if the rules are dumb. This is a Bad
> > > > Thing. 
> > >
> > > Um, dumb rules are a Bad Thing, nothing we can do here about that
> > > :)
> > 
> > No doubt about that. My point is that dumb rules should probably
> > continue to do the same dumb thing, at least if you're only moving
> > between stable kernels.
> 
> You didn't answer my question about the sg device.  Did you change
> your config between the two kernels?  Perhaps the sg device is bound
> to the device before the sd driver is now, which caused the change you
> saw.

Oh, I hadn't realized you asked a question. No, the configurations are
identical. Otherwise, I would blamed that for the problem.

> Either way, if you have a very general rule, like you had, expecting
> it to work the same way all the time is nothing you can do, sorry.
> 
> Again, make the rule a specific as you can to help prevent things like
> this happening in the future.

That much, I understand completely. What I don't understand is what
constitutes a general rule and what constitutes a specific rule. My
intention was to make it as specific as possible by matching the
device's serial number. In this sense, the my original rule actually
worked just fine (it only matched my USB memory stick, and not other
things). The problem arose from the precedence of virtual devices
associated with the (correctly matched) real device. 

Matching the name the kernel assigns seems to be _less_ specific, not
more. So, clearly there is some subtlety required in one's approach to
writing good rules. Can you offer any advice? Or, can you offer some
examples of things that look right, but turn out to be "gotchas"?

For instance, this document 

  http://www.reactivated.net/udevrules.php

mentions rules like 

  BUS="scsi", SYSFS{manufacturer}="Tekom Technologies, Inc", NAME="%k"

won't work because it combines information from different directories in
sysfs. That's why I wrote the my rule the way I did -- because I thought
it was necessary to avoid this problem. The example USB storage device
rule from that HOWTO includes the KERNEL="sd*" parameter, but doesn't
explain the rational for why it is necessary. (Now that I think of it, I
did see this key when I wrote my rules, and left it out because it
worked without it. By the time I got to 2.6.6, I'd forgotten all about
it.)

So, if I promise not to be grouchy about it, can you shed some light on
how udev works as it pertains to writing good rules? I like udev. I
think udev is cool. But, you have to admit that using it properly is
still a bit mysterious.

Russell


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Daniel Drake]

Russell Neches wrote:
> For instance, this document 
> 
>   http://www.reactivated.net/udevrules.php
> 
> mentions rules like 
> 
>   BUS="scsi", SYSFS{manufacturer}="Tekom Technologies, Inc", NAME="%k"
> 
> won't work because it combines information from different directories in
> sysfs. That's why I wrote the my rule the way I did -- because I thought
> it was necessary to avoid this problem. The example USB storage device
> rule from that HOWTO includes the KERNEL="sd*" parameter, but doesn't
> explain the rational for why it is necessary. (Now that I think of it, I
> did see this key when I wrote my rules, and left it out because it
> worked without it. By the time I got to 2.6.6, I'd forgotten all about
> it.)

The rule which you are referring to (containing sd*) is not the example rule, 
thats actually part of the "footnote" section explaining some different 
scenario's.

Would you mind re-reading the section titled "Example: Writing a rule for my 
USB-Storage digital camera"?
In that section I explain the importance of a key such as KERNEL="sd?1", and 
if you had followed this section while writing your rule, I think you may have 
avoided the problems you describe in this thread.
If that still does not clear it up for you, let me know, and I'll see if there 
is a way I can improve the wording there.

Thanks

Daniel


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Russell Neches]

> Would you mind re-reading the section titled "Example: Writing a rule for 
> my USB-Storage digital camera"?
> In that section I explain the importance of a key such as KERNEL="sd?1", 
> and if you had followed this section while writing your rule, I think you 
> may have avoided the problems you describe in this thread.
> If that still does not clear it up for you, let me know, and I'll see if 
> there is a way I can improve the wording there.

Actually, I think the wording is quite clear in that section. I
reckoned that I was having a different problem, though. My origional
rules did, after all, work exactly as I wanted them to under
2.6.5. It's easy enough to see why one would want to distinguish
between sda and sda1 and how to do it. My problem wasn't that I
couldn't figure out how to solve that particular problem, it was that
the behavior changed between minor version numbers of the kernel. I
had thought (incorrectly, it seems) that sysfs is intended
specifically to provide a standardized, reliable source of hardware
information, and that the whole point of the thing was to prevent
problems like the one I noticed. If sysfs is going to be a mix of some
values that aren't supposed to change, and some that do, or might, or
can, or could change (aside from chanes to _enforce_ compliance with
policy), then it's much less useful. 

If there is some way of knowing which values may be expected to "stay
put" between kernel revisions, then that goes part of the way to
fixing the problem.

This particular situation is pretty harmless. However, I can easily
imagine a situation where it woudln't be. For instance, a server with
a very large, complex disk array. This is one of the situations that
udev is intended to address. If you don't know what can be changed in
sysfs, then how do you write safe, effective rules so that you can use
your disk array the way you want? It would be a fairly subtle
problem. Now, if that's just the way it is, then that's the way it is.

Russell





-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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

Re: 2.6.6/udev weirdness

[Daniel Drake]

Hi,

Russell Neches wrote:
> Actually, I think the wording is quite clear in that section. I
> reckoned that I was having a different problem, though. My origional
> rules did, after all, work exactly as I wanted them to under
> 2.6.5. It's easy enough to see why one would want to distinguish
> between sda and sda1 and how to do it. My problem wasn't that I
> couldn't figure out how to solve that particular problem, it was that
> the behavior changed between minor version numbers of the kernel.

Yes, but your rule was problematic. It was being applied for sda, sda1, and 
also sg1 each time. I'm not sure if udev uses the first or last match, but 
either way, it was effectively choosing 1 and discarding 2. I've seen rules 
like this change their behaviour over reboots, and I suspect that might have 
been what caused it (rather than the fact that you upgraded kernel). You were 
just lucky that your rule worked originally (1 in 3 chance), and then your 
luck ran out :)

> I had thought (incorrectly, it seems) that sysfs is intended
> specifically to provide a standardized, reliable source of hardware
> information, and that the whole point of the thing was to prevent
> problems like the one I noticed. If sysfs is going to be a mix of some
> values that aren't supposed to change, and some that do, or might, or
> can, or could change (aside from chanes to _enforce_ compliance with
> policy), then it's much less useful. 

I'm 99% sure that the relevant parts of _sysfs_ would have stayed identical 
over your kernel upgrade. The problem is that your _udev_ rule was matching at 
least 3 areas of sysfs each time: scsi generic (sg1), scsi disk (sda), and 
each partition (sda1, sda2, ...).

This is where the section of the doc explaining about specificity comes in. I 
was trying to explain that you need to be specific about the partition/disk 
you are selecting, otherwise you might get something "useless" (e.g. 
unmountable node).

I'm not suprised that you experienced that the behaviour of your rule changed 
over time, even if we think it was triggered by a kernel upgrade.

> If there is some way of knowing which values may be expected to "stay
> put" between kernel revisions, then that goes part of the way to
> fixing the problem.

I think you have gone beyond the problem here. *If* the kernel upgrade caused 
the change in behaviour for your particular rule, then it will have been due 
to something like the timing of module loading changed, or the code used to 
create the sysfs tree being moved into an earlier/later stage of 
initialization, *not* because the sysfs values changed.

Daniel


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&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