It would probably be best to get a serial console boot log. This would provide both reliable access and information you probably couldn’t get from a regular terminal login. See:
It would also be useful to know which L4T release the Nano was flashed with, and if this is the dev kit or a module on a third party carrier board.
FYI, if this is an SD card model, then you could easily save a copy of the partition and even if an experiment does not work out, then you’d still be able to go back to the saved SD card image and try again.
I don’t know if it will help or not, but it could be useful to find the list of upgrades which were installed with KDE. If you examine the “
/var/log/dpkg.log*” series of logs, you will perhaps find some have zero size (log rotate on a day when no changes were made), and the most recent non-zero-size logs could have KDE package changes listed. You could post those logs here (you might need to
gunzip ones which are older “
.gz” compressed logs, and then rename as a “
.txt” file name extension if the forums don’t like the file name).
Incidentally, if there is a simple configuration change to fix the issue, and if you are using an SD card model (dev kit), then having a second SD card which has otherwise been updated similarly to the current problem install could provide “donor” configuration files and package lists.
Probably the biggest problem is if kernel modules were overwritten, and this is likely since KDE may have installed some Nouveau content which may overwrite the NVIDIA content (I saw it failed to load a module). In that case it might be simple to just copy the content back in to the right place, but you’ll need to provide that serial console boot log to know.
FYI, if you get serial console access (or just plain console or ssh), then you can check the current L4T release version via:
head -n 1 /etc/nv_tegra_release