From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Thu, 13 May 2004 05:59:46 +0000 Subject: Re: 2.6.6/udev weirdness Message-Id: <20040513055946.GA9821@kroah.com> List-Id: References: <20040512235509.GA3836@heliopause.vort.org> In-Reply-To: <20040512235509.GA3836@heliopause.vort.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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