Dell Latitude 7490 freezing when unplugging USB3 WD15 dock

Setup – Dell Latitude 7490 running Ubuntu 18.04 Bionic and Dell WD15 USB-C dock.

Problem – system freezes when dock unplugged.

This problem started after updates. The solution found was to revert to the previous kernel (4.15.0-43-generic) from 4.15.0-44-generic. Did this by setting GRUB to remember the boot setting – change /etc/grub/grub with:


and run


Then hit esc at the loading screen to get to the grub menu.

Making nis authentication work with Ubuntu 16, Debian 8, Fedora 28 etc.

After updating anything to use systemd-235 NIS logins either don’t work at all (usually for GUI logins), or take a long time to login (console or ssh, sometimes). The culprit is a line in the systemd-logind.service:


This sandboxes the service and doesn’t allow it to talk to the network. Unfortunately this affects nis lookups done via the glibc NSS API. See the links at

The quick solution is to turn off the sandboxing, either by commenting out or changing the line in systemd-logind.service, or creating a drop-in snippet that overrides it. This can be done by creating a file /etc/systemd/system/systemd-logind.service.d/IPAddress_clear.conf with the contents:


The file can be called anything you like (.conf).

Then restart things:

systemctl daemon-reload
systemctl restart systemd-logind.service

You can check that the drop-in is being loaded with

systemctl status systemd-logind.service

In the output you should see something like:

   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
  Drop-In: /etc/systemd/system/systemd-logind.service.d

The other test is to see if NIS logins work correctly, of course…

The slightly slower solution is to use nscd to cache the lookup requests, and apparently does so in a way that plays nicely with the sandboxing. The much slower solution is to switch to using sssd or similar and ditch NIS once and for all…

Note – this may also affect systemd-udevd.

Making Debian 9 (Stretch) configure GRUB to boot partitions with UUIDs

As per this bug:

Debian Bug report logs – #852323

The Debian 9 installer (up to v9.5 at least) does not always configure GRUB to find the boot partition using UUID, but leaves it pointing to /dev/sdb or whatever. This can be a problem if you change disks in the system. In particular, if you install from a USB stick and then remove it when the system reboots after the install this can change the disk /dev id. The result is a unbootable system. This can be a bit fiddly to fix (although the first thing that’s always worth trying is to reverse the changes you made and see if it boots, e.g. plug the install USB stick back in to the same usb slot).

You can check this by looking at the /boot/grub/grub.cfg file. A quick check is:

grep "/boot/v" /boot/grub/grub.cfg

The fix is easy. Let the system reboot while leaving the install media in place (obviously make sure you don’t boot from the install media again!). Log in to the system and run (as root/using sudo)


Compare the grub.cfg before and after. Then test by removing the install media and rebooting.

Making nis automounting work in Debian and Ubuntu (and BSD)

We have a problem that with recent versions of Ubuntu (16.04 and later) and Debian (8 and later) the normal way we set up automounting to mount our nis users home directories doesn’t work – apparently due to boot ordering issues. (It works fine with Red Hat derivatives). We accidentally found a solution when copying a BSD configuration…

We create a file in /etc/auto.master.d (gets read in by auto.master in the standard Debian/Ubuntu setup):

/home auto.astro
/scratch auto.scratch

Then in /etc we have:

#! /bin/sh -

if test $# -eq 0; then
    ypcat -k auto.home | awk '{print $1}'
    ypmatch "$1" auto.home


#! /bin/sh -

if test $# -eq 0; then
    ypcat -k auto.scratch | awk '{print $1}'
    ypmatch "$1" auto.scratch


Note these files are shell scripts so need to be executable!

(yes, it’s a bit odd we call the home mapper auto.astro. Historical reasons).

These seem to work reliably on Ubuntu and Debian. This setup actually came from a BSD box.

Making static networking work in Ubuntu 18.04

Ubuntu 18.04 has switched to netplan for configuring the network interfaces. Netplan generates configurations for NetworkManager or systemd-networkd and effectively replaces ifupdown and the /etc/network/interfaces file.

In an install of Ubuntu Desktop, the default netplan configuration comes from /etc/netplan/01-network-manager-all.yaml which reads:

  version: 2
  renderer: NetworkManager

This basically hands over all network control to NetworkManager. For a static setup we can change the configuration to:

  version: 2
  renderer: networkd
      dhcp4: no
      addresses: []
      gateway4: bbb.bbb.bbb.bbb
        search: []
        addresses: [,yyy.yyy.yyy.yyy,zzz.zzz.zzz.zzz]

Where enp0s25 is my network interface in this case, the address has a netmask of and the search is the default dns search domain(s) (note this can be vital for getting automounting to work if your setup just uses machine names and assumes the domain is the same).

Note that if you have a laptop you could put this in a file called, say 02_ethernet_interface.yaml and it should override the first configuration for that interface only. I think. Later configurations override earlier ones.

To test:

netplan try

This applies the configuration and then rolls it back in 120 seconds (by default). Press Enter to accept the new settings.

netplan apply

To apply the changes.

For a desktop I just deleted the first config file.

In theory you could probably use this to generate a configuration for NetworkManager (note that on a server you need to explicitly configure NetworkManager to bring up the interface on boot).

Invalid self-signed certificates in FreeNAS 11

Had a problem with several FreeNAS 11 systems – when trying to enable https for the web interface I couldn’t get a working certificate.

  1. Generate internal CA.
  2. Generate internal certificate.
  3. Chrome complains the certificate is invalid and does not allow you to bypass it.
  4. Delete certificate and CA, repeat, same problem.

After mucking about with using upper and lower case for the certificate CN names etc, eventually got things to work by generating a second certificate with the same CA. Which makes me think it might be this problem:

FreeNAS-Generated Certificates: Buyer Beware

So either generating a couple of certificates (and using the second one) or changing the serial number of the CA to something bigger than 1 (and then generating a certificate) should work.

(Go to the CA tab, double-click the CA entry and scroll down to the bottom to view/edit the serial number).

OneDrive for Business High CPU

Had an issue where OneDrive for Business (installed with Office 365) was constantly using one CPU core. None if the fixes involving the cache or resetting the client worked. The problem seems to have started with recent (possibly after Office 365 1712 8827.2148) updates. What did work was the solution in this thread:

Condensed version: Stop using the old client (groove.exe) and use the personal client instead, which now seems to work (at least, the latest Windows 10 version) with business accounts as well.

(Note that this doesn’t apply to connections to onsite hosted sharepoint drives – there is apparently a fix coming sometime.)

The sequence is:

  1. Stop the OneDrive for Business client (right-click the system tray icon and choose exit, or kill it otherwise).
  2. Disable it from starting (use msconfig as an easy way to do this).
  3. Remove the existing OneDrive for Business folders (move them to a backup location)
  4. Open the personal OneDrive settings.
  5. Add an account and connect to the business account.


502 Bad Gateway with SVN copy, move or rename behind a reverse proxy

Problem: You have a SVN server sitting behind a reverse web proxy (e.g. for convenient SSL termination purposes). This works for new files, changes etc. but fails when you try to rename something, make a copy or move. The error is:

Unexpected HTTP status 502 'Bad Gateway'

The reason is explained here, but to summarise:

These operations involve sending a http COPY method. This includes a Destination: field in the header, which is not rewritten by Apache’s ProxyPass directives. Thus the destination field starts with https – not http. This confuses mod_dav on the SVN server.

The solution is to change the header. We can do this on Apache (2.2 or higher) using the headers module. This can be done either on the proxy server or the SVN server. As my SVN server is very old (the main reason why it’s behind a proxy) I’ll do this on the proxy server.

Enable the headers module if required. On Debian:

# a2enmod headers

and restart Apache. Then alter your configuration to include:

RequestHeader edit Destination ^https http early

This probably should go before any ProxyPass directives.

Then your config might look like:

RequestHeader edit Destination ^https http early

ProxyPass /svn http://your.real.svn.server/svn
ProxyPassReverse /svn http://your.real.svn.server/svn
<Location /svn/>
  Require all granted

(Note this is for a gateway system where other locations can proxy to other application servers.)