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.
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: Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
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
$ /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.
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
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
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.
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.
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.
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
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
A simple solution is to manually remove all DKMS build directories and reinstall all
$ 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