· 729 words · 4 minute read

Broken Ubuntu

So I haven’t used Ubuntu for a while… But I installed it on my new Intel NUC. And my God, what have “they” (=canonical) screwed things up.

What follows is a list of my irritations, hope it’s useful for some of you.

Remote login (VNC) #

By default Ubuntu uses vino as vnc-server (aka remote desktop login). Sadly, this thing is broken by default, it uses an ‘unknown encryption’

The internet offers a slew of options, nothing worked out of the box. What finally got everything ticking was this set of steps:

Reset dconf (to turn off encryption, just google it)
Reboot
Set a password (otherwise it still won't work)

But don’t bother. Because as soon as you have set it up, it’s slow as hell.

The only option is to use X11vnc, with noxdebug option on. Then it’s semi-usable. Unbelievable. I remember this working smoothly 10 years ago! How bad can you break things?

Oh and the fancy feature X11vnc wants you to use, ncache? Also broken :( Makes x11vnc crash…

Also none of the instructions online for starting a VNC session before having logged in work. Right command is:

sudo x11vnc -xkb -auth /var/run/lightdm/root/:0 -noxdamage -rfbauth
~/.vnc/passwd

But probably Canonical will make sure this command won’t work next month.

Locale #

My locale is messed up and I can’t fix it. I’m not the only one with this problem, as a Google search will tell you!

I have tried everything:

locale-gen
dpkg-reconfigure locales
install --reinstall locales

Still not fixed. Locale keeps showing LC_ALL and LANGUAGE to be empty, which means I get screwed up error messages like

exception:
locale::facet::_S_create_c_locale name not valid

(from Grive) or

set LC_CTYPE
to default locale: No such file or directory

Sh*t.

The only option is to do an export EVERY TIME (or put it in your bash_profile):

export LC_ALL="en_US.utf-8
export LANGUAGE="en_US.utf-8

Which officially I shouldn’t be doing, because it’s not good to overwrite your language settings.

Configuration files all over the place #

At least one thing that was consistent was that you could count on stuff being in the right place. Well, not any more. For instance, look at the mess in /usr/share/lightdm/lightdm.conf.d/ Why do I need so many config files?? What do they all do?

50-greeter-wrapper.conf  
50-guest-wrapper.conf  
50-ubuntu.conf  
50-unity-greeter.conf  
50-xserver-command.conf

Which leads right into the next frustration:

The settings file of Transmission #

This one is an even bigger mess. It’s completely unclear which settings file the Transmission-daemon eats.

It could be either one of these:

$HOME/.config/transmission-daemon/settings.json
transmission-daemon/.config/transmission-daemon/settings.json (if you run it as
a separate user)
/var/lib/transmission-daemon/info/settings.json (a symlink in ubuntu)
/etc/transmission-daemon/settings.json
/var/run/transmission

Which one is actually used depends on how you start the daemon. Running it using automatically at boot using init (which there’s also two locations for in Ubuntu, /etc/init and /etc/init.d, only the last one does anything as far as I can find out), starting it manually using init or manually from the command line. The difference between manually or automatically running using init is because of drive encryption: if transmission can’t find the file, it’ll fall back on /var/lib. What a huge mess!

I have set all settings files to log stuff to the /tmp/ folder. This way I can at least see when something goes wrong. Was also the only way to finally figure out the mess.

Other fun stuff:

  • You can’t edit the file with transmission running, because it’ll overwrite it when you stop the service.
  • Transmission will sometimes overwrite the RPC-whitelist to only include localhost. No clue why, it’s the only setting that’s written over.
  • Transmission itself won’t warn you if there’s already a copy running, so use ps aux to check whether this is the case, especially in combination with bullet number 1…

Services sometimes not loading on startup #

This ones a bit of a cr*pshoot. Sometimes it works, most times it doesn’t. My Plex server should run on startup (eg. after logging into the graphical shell). I’ve added it too the startup services, which Ubuntu doesn’t really seem to care about.

Most likely has to do with the encrypted drive…

Shutdown not working as expected #

I used to use shutdown -h now, but they’ve gone ahead and broke that. The machine doesn’t power down, but instead lands in a nonfunctional terminal. Now we have to use poweroff. Which also doesn’t work, because Intel has decided that NUCs should reboot when powering off this way. :(