Booting two Devuan GNU/Linux installed on encrypted partitions on a single disk

Followup of previous article (Single passphrase to boot Devuan GNU/Linux with multiple encrypted partitions), I found out that if you have two clone system, both on encrypted partitions, on the same hard disk, grub/os-prober as of today fails to automatically configure boot for the clone.

It the concept of having such clone system odd? Not really if you think of laptop that you use for two completely unrelated activities (work and out of the work?), that you do not want to mix at all.

I spent quite a time trying to understand why the clone system was ignored by os-prober and all, even though the partition it was on was mounted.

In the end, I decided it was easier to actually clone the config built for the running system, adjusting the UUID of partitions than to look further.

Here is my /etc/grub.d/11_linux_cryptoclone wrapper for /etc/grub.d/10_linux:

#! /bin/bash
set -e

# require GRUB_LINUX_CLONE_MAPPER_NAME to be set
# for instance to XY if the relevant fs is /dev/mapper/XY
# along with relevant grub parameters
#GRUB_PRELOAD_MODULES="luks cryptodisk lvm"

. /etc/default/grub
[ x"$GRUB_LINUX_CLONE_MAPPER_NAME" == x ] && exit

# setup
CLONE=$GRUB_LINUX_CLONE_MAPPER_NAME # only necessary to edit
CLONEUUID=`blkid /dev/mapper/$CLONE -o value -s UUID`
CLONENAME="Devuan GNU/Linux (on $CLONE)"
CLONECRYPTOUUID=`grep $CLONE /etc/crypttab | awk '{print $2}' | cut -f 2 -d =`

ORIG=`df / --output=source | tail -1 | tr -d /dev/mapper`
ORIGUUID=`blkid /dev/mapper/$ORIG -o value -s UUID`
ORIGNAME="Devuan GNU/Linux"
ORIGCRYPTOUUID=`grep $ORIG /etc/crypttab | awk '{print $2}' | cut -f 2 -d =`

# produce arranged conffile
>&2 echo "$ORIG -> $CLONE:"
>&2 echo " $ORIGUUID -> $CLONEUUID"

# make sure there is proper kernel and initrd installed
CLONEDIR=`grep /dev/mapper/$CLONE /etc/mtab | awk '{print $2}'`
if [ "x$CLONEDIR" == "x" ]; then
 mount /dev/mapper/$CLONE
 CLONEDIR=`grep /dev/mapper/$CLONE /etc/mtab | awk '{print $2}'`
for file in /boot/config-* /boot/init* /boot/vmlinuz-* /boot/*; do
 [ ! -e "$CLONEDIR/$file" ] && >&2 echo " $CLONE $file missing!"
>&2 echo " (remember $CLONE needs properly built initramfs)" 
if [ $MCLONE == 1 ]; then umount /dev/mapper/$CLONE ; fi


As said it requires you to add GRUB_LINUX_CLONE_MAPPER_NAME=XY in /etc/default/grub, XY  being the /dev/mapper/XY of the clone system.

It expect the clone system to be similarly set up: it needs to have proper initramfs for the same kernel.

It also expect this clone system to be accessible and set in /etc/crypttab et /etc/fstab, since it needs to be able to find clone UUIDs which should not come as a surprise because if it would have to be if os-prober was to find it anyway.

Once done, you can simply run


Single passphrase to boot Devuan GNU/Linux with multiple encrypted partitions

These days, considering the amount of data are stored on an average computer and how easy is it to get access to it once you get physical access, running such computer without any form of encryption seem unsound. Especially since it is reasonably easy to set up a en encrypted system and does not seems to imply much overhead.

When you have an old setup you are fine with, using numerous partitions or systems, it can be inconvenient, though. For instance  if you have to type a long specific passphrase 5 times when booting your computer.

There are a few things I found useful to make my life easier. Obviously, any shortcut security wise means less security. It is help to you to decide whether the risk is worth it or not depending on what kind of data you carry, what kind of attackers you expect, etc. This is part 1.

Single passphrase to boot GNU/Linux with multiple encrypted partitions

One obviously approach to type a single passphrase to boot a system is to have the boot loader files on a regular partition and the rest on a single encrypted partition. In GNU/Linux case, you would have /boot on a specific non-encrypted partition. Fact is anyone with access to your computer can easily replace your kernel or initramfs with a malicious one and you would not notice.

So I think non-encrypted /boot is as much of the table as would be a non-encrypted swap partition.

So for the boot manager grub to load, /boot need to be readable: the passphrase will be required here. The idea is that from this moment on, a keyfile will be used instead of passphrase to load any other partition.

I guess there is not much point to describe in detail the crypt setup itself (I followed the many guides out there). For each partition you want:

# 1. you create the partition with parted/fdisk

# 2. you format it as encrypted
cryptsetup luksFormat /dev/sdX1

# 2b. you record it in crypttab
# <target name> <source device> <key file> <options>
echo "Name1 UUID=`blkid -s UUID -o value /dev/sdX1` /boot/k/ka luks,tries=3" >> /etc/crypttab

# 3. you open the encrypt-formatted partition
cryptsetup luksOpen /dev/sdX1 Name1

# 4. you format the resulting /dev/mapper... to a regular filesystem
mkfs.ext4 /dev/mapper/Name1 -L Name1

# 4b. you record it in fstab (adjusting the mount point!)
# <file system> <mount point> <type> <options> <dump> <pass> 
echo "/dev/mapper/Name1 / ext4 errors=remount-ro 0 1" >> /etc/fstab

# you are set, you can mount the partition, 
#  and install the system/copy the system there

The swap  require specific treatment. Provided you know one with partition is the current  unencrypted swap is (here sdX?), this is enough:

# update crypttab
echo "SW `find -L /dev/disk -samefile /dev/sdX? | grep by-id | tail -1` /dev/urandom swap" >> /etc/crypttab

# update fstab
echo "/dev/mapper/SW  none   swap sw 0 0" >> /etc/fstab

Noticed the /boot/k/ka? That’s the unlocking key. You can use whatever other filename, just be consistent.

# generate some
dd if=/dev/urandom of=/boot/k/ka bs=1024 count=4
chmod 400 /boot/k/ka

# and obviously, add it to any luks formatted partition:
for part in `blkid | grep crypto_LUKS | awk {'print $1 '} | tr -d :$`; do cryptsetup -v luksAddKey $part /boot/k/ka; done

Then, you need a proper initramfs:

# dracut works almost out of the box
apt install dracut

# set up a few things
echo 'omit_dracutmodules+="systemd"' > /etc/dracut.conf.d/00-systemd.conf
echo 'add_dracutmodules+="crypt lvm"
install_items+="/sbin/e2fsck /sbin/cryptsetup /boot/k/ka" > /etc/dracut.conf.d/99-luks.conf

# (re)build ramfs
dracut --force

# make sure there are no old initrd leftovers, that would confuse grub
rm /boot/initrd* -f


Then, you need to edit grub (version 2!) config:

# first obtain the UUID of crypted partition (not the /dev/mapper/... one) 
# that hold the /boot partition. 
# (it was Name1 earlier but obviously it depends to the real name you gave)
grep Name1 /etc/crypttab

# now edit /etc/default, with XXXXXXXXXXXX being the UUID value
# you just found.
GRUB_PRELOAD_MODULES="luks cryptodisk lvm"

# and now update-grub (install grub if not done yet)

It took me a while to find the proper rd.luks.key value, no docs I read were clear about it. Many give the impression that putting rd.luks.key=/keyfile or rd.luks.key=/keyfile:/ would be enough since the key is actually on the same partition as grub.cfg. But no.

That is all. Rebooting now, you should be asked for the passphrase before getting the grub menu. And then boot process should be uninterrupted.

Build a simple mobile music player with mpd and a Raspberry Pi B+

Turned out that my kitchen device was not satisfying. Not for the reasons suggested in comments, not because I wanted to use cheezy OS like the ones actually supported for most tablets (last time I checked, you cannot get a decent libre OS with full hardware support) for instance. But  the Raspberry Pi B+ is just not powerful enough to browse Internet of these days with such a resolution. It is just too slow.

On another hand, for years, I had issues with a declining portable music player I have plugged into the car audio system (that have RCA connectors or otherwise only specific mp3 files support). Either it got stuck on some files, or it had problems to recharge. And even working best as it could, the random mode seemed to have a few songs in favor.

So, for less than 30 €, I ordered a tactile 3,5″ screen from Quimat. It work fines with Raspbian, provided you use their specific script that you can obtain via (otherwise the screen would  remain white):

git clone

The box isn’t perfect, on one side the screen won’t be properly supported. But I do not intend to put my paws so much on it so let’s say it is acceptable for such price.

Then, to get some acceptable music player system, I went for a mpc/mpd solution, not wanting to bother with Kodi or any complicated solution that might not work or require a dedicated system other  than raspbian.

So I ended up with mpd along with awesomewm and a few wrapper scripts for mpc just build playlist or send OSD notifications.


(since the screen I improved the icon set, removed the visible cursor)

I use cava to provide a visualizer. Access to the device is made through anonymous Samba. My -utils-mpc package carries such setup mostly based on mpc-monitor (check currently played, could be used to made stats or scrobbling later), mpc+notify (run mpc command with sendnotify call),  mpc-playlist-build, mpc-playlist-next and few sample conffiles (awesome/rc.lua, smb.conf, redshift.conf + extra details in the README about input calibration, mpd.conf).

This Raspbian was purged of systemd, because I do want unexpected troubles, and of pulseaudio, because it causes mpd sometimes to stall and works perfectly without.

All files at stored in the main mpd music directory. Any file within a subdirectory will be treated as belonging to a specific playlist.

Plugging the USB energy input on the car relevant plug generates some odd noise: it has to be plugged to an energy bank. It seems to draw very little power.

Last step was to fill the 32GB USB key serving as storage for the music directory. Turns it was quite boring to hand pick such amount of files. So I used another quite crude script to fill it, taking randomly two thirds of available files for a given directory (a band name):


if [ ! -d "$PWD/$1" ]; then echo "$PWD/$1" not found && exit; fi

LIST=`find "$1" | grep -v .JPG$ | grep -v .jpg$ | grep -v .png$ | shuf`

for file in $LIST; do
 [ -d "$file" ] && continue ;

echo $COUNT
THIRD=$(($COUNT / 3))
echo a third is... $COUNT
# div by 3 and and skip this count

if [ "$2" ]; then COUNT=$2; fi

echo but... $COUNT

for file in $LIST; do
 if [ "$COUNT" -lt 0 ]; then exit ; fi
 [ -d "$file" ] && continue ;
 #echo $COUNT $file
 COUNT=$(($COUNT - 1))
 cp -v "$file" $DEST/`basename "$file"`

Quite crude indeed. mpc-monitor could be used to make stats to, in the end, remove unwanted out. But for now it should properly replace dying mp3/ogg player that you have no control over beside the power-off and play button.

Sure, maybe there are cool mp3/ogg/whatever players out there that could come for cheaper. Not really the point, I enjoy having full control over this one, even if I am not using more than 0,001% of this power. And, BTW, I intend, for another pre-electronics vehicule, to get a proper setup with music player and GPS so any experience in this regard is worth it.





The wild idea of mining cryptocurrency with your electrical car

Cryptocurrencies are as trendy as electrical cars. It should not come as a surprise that people now think about the possibility to use the car to mine cryptocurrency. It is mostly about abusing the electricity plan (for instance free plugs in Paris could do), but what is quite funny (or sad, depending) is that now, we’re getting some self-righteous anti-diesel anti-piston engine crowd considering to contribute to one of the worth energetical waste of the period. More or less in 2017 the consumption of a country like Slovakia, just burned, not producing anything but unneccessary heat, just to make a logical proof that some transactions are legit.

So, yeah, cryptocurrencies are fun in principle. Yeah, surely we should expand electrical engine territory. Still, the idea that both could be promoted by the same crowd is kind of a joke. Can you be a so-called hard core environmentalist when you burn energy just because?


Getting nginx’s wildcard-based server names to pass Exim HELO syntax checks

Many PHP-based apps, like webmails, when using SMTP functions, depends on nginx server_name value to set up the HELO sent.

But if your server_name value is wildcard-based, you’ll get “syntactically invalid argument(s)” from the SMTP server. Example with ownCloud.

Assuming that the SMTP running on the same host as your webmail is not accepting mail but from the webmail itself, you can easily work around this. You can addd


in, for example, /etc/exim4/conf.d/main/00_webmail, if your server name is something like ~^mx.


Checking mails/addressbook/calendars with IMAPS (Dovecot) + DAV (ownCloud)

As a followup to my article Replicating IMAPs (dovecot) mails folders and sharing (through ownCloud) contacts (kmail, roundcube, etc),  I’d like to point out that, these days, I almost completely dropped Kmail (only use it on a laptop, mostly because I do not use the laptop frequently enough to bother) and switched to Thunderbird.

Using Thunderbird enables me to use cool Firefox modules like S3.Google Translator (note that Kmail also has a similar functionality) and works decently with modules Lightning and Inverse Sogo Connector for proper CardDav and CalDav handling. I went away from Kmail due to still existing akonadi issues after so many years and the fact I was still forced to run ‘qdbus org.kde.kded /modules/networkstatus setNetworkStatus ntrack 4’ after suspend for it to notice network is on. In general, I do not think KDE people are going in a direction that makes sense for me and Kmail was almost the last piece of KDE I was still using (since they more or less killed Konqueror themselves). I still enjoy Dolphin though, especially for the group results and filter bar.

Regarding Roundcube, CardDav is nicely handled by RCMCardDav even though it requires a bit a work to properly deal with dependencies.