#StackBounty: #hibernate #lock-screen #luks #cryptsetup Lock on "suspend", but do not lock on "suspend to swap" (hi…

Bounty: 50

I enabled "lock on suspend" (sleep). This works fine, however this will also trigger when I hibernate the laptop. When I resume from hibernation, I have to enter two passwords: On the cryptsetup screen to unlock the drive and on the login screen.

Is there a way to not lock on hibernate (systemctl hibernate), but still lock on sleep?

I am on Ubuntu 20.04 (but I am flexible and will switch to any version, if that solves this problem).

Get this bounty!!!

#StackBounty: #arch-linux #grub2 #manjaro #luks #ssd How should I enable discard and no workqueue for LUKS in Arch/Manjaro

Bounty: 200

So I’ve read the wiki and this answer, and I’m still a bit overwhelmed. In the wiki it feels like a lot of these are optional.

Here’s what I did. I used Manjaro to install into a single partition, which I may be regretting, and I enabled full disk encryption. What I observe when booting, to either windows or Linux, is I’m prompted for a password, and then I see the actual grub menu.

I’m not then certain which options will work. I think that LVM is enabled, but not 100% and I’m sure I selected ext4. I looked at modifying the grub.conf generation scripts, but I’m not sure where, nor am I sure if that’s the right place.

What’s the right answer for adding discard, no_read_workqueue, and no_write_workqueue on Manjaro?


here’s what my most current configuration is, but I keep getting dropped into a rescue shell. I’m trying to used the systemd cryptsetup to do all the things, which seems to suggest that I use luks.* parameters.

note: the name root is coming from my manual mounting in the rescue shell.

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS                                MOUNTPOINT                                 UUID
loop0         7:0    0 450.2M  1 loop  /var/lib/snapd/snap/wickrme/543            /var/lib/snapd/snap/wickrme/543            
loop1         7:1    0  55.4M  1 loop  /var/lib/snapd/snap/core18/2074            /var/lib/snapd/snap/core18/2074            
loop2         7:2    0  65.1M  1 loop  /var/lib/snapd/snap/gtk-common-themes/1515 /var/lib/snapd/snap/gtk-common-themes/1515 
loop3         7:3    0  32.3M  1 loop  /var/lib/snapd/snap/snapd/12398            /var/lib/snapd/snap/snapd/12398            
zram0       253:0    0   1.5G  0 disk  [SWAP]                                     [SWAP]                                     
nvme0n1     259:0    0 953.9G  0 disk                                                                                        
├─nvme0n1p1 259:1    0   100M  0 part  /boot/efi                                  /boot/efi                                  6CEB-F417
├─nvme0n1p2 259:2    0    16M  0 part                                                                                        
├─nvme0n1p3 259:3    0 780.6G  0 part                                                                                        
├─nvme0n1p4 259:4    0   508M  0 part                                                                                        CA343C30343C223D
├─nvme0n1p5 259:5    0 146.5G  0 part                                                                                        74c51543-eb14-4f61-afeb-b5de6c10a32a
│ └─root    254:0    0 146.5G  0 crypt /                                          /                                          e0a93c98-88a8-4fc9-9948-acdb423d05fd
└─nvme0n1p6 259:6    0  18.6G  0 part  [SWAP]                                     [SWAP]                                     72db96da-87e4-4b17-a622-6a4d56b314c6
4 ❯ cryptsetup luksDump /dev/nvme0n1p5                                                                                                                                                                         # ~
LUKS header information for /dev/nvme0n1p5

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
UUID:           74c51543-eb14-4f61-afeb-b5de6c10a32a
❯ cat /etc/default/grub | grep -v -e '^[[:space:]]*$' -e '^#'                                                                                                                                                  # ~
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.uuid=74c51543-eb14-4f61-afeb-b5de6c10a32a luks.options=discard,no_read_workqueue,no_write_workqueue root=/dev/mapper/luks-e0a93c98-88a8-4fc9-9948-acdb423d05fd splash apparmor=1 security=apparmor udev.log_priority=3"
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

from what I understand systemd-cryptsetup-generator shouldn’t need more options, I do have an /etc/crypttab but everything is commented out.

I’m fairly confident that GRUB_CMDLINE_LINUX_DEFAULT is my only problem, I’m not certain what it should be though. google isn’t finding me a lot of (read no) examples of how to do this with the output of blkid or lsblk.

Get this bounty!!!

#StackBounty: #encryption #luks #20.10 Ubuntu 20.10 – move LUKS header to external device

Bounty: 100

I recently installed Ubuntu 20.10 to test the ZFS file system together with encryption. I discovered the system not only use the native ZFS encryption, but also encrypts the ZFS keys with LUKS (please correct me if I’m wrong).

What I’m trying to achieve is to decrypt the LUKS container with a key file and password at boot. If both are not present, it should not be possible to decrypt the container. Also I would like to keep the key file on external device. While LUKS currently doesn’t provide such a functionality, I found that moving the LUKS header to an external device is the closest solution to my problem. However, after 2 days of fighting, I still can’t figure out what’s wrong.

I was following the steps from this answer.

Steps I took after fresh Ubuntu 20.10 installation:

  1. Copying the existing LUKS header into USB drive

sudo cryptsetup luksHeaderBackup /dev/zd0 --header-backup-file=/dev/sdb

  1. Removing existing LUKS header from /dev/zd0

sudo cryptsetup erase /dev/zd0

  1. Adding the following entry to /etc/crypttab

keystore-rpool /dev/zd0 none luks,header=/dev/sdb

  1. Applying changes

sudo update-initramfs -u -k all

After all this, typing the right password for keystore-rpool at boot always fails to decrypt the volume. By typing few times the password I’m redirected to initramfs where I can mount manually the volume with commands

sudo cryptsetup open /dev/zd0 keystore-rpool –header=/dev/sdb
sudo mount /dev/mapper/keystore-rpool <somemountpoint>

I assume something may be wrong with the entry in /etc/crypttab, but I don’t know how to check it. Also I was grepping the whole system to find out the place, where system is opening the LUKS volume and mapping to /dev/mapper/keystore-rpool, to see exactly how the command looks, but couldn’t find anything. Where is it happening? Any hints how to solve this problem would be useful.

Get this bounty!!!

#StackBounty: #linux #fedora #hibernate #btrfs #luks btrfs, LUKS, swapfile: How to hibernate on swapfile?

Bounty: 50

I’m using btrfs encrypted by LUKS on fedora 32 silverblue, kernel version 5.7.7 with anaconda installer default setting.

Because fedora installer automatic partition does not add swap partition or file (or I’ve done wrong), I added swapfile on myself for hibernation like this:

$ # swapfile under /var directory because the location is the only part user can modify on fedora silverblue
$ touch /var/swapfile
$ chattr +C /var/swapfile 
$ fallocate --length 10GiB /var/swapfile
$ sudo chown root /var/swapfile 
$ sudo chmod 600 /var/swapfile 
$ sudo mkswap /var/swapfile 
$ sudo swapon /var/swapfile

and I added swapfile_t attr for selinux:

$ ls -Z /var/swapfile
unconfined_u:object_r:swapfile_t:s0 /var/swapfile

Then I followed arch wiki instruction(https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Hibernation_into_swap_file_on_Btrfs).

my /var/swapfile‘s physical offset is 19793240064 and page size is 4096, so I added kernel param with grub. here’s part of my /etc/default/grub kernel params now:

GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-572bfd87-6fa7-4be1-8c73-4759ac9af3cd rhgb quiet resume=UUID=572bfd87-6fa7-4be1-8c73-4759ac9af3cd resume_offset=4832334"

here’s my blkid:

$ sudo blkid
/dev/nvme0n1p1: UUID="5490-E733" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="46ecd0d1-6722-4b92-af73-9574a58eb332"
/dev/nvme0n1p2: UUID="c9294f4d-9c92-4c08-a037-715223443f2b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="731852d5-26cd-43bb-8904-c4256247f97d"
/dev/nvme0n1p3: UUID="572bfd87-6fa7-4be1-8c73-4759ac9af3cd" TYPE="crypto_LUKS" PARTUUID="e74de89a-fe5f-402f-a3bf-e398ad069b5b"
/dev/sda: BLOCK_SIZE="512" UUID="C602B4D602B4CD25" TYPE="ntfs"
/dev/mapper/luks-572bfd87-6fa7-4be1-8c73-4759ac9af3cd: LABEL="fedora_fedora" UUID="337b2fcb-a61b-4976-89ac-2b3feee02963" UUID_SUB="932cfe1c-9713-4063-bda0-a8a792654c39" BLOCK_SIZE="4096" TYPE="btrfs"

and hibernation failed. it seems resume parameter problem. I tried UUID=572bfd87-6fa7-4be1-8c73-4759ac9af3cd and UUID=337b2fcb-a61b-4976-89ac-2b3feee02963 and both failed. What were wrong? How can I setup swapfile hibernate properly?

I’ve checked journalctl -u systemd-logind and found the message but that didn’t help:

 localhost.localdomain systemd-logind[936]: Failed to open swap file /var/swapfile to determine on-disk offset: Permission denied

Get this bounty!!!

#StackBounty: #boot #grub #luks Booting LUKS Linux installation from external USB disk

Bounty: 100

Before: SATA internal SSD with a LUKS encrypted ext4 partition (Debian installation) + a small unencrypted boot partition with kernel, initrd and GRUB configuration files

After: that same disk is now externally attached with a USB-to-SATA adapter

Now GRUB fails to boot it, but both GRUB and the Debian kernel recognize the disk (I see the correct size and partitions). Also after loading the kernel it asks for the LUKS password, and it recognizes it (if entered correctly)
I’ve tried providing the kernel and initrd files from the GRUB command line, and also loading the old grub.cfg file with the GRUB ‘configfile’ command.

This was the GRUB section that worked with the former setup:

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8b6b854f-d92a-439d-a0e3-315d39bb0802' {
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_msdos
    insmod ext2
    set root='hd0,msdos3'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  a597f222-87d2-4e19-8965-aa0eff0bceea
      search --no-floppy --fs-uuid --set=root a597f222-87d2-4e19-8965-aa0eff0bceea
    echo    'Loading Linux 4.9.0-11-amd64 ...'
    linux   /vmlinuz-4.9.0-11-amd64 root=UUID=8b6b854f-d92a-439d-a0e3-315d39bb0802 ro  quiet
    echo    'Loading initial ramdisk ...'
    initrd  /initrd.img-4.9.0-11-amd64   

And this are the various error screens (I can’t remember what screen corresponds to what I was trying)

enter image description here

enter image description here

enter image description here

Is it even possible to boot the Debian install with this new setup?

Get this bounty!!!

#StackBounty: #boot #luks #touch-screen #plymouth #tablet-computer Linux Tablet: Is there a way to enter a password with onscreen keybo…

Bounty: 50

I just installed Linux (Ubuntu, but it does not really matter) on an x86-based tablet. I also encrypted a partition which is mounted during bootup. Of course, one usually needs to enter the password to unlock the partition during bootup.

Is there a way to unlock (cryptsetup luksOpen) the partition with onscreen keyboard (touchscreen only, no physical keyboard present!) before the first user logs in?

The onscreen keyboard (Onboard) works very well during login (in gdm or other display manager) and later on.

I do realise X has not started at the normal time /etc/init.d/boot.crypto (or newer systemd) interactively requests passwords according to /etc/crypttab, so the question could mean, is there a way to defer unlocking until X has started (but before a user logs in).

PS: The process usually showing the password prompt is plymouth which asks for a password using https://wiki.ubuntu.com/Plymouth#A.22plymouth_ask-for-password.22. It does use a graphical display mode but I think not X?! A lightdm integration would be the other alternative (with onscreen keyboard readily available).

Get this bounty!!!

#StackBounty: #scripting #luks script to automate luksHeaderBackup for multiple partitions

Bounty: 50

I have several servers each with at least six dm-crypt partitions. I would like to have an automated way to make sure I always have a luks header backup stored in a safe place. I’ve been making header backups manually until now. My problem with that is that I tend to forget to make a new luks header backup when I have to swap out a hard drive or make other system changes.

I’m looking for an existing script that will check to see if a luks header backup exists, and if not, create one. I have to assume somebody has written such a script already. (The need for it seems obvious.)

If one does not exist, I’ll attempt to make a bash script for the purpose.

My manual commands look like this:

cryptsetup luksHeaderBackup /dev/sdXN --header-backup-file /path/to/backup/$mountpoint_luksHeader_$devUUID.img

I would like to have both the mountpoint and the device UUID in the file name of the header image file.

The only clue I have about getting started is that I would need to iterate through all devices and find the partitions of type crypt, then find the corresponding mount point and UUID. I know most of that info exists in lsblk and blkid. I’m not sure how to extract it for use in a script.

Get this bounty!!!

#StackBounty: #arch-linux #luks #disk-encryption #whole-drive-encryption Migrate Arch from encrypt to sd-encrypt

Bounty: 50

I recently installed Antergos (which is basically Arch) and set it to use full disk encryption. Now, I want to migrate from encrypt to sd-encrypt because I want to be able to hibernate and I couldn’t put swap partition in the same LUKS volume..


During the setup:

  • I used LUKS for / partition and swap partition,
  • because my main SSD is small, I wanted to be able to hibernate and I have 32GB of RAM I created the encrypted swap partition on the second drive,
  • I mounted swap partition (as well as another encrypted EXT4 partition from the second drive) using /etc/crypttab.

I tested that installation works, grub let me boot into both linux and dual booted Windows, on Linux boot it decrypts and mounts both encrypted drives.

However, I was getting error about not finding disk with the UUID of a swap drive, and Arch manual confirmed that encrypt which I got from installer can handle only one encrypted partition during boot. If I want to handle more of them I should move to sd-encrypt. However, even after reading the documentation I am not certain what I have to do in order to migrate to sd-encrypt.


  • HOOKS="base udev autodetect modconf block keyboard keymap encrypt resume filesystems fsck"
  • GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=[encrypted swap UUID]"
  • GRUB_CMDLINE_LINUX=cryptdevice=/dev/disk/by-uuid/[/ UUID]:Arch_crypt
  • /etc/crypttab
      swap_crypt /dev/disk/by-uuid/[/ UUID] password_file luks
      data_crypt /dev/disk/by-uuid/[/ UUID] password_file luks

What else should I do after I change encrypt to sd-encrypt in HOOKS? Do I have to create a /etc/crypttab.initramfs and move swap_crypt there? Do I have to change luks to rd.luks? Both swap partition and / partition uses the same password, so according to the documentation both should be mounted on boot after I entered the password once, is that right? Documentation mentions luks.* and rd.luks.* params and similar – do I have to use them and if so, where should I put them?

Get this bounty!!!

#StackBounty: #encryption #luks How do I troubleshoot a disk IO performance issue possibly related to dm-crypt/LUKS?

Bounty: 50


I recently installed Ubuntu 16.04 LTS (kernel 4.8.0-52) on a Lenovo T460p with an i7-6820HQ, 32GB of RAM, and a 512GB Micron 1100 SSD. I checked the full disk encryption box during the installation and used the default partitioning layout. In general, performance is great.

However, over time my builds started running taking about twice as long. Further, during parts of the build that write large files any (non-build) task that requires disk I/O ends up waiting a lot. This includes launching new programs, loading pages in Firefox, etc. In Firefox, for example, I can navigate the UI, switch tabs and everything is fine. But if I follow a link the whole UI locks up until things quiet down.

So in summary, after some period of time, builds suddenly take longer and at certain points during the build the computer is basically unusable.

What can I do to try and diagnose or resolve this issue?

Troubleshooting Info

  • Don’t reboot often so the system is often up for several days before I run into this issue. Once I hit it, I flail for a bit trying to figure out the issue, then reboot so I can keep working.

  • The only thing that resolves the issue is rebooting the machine. I’ve tried exiting all applications, logging out and back in, and dropping the buffer cache (flail theory that as it used memory space disk syncs were happening more frequently) but only rebooting works.

  • As a long shot, I tried the solution to this answer but there was no change in behavior.

  • Running iotop shows the dmcrypt_write thread using 99% I/O whenever I’m experiencing the issues. When I’m not experiencing the issue, I also see dmcrypt_write pop to the top with a relatively high IO % but it doesn’t stay there very long.

  • If I run dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; sync when things are working normally, dmcrypt_write will jump to the top for a second or two but it’s no where near the same duration as during one of my builds.

  • A full build generates about 1.4 GB of data. It’s a Java project with several modules. So, lots of little files are created plus some larger JAR files that aggregate all those little files.

  • There is always plenty of memory available and the swap partition is not being used.

  • I have coworkers with similar computers (T460p) also running Ubuntu that are not experiencing this issue. They they all seem to have different SSD brand/models, though.


The issue just surfaced again so I did some more testing based on the reply to this question.

  • The file system is still not mounted with the discard option so I instead ran fstrim assuming that would be somewhat similar to having had the discard option enabled
  • I didn’t do enough timing when the issue first happened, but after running fstrim, build speeds seemed to be back to normal… but after the build completes, the dmcrypt_write thread kicks in and makes the system unusable for a period of time. All and all the total time to build and for the system to become usable seems to be about the same as before.
  • I changed /proc/sys/vm/dirty_ratio to 2 and /proc/sys/vm/dirty_background_ratio to 1 and ran some builds. The builds took longer than normal—about the same as the last time I hit this issue, but the system didn’t seem to lock up as much. Changing it back to 20 and 10 reverted to the behavior mentioned above.
  • On a clean boot, I tried setting /proc/sys/vm/dirty_ratio to 2 and /proc/sys/vm/dirty_background_ratio to 1 and the time was comparable with it at 20 and 10.

Get this bounty!!!