Re: udev alzheimers

[tomas]

On Thu, May 21, 2020 at 12:25:51PM -0700, John Conover wrote:
> 
> David Wright writes:
> > On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote:
> > > On Thursday 21 May 2020 10:10:10 to...@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.
> > > > >
> 
> .
> .
> .
> 
> Perhaps:
> 
> /dev/serial/by-id
> /dev/serial/by-path

Actually... this is better than messing with udev rules. I keep
forgetting about that (the built-in rules manage that).

Thanks for reminding, cheers
-- t


signature.asc
Description: Digital signature

Re: udev alzheimers

[David Wright]

On Thu 21 May 2020 at 13:26:03 (-0400), Gene Heskett wrote:
> On Thursday 21 May 2020 12:11:42 David Wright wrote:
> > On Thu 21 May 2020 at 08:23:55 (-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
> >
> > To give you a concrete example, I've attached a set of files that
> > I use to generate stable mountpoints (USB sticks) and symlinks
> > (drives) in /media when I insert known sticks or DVD-burners.
> >
> > The comments in the first file explain how to find out the relevant
> > information for writing the others. It looks as if your serial numbers
> > would be a good choice to concentrate on, just like my burners.
> >
> > Note that, because I'm lazy, I treat the LABELs, UUIDs and serial
> > numbers as unique and distinct from each other, in one mixed namespace
> > (the filenames in /etc/udev/rules.d/my-mountpoints/).
> > The mountpoint or link is the contents of the file in that directory.
> > Thus a 1GB USB that I acquired 2017-04-03 with USGS inscribed on it
> > is FAT formatted with a "UUID" 2017-0403, and generates a mountpoint
> > /media/usgs1g. The DVD-burner with the serial number KZ3E2DH0440
> > generates a link /media/cdrom3, which makes it easy to distinguish
> > two identical LG Slim Portables plugged in simultaneously.
> >
> > > and chattr +i to
> > > effect a permanent cure for this apparently random device renaming?
> >
> > No. don't do that!
> >
> > > And whats the command to restart udev from a clean slate without
> > > rebooting?
> >
> > # udevadm control -R
> >
> Yet another way, thats at least 2 different ways.

That command causes udevadm to reread its rules and so on. If you
then unplug your USB plug, it will process the two events under the
new regime.

AIUI   udevadm trigger   will replay all the events without
(un)plugging anything, but that could be confusing for you, as you'll
get events for both your devices at the same time. So if all the
(un)plugging does no harm, perhaps do that, one at a time. Then
you know which is which.

> Do I dare run that as 
> root right now?

Rereading the rules will have no effect on the devices themselves,
just future events.

> Did, date of /dev/ttyUSB0 updated, heyu works but has to 
> restart the relay before I can query status, everytime, relay once 
> started should drop into the background noise and run till a reboot, not 
> exit between sessions.  This might be a separate problem though.

I don't understand any of this. I don't know what your rules are
designed to do.

Cheers,
David.

Re: udev alzheimers

[Gene Heskett]

On Thursday 21 May 2020 15:25:51 John Conover wrote:

> David Wright writes:
> > On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote:
> > > On Thursday 21 May 2020 10:10:10 to...@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.
>
> .
> .
> .
>
> Perhaps:
>
> /dev/serial/by-id
> /dev/serial/by-path
>
> may be of some help since they are symbolic links into /dev/ttyUSB*
> with additional identification.
>
> John

by-id might work, but that is a very long argument. by serial number 
seems to make the most sense. I'll see about it tomorrow, having used up 
my creative juices on another project today,

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev alzheimers

[John Conover]

David Wright writes:
> On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote:
> > On Thursday 21 May 2020 10:10:10 to...@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.
> > > >

.
.
.

Perhaps:

/dev/serial/by-id
/dev/serial/by-path

may be of some help since they are symbolic links into /dev/ttyUSB*
with additional identification.

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: udev alzheimers

[Gene Heskett]

On Thursday 21 May 2020 14:13:29 David Wright wrote:

> On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote:
> > On Thursday 21 May 2020 10:10:10 to...@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
>
> 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.
>
If you run it with the right options. Now I know how but my editing foo 
is burned out for today. Tommorrow before a big box of parts arrive I 
should arrive at working code.  Thanks and stay well David.

> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev alzheimers

[David Wright]

On Thu 21 May 2020 at 13:02:49 (-0400), Gene Heskett wrote:
> On Thursday 21 May 2020 10:10:10 to...@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

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.

Re: udev alzheimers

[Gene Heskett]

On Thursday 21 May 2020 12:11:42 David Wright wrote:

> On Thu 21 May 2020 at 08:23:55 (-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
>
> To give you a concrete example, I've attached a set of files that
> I use to generate stable mountpoints (USB sticks) and symlinks
> (drives) in /media when I insert known sticks or DVD-burners.
>
> The comments in the first file explain how to find out the relevant
> information for writing the others. It looks as if your serial numbers
> would be a good choice to concentrate on, just like my burners.
>
> Note that, because I'm lazy, I treat the LABELs, UUIDs and serial
> numbers as unique and distinct from each other, in one mixed namespace
> (the filenames in /etc/udev/rules.d/my-mountpoints/).
> The mountpoint or link is the contents of the file in that directory.
> Thus a 1GB USB that I acquired 2017-04-03 with USGS inscribed on it
> is FAT formatted with a "UUID" 2017-0403, and generates a mountpoint
> /media/usgs1g. The DVD-burner with the serial number KZ3E2DH0440
> generates a link /media/cdrom3, which makes it easy to distinguish
> two identical LG Slim Portables plugged in simultaneously.
>
> > and chattr +i to
> > effect a permanent cure for this apparently random device renaming?
>
> No. don't do that!
>
> > And whats the command to restart udev from a clean slate without
> > rebooting?
>
> # udevadm control -R
>
Yet another way, thats at least 2 different ways. Do I dare run that as 
root right now? Did, date of /dev/ttyUSB0 updated, heyu works but has to 
restart the relay before I can query status, everytime, relay once 
started should drop into the background noise and run till a reboot, not 
exit between sessions.  This might be a separate problem though.


> > These are the ttyUSB ports that need persistent names:
> >
> > root@coyote:rules.d$ usb-devices|grep -C4 SERIAL
> > T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
> > D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> > P:  Vendor=0403 ProdID=6001 Rev=04.00
> > S:  Manufacturer=FTDI
> > S:  Product=USB HS SERIAL CONVERTER
> > S:  SerialNumber=FTDHG45D
> > C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=44mA
> > I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff
> > Driver=ftdi_sio
> >
> > --
> > T:  Bus=01 Lev=02 Prnt=04 Port=02 Cnt=02 Dev#=  7 Spd=12  MxCh= 0
> > D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> > P:  Vendor=0403 ProdID=6001 Rev=06.00
> > S:  Manufacturer=FTDI
> > S:  Product=USB FAST SERIAL ADAPTER
> > S:  SerialNumber=FTOOS09N
> > C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> > I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff
> > Driver=ftdi_sio
>
> Cheers,
> David.
Stay well David

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev alzheimers

[Gene Heskett]

On Thursday 21 May 2020 10:10:10 to...@tuxteam.de wrote:

> On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote:
> > greetings all;
> >
> > 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.
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.

Now it appears I have blown a salt chip in the coco, and they are made 
out of pure unobtainium in 2020 as they are now 35+ years old. They were 
a custom chip first made in 81 or 82 for Radio shacks color computer 
line. Analogue portions of it have been bypassed 25 years already, looks 
like its logic has now died too. 2nd time.

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


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.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev alzheimers

[David Wright]

On Thu 21 May 2020 at 08:23:55 (-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

To give you a concrete example, I've attached a set of files that
I use to generate stable mountpoints (USB sticks) and symlinks
(drives) in /media when I insert known sticks or DVD-burners.

The comments in the first file explain how to find out the relevant
information for writing the others. It looks as if your serial numbers
would be a good choice to concentrate on, just like my burners.

Note that, because I'm lazy, I treat the LABELs, UUIDs and serial
numbers as unique and distinct from each other, in one mixed namespace
(the filenames in /etc/udev/rules.d/my-mountpoints/).
The mountpoint or link is the contents of the file in that directory.
Thus a 1GB USB that I acquired 2017-04-03 with USGS inscribed on it
is FAT formatted with a "UUID" 2017-0403, and generates a mountpoint
/media/usgs1g. The DVD-burner with the serial number KZ3E2DH0440
generates a link /media/cdrom3, which makes it easy to distinguish
two identical LG Slim Portables plugged in simultaneously.

> and chattr +i to 
> effect a permanent cure for this apparently random device renaming?

No. don't do that!

> And whats the command to restart udev from a clean slate without 
> rebooting?

# udevadm control -R

> These are the ttyUSB ports that need persistent names:
> 
> root@coyote:rules.d$ usb-devices|grep -C4 SERIAL
> T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=0403 ProdID=6001 Rev=04.00
> S:  Manufacturer=FTDI
> S:  Product=USB HS SERIAL CONVERTER
> S:  SerialNumber=FTDHG45D
> C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=44mA
> I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
> 
> --
> T:  Bus=01 Lev=02 Prnt=04 Port=02 Cnt=02 Dev#=  7 Spd=12  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=0403 ProdID=6001 Rev=06.00
> S:  Manufacturer=FTDI
> S:  Product=USB FAST SERIAL ADAPTER
> S:  SerialNumber=FTOOS09N
> C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

Cheers,
David.
# /etc/udev/rules.d/80-mymkdir.rules last edited 2020-02-14

# $ udevadm monitor -u -p
# is used to check what udev is doing when USB devices are (un)plugged.
# $ udevadm monitor -u -p -s block/partition
# filters out all but USB sticks etc
# $ udevadm monitor -u -p -s block/disk
# filters out all but CDROM/DVD devices etc
# # udevadm control -R
# as root is used to reread the rules whenever a rule is changed.

# Don't touch swan but leave it to fstab.
ENV{ID_SERIAL_SHORT}=="W3708T01", GOTO="mymkdir_rules_end"

# Run a shell script for more flexibility with LABELs, UUIDs and so on.

ACTION=="add",SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", 
RUN+="/etc/udev/rules.d/mymkdir.sh"
ACTION=="remove", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", 
RUN+="/etc/udev/rules.d/myrmdir.sh"

ACTION=="add",SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", 
RUN+="/etc/udev/rules.d/mymkdirlnk.sh"
ACTION=="remove", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", 
RUN+="/etc/udev/rules.d/myrmdirlnk.sh"

LABEL="mymkdir_rules_end"
#


mymkdir.sh
Description: Bourne shell script


myrmdir.sh
Description: Bourne shell script


mymkdirlnk.sh
Description: Bourne shell script


myrmdirlnk.sh
Description: Bourne shell script
usgs1g
cdrom3

Re: udev alzheimers

[tomas]

On Thu, May 21, 2020 at 08:23:55AM -0400, Gene Heskett wrote:
> greetings all;
> 
> 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.

> 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.


signature.asc
Description: Digital signature

Re: udev alzheimers

[Dan Ritter]

Gene Heskett wrote: 
> greetings all;
> 
> 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?
> 
> And whats the command to restart udev from a clean slate without 
> rebooting?
> 
> These are the ttyUSB ports that need persistent names:
> 
> root@coyote:rules.d$ usb-devices|grep -C4 SERIAL
> T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=0403 ProdID=6001 Rev=04.00
> S:  Manufacturer=FTDI
> S:  Product=USB HS SERIAL CONVERTER
> S:  SerialNumber=FTDHG45D
> C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=44mA
> I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
> 
> --
> T:  Bus=01 Lev=02 Prnt=04 Port=02 Cnt=02 Dev#=  7 Spd=12  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=0403 ProdID=6001 Rev=06.00
> S:  Manufacturer=FTDI
> S:  Product=USB FAST SERIAL ADAPTER
> S:  SerialNumber=FTOOS09N
> C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0)   # will get
you the list of attributes you can match on

Then in /etc/udev/rules.d/  you want a file that says things
like:

SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", 
ATTR{idSerialNumber="FTDHG45D" SYMLINK+="ttyUSB0", GROUP="serial"
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", 
ATTR{idSerialNumber="FTTOOS09N", SYMLINK+="ttyUSB1", GROUP="serial"

ATTR{idSerialNumber} will be crucial, but it might not be
labeled that way - check with the udevinfo statement above.

Change GROUP as desired.

-dsr-