Ubuntu Mate 20-04.5 Desktop 64b stability

H/W: Dell Precision M6800 i7-4600M 64b, 16GB RAM, 230GB SSD, Intel HD 4600
S/W: as per title, with 5.15.0-18-generic x86_64 kernel; Mate 1.24.0
one partition for system on /, another for /home, and finally one for swap (16GB)

  1. This week had to re-install Ubuntu following an update where an issue with video driver appeared: pointed to an incorrect driver. Would get a blank screen on reboot and was unable to get system to boot in recovery mode.

    Is there a definitive method to boot into recovery mode?

  2. In re-installing Ubuntu: 20-04.3 -> 20-04.5. Machine freezes regularly and unable to recover this without forcing a hard power down by keeping power button pressed until off.
    If memory serves, in Windows, it was usually possible to do a Cntrl+Alt+Del and you got a system menu where one could kill a delinquent process or at least force a controlled reboot, versus a hard power down.

    How can one always have the possibility of being able to open a terminal with a minimum of resources available, both CPU and memory, to be able to resolve issue?

I'd like to improve my Linux Ubuntu skills and learn how to drill down on issues like the present freezing by examining journals.

What system journals should be examined and what should be looked at for system freezing please?

Many thanks for all help.


This won't be complete, but I'll provide my 2c on a few points only.

I won't be good here, as I use generic GNU/Linux methods & not those provided by Ubuntu. For Ubuntu the following maybe helpful - RecoveryMode - Ubuntu Wiki

Me, I'd just edit the line on grub that boots the system, remove any 'quiet splash' and add a 1 to the linux kernel line, so it stops at runlevel 1, then boot, for starters anyway...

I hope you realize you can re-install non-destructively... ie. for problems, I can re-install my system within 15 minutes which won't impact my user settings/files (they're not touched!), and my manually installed packages (ie. those I installed myself) get auto-reinstalled. Sure if your problems are related to a user setting, as they're not touched any problems in those will survive the re-install; but that is also often helpful diagnostic news... ps: the system I'm using now is a 2008 dell with spinning rust drive, ie. the 15 mins I assume maybe slower than what your hardware can achieve too!

The Linux kernel allows you to directly communicate with it using SysRq commands. Sure a few modern keyboards don't have the SysRq key anymore, but thankfully most do, and even the ones that don't have it printed on the keyboard, have it available with the use of the extra Fn key in my experience.

If you need to remind yourself what those keys are, pull out your phone (or use another box) to search "magic sysrq", and the Wikipedia page is usually at or near the top of results, and is good enough. Whilst it won't provide all features (such as your wanting to open a terminal), it allows you to command the kernel through a stuck/crashed GUI etc. & allow a clean shutdown; instead of potentially dangerous power-off button.

If I have an issue that I think is problematic & want to explore it, I tend to open a terminal before hand, and just let it sit idle. If I expect to lose access to my GUI, I'll use a text terminal (CtrlAltF4 for example) and leave it logged in so I can switch there and explore. Alternatively I'll use a nearby box and ssh into the machine to explore, if I have one nearby & I have openssh-server running.

If you reboot, you've lost anything that was found in dmesg & some logs, as they cover the current session only (ie. since boot). Systemd journals however extend beyond the current session, and especially if you cleanly shutdown (SysRq-REISUB for example) I'd expect the logs to be complete. A journalctl for example can be used to view those logs, with standard POSIX/unix/vi search features available (/ to search etc)