Issues and workarounds for Debian 8

Debian 8 logo

Debian 8 brings updates to 66% of packages and switches to systemd as its default system and service manager. This can result in a couple of issues, so check below for workarounds and solutions.

Systemd ignores decrypt_derived keyscript

Many security aware users of Debian have encrypted root, swap, home, and other partitions using cryptsetup. Automatic mounting of those partitions at boot time can be configured in /etc/crypttab. Instead of entering passwords for each partition each time it is possible to use keyscript scripts to use other key sources and automate the process. One of those keyscripts is decrypt_derived that provides a way to chain encrypted partitions, such that the encryption key is automatically derived from a previously unlocked partition.

This used to work pretty well on Debian 7 and older that used SysV service manager:

$ cat /etc/crypttab
debian_crypt UUID=08bd04d5-... none luks
sdb1_crypt UUID=a84f890c-... debian_crypt luks,keyscript=decrypt_derived
swap_crypt /dev/sda2 debian_crypt swap,cipher=aes-cbc-essiv:sha256,hash=ripemd160,size=256,keyscript=decrypt_derived

Although the new systemd service manager processes the /etc/crypttab configuration, it unfortunately ignores keyscripts and can not use anything equivalent.

$ cat /var/log/syslog
Apr 04 20:37:38 xxx systemd-cryptsetup[544]: Encountered unknown
/etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.

Workaround

Instead of using decrypt_derived keyscript, you can save its output into a file and put it on the encrypted partition from which it derived. For the above example, where debian_crypt is the root partition and other keys are derived from it, this means saving it into /.debian_crypt.key (make sure no one but root can access it). Then specify this as the key file, add a dependency to initially mount this partition, and do not forget to update the boot-time initramfs archive. This at least works for the encrypted root partition on which others depend on and is as secure as using the decrypt_derived keyscript.

$ /lib/cryptsetup/scripts/decrypt_derived debian_crypt > /.debian_crypt.key
$ chown root:root /.debian_crypt.key
$ chmod 600 /.debian_crypt.key
$ cat /etc/crypttab
debian_crypt UUID=08bd04d5-... none luks
sdb1_crypt UUID=a84f890c-... /.debian_crypt.key luks
swap_crypt /dev/sda2 /.debian_crypt.key swap,cipher=aes-cbc-essiv:sha256,hash=ripemd160,size=256
$ grep CRYPTDISKS_MOUNT /etc/default/cryptdisks
CRYPTDISKS_MOUNT="/dev/mapper/debian_crypt"
$ update-initramfs -u
$ reboot

Systemd hibernation with encrypted swap partition

Although suspend to RAM works well on all versions of Debian, one may also want to hibernate it to disk now and then. Unfortunately this does not work if you are using an encrypted swap partition. It seems that by digging into the initramfs archive scripts and hibernation hooks one could accomplish this in Debian 7 or older, but in Debian 8 with systemd manager it seems to become more complicated.

Nvidia graphic driver kernel updates

Proprietary kernel drivers and apps often cause problems and inconveniences. One of them is recompiling the binary driver each time you switch to a new kernel. If you fail to do that, you will not be able to start the X.org server graphical window interface and be stuck in the console.

Workaround

Luckily Debian 8 or older contain a Nvidia DKMS driver that, when installed, automatically recompiles itself after each kernel update.

$ aptitude install nvidia-kernel-dkms xserver-xorg-video-nvidia

Skype error loading libGL.so.1

In case you are using Skype on a 64-bit system, it may not even start after updating to Debian 8. Skype is looking for an i386 library that is not provided by the Nvidia package.

$ skype
libGL.so.1: cannot open shared object file: No such file or directory

Workaround

As an workaround the MESA i386 library libGL1.so.1 can be used. To use this library for Skype create the file /etc/ld.so.conf.d/skype.conf with the following contents and reload shared libraries.

$ cat /etc/ld.so.conf.d/skype.conf
# Skype error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
/usr/lib/mesa-diverted/i386-linux-gnu
$ ldconfig -v

Black screen with cursor after suspend

When using a proprietary Nvidia driver, it may happen it doesn’t initialize correctly after returning from a suspend to RAM, so you end up at a black or garbled screen with a cursor. The problem seems to be connected with using OpenGL effects on a composing desktop environment.

Workaround

In KDE under System Settings/Workspace Appearance and Behavior/Desktop Effects those desktop effects can be turned off. Alternatively you can setup a keyboard shortcut (default Alt+Shift+F12) to toggle effects and each time you get stuck in a black screen just switch it off and on again, so that everything gets redrawn correctly.

KDE screensaver during a fullscreen application

In KDE 4.11 it sometimes happens that the screensaver turns on although you are watching a movie in fullscreen, e.g. in VLC media player, from browser with Flash or HTML5 video. In previous versions a workaround script called lightsOn.sh used to prevent the screensaver from turning on by triggering events while it was running.

Workaround

So the only way to is to actually turn it off. In KDE under System Settings/Hardware/Display and Monitor/Screen Locker turn off Start automatically after # minutes and turn it back on when you stop watching the fullscreen application.

You may also try programmatically disabling and enabling the screensaver with:

$ xset -dpms; xset s off
$ xset +dpms; xset s on

Unbootable with software RAID1 and GRUB2

There is a bug in Debian Installer that results in an unbootable system after fresh installation of Debian 8.1. It happens if you manually partition your disks and setup all partitions in software RAID array, including partition with /boot. mdadm will by default create arrays with metadata format version 1.2 (not 0.90). This messes up the GRUB2 installation step so that it doesn’t install itself into the master boot record of hard drives correctly. As a result the system hangs and shows a blank screen where GRUB2 boot loader should appear.

Workaround

During the installation process, just after you Install the GRUB boot loader on a hard disk, you should switch to the console (Ctrl+Alt+F2) and force install GRUB2 boot loader on all hard drives (not partitions) and update initramfs (in case it was missing something):

$ mount -t proc proc /target/proc
$ chroot /target
$ update-grub
$ grub-install --recheck /dev/sda
$ grub-install --recheck /dev/sdb
$ update-initramfs -u

Afterwards switch back to the Debian Installer (Ctrl+Alt+F1) and finalize the installation.

DKMS could not locate dkms.conf

Each time you upgrade the kernel, you should check whether everything went smooth, especially if you are using proprietary drivers or custom kernel modules. It can happen that the DKMS framework for automatically recompiling kernel modules gets stuck and consequently some modules won’t work under the new kernel.

$ dkms status
Error! Could not locate dkms.conf file.
File:  does not exist.

Cause of this error is an invalid state in DKMS build directories /var/lib/dkms.

Workaround

A simple solution is to manually remove all DKMS build directories and reinstall all *-dkms packages.

$ rm -rf /var/lib/dkms/nvidia /var/lib/dkms/nvidia-current /var/lib/dkms/virtualbox
$ aptitude search '~i-dkms'
i   nvidia-kernel-dkms
i   virtualbox-dkms
$ aptitude reinstall nvidia-kernel-dkms
...
Setting up nvidia-kernel-dkms (340.65-2) ...
Loading new nvidia-current-340.65 DKMS files...
Building only for 3.16.0-4-amd64
Building initial module for 3.16.0-4-amd64
Done.
nvidia-current:
...
nvidia-uvm.ko:
...
DKMS: install completed.
$ aptitude reinstall virtualbox-dkms
...
Setting up virtualbox-dkms (4.3.18-dfsg-3+deb8u3) ...
Loading new virtualbox-4.3.18 DKMS files...
Building only for 3.16.0-4-amd64
Building initial module for 3.16.0-4-amd64
Done.
vboxdrv:
...
vboxnetadp.ko:
...
vboxnetflt.ko:
...
vboxpci.ko:
...
DKMS: install completed.

Afterwards make sure your kernel modules were recompiled for the new kernel:

$ dkms status
nvidia-current, 340.65, 3.16.0-4-amd64, x86_64: installed
virtualbox, 4.3.18, 3.16.0-4-amd64, x86_64: installed