From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: 2.6.6/udev weirdness
Date: Thu, 13 May 2004 05:59:46 +0000 [thread overview]
Message-ID: <20040513055946.GA9821@kroah.com> (raw)
In-Reply-To: <20040512235509.GA3836@heliopause.vort.org>
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
next prev parent reply other threads:[~2004-05-13 5:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-12 23:55 2.6.6/udev weirdness Russell Neches
2004-05-13 5:59 ` Greg KH [this message]
2004-05-13 17:51 ` Russell Neches
2004-05-13 18:15 ` Kevin P. Fleming
2004-05-13 21:02 ` Greg KH
2004-05-15 5:42 ` Russell Neches
2004-05-16 9:21 ` Daniel Drake
2004-05-16 21:03 ` Russell Neches
2004-05-17 9:49 ` Daniel Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040513055946.GA9821@kroah.com \
--to=greg@kroah.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.