While hardware fault and memtest bugs are possible, there’s also LP #1876157: Memtest86+ in Ubuntu 20.04 doesn’t work. So if the memtest you ran was from Ubuntu 20.04 images, try running memtest from Ubuntu 18.04 images.

My guess is this is due to bug #1785354: ”/etc/fstab: fs_passno is 0 for all file systems”. So yes, you should probably correct it.

I think a warning is warranted: you may be tempted to do a dconf reset -f /, but besides clearing out schema-less keys, reset resets all affected values to their defaults. In any case, I recommend backing up your existing configuration (with dconf dump / >my-dconf.dump) before issuing a dconf reset.

Note that this method may now result in a not authorized error; see this related question (and answers).

I’m unfamiliar with ThinLinux, but is there a good reason you cannot use your desktop environment’s settings application to adjust display settings? The wiki article is quite old, and while some of it may still be valid, display detection and GUI settings tools have improved over the years. Those tools should be the preferred method of adjusting settings, barring exceptions such as brand new hardware with lacking support.

`libinput debug-events` should show scrolling and other pointer events so that you can at least see the numbers have changed according to your custom configuration.

(Expanding on the solution from oldmankit over at Ubuntu Forums)

1. Install bchunk and flac:

   sudo apt install bchunk flac
   

2. Use bchunk to convert the .bin to WAV files:

   bchunk -w image.bin image.cue track
   

3. Use flac to compress the WAV files:

   for f in track*.wav; do flac $f; done
   

Naming and tagging the FLAC files is subject for another question, but cuetools (particularly the cueprint command) may be of help there.

I’ve downloaded the .bin, .cue and .cdt files of an audio CD (freely available), but I’d prefer to have the audio in FLAC format on my computer. How do I convert the audio tracks of the .bin file to FLAC files without losing quality?

I’m using Ubuntu 16.04.

The issue went away when I removed gnome-user-share (sudo apt-get --purge remove gnome-user-share). Apparently it was caused by Gnome’s file sharing function referring to $XDG_PUBLICSHARE_DIR and recreating the (default-named) directory when not found. With gnome-user-share removed, the ”Public” directory no longer reappears.

I’ve set ”enabled=False” in my /etc/xdg/user-dirs.conf which, according to comments in that file, and also according to the spec, should stop xdg-user-dirs-update from running at login time and thus also from recreating any missing $XDG_*_DIR directories.

Additionally, I’ve commented out the definition of XDG_PUBLICSHARE_DIR in my user’s ~/.config/user-dirs.dirs due to not being able to decide where to point it at for now.

Despite xdg-user-dirs-update being disabled, a directory named ”Public” reappears in my user’s home directory at every login. What is causing this and how can I stop the unwanted Public directory from appearing? I’ve found an old Red Hat bug referencing a similar issue, but it’s closed without a known fix.

The issue doesn’t occur for $XDG_TEMPLATES_DIR which I’ve similarly commented out.