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