[SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

uther · 2020-10-26 22:01:43

I have FDE made with guided partitioning during install and after upgrading kernel to 5.8.0 I can't open it anymore. I'm getting standard response as if I made a typo. However I can open the crypt with older kernels like 4.19.x.

The issue is present on two different hardware configs. I'm using vanilla Beowulf installs and the 5.8.0 kernel is installed from backports.
This wasn't happening on 5.7.x IIRC.

stevendemetrius · 2020-10-30 02:42:29

Please clarify and provide more details on what is happening. What is FDE? What exactly can't you open anymore? When is this happening, what is being displayed, what are you typing, and what is the response shown? Is the problem happening during boot, at what stage, or after boot?

chris2be8 · 2020-10-30 17:26:10

At a guess FDE stands for Full Disk Encryption. Which seems to match his description.

But we still need more details to have any chance of solving the problem.

Chris

rolfie · 2020-10-30 17:35:04

I have got 4 PC with encrypted LVMs/unencrypted boot running under Beowulf on 5.8 kernel with no issues. They are automatically decrypted during boot based on keys from USB sticks.

rolfie

uther · 2020-10-31 10:32:57

Hello, thanks for responses.
Yes, FDE means Full Disk Encryption. After upgrading the kernel I cannot open the cryptsetup during boot. The only message is as if I made a typo during typing passphrase, but when I'm trying to boot with older kernel the passphrase works.
I've managed to resolve this issue on one machine with wiping the drive and reinstallation but that's overkill.

stevendemetrius · 2020-10-31 15:30:42

Form the information you provided, the only thing that is different is installation of a new kernel, there maybe something missing from the initrd.img.x.x.x.x generated for that specific kernel.

The related initrd.img.x.x.x.x is automatically generated and updated for a new kernel, when the kernel is installed, and is configured based on the relevant configuration files: GRUB and initramfs configuration files. If these configuration files have been modified then the boot process will be affected. The update can be done manually with update-grub and/or update-initramfs, (update-grub normally calls update-initramfs).

The initrd.img.x.x.x.x files for each installed kernel are located under /boot/, which must be accessible to GRUB at boot, i.e., if GRUB can not access /boot then the system will not boot. The filesystem hosting /boot must be available and readable by GRUB at boot.
E.g.,
ls -1 /boot/
config-5.5.0-0.bpo.2-amd64
config-5.7.0-0.bpo.2-amd64
config-5.8.0-1-amd64
efi
grub
initrd.img-5.5.0-0.bpo.2-amd64
initrd.img-5.7.0-0.bpo.2-amd64
initrd.img-5.8.0-1-amd64
System.map-5.5.0-0.bpo.2-amd64
System.map-5.7.0-0.bpo.2-amd64
System.map-5.8.0-1-amd64
vmlinuz-5.5.0-0.bpo.2-amd64
vmlinuz-5.7.0-0.bpo.2-amd64
vmlinuz-5.8.0-1-amd64

The files under /boot/grub/ are automatically generated and modified every time update-grub is run, and their manual modification is not recommended.

To modify GRUB modify either /etc/default/grub and/or the files under /etc/grub.d/ and then run update-grub, which will generate/modify the files under /boot/grub
Similarly with initramfs, after modifying file under /etc/initramfs-tools/, run update-initramfs to make the changes take effect.

I suggest doing the following, running all commands as the root user:
1. Run
update-grub
2. Reboot and check the outcome. Note all messages and address any errors, warnings, etc.

If the above does not work...
1. Run
update-initramfs -u -k all
-u: update initrd.img.x.x.x.x
-k all: update all initrd.img.x.x.x.x
2. Reboot and check the outcome. Note all messages and address any errors, warnings, etc.

If it still does not work...
1 Edit the default grub file comparing it with a know-good file.
nano /etc/default/grub
2. Reboot and check the outcome. Note all messages and address any errors, warnings, etc.

If it still does not work...
Check the files under /etc/initramfs-tools/
2. Reboot and check the outcome. Note all messages and address any errors, warnings, etc.

If it still does not work post the content of the /etc/default/grub and /etc/initramfs-tools/ here and state exactly what you did and the results as well as a relevant log entries.

Note: currently the are two versions of luks for cryptsetup: luks1 and luks2. The current stable version of GRUB does not have full support for luks2, therefore, it will not decrypt luks2.

FYI: I have been using ZFS on luks1 to boot, which requires the installation of the related kernel header files to generate the needed ZFS modules for incorporation into the related initrd.img.x.x.x.x.

Host build suggestion: you can modulize your host's OS and data to minimize data loss and ease repairs, backup, restores, etc., by using separate partitions or drives/disks.
Example 1.
/dev/sda
sda1 # boot filesystem: only used to boot the host
sda2 # root filesystem: only used to run the host
sda3 # users' home filesystem; only used to store users' configuration and data
sda4 # swap space: only used by the running kernel

Example 2. This can be done for physical machines (PMs) but is better suited for virtual machines (VMs).
/dev/sda
sda1 # boot
/dev/sdb
sdb1 # root filesystem
/dev/sdc
sdc1 # users' home filesystem
/dev/sdd
sdd1 # swap space.

You can mix and match examples 1 and 2 to suite your needs.

xinomilo · 2020-11-05 21:05:27

make sure you have cryptesetup-initramfs package installed. that usually does the above suggestion automatically..

uther · 2020-11-13 21:31:40

xinomilo - I have cryptsetup-initramfs installed

stevendemeritus - thanks for detailed response

I run update-grub every time after updating the kernel just to be sure anyway, so we can rule that one out.
And after running the above plus update-initramfs -u -k all there are no error messages during boot - its just like before.

I'm using guided partitioning with LUKScrypt and LVM during OS installation.
The partitioning is as follows:

─sda5   
 └─sda5_crypt  
   ├─user--vg-root
   ├─user--vg-var
   ├─user--vg-swap_1
   ├─user--vg-tmp
   └─user--vg-home

As for GRUB the installed version is 2.02+dfsg1-20+deb10u2

/etc/default/grub looks pretty normal, considering that the OS is freshly reinstalled:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Same goes for the /etc/initramfs-tools/*

After further investigation with cryptsetup luksDump /dev/... it looks like this might be luks version issue.

For further explanation - I have 3 machines with Beowulf:

#1 new desktop - grub 2.02+dfsg1-20+deb10u2, luks1, kernel 5.8 - works (upgraded from ASCII)
#2 new laptop - grub 2.02+dfsg1-20+deb10u2, luks2 + kernel 5.8 - wasn't working but works after reinstall
#3 old laptop - grub 2.02+dfsg1-20+deb10u2, luks2 + kernel 5.8 - doesn't work before and after reinstall

Both #2 #3 laptops have Devuan installed from the same iso image and the issue with encryption was present only on them.
#3 is an old Core2Duo.
All 3 machines have proper linux-headers package installed.

You said that the current GRUB cannot decrypt luks2, but on laptop #2 listed above it seems to be working, or am I missing something (aside from hardware)?

Thanks again,
uther

stevendemetrius · 2020-11-14 04:49:50

You are welcome.

There seems to be two entries missing from /etc/default/grub:

GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX="cryptdevice=<crypto device>:<mapper name>"

GRUB_ENABLE_CRYPTODISK=y
Reference: info grub
"If set to 'y', 'grub-mkconfig' and 'grub-install' will check for encrypted disks and generate additional commands needed to access
them during boot. Note that in this case unattended boot is not possible because GRUB will wait for passphrase to unlock encrypted container."

and

GRUB_CMDLINE_LINUX="cryptdevice=<crypto device>:<mapper name>"
E.g.,
GRUB_CMDLINE_LINUX="cryptdevice=UUID=f1ad0cb32e8c-e494-43ab-a574-b9f1ba0e-43ab-a574:sda1_crypt"
You may not need this line if there is only one cryptdevice. However, the addition of one or more cryptdevices may cause GRUB to try to unlock the incorrect cryptdevice. I recommend adding it anyway to be explicit and to avoid "head scratching" later if you add one or more cryptdevices.

Suggest removing "quiet" form the Linux command line so that you can see what is going on during the boot process. This may give some additional clues as to what is happening or not happening.

/etc/default/grub:

-- GRUB_CMDLINE_LINUX_DEFAULT="quiet"
++ GRUB_CMDLINE_LINUX_DEFAULT=""

So your /etc/default/grub file will look similar to this:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="cryptdevice=UUID=f1ad0cb32e8c-e494-43ab-a574-b9f1ba0e-43ab-a574:sda5_crypt"
GRUB_ENABLE_CRYPTODISK=y

The blkid command can be used get the UUID: blkid /dev/sda5

I've seen claims that GRUB has added luks2 support and that a patch has been available since January, however, I can not verify this. According to GNU GRUB Bugs #55093 support for luk2 is expected to appear in release 2.06. Reference: https://savannah.gnu.org/bugs/?55093. If it works great! I'm using the same version of GRUB as you are, so I'll try it myself.

One more thing. This shows that partition sda5 is being used for the entire OS. What are sda1-4 being used for? Is sda using DOS or GPT disk partitioning? GRUB requires a "BIOS boot" partition on GPT while it does not on DOS type disks.

─sda5
└─sda5_crypt
├─user--vg-root
├─user--vg-var
├─user--vg-swap_1
├─user--vg-tmp
└─user--vg-home

Suggestion: put swap in it own partition or drive. This has many advantages such as excluding swap form backup jobs, more flexibility regarding swap manipulation, and more. If hibernation is not a requirement then a swap partition or drive can be encrypted with a random encryption key. Just add the appropriate line to the /etc/crypttab and /etc/fstab files, the partition or drive must not contain a filesystem.

E.g./etc/fstab entry

# Swap filesystem luks2 random, was on /dev/sda3
/dev/mapper/luks2-swap none    swap sw 0 0

E.g. /etc/crypttab entry

# Random key encrypted partition
luks2-swap /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap,discard

uther · 2020-11-14 14:18:42

I've added the following to the grub config file with the proper drive UUID and updated the grub. Still without the effect.

GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX="cryptdevice=<crypto device>:<mapper name>"

After disabling quiet boot option I'm getting the following just before passphrase request:

Begin: Mounting root filesystem ... Begin: Running /scripts/local-top ...  Volume group "user--vg" not found
 Cannot process volume group user--vg
 Volume group "user--vg" not found
 Cannot process volume group user--vg

After typing passphrase:

cryptsetup: ERROR: sda5_crypt: cryptsetup failed, bad password or options?

With the 4.19.0-12-amd64 kernel I'm getting the same message as above but the crypt is openning without a problem.
After checking - the same message about not founding volume group is present on all machines mentioned in my last post.

The sda5 have DOS partition table.
As for the device number - that's the number given during guided partitioning, so I didn't change that. There are no other drives in the system.
During boot there is this however:
[] sda: sda1 sda2 < sda5 >
But there is no sign of sda3 and sda4.

Thanks for the tip about swap! Here I have one question - will changing swap entry in fstab automatically free the diskspace that the swap is using right now?

I don't know if this is relevant but it looks like Beowulf is using 'discard' option in crypttab as a default now:
machine #1 sda1_crypt UUID=xxx none luks
machine #2 sda1_crypt UUID=xxx none luks,discard
machine #3 sda5_crypt UUID=xxx none luks,discard

Last edited by uther (2020-11-14 14:19:57)

stevendemetrius · 2020-11-14 17:44:40

For clarification
/dev/sda - first disk
/dev/sdb - second disk
/dev/sda1 - first partition on first disk
/dev/sdb2 - second partition on second disk
/dev/sdc5 - fifth partition on third disk

The configuration of /etc/crypttab does not seem correct. It has two entries for mapper device sda1_crypt, there should only be one per device. Second the initramfs option is missing from each entry. You can ignore the discard option it is not relevant for boot up. Look at the man page for crypttab for details: man crypttab. The initramfs option is needed to unlock and process the device during boot up: see the man page for details.

E.g., sda1_crypt UUID=xxx none luks,initramfs

Adding the initramfs option to /etc/crypttab entries, requires running update-initramfs for the device to be added to the /boot/initrd.img-x.x.x.x.x which is used during boot.

The /etc/crypttab also shows that there are more than one cryptdevices. The cryptdevcie entry in /etc/default/grub with the UUID must be the UUID of the device that contains /boot. The /boot may be on its own partition. I'm guessing /boot on sda1_crypt and the root (/) is on sda5_crypt. If I'm right the cryptdevice for GRUB is the UUID of sda1_crypt.

In order to eliminate the guess-working can you please provide the output information form the following commands, you can remove sensitive information such as exact UUID, etc.

cat /etc/default/grub
cat /etc/fstab
cat /etc/crypttab
lsblk -f -o +size
fdisk -l

Since you cannot boot into the system you can use the Devuan live-CD/DVD/USB or mount the disk in another system to get the information.
Advice: before running any command you are give by others, always look at the command's man page and check the options to see what should happen.

uther · 2020-11-14 18:35:55

machine #1 sda1_crypt UUID=xxx none luks
machine #2 sda1_crypt UUID=xxx none luks,discard
machine #3 sda5_crypt UUID=xxx none luks,discard

Above refers to 3 different machines which I wrote about earlier. The problematic one is the third one (#3). I might wrote it badly, sorry for that.

Thing is I can boot the system - but only with the older kernel like 4.19.0-12-amd64.

Here are all requested dumps from problematic machine. Please bear in mind that this is fresh OOTB install before any configuration and optimisation.

cat /etc/default/grub

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="cryptdevice=UUID=123456789:sda5_crypt"
GRUB_ENABLE_CRYPTODISK=y

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

cat /etc/fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>			<mount point>   <type>  <options>		<dump>  <pass>
/dev/mapper/dux--vg-root	/               ext4    errors=remount-ro	0       1
# /boot was on /dev/sda1 during installation
UUID=987654321			/boot           ext2    defaults		0       2
/dev/mapper/dux--vg-home	/home           ext4    defaults	        0       2
/dev/mapper/dux--vg-tmp		/tmp            ext4    defaults	        0       2
/dev/mapper/dux--vg-var		/var            ext4    defaults	        0       2
/dev/mapper/dux--vg-swap_1	none            swap    sw      	        0       0

cat /etc/crypttab

sda5_crypt UUID=123456789 none luks,initramfs

lsblk -f -o +size

NAME                 FSTYPE      LABEL     UUID            FSAVAIL FSUSE% MOUNTPOINT             SIZE
sda                                                                                            931.5G
├─sda1               ext2                  987654321	   178M    19%    /boot                  243M
├─sda2                                                                                             1K
└─sda5               crypto_LUKS           123456789	                                       931.3G
  └─sda5_crypt                                                                                 931.3G
    ├─user--vg-root                                            18G    16% /                     23.3G
    ├─user--vg-var                                            8.3G     3% /var                   9.3G
    ├─user--vg-swap_1                                                     [SWAP]                 3.2G
    ├─user--vg-tmp                                            1.7G     0% /tmp                   1.9G
    └─user--vg-home                                         833.8G     0% /home                893.6G

fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x--------------

Device     Boot  Start        End    Sectors   Size Id Type
/dev/sda1  *      2048     499711     497664   243M 83 Linux
/dev/sda2       501758 1953523711 1953021954 931.3G  5 Extended
/dev/sda5       501760 1953523711 1953021952 931.3G 83 Linux

Disk /dev/mapper/sda5_crypt: 931.3 GiB, 999930462208 bytes, 1952989184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-root: 23.3 GiB, 24998051840 bytes, 48824320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-var: 9.3 GiB, 9999220736 bytes, 19529728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-swap_1: 3.2 GiB, 3418357760 bytes, 6676480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-tmp: 1.9 GiB, 1996488704 bytes, 3899392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/user--vg-home: 893.6 GiB, 959480594432 bytes, 1873985536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

stevendemetrius · 2020-11-15 01:30:12

I made an incorrect assumption that the host's /boot was on a cryptdevice, which lead us down the wrong path. Sorry about that. I should have initially asked for the contents of the configuration files you supplied.

The install is not Full Disk Encryption (FDE). Only one partition is encrypted. The disk has an extended partition which indicates that it uses DOS partitioning scheme.
/dev/sda is the boot disk.
/dev/sda1 is the unencrypted /boot partition.
/dev/sda2 is the extended partition. Required on DOS partitioned disk in order to have more than four (4) partitions.
/dev/sda5 is the OS partition with swap on LVM on luks encryption.
In this case the OS partition contains swap and the root (/) tree excluding /boot, all on top of LVM. Which in turn is on top of luks encryption.
The Debian Installation (di) uses that method as the default installation method using encrypted storage. It is arguably not the best method but it makes things easy for beginners.

GRUB requires access to /boot, in this case /boot is not on an encrypted device, therefore, the cryptdevice definition on the /etc/defautl/grub GRUB_CMDLINE_LINUX="cryptdevice=<crypto device>:<mapper name>" line entry should not be there. Additionally, the initramfs option is not needed in /etc/crypttab, though it does not hurt.

Change the grub and crypttab files.
/etc/default/grub

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
GRUB_ENABLE_CRYPTODISK=y

/etc/crypttab

sda5_crypt UUID=<UUID> none luks,initramfs

Run:
update-initramfs -u -k all to update the /boot/initrd.img.xxxxx images.
and
update-grub to update /boot/grub/grub.cfg.

After, reboot and test boot up with the 4.19.x and then the 5.8.x kernels. The results should be the same as before: boot okay with 4.19.x kernel and
password error with 5.8.x kernel.

cryptsetup: ERROR: sda5_crypt: cryptsetup failed, bad password or options?

In this case the problem is just that: bad password or options.

Bad password: this can be either user error or keyboard configuration miss-match during boot.
An easy test is to boot up using the 4.19.x kernel and add a key to the luks on /dev/sda5. luks can have up to eigth (8) keys.
Reference: man cryptsetup
To add a key enter the following command after full boot up with the 4.19.x kernel
cryptesetup luksAddKey /dev/sda5 use "1234" ad the key. This is for testing, you can change it later.
Reference: man cryptsetup
Reboot using the 5.8.x kernel and try the 1234 password. If this works the it a keyboard configuration issue.

Let me know the results.

uther · 2021-01-11 13:05:59

The install is not Full Disk Encryption (FDE). Only one partition is encrypted. The disk has an extended partition which indicates that it uses DOS partitioning scheme.
/dev/sda is the boot disk.
/dev/sda1 is the unencrypted /boot partition.
/dev/sda2 is the extended partition. Required on DOS partitioned disk in order to have more than four (4) partitions.
/dev/sda5 is the OS partition with swap on LVM on luks encryption.
In this case the OS partition contains swap and the root (/) tree excluding /boot, all on top of LVM. Which in turn is on top of luks encryption.
The Debian Installation (di) uses that method as the default installation method using encrypted storage. It is arguably not the best method but it makes things easy for beginners.
GRUB requires access to /boot, in this case /boot is not on an encrypted device, therefore, the cryptdevice definition on the /etc/defautl/grub GRUB_CMDLINE_LINUX="cryptdevice=<crypto device>:<mapper name>" line entry should not be there. Additionally, the initramfs option is not needed in /etc/crypttab, though it does not hurt.

Thank you for clarification, you are right about that. I forgot that this is an accual state and used laymans term. Thou in Devuan installer i belive there is explicitly said about using 'full disk encryption' to describe the default LUKS crypt partitioning scheme. Maybe the description should be improved.

As for the problem, I moved all my systems to Chimaera and so far it's gone.
Thanks everybody for help.

The officially official Devuan Forum!

#1 2020-10-26 22:01:43

[SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#2 2020-10-30 02:42:29

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#3 2020-10-30 17:26:10

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#4 2020-10-30 17:35:04

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#5 2020-10-31 10:32:57

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#6 2020-10-31 15:30:42

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#7 2020-11-05 21:05:27

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#8 2020-11-13 21:31:40

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#9 2020-11-14 04:49:50

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#10 2020-11-14 14:18:42

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#11 2020-11-14 17:44:40

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#12 2020-11-14 18:35:55

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#13 2020-11-15 01:30:12

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

#14 2021-01-11 13:05:59

Re: [SOLVED] LUKS crypt fail to open on recent kernel 5.8.x

Board footer