Ah, my mistake. I didn’t realize nofail would cause it to immediately fail if the drive wasn’t found. I was thinking it would default to hanging for 90s like filesystems.
1 Like
I think I crafted a good systemd unit which does not suffer from extra boot time when the μSD is not inserted. Instead of waiting for /dev/mapper/crypt_sd to exist, I take advantage of the fact that /etc/crypttab entries are turned into systemd units at boot, called systemd-cryptsetup@.service
In /etc/systemd/system/usd.service
[Unit]
Description=mount decrypted home if μSD exists
Before=user.slice
Requires=systemd-cryptsetup@crypt_sd.service
After=systemd-cryptsetup@crypt_sd.service[Service]
Type=oneshot
ExecStart=/usr/bin/mount /dev/mapper/crypt_sd /home
ExecStop=/usr/bin/umount /home[Install]
WantedBy=local-fs-pre.target
EDIT: For completion, the above works with a /etc/crypttab and μSD formated like so
sudo mkdir /etc/luks-keys
sudo dd if=/dev/urandom of=/etc/luks-keys/disk_secret_key bs=512 count=8
sudo cryptsetup luksFormat /dev/sda
sudo cryptsetup luksAddKey /dev/sda /etc/luks-keys/disk_secret_key
echo crypt_sd UUID=$(sudo cryptsetup luksUUID /dev/sda) /etc/luks-keys/disk_secret_key nofail,luks | sudo tee -a /etc/crypttab
# the above line appends to /etc/crypttab. Remove the previous added line before rerunning
sudo cryptsetup open /dev/sda crypt_sd /etc/luks-keys/disk_secret_key
sudo mkfs.ext4 /dev/mapper/crypt_sd
sudo mount /dev/mapper/crypt_sd /mnt
sudo cp -a /home/purism /mnt/
WARNING: above script has not been tested. cryptsetup luksFormat and luksAddKey will prompt for encryption passphrase, so it pasting the above in a terminal at once won’t work
1 Like
This doesn’t work for me and I’m unclear how it is working for you, although great that it is.
The stumbling block for me is…
…this causes the systemd-cryptsetup@ service to start even when there is no card present, under the hood it looks to be that the systemd-cryptseup service BindsTo the <LUKS-UUID> device so it will wait some time for the device to show up before eventually giving up and failing, at which point the your unit will fail (which is the desired result). The issue is that I am seeing the boot process extended by the wait some time period which is around 90 seconds or so.
However, it did prod me to look a little deeper into it and I can see that the systemd-cryptsetup@service does start quite early on in the process so changing the Requires to Requisite would be enough to get this working as you intended at my end.
But, for me, ideally I would prefer to have the service bound to the underlying block device (in this case dev-mapper-crypt_sd.device) which as far as I can tell at the moment would require at least a timeout also be defined to avoid the long wait period. I’d also want the unit to Conflicts with umount.target to do as much to ensure it’s unmounted cleanly at shutdown.
I’ve been running the home directory on a card for some time now, the phone is not my daily device and is seldom used but still I have seen the mount error on a few occasions so would recommend also adding error options to the mount.
1 Like