Re: udev alzheimers
On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote:
> On Thursday 21 May 2020 10:10:10 tomas@tuxteam.de wrote:
> > On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote:
> > >
> > > Since updating to stretch, udev has been randomly swapping ttyUSB0
> > > and ttyUSB1 and sometimes ttyUSB2 around, confusing the hell out of
> > > heyu, a trs-80-coco3, and occasionally even nut. Nut (apc ups) is
> > > not on a usb-serial adapter, it just a usb cable but the other 2 are
> > > on individually unique FTDI adaptors.
> > >
> > > What udev persistent file, and where is it, do I edit and chattr +i
> > > to effect a permanent cure for this apparently random device
> > > renaming?
> >
> > I don't know about this one -- but note that the files in /etc
> > (i.e. /etc/udev/rules.d) are yours to play with and override the
> > distro's, which are in /lib/udev/rules.d. So you shouldn't (TM)
> > muck around with chattr.
> >
> IOW, and what the man pages keep secret, I should cp
> the /lib/udev/rules.d stuff I need to /etc/udev/rules.d and edit that.
That's one way of doing it. The other is to use /lib/udev/…
as examples to make it easier to understand the man page
(there's no secret).
> I wasn't sure which was which, thank you.
>
> > > And whats the command to restart udev from a clean slate without
> > > rebooting?
> >
> > I don't know by heart, but something with udevadm (perhaps
> > 'udevadm trigger'). Probably you need an 'udevadm control reload'
> > for udev to see the changes you made to its configuration.
> >
> > Also possibly useful are 'udevadm monitor' and 'udevadm test'.
> >
> > My hunch is that the rules which recognize your USB adapters
> > have somehow changed and that it can't reliably distinguish
> > among the individual fobs.
>
> They have not been touched since stretch was installed about 9 months
> back and I have been trying to keep ahead of udev by editing conf files
> ever since. But you have to do that by guess and by golly cuz udev
> increments the name if you pull the cable and reinsert it just to get an
> ID of which one it is from dmesg. So you wind up chaseing your tail
> until it catches you, at one point 2 years ago on a diff mobo I was
> running heyu on ttyUSB14, with only 2 ttyUSB's in the cage. Why the
> heck can it not reuse a vacated device number? Boggles what little mind
> I have left.
> […]
> I have no clue why its even named persistent when in 2 Asus motherboards
> and 12 years with the weeping willow I have for a usb tree here, it has
> never assigned the same usb socket the same ttyUSB# in a row during
> bootup. We were far better off when they were assigned in the order
> found & things only got scrambled if you scrambled the cables plugging
> them back in after the systems annual D&C.
So you have to write a list with the order of plugging in, and stick
that to the back of the computer? And every time you reboot, you have
to unplug everything first to prevent a race? No, thank you.
> Thanks for the info, maybe, hopefully I can make it persistent now.
> Maybe. usb-devices does give me the unique stuff, but udevadm does not.
Why would you use usb-devices? You have to run it and then search
through the list it returns. Whereas udevadm comes to you whenever
something changes, tells you what, and gives you all the information
you need as event properties.
Cheers,
David.
Reply to: