Short cryptsetup/LUKS tutorial

This short tutorial will guide you in encrypting a drive with cryptsetup and LUKS scheme.

Before starting, if the device had previous data on it, it’s best to delete any filesystem signatures that may be on it. Assuming that the drive we operate is /dev/sda you can use the following command to remove the signatures:

$ sudo wipefs --all /dev/sda --no-act

Remove the --no-act flag to actually modify the disk.

The next step is to actually format the drive using LUKS. This is done using the cryptsetup utility.

$ sudo cryptsetup luksFormat --type=luks2 /dev/sda

WARNING!
========
This will overwrite data on /dev/sda irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda: 
Verify passphrase: 

The command will prompt you to enter a passphrase for the encryption and should take a few seconds to complete.

The next step is to add an appropriate entry to crypttab which will simplify starting the dm-crypt mapping later. Add the following line to /etc/crypttab:

archive_crypt UUID=114d42e5-6aeb-4af0-8758-b4cc79dd1ba0 none luks,discard,noauto

where the UUID is obtained through lsblk /dev/sda -o UUID or a similar command. The archive_crypt is the name for the mapped device. It will appear as /dev/mapper/archive_crypt when the device is mapped. The none parameter specifies that no keyfile is used and the system should prompt for an encryption passphrase instead. The noauto, means not to attempt to load the device automatically upon boot. discard should be used if the underlying device is an SSD.

You can test everything works so far by opening and loading the LUKS device:

$ sudo cryptdisks_start archive_crypt

While the device is now encrypted, there is a possible leakage of metadata such as used blocks as an attacker can discern used vs unused blocks by examining the physical drive. This and other side-channel leaks can be mitigated by simply wiping the contents of the encrypted device.

$ openssl rand -hex 32 | openssl enc -chacha20 -in /dev/zero -pass stdin -nosalt | sudo dd if=/dev/stdin of=/dev/mapper/sda_crypt bs=4096 status=progress

We could also have used /dev/urandom but the above technique is much faster.

Now we can create the actual filesystem.

$ sudo mkfs.btrfs --label archive /dev/mapper/archive_crypt

At this point we’re actually pretty much done. You can add and entry to /etc/fstab to easily mount the filesystem and you’re done.

/dev/mapper/archive_crypt /home/guyru/archive btrfs noauto,user 0 0

Gave up waiting for suspend/resume device

My boot process was pretty slow in a new setup I had. It would stop for about 30 seconds and then give the following error:

Gave up waiting for suspend/resume device

Turns out I had a resumable device listed in /etc/initramfs-tools/conf.d/resume even though my swap is both encrypted with random keys and too small. Editing that file and setting RESUME=none and running sudo update-initramfs -u fixed the issue.

Fixing Zoom’s Screen Sharing on Debian Unstable

Zoom has a native Linux client which supports screen sharing in Wayland, at least on some platforms. Today when I tried to start a Share Screen I encountered the following error:

Error when trying to start Share Screen

Can not start share, we only support Wayland on GNOME with Ubuntu 17 and above, Fedora 25 and above, Debian 9 and above, CentOS 8 and above, OpenSUSE Leap 15 and above, Oracle Linux 8 and above, Arch Linux, AnterGos, Manjaro. If your OS is not on the list, please use x11 instead.

The feature works for me when I’m using Debian Stable (Buster), and also worked for the short while I’ve used Debian Testing (Bullseye). So, I guessed that the feature is broken due to wrong OS version detection. The fix is easy: Remove /etc/os-release (which is by default a symlink to /usr/lib/os-release) and append to the original contents the following lines:

VERSION_ID="99"
VERSION="99 (sid)"
VERSION_CODENAME="sid"

So the entire file should look like:

PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
VERSION_ID="99"
VERSION="99 (sid)"
VERSION_CODENAME="sid"

Why it works?

When I first encountered the error, I guessed Zoom doesn’t actually attempt the Share Screen, but relies on a pre-configured list of supported distros and (minimal) versions. It worked for me with Debian Stable (10) and Testing (11), but what version number is Unstable? Debian Unstable doesn’t have a version number associated with it, so it must be the problem.

A quick strace revealed how Zoom retrieves the current distro name and version:

$ strace -f -tt zoom
...
107498 11:20:58.943764 openat(AT_FDCWD, "/etc/os-release", O_RDONLY|O_CLOEXEC
107513 11:20:58.943771 futex(0x565257f88760, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1592727659, tv_nsec=303765000}, FUTEX_BITSET_MATCH_ANY
107498 11:20:58.943779 <… openat resumed>) = 17
107498 11:20:58.943787 fcntl(17, F_SETFD, FD_CLOEXEC) = 0
107498 11:20:58.943802 fstat(17, {st_mode=S_IFREG|0644, st_size=200, …}) = 0
107498 11:20:58.943817 read(17, "PRETTY_NAME=\"Debian GNU/Linux bu"…, 200) = 200
...

As you can see Zoom reads (and probably later parses) the entire /etc/os-release file. This file contains identification data for the current running distro including name and version. Because Debian Sid doesn’t have the version variables set, Zoom erroneously misinterpret it as an old version instead of the newest. Thus, it refuses to enable the Share Screen feature. Adding the relevant version variables solves this issue.

See also: man os-release (5)

Prevent applications from increasing output volume in PulseAudio

By default, PulseAudio allows an application to change the max volume output to be louder than the one set by the user. I find it annoying that some apps tend to set volume to 100% which ends up increasing the system volume to unreasonable levels. You can prevent it by setting flat-volumes to no in ~/.config/pulse/daemon.conf.

$ echo "flat-volumes = no" >> ~/.config/pulse/daemon.conf 
$ pulseaudio --kill
$ pulseaudio --start

With flat-volumes = no PulseAudio uses relative volumes. Each applications sets its own volume relative to the system output.

References:

`xdg-open` fails when using Firefox under Wayland

Recently I noticed xdg-open started failing opening links in Firefox. Giving me the following error:

Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

It happened while I had Firefox running and responding to everything else. I’m running the latest stable Firefox (74 as I’m writing this) on Wayland. Wayland brings a lot of good things, but also a lot of interoperability problems, so I suspected it had something to do with it. Thanks to Martin Stransky I found out that the solution is to set the MOZ_DBUS_REMOTE environment variable prior to launching Firefox. If you are using a desktop file to launch Firefox, you can set the variable in the Exec line like this:

[Desktop Entry]
Type=Application
Name=Firefox
Exec=env MOZ_DBUS_REMOTE=1 MOZ_ENABLE_WAYLAND=1 /home/guyru/.local/firefox/firefox %u
X-MultipleArgs=false
Icon=firefox-esr
Categories=Network;WebBrowser;
Terminal=false
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;

You will need to restart Firefox before the fix will take affect.

TP-Link Archer T4Uv2 support for Debian Buster

This post outlines how I backported rtl8812au-dkms from Ubuntu Focal for Debian Buster and added support for the TP-Link Archer T4U v2 card to it. If you are only interested in the resulting .deb file skip to the end.

The TP-Link Archer T4U v2 is an AC1300 WiFi USB adapter. TP-Link provides drivers but they are built only for old kernel versions (<=3.19) and do not supoort DKMS, which makes upgrading a hassle.

Ubuntu provides the rtl8812au-dkms package which support the chipset in the Archer T4Uv2, but it doesn’t recognize the TP-Link product. So I set out to backport it to Debian Buster and make it support the Archer T4Uv2.

We start by fetching the rtl8812au source package from Ubuntu.

$ dget --allow-unauthenticated http://archive.ubuntu.com/ubuntu/pool/universe/r/rtl8812au/rtl8812au_4.3.8.12175.20140902+dfsg-0ubuntu12.dsc
$ cd rtl8812au-4.3.8.12175.20140902+dfsg/
$ sed -i s/dh-modaliases// debian/control
$ sed -i s/,modaliases// debian/rules
$ mk-build-deps ./debian/control --install --root-cmd sudo --remove

The sed lines remove reference to the dh-modaliases build dependency which Debian doesn’t have. I’m not really sure why they needed it for this package, but removing it didn’t hurt.

Next we add a new patch using quilt to support the Archer T4Uv2. We extract the 2357:010d USB vid:pid pair of the adapter using lsusb.

$ quilt push -a
$ quilt new add_archer_t4uv2.patch
$ quilt add os_dep/linux/usb_intf.c
$ vim os_dep/linux/usb_intf.c

The change we’ll be making to os_dep/linux/usb_intf.c is outlined by the following patch:

--- rtl8812au-4.3.8.12175.20140902+dfsg.orig/os_dep/linux/usb_intf.c
+++ rtl8812au-4.3.8.12175.20140902+dfsg/os_dep/linux/usb_intf.c
@@ -303,6 +303,7 @@ static struct usb_device_id rtw_usb_id_t
 	{USB_DEVICE(0x20f4, 0x805b),.driver_info = RTL8812}, /* TRENDnet - */
 	{USB_DEVICE(0x2357, 0x0101),.driver_info = RTL8812}, /* TP-Link - Archer T4U */
 	{USB_DEVICE(0x2357, 0x0103),.driver_info = RTL8812}, /* TP-Link - Archer T4UH */
+	{USB_DEVICE(0x2357, 0x010d),.driver_info = RTL8812}, /* TP-Link - Archer T4Uv2 */
 	{USB_DEVICE(0x0411, 0x025d),.driver_info = RTL8812}, /* Buffalo - WI-U3-866D */
 #endif

Finish up adding the patch:

$ quilt header --dep3 -e
$ quilt refresh
$ quilt pop -a

And build the package:

$ DEBEMAIL="Guy Rutenberg <guyrutenberg@gmail.com>" debchange --bpo
$ debuild -us -uc

Now we can install the newly created deb package:

$ cd ../
$ sudo apt install ./rtl8812au-dkms_4.3.8.12175.20140902+dfsg-0ubuntu12~bpo10+1_all.deb

If you came here only for the actual binary package you can find it in my deb repository: https://guyrutenberg.com/debian/buster/

Install JetBrains Mono in Debian/Ubuntu

JetBrains Mono is a new monospace typeface designed to be comfortable to read. It has clear distinction between the different letters and relatively high x-height.

The installation instruction were tested on Debian, but should work on every Linux.

Download and unzip the font:

$ wget https://download.jetbrains.com/fonts/JetBrainsMono-1.0.0.zip
$ unzip JetBrainsMono-1.0.0.zip

Install the font to either the user’s font directory

$ mv JetBrainsMono-*.ttf ~/.local/share/fonts/

or the system-wide one:

$ sudo mv JetBrainsMono-*.ttf /usr/share/fonts/

To use the font in gVim set guifont accordingly in ~/.vimrc:

:set guifont=JetBrains\ Mono\ 13

Compiling lensfun-0.3.95 on Debian Buster

Lensfun provides lens distoration correction for Darktable and other raw processing applications. Version 0.3.95 provides ability to use the Adobe Camera Model, and hence use Adobe lens profiles (lcp files). However, lensfun 0.3.95 is not packaged for Debian Buster. Also Darktable won’t compile against the latest git version of Lensfun, so you must compile and install specifically version 0.3.95 to get ACM support.

We begin by downloading and extracting Lensfun 0.3.95. Lensfun 0.3.95 is not tagged in git, so we have to download the release directly from SourceForge. The release is not available from the GitHub repository.

$ wget https://sourceforge.net/projects/lensfun/files/0.3.95/lensfun-0.3.95.tar.gz
$ tar -xvf lensfun-0.3.95.tar.gz
$ cd lensfun-0.3.95/

Lensfun uses CMake for building and has also has CPack enabled. We can use it to build a deb package and install it. This allows easier integration and uninstallation in the future.

$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=release -DCPACK_BINARY_DEB=ON ../
$ make -j`nproc` && make package
$ sudo apt install ./liblensfun2_0.3.95.0_amd64.deb

libGL error: unable to load driver: radeonsi_dri.so

After playing with installing and removing the amdgpu and amdgpu-pro drivers, my system could not load the radeonsi. glxinfo returned the following error:

$ DRI_PRIME=1 glxinfo | grep OpenGL
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi

It was solved by cleaning up leftover symlinks and reinstalling libgl-mesa-dri

$ sudo find /usr/lib/ -lname "/opt/amdgpu/*" -print -delete
/usr/lib/i386-linux-gnu/dri/kms_swrast_dri.so
/usr/lib/i386-linux-gnu/dri/r600_dri.so
/usr/lib/i386-linux-gnu/dri/r200_dri.so
/usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so
/usr/lib/i386-linux-gnu/dri/swrast_dri.so
/usr/lib/i386-linux-gnu/dri/radeonsi_dri.so
/usr/lib/i386-linux-gnu/dri/r300_dri.so
/usr/lib/x86_64-linux-gnu/dri/kms_swrast_dri.so
/usr/lib/x86_64-linux-gnu/dri/r600_dri.so
/usr/lib/x86_64-linux-gnu/dri/r200_dri.so
/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
/usr/lib/x86_64-linux-gnu/dri/r300_dri.so

$ sudo apt install --reinstall libgl1-mesa-dri