I struggled with this problem for some time and found a solution or rather the reason it happens. Let me explain and hopefully it will help someone.

My problem manifested itself a little different. With all my usb/serial devices plugged in and powered at the time I booted the pi, all was good, sometimes. If I unplugged/plugged in a device, my dev rules where ignored. They would show up connected to gpiochipN or somewhere in the usb bus. Just as an aside, I also have a PoleMaster that could be started as a regular user under one os kernel, but after an upgraded could only be started as root. Udev rules where a constant source of wasted time and effort.

The breakthrough came after much research, trial, error, and a revelation. The revelation? The kernel version and module versions where not the same. I had a recent kernel with no matching modules directory. Verify with :
The solution was simple and this is right from raspberrypi.org
First, update your system's package list by entering the following command:
Next, upgrade all your installed packages to their latest versions with the following command:
Note that full-upgrade is used in preference to a simple upgrade, as it also picks up any dependency changes that may have been made.

This really made a difference in the performance of my rig all around, besides fixing the udev and PoleMaster problems. In fact I doubt I will be doing any hardware upgrades soon, I'm that happy with the way it is working. I did add an rtc to my pi's for $8 US each.

Tim

Tim,

I want to make sure I understand the issue. I ran those commands, and I see:

Since in tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html it says:Does that mean that everything's fine with my system (even though I had that udev issue)? (there is no "build" below any of the kernel version directories)

Thanks,
Hy

PS I ordered a 2nd SSD. My plan/hope is to do a full copy, using the RPi's SD Card Copier, from one SSD to the other before any full-upgrade, since I finally do have a working version.

sudo apt update && sudo apt full-upgrade

is actually part of the script I am using whenever I complile indi and kstars from the source. Just so to make sure that all dependencies and drivers are always up-to-date.

it looks like your kernel version and module versions are the same. I’m not an authority on linux, i’ll admit. But, as El Corazon says, ‘just to make sure.’
It could be there is some other dependency not satisfied, so i would try an update and full-grade. As always, WMMV.

Tim

FWIW, full-upgrade is a pretty heavy hammer to use in a script like this.
It may upgrade the OS, if a new version is available, which can take an hour or two.

Also, FWIW, "sudo apt update ; sudo apt dist-upgrade" did not fix the udev problem.
I still need the workaround where I place the following near the end of /etc/rc.local
Hy

Hy, I do not recall how this works on RaspiOS, but in Ubuntu, which I am using on the Pi4, the default setting of the built-in software updater IS full-upgrade. I.e. unless one goes in there and manually deselects system upgrades, it will always default to marking all upgrades of system files and applications and then installing them.

I don't recall how long a full-upgrade can take with RaspiOS, but with Ubuntu it rarely takes longer than 5 min, 10 min tops if new linux headers and kernel need to be installed.

Note, I am referring to a system-wide update, not to a full distribution upgrade to a whole new version. That would take a lot longer, I agree. But that only happens yearly.

And at any rate, unless I add the -y statement, the terminal will ask me whether I want to proceed with all those new updates, so I can still pull the plug at that stage if it looks too much or might take too long.

Which raspberry OS are you using, 32 or 64 bits? i tryed the latest with 32bits from this december on a rpi4 8GB with kernel 5.4.79-v71+ and my devices that work on a ubuntu dosen't work with raspberry os.

Looks like I'm using the same as you--latest 32-bit OS.It is running fine with all my stuff (see signature below for details of what I'm running).
As I mentioned, I needed a little workaround to get the udev rule to assign the right symbolic links for the mount and focuser.

I wonder if this is the same issue which a number of us suffered from back in the summer when the Raspberry Pi OS kernel was upgraded from 4.19 to 5.4? Especially when there was a powered USB 3.0 hub involved, we found that FTDI USB-Serial chips which had worked perfectly well were no longer being recognised and listed on active USB ports. I still suffer from the invisibility of my Pegasus Astro Pocket Power Box which contaIns an FTDI chip.My workaround is to initially chooose an Ekos profile which omits the PPB from its connenctions, close it down and start up the full profile. The order of the tabs in the Indi window would usually start with the PPB if I engage the full profile at the start, but if I carry out the workaround, the mount is first tab and the PPB is second. The behaviour has gradually improved with each kernel tweak since the big move to 5.4, but the USB ports are still not as stable as they were under the 4.19 kernel. If you think it's worth it, I'll look out the earlier threads on this subject.

Ed (@avocette):

Thanks, but FWIW, I have reached a stable working workaround with the udevadm lines in rc.local, as described earlier in this thread.
I did test and dist-upgrade didn't improve anything.
I'm now quite happy with my Rpi4-8Gb with SSD running the new RPi OS.

IMHO it is a big improvement over the RPi4 4Gb (the SSD is the improvement),
which itself was last year a huge improvement, of course, on the RPi3b.

Thanks - I may well try your workaround (when I’ve put in a bit more learning on udev etc.). I have been running my RPi4 from an SSD ever since the beta firmware was issued, and I must agree that the combination is great. I also run an Astroberry server on a first generation 2GB from an SSD, and have had no problems with the reduced RAM size. The only time I have noticed the memory occupancy getting above 1GB is when I open several images at once in the KStars fits viewer (when I want to compare atmospheric transparency at that moment with an hour earlier for instance).