Maybe of use to some - especially Rasp Buster/Stretch - but on an old RPI3 I had slow boots and reboots for REALVNC server connections.
However it seems its not the vnc server but a headless problems - no mouse seems to be the problems reading the thread below. Any how installing HAVEGED cures this problem and now vnc sessions (especially on reboot) and faster (alot). Dont know if it works on other O/S on RPI.
If it helps someone great.
Are you sure the cable isn't snagging on something ?
IMO Its sounds like a cable or power spike/drop off or adapter problem nothing to do with Linux OS - as you say you have been using it fine for several hours and over a year ok.
Here I was doing the normal Platesolving when things started to go a bit wrong and Platesolving (any type - ASTAP,Astrometry local etc) starting failing - some weird errors and even core dumps from segmentation failures.
Anyway after pulling all of the little hair left out I found the problem - on 1 Index Platesolving gave some saying "Invalid Star ID" - trouble is unless you scroll through the whole log you wouldn't necessarily see it as you get the segmentation fault or iotclt fault info. It appears the index had become corrupted ( I did have a lock up once - but reading ! ) so replacing that single index cured the problem.
Still perplexed / worried why reading should corrupt files on a newish SSD .
So if you have a weird set of errors (think I had error 139 and error 256) and /or segmentation fault / core dumps when running platesolving - check the log closely for any "Invalid ID" it might help
Perhaps this might help others !
If you go to the follow and scroll down to "how to make my own etc" you will find a tried and tested ,over a good number of years by many people,the correct details of wiring ,plugs and voltages.
. Personally I would stick to the std TTL voltages ,as described ,even if it says "tolerant" !
FDTI cables are the best for another good reason they have unique serial numbers which allow Linux via Udev to assign ports to devices. CH340 work too and come with 5v/3.3v switch but with the Udev problem.
Prolific and CH340 ,to name a few, do not any unique identification and so there is no simple way , other than position (as far as I am aware) in the USB hub to create a udev rule - but this is messy and prone to "cock ups".
But most would NEVER use a working set up to "try" something out - learn't that a long time ago on any computer system.
At least you had a back up.
Instructions to create KDE Desktop version on RPI4 - Not tried them
Haven't tried it on RPI4 but i used this version which includes KDE on RPI3b+ and my 5ghz Wifi problem disappeared but it wasn't very stable then. It now runs on RPI4 as well as RPI2,3,3B+ if someone cares to try it and there is an image ready to download.
Unfortunately a lot of Nano's are CH340 chipped based and so are a lot of ESP "stuff" - all appear to have no uniqueness so you have to buy other vendor's. It would be nice to have it one day.
" I have no experience with docker" nor me
I was thinking of just Indi/Kstars on Raspbian as we can't use the same method as Ubuntu update for Kstars/Ekos/Indi as I understand it .
OK thanks for the answer
Question on Udev rules script - it looks like you rely on each device being unique but I have had problems using CH340 chipped devices which do not have any unique way of identifying the device.
Forgive me in case I am wrong (more than likely )but the Udev rules script does not have anyway to use "position" (e.g. always position 1) which is the only way I know of that can be used if the Product Id ,serial etc are the same.
Future request maybe - Docker version so that we can have different versions on the one SD/SSD device and change quickly - if thats possible ?
OK I am not using RPI4 just a RPI3b+ BUT i am using RPI3b+ using Buster and you can certainly mount USB sticks as well as a DSLR.
Unfortunately I am using Indigo_server not Indi_server but the principle is the same as far as devices being mounted etc.
So long as the actions in the DSLR FAQ's are used INCLUDING GNOME stop automounting
jrlaffoon provided the following solution:
sudo rm /usr/share/dbus-1/services/org.gtk.Private.GPhoto2VolumeMonitor.service
sudo rm /usr/share/gvfs/mounts/gphoto2.mount
sudo rm /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor
sudo rm /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
gsettings set org.gnome.desktop.media-handling automount false
The above works everytime - so far.
As you can see from attached screen captures there is a USB stick mounted (has Ubuntu Mate on it ) , no Canon mounts (which did appear before using above settings) and Indigo_server is running and being used by CCDCiel on another PC.
So unless there is something odd going on with RPI4 Kernel or whatever it should,one would think, still be the same or possible.
Note FYI I never switch on the DSLR or stick in the Stick until the system has booted.
If you search this forum you will see that I had the same problem on RPI3b+ and changing the country code does not always work - e.g. Ubuntu Mate . Raspbian it worked. "Grey" imported AP's also seem to cause this problem as they are built for the country they are normally sold in and have different REGS/freq etc - its just a mess
Hope the country code works for you.
I have set up 1000's of networks,some very large and complex , over the years and I know my statement is true.
"But, firstly my point is that the rpi can connect direct to another PC with Ethernet cable without the need for a static ip, just plug the cable between and it works straight away"
This only works if either a DHCP server is available somewhere on your network , you have a static address defined in the Wired Ethernet settings or you have connected via the Ethernet(wired) before and the lease time provided by DHCP that you originally connected to hasn't expired - the latter should fail but I have noticed this does work sometimes.
This is standard networking, be it Windows or Linux