udev reorders assignment [was Re: Solved Debian update - keyboard responsive, Lennart Sorrenson not so much]

[Russell Reiter]

<snip previous>
> What do you mean by "devices re polled by udev seem to be reordered in
> assignment"?
>
> Are you talking about /dev entries for similar devices having unstable
> names?  For example, /dev/sda and /dev/sdb might switch between
> devices in different boots?  Or eth0 vs eth1?  Or something else?

Sorry for the confusion. That's it mostly, although I have helped
people deal with some weird issues in the last several months, as
different people upgrade their distributions. In one case the screen
would flicker and the keyboard would become unresponsive. Ten or so
seconds later it would flicker again and the keyboard would come back.
No effect on the usb mouse. It was however a PS2 keyboard.

That one was hard to reproduce consistently on boot. I think it was a
gdm bug but I'm not sure. I was looking into it but it seems to have
been solved by an update.

The joy of automation, also the pain. I'd kind of liked to know what's
was going on.

>
> Name instability seems to be an outcome of doing things in parallel (at
> least at at abstract level).  The kernel folks think that this is a win
> (speed, elegance, and moving things out of the kernel, if I remember
> correctly).
>
> There are many workarounds.
>
> In the case of disks, /etc/fstab entries should now use UUIDs (or LABELs)
> to refer to partitions.  Nicer in a lot of ways.
>
> In the case of TV tuner cards (my problem on my MythTV boxes),
> there are interesting entries in /dev that allow you to address them
> by PCI slot.
>
> Do "ls -d /dev/*/by-*" to see how you can get at particular devices by
> UUID or LABEL or PCI slot or whatever.

Thanks that's very helpful. I had just dug out my ten year old copy of
Unix Power Tools for inspiration.

I'm going to try to use udev to tame Xsane after an update. That
update broke a plugdev group. For now I'm using a sudo script to find
the scanner and chmod a+w for Xsane. It's work that udev can handle
but I needed a quik fix to send to the user. The script seems to work,
for now.

>
> In the case of ethernet interfaces (not in /dev, thanks to BSD brain
> damage 30 years ago), you can discriminate by way of MAC address, but
> I don't think that that is satisfactory since a card's MAC addresses
> can be changed.  I've not yet bumped hard into this problem so I

Could you elaborate a little more on BSD brain damage. Also, I assumed
MAC address's were stored on prom's not eproms and so were permanently
assigned by the manufacturer.

> haven't searched for a better technique.  I guess if the hardware is
> different you could discriminate via PCI device IDs.  Any better
> solutions?  I sure want my router to know very early in the boot
> sequence which interfaces are inward facing and which are outward
> facing.  Heck, I'm so behind the times I still use ifconfig etc. that
> are long obsolete.
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists