Typing SSH passphrase(s) only once per session

Here’s a very simple way to type SSH passphrases only once. This simple function, to be added in your ~/.bashrc, will make sure that ssh-agent will always be called before ssh, once per session, so you do not have to type your ssh passphrase more than once:

function sshwithauthsock {
 if [ ! -S ~/.ssh/ssh_auth_sock ]; then
   eval `ssh-agent`
   ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock
 export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock
 ssh-add -l > /dev/null || ssh-add

alias ssh='sshwithauthsock ssh'
alias scp='sshwithauthsock scp'

Check for possibly updated version directly in my repository.



Checking Western Digital Green load cycle per hour / Intellipark issues

I got a few Western Digital Green hard disk. I’ve read they have been rebranded blue now. It was supposed to be hard disk with long consumption, possibly lower speed due to low rotation. Low rotation, you would assume: longer-life span, since usually, mechanical devices lives longer when running slower.

But when you do realize that these Green have the shortest warranty possible (2 years against 3 or 5 for others), you wonder.

And then, when you have a hard disk that starts to fails, you learn stuff like these Western Digital Green having a 8 seconds timeout to park the drive (yeah, like in old DOS era, when you where using park before shutting off your computer). I assume it is to save energy but it takes no genious to evaluate the result if your system writes every 10 seconds, which is not un unlikely scenario.

I am not talking theory, I do have a failing Western Digital Green 2Tb (WDC WD20EZRX-22D8PB0) that is just 2 years and a few months.

With different cables and different mainboards, power supply units, etc, it sprouts:

 [ 3996.054577] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 3996.054580] ata7.00: irq_stat 0x40000001
[ 3996.054585] ata7.00: failed command: READ DMA EXT
[ 3996.054595] ata7.00: cmd 25/00:08:00:88:e0/00:00:e8:00:00/e0 tag 17 dma 4096 in
 res 51/04:08:00:88:e0/00:00:e8:00:00/e0 Emask 0x1 (device error)
[ 3996.054598] ata7.00: status: { DRDY ERR }
[ 3996.054600] ata7.00: error: { ABRT }
[ 3996.055191] ata7.00: failed to enable AA (error_mask=0x1)
[ 3996.056015] ata7.00: failed to enable AA (error_mask=0x1)

So what about this wdidle3 timeout and resulting Load_Cycle?

# hdparm -J /dev/sdd
 wdidle3 = 8.0 secs

# smartctl /dev/sdd -a | grep Load_Cycle
193 Load_Cycle_Count 0x0032 116 116 000 Old_age Always - 253474

253474 for recent hard disk? I’ve read the life expectancy is usually between 300000 and 1000000 load cycle count. But as reference, I’ll check my other hard drives on the workstation I put the disk to test:

# DISK="a b c d e"
# TMP=`mktemp` && for disk in $DISK; do smartctl -xa /dev/sd$disk > $TMP ; grep "Device Model" $TMP ; hdparm -J /dev/sd$disk 2>/dev/null| grep wdidle ; grep Power_On_Hours $TMP ; grep Load_Cycle_Count $TMP ; Count=`grep Load_Cycle_Count $TMP | grep -oE '[^ ]+$'` ; Hours=`grep Power_On_Hour $TMP | sed "s/\s[(][^)]*[)]//g" | grep -oE '[^ ]+$'` ; if [ x$Hours != x ]; then echo `echo print $Count/$Hours. | perl` load cycles per hour ; echo ; fi ; done
Device Model: WDC WD5000AZRX-00A8LB0
 wdidle3 = 128 ??
 9 Power_On_Hours -O--CK 075 075 000 - 18587
193 Load_Cycle_Count -O--CK 121 121 000 - 239519
12.8863721956206 load cycles per hour

Device Model: ST2000DX002-2DV164
 wdidle3 = 1 ??
 9 Power_On_Hours -O--CK 094 094 000 - 5385
193 Load_Cycle_Count -O--CK 099 099 000 - 3617
0.671680594243268 load cycles per hour

Device Model: WDC WD20EZRX-22D8PB0
 wdidle3 = 8.0 secs
 9 Power_On_Hours -O--CK 090 090 000 - 7672
193 Load_Cycle_Count -O--CK 116 116 000 - 253490
33.0409280500521 load cycles per hour

Device Model: WDC WD2001FASS-00W2B0
 wdidle3 = 128 ??
 9 Power_On_Hours -O--CK 038 038 000 - 45726
193 Load_Cycle_Count -O--CK 073 073 000 - 382183
8.35811135896427 load cycles per hour

Depends obviously of the purpose of the hard disk. Still, the affected Western Digital Green, with its 33  load cycles per hour stands out, in the wrong sense. At this rate, the first disk would reach 613000 load cycles instead of 239519 by now, likely a goner already.  And the last one would be around 1509000, a goner definitely too!

Then on a  server:

Device Model: ST4000DM005-2DP166
 wdidle3 = 1 ??
 9 Power_On_Hours -O--CK 090 090 000 - 9091 (43 85 0)
193 Load_Cycle_Count -O--CK 100 100 000 - 400
0.0439995600044 load cycles per hour

Device Model: WDC WD40EFRX-68WT0N0
 wdidle3 = 300 secs (or 13.8 secs for older drives)
 9 Power_On_Hours -O--CK 062 062 000 - 28038
193 Load_Cycle_Count -O--CK 200 200 000 - 653
0.0232898209572723 load cycles per hour

We have read too an infamous Western Digital, but not a Green, so the widle3 is much less extreme.

What about on a laptop (Lenovo 20017 IdeaPad Y550 ) ?

Device Model: WDC WD5000BEVT-22ZAT0
 wdidle3 = 8.0 secs
 9 Power_On_Hours -O--CK 041 041 000 - 43353
193 Load_Cycle_Count -O--CK 001 001 000 - 889112
20.508661453648 load cycles per hour

Gasp! But wait, isn’t it a Western Digital Blue – so, Green rebranded?

Questioned about this kind of issue, it seems that Western Digital claims “we’ve not seen the drives fail over high load/unload counts”. It may be right, maybe the problem is something else. But that the only odd thing noticeable to me. And I am apparently not the only one questioning Western Digital statements, if not challenging them.

As you can see, I got a few disk from this brand and must say even the Western Digital knowledge base entry titled “The Load/Unload counter for S.M.A.R.T Attribute 193 continues to increase under some distributions of the Linux Operating system and some Windows applications”  is not what I expect as customer. They do not question their 8 seconds timer, which is questionable – I do not care about their very own opinion about how often a system should or should not write to a disk.  They claim the issue “artificially increases the number of load-unload cycles”. There is nothing artificial, it simply does increase. They say it is no problem because they are “within design margins (drive has been validated to 1 million load/unload cycles without issue)”. But my test shows that it is out of proportions in any case, for no real added benefits.

I have to admit the issue is not new. But if you do not especially pay attention to hard drives in general, why would you be aware of it.

What to make out of this?

First, on the laptop, I’ll disable this widle3:

# apt install idle3-tools 
# idle3ctl -g /dev/sda
Idle3 timer set to 80 (0x50)
# idle3ctl -d /dev/sda

Myself, I think I’ll stay clear of Western Digital all together.





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/System.map-*; 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 systemd-initrd dracut-system"' > /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 https://github.com/goodtft/LCD-show.git

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?