Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Cryptsetup is not working right
Cryptsetup is not working right
Hi, I have a strange issue.
So I'm running Debian stable with a backported kernel 5.10.0-0.bpo.7-amd64 I'm and trying to open a LUKS2 encrypted partition. I know for a fact, 100 percent, that my password is correct, since I have also tested it successfully in a Debian LXQT live environment without the backported kernel.
But cryptsetup refuses to open it each time with my installed OS. The command I use is: `cryptsetup open /dev/disk/by-partlabel/filebox filebox`. It gives me "No key available with this passphrase." Any ideas what could be happening?
I do want to mention that this installed OS can, in fact, decrypt the LUKS root partition on my laptop just fine every time during boot. It's just that whenever I try cryptsetup on removable media, it just doesn't work... I don't get it.
So I'm running Debian stable with a backported kernel 5.10.0-0.bpo.7-amd64 I'm and trying to open a LUKS2 encrypted partition. I know for a fact, 100 percent, that my password is correct, since I have also tested it successfully in a Debian LXQT live environment without the backported kernel.
But cryptsetup refuses to open it each time with my installed OS. The command I use is: `cryptsetup open /dev/disk/by-partlabel/filebox filebox`. It gives me "No key available with this passphrase." Any ideas what could be happening?
I do want to mention that this installed OS can, in fact, decrypt the LUKS root partition on my laptop just fine every time during boot. It's just that whenever I try cryptsetup on removable media, it just doesn't work... I don't get it.
Re: Cryptsetup is not working right
So I was just reminded upon looking up solutions that there is a `cryptdisks_start` and `cryptdisks_stop` command.
By some miracle, putting this line in `/etc/crypttab`:
And then running `cryptdisks_start filebox` and entering in the password there actually works! Doesn't actually solve the problem with `cryptsetup` not working, but this is a great solution at least.
By some miracle, putting this line in `/etc/crypttab`:
Code: Select all
filebox /dev/disk/by-partlabel/filebox none luks,discard
- cds60601
- df -h | participant
- Posts: 706
- Joined: 2017-11-25 05:58
- Location: Florida
- Has thanked: 129 times
- Been thanked: 60 times
Re: Cryptsetup is not working right
Try this:mrjpaxton wrote:Hi, I have a strange issue.
So I'm running Debian stable with a backported kernel 5.10.0-0.bpo.7-amd64 I'm and trying to open a LUKS2 encrypted partition. I know for a fact, 100 percent, that my password is correct, since I have also tested it successfully in a Debian LXQT live environment without the backported kernel.
But cryptsetup refuses to open it each time with my installed OS. The command I use is: `cryptsetup open /dev/disk/by-partlabel/filebox filebox`.
cryptsetup luksOpen /dev/disk/by-partlabel/filebox filebox
Supercalifragilisticexpialidocious
Re: Cryptsetup is not working right
Same issue.cds60601 wrote:
Try this:
cryptsetup luksOpen /dev/disk/by-partlabel/filebox filebox
- cds60601
- df -h | participant
- Posts: 706
- Joined: 2017-11-25 05:58
- Location: Florida
- Has thanked: 129 times
- Been thanked: 60 times
Re: Cryptsetup is not working right
I dunno - I never used LUKS with a partlabel (Im not saying that's the issue), Mine have always been/are pretty vanillamrjpaxton wrote:Same issue.cds60601 wrote:
Try this:
cryptsetup luksOpen /dev/disk/by-partlabel/filebox filebox
Supercalifragilisticexpialidocious
-
- Global Moderator
- Posts: 2639
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Cryptsetup is not working right
? I checked a few setups and no LUKS volume or partition is enumerated in /dev/disk/by-partlabel.
Actual, there are no 'by-partlabel' at all. ?
Actual, there are no 'by-partlabel' at all. ?
- cds60601
- df -h | participant
- Posts: 706
- Joined: 2017-11-25 05:58
- Location: Florida
- Has thanked: 129 times
- Been thanked: 60 times
Re: Cryptsetup is not working right
I dunno - all examples I ever saw were using something like cryptsetup luksOpen /dev/xxxx (target)CwF wrote:? I checked a few setups and no LUKS volume or partition is enumerated in /dev/disk/by-partlabel.
Actual, there are no 'by-partlabel' at all. ?
Then again, I never did extensive searches and never really used LVM.
The before mentioned always worked for me while using RedHat's Configuring LUKS: Linux Unified Key Setup as a guide.
So if by-partlabel is a thing, then I'll learn something new
Supercalifragilisticexpialidocious
Re: Cryptsetup is not working right
Partition labels are something introduced in GPT layouts, which don't exist for MBR. In a nutshell, it is basically a way to name or label your partitions without labeling them with filesystem tools, or at a filesystem level. It is possible to have both a regular filesystem label and a partition label (even as the same name), but I don't do that.cds60601 wrote:I dunno - all examples I ever saw were using something like cryptsetup luksOpen /dev/xxxx (target)CwF wrote:? I checked a few setups and no LUKS volume or partition is enumerated in /dev/disk/by-partlabel.
Actual, there are no 'by-partlabel' at all. ?
Then again, I never did extensive searches and never really used LVM.
The before mentioned always worked for me while using RedHat's Configuring LUKS: Linux Unified Key Setup as a guide.
So if by-partlabel is a thing, then I'll learn something new
So, for example, let's say you make a partition, whether it's Ext4, Btrfs, FAT32, unformatted or anything else, and then you encrypt it, or you even want to put it in an LVM container...
Well, without a partition label, any encrypted/LVM partition's filesystem label will be hidden and not accessible until opened/decrypted. But with GPT, since the name of the partition itself is in the partition table (or whatever they call it), it is always accessible, if that makes any sense. You can have the encrypted partition have the exact same partlabel as the same unencrypted partition if you want to. Heck, I can still mount separately by UUIDs even if they have the same partition label name.
Anyway, the point is, cryptsetup won't work, even if I do the regular unpredictable udev naming of like `/dev/sda1` or whatever, or even `/dev/disk/...` names.
I do press the enter key after cryptsetup asks for my password. Maybe it's reading in the enter key for some reason. I do have a custom ~/.inputrc file, and maybe it's conflicting with how it's supposed to work. I dunno, could be any multitude of factors. I've even tried it without tmux, but maybe the terminal emulator I'm using is sending in the extra enter key to it. Maybe `cryptsetup open` with a passphrase was not designed to handle the "enter" key correctly in all cases, but `cryptdisks_start` can?? Not sure, yet.
I suppose one thing I haven't tried it with a properly formatted key file. I'll report back sometime and see if that works...
- cds60601
- df -h | participant
- Posts: 706
- Joined: 2017-11-25 05:58
- Location: Florida
- Has thanked: 129 times
- Been thanked: 60 times
Re: Cryptsetup is not working right
That is exaclty how I have mine setup - I encrypt 3 drives and have them auto-open on boot using the key-file.mrjpaxton wrote: I suppose one thing I haven't tried it with a properly formatted key file. I'll report back sometime and see if that works...
I added an additional slot and have a pass-phrase set as a Justin Case
Just to give you an idea on how it looks on my side - I'm doing so in the hopes that you might find something that sticks out at you
and allows you to have an "Ah Ha!" moment.
Code: Select all
/etc/crypttab:
# /dev/sda1 = /mnt/data
data UUID=7f2cf990-e9bd-4767-90d5-48955fbc32a7 /root/.key_file luks
# /dev/sdb1 = /mnt/backup1
backup1 UUID=efe5e12a-6f3b-4eae-829f-934fbee5f553 /root/.key_file luks
# /dev/sdc1 = /mnt/backup2
backup2 UUID=a8d6f317-a138-4e96-8bc3-39487c1ce2fe /root/.key_file luks
Code: Select all
/etc/fstab (relevant bits for LUKS)
### Custom Additions - nvme is the system drive
# Internal 1TB SSD drive - dev, uuid, or encrypted
/dev/mapper/data /mnt/data ext4 defaults,nofail 0 0
# External Drives - dev, uuid, or encrypted
/dev/mapper/backup1 /mnt/nacjup1 ext4 defaults,nofail 0 0
/dev/mapper/backup2 /mnt/backup2 ext4 defaults,nofail 0 0
Supercalifragilisticexpialidocious
Re: Cryptsetup is not working right
Okay, so I think the issue isn't the terminal emulator. I have tried `cryptsetup open` with both Kitty and LXTerminal, all without my usual tmux sessions, and both presented the same problem.
However, when I tried the keyfile. I made sure to use: `set binary noeol` in Vim and copy-pasted they key into a text file in "/tmp/keyfile.txt".
When I did this:
It actually worked! I saw the `/dev/mapper/filebox` mounted it and checked some of the files, closed it afterwards. Everything was good. So it looks like at least cryptsetup isn't completely broken, it's just having a hard time reading from standard input for some reason. As least I'm getting somewhere with narrowing down the problem...
Maybe I will check with the cryptsetup folks if there are any potential bugs that have been fixed in newer versions. I know Debian likes to use older stable versions whenever possible, but maybe I have an uncommon issue here that could be looked more into.
Actually, since only a couple years ago when I finally took the plunge and started the endeavor of figuring out LUKS and FS/block encryption works, I have since then wanted a clean and easy way to be able to use a removable thumb drive, much like a USB "key" with keyfiles on it that when inserted at boot would unlock the OS filesystem(s). I've also never liked the limitations of FAT32, so my reason for using a kernel that is at least version 5.6 (or whenever native ExFat was introduced) was so that I didn't have to use the userspace ExFat FUSE drivers. Instead, I would like to insert an ExFat formatted drive with keyfiles to unlock it, and have it be read by GRUB2.
Turns out that task can be a bit more complicated, especially with Debian Stable that still uses 4.19 kernel by default, and IIRC it doesn't enable ExFat drivers in the initramfs without explicitly specifying it so it can be used at boot time. I also have to think about how in the world removable drives are gonna be auto-mounted like that before "/etc/fstab" is even read. I don't think GRUB2 can use it either, so trying to decrypt "/boot" with an ExFat drive inserted still seems to be out of the question. I don't bother encrypting "/boot" anyway. There doesn't seem to be too much personal data ever on there for me to care about that. It's also a hassle having to still use LUKS1 for encrypting the boot partition. Lol.
Anyway... sorry to go too off topic. yeah, I just use a simple passphrase at boot, but I really should take advantage of some more of the LUKS features and use the multiple keyslots sometime. Haven't bothered to do that yet, and I also need to figure out how to confidently backup the RAID1 /w encryption setup on my PC before I do that, too.
However, when I tried the keyfile. I made sure to use: `set binary noeol` in Vim and copy-pasted they key into a text file in "/tmp/keyfile.txt".
When I did this:
Code: Select all
cryptsetup --key-file=/tmp/keyfile.txt open /dev/disk/by-partlabel/filebox filebox
Maybe I will check with the cryptsetup folks if there are any potential bugs that have been fixed in newer versions. I know Debian likes to use older stable versions whenever possible, but maybe I have an uncommon issue here that could be looked more into.
Oh, so you store your keyfile in "/root"? That is intriguing.cds60601 wrote:That is exaclty how I have mine setup - I encrypt 3 drives and have them auto-open on boot using the key-file.mrjpaxton wrote: I suppose one thing I haven't tried it with a properly formatted key file. I'll report back sometime and see if that works...
I added an additional slot and have a pass-phrase set as a Justin Case
Just to give you an idea on how it looks on my side:
Code: Select all
/etc/crypttab: # /dev/sda1 = /mnt/data data UUID=7f2cf990-e9bd-4767-90d5-48955fbc32a7 /root/.key_file luks # /dev/sdb1 = /mnt/backup1 backup1 UUID=efe5e12a-6f3b-4eae-829f-934fbee5f553 /root/.key_file luks # /dev/sdc1 = /mnt/backup2 backup2 UUID=a8d6f317-a138-4e96-8bc3-39487c1ce2fe /root/.key_file luks
Code: Select all
/etc/fstab (relevant bits for LUKS) ### Custom Additions - nvme is the system drive # Internal 1TB SSD drive - dev, uuid, or encrypted /dev/mapper/data /mnt/data ext4 defaults,nofail 0 0 # External Drives - dev, uuid, or encrypted /dev/mapper/backup1 /mnt/nacjup1 ext4 defaults,nofail 0 0 /dev/mapper/backup2 /mnt/backup2 ext4 defaults,nofail 0 0
Actually, since only a couple years ago when I finally took the plunge and started the endeavor of figuring out LUKS and FS/block encryption works, I have since then wanted a clean and easy way to be able to use a removable thumb drive, much like a USB "key" with keyfiles on it that when inserted at boot would unlock the OS filesystem(s). I've also never liked the limitations of FAT32, so my reason for using a kernel that is at least version 5.6 (or whenever native ExFat was introduced) was so that I didn't have to use the userspace ExFat FUSE drivers. Instead, I would like to insert an ExFat formatted drive with keyfiles to unlock it, and have it be read by GRUB2.
Turns out that task can be a bit more complicated, especially with Debian Stable that still uses 4.19 kernel by default, and IIRC it doesn't enable ExFat drivers in the initramfs without explicitly specifying it so it can be used at boot time. I also have to think about how in the world removable drives are gonna be auto-mounted like that before "/etc/fstab" is even read. I don't think GRUB2 can use it either, so trying to decrypt "/boot" with an ExFat drive inserted still seems to be out of the question. I don't bother encrypting "/boot" anyway. There doesn't seem to be too much personal data ever on there for me to care about that. It's also a hassle having to still use LUKS1 for encrypting the boot partition. Lol.
Anyway... sorry to go too off topic. yeah, I just use a simple passphrase at boot, but I really should take advantage of some more of the LUKS features and use the multiple keyslots sometime. Haven't bothered to do that yet, and I also need to figure out how to confidently backup the RAID1 /w encryption setup on my PC before I do that, too.
-
- Global Moderator
- Posts: 2639
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Cryptsetup is not working right
Thanks for the clarification, I did not know that.mrjpaxton wrote: Partition labels are something introduced in GPT layouts, which don't exist for MBR.
- cds60601
- df -h | participant
- Posts: 706
- Joined: 2017-11-25 05:58
- Location: Florida
- Has thanked: 129 times
- Been thanked: 60 times
Re: Cryptsetup is not working right
S'ok - I learned a bit here also. Yeah - the key-file may not be in the best of places and even though its set to chmod 0400, its still not a perfect situation.mrjpaxton wrote: Anyway... sorry to go too off topic. yeah, I just use a simple passphrase at boot, but I really should take advantage of some more of the LUKS features and use the multiple keyslots sometime. Haven't bothered to do that yet, and I also need to figure out how to confidently backup the RAID1 /w encryption setup on my PC before I do that, too.
As to off topic - lol, I'm trying to figure a good way to backup the laptop when I move to encrypting that. Currently, I enjoy the ease of Clonezilla.
I'm not finding "easy" solutions, but at least there are some.
Supercalifragilisticexpialidocious
-
- Global Moderator
- Posts: 2639
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Cryptsetup is not working right
Boot a usb or other OS and use qemu-img. The bad is image is uncompressed and real size. I've used it for multiple encrypted OS backups. Actual not a backup, I image to a new device (ssd) every so often, the one I take out is the backup..the temp image on a HD is also a backup.cds60601 wrote:As to off topic - lol, I'm trying to figure a good way to backup the laptop when I move to encrypting that. Currently, I enjoy the ease of Clonezilla.
Re: Cryptsetup is not working right
I mean, as a little tech project idea, anyone can try out GPT on any modern PC. There are ways to convert any existing system from MBR to GPT. Sometimes the tutorials will leave out something important: You may also need to create a GPT BIOS partition, which is needed for non-UEFI (BIOS) systems that only support MBR. Without this partition, not even GRUB will be able to start up. The Arch Linux Wiki and other tech blogs have been really helpful on this topic. I can't remember which MBR to GPT conversion tutorials I have used years before, but there may even be some info on the Debian Wiki, not sure... But it is risky, so always backup!CwF wrote:Thanks for the clarification, I did not know that.mrjpaxton wrote: Partition labels are something introduced in GPT layouts, which don't exist for MBR.
So on my laptop, I have a Bash script in a cron job doing once-every-5-hour, read-only Btrfs snapshots for backing up the OS filesystem, which I can use to recover from any simple mistakes. There's more graphical utilities like Timeshift that can aid in this, but I prefer doing it all CLI because I'm crazy like that... And the bash script is designed only to keep snapshots for 7 days.cds60601 wrote:S'ok - I learned a bit here also. Yeah - the key-file may not be in the best of places and even though its set to chmod 0400, its still not a perfect situation.mrjpaxton wrote: Anyway... sorry to go too off topic. yeah, I just use a simple passphrase at boot, but I really should take advantage of some more of the LUKS features and use the multiple keyslots sometime. Haven't bothered to do that yet, and I also need to figure out how to confidently backup the RAID1 /w encryption setup on my PC before I do that, too.
As to off topic - lol, I'm trying to figure a good way to backup the laptop when I move to encrypting that. Currently, I enjoy the ease of Clonezilla.
I'm not finding "easy" solutions, but at least there are some.
Then the filesystem OS, along with the snapshots (which are in the OS filesystem), I tend to back that up manually like once a month on an external drive. I think you can use btrfs send/receive for that for Btrfs, or otherwise rsync will work for Ext4 or whatever. I was warned and advised not to use `dd` to do it, since it will copy over UUIDs/inodes and everything with it, causing potential problems when both are mounted. so DON'T do that. I think I learned that the hard way when my system froze up once when I attached the disk. Lol. I might try rsnapshot or rdiff-backup or something else in case pure rsync is a little too inconvenient for me...
But yeah, I've always personally struggled with trying to find out good backup solutions, specially with RAID drives. I've also heard backing up is the easier part, but figuring out how to recover from backups is the hard and stressful part. And I haven't had enough experience doing that because most of my drives have been working great for many years. Haha.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Cryptsetup is not working right
Note that crypttab also supports the more compact syntax PARTLABEL=filebox (as well as PARTUUID=, UUID=, and LABEL=).mrjpaxton wrote:filebox /dev/disk/by-partlabel/filebox none luks,discard
Could it be some "unusual" (non ASCII ?) character in the passphrase ?mrjpaxton wrote: Okay, so I think the issue isn't the terminal emulator. I have tried `cryptsetup open` with both Kitty and LXTerminal, all without my usual tmux sessions, and both presented the same problem.
Also on any older PC like mine (2006), and get rid of the awful extended and logical partitions. Any BIOS should not care about the partition layout. Some BIOS just require to mark the GPT partition bootable in the MBR.mrjpaxton wrote:anyone can try out GPT on any modern PC
I did it online with gdisk from the system installed on the disk. Didn't need any tutorial.mrjpaxton wrote:There are ways to convert any existing system from MBR to GPT.
A BIOS boot partition is not mandatory for GRUB in all situations (/boot/grub in a plain ext4 partition does not require it), but I still recommend it for reliability.mrjpaxton wrote:You may also need to create a GPT BIOS partition, which is needed for non-UEFI (BIOS) systems that only support MBR. Without this partition, not even GRUB will be able to start up.
The size requirement for the BIOS boot partition is so low (100 kB) that it can usually fit in the empty space between the main partition table and the first partition, or in the space previously used by the extended partition.
Re: Cryptsetup is not working right
Hi p.H,p.H wrote: ↑2021-07-10 11:08Note that crypttab also supports the more compact syntax PARTLABEL=filebox (as well as PARTUUID=, UUID=, and LABEL=).mrjpaxton wrote:filebox /dev/disk/by-partlabel/filebox none luks,discard
Could it be some "unusual" (non ASCII ?) character in the passphrase ?mrjpaxton wrote: Okay, so I think the issue isn't the terminal emulator. I have tried `cryptsetup open` with both Kitty and LXTerminal, all without my usual tmux sessions, and both presented the same problem.
Also on any older PC like mine (2006), and get rid of the awful extended and logical partitions. Any BIOS should not care about the partition layout. Some BIOS just require to mark the GPT partition bootable in the MBR.mrjpaxton wrote:anyone can try out GPT on any modern PC
I did it online with gdisk from the system installed on the disk. Didn't need any tutorial.mrjpaxton wrote:There are ways to convert any existing system from MBR to GPT.
A BIOS boot partition is not mandatory for GRUB in all situations (/boot/grub in a plain ext4 partition does not require it), but I still recommend it for reliability.mrjpaxton wrote:You may also need to create a GPT BIOS partition, which is needed for non-UEFI (BIOS) systems that only support MBR. Without this partition, not even GRUB will be able to start up.
The size requirement for the BIOS boot partition is so low (100 kB) that it can usually fit in the empty space between the main partition table and the first partition, or in the space previously used by the extended partition.
Thanks a lot for your clarifications and additional info! I wasn't too sure that "/etc/crypttab" supported those inline variables/definitions, but I know for a fact that cryptsetup on the other hand does NOT, so that's what I was concerned about. I use them in "/etc/fstab" as well.
So when I generate my passwords in KeePassXC, typically I turn extended ASCII off (or add them if a Website requires it). So I only have "[A-Z][a-z][0-9]" being used here. And I understand while it does make the passwords more compatible with things in a sense, it also makes them have less entropy, but that can be managed with using longer passwords.
But yes, I always, always mention the GPT boot partition because I had been scratching my head over that for hours trying to learn the hard way about that. I also couldn't boot in anymore without it. It's always good to have another computer around, or have a live system or backup OS/drive around before messing with that stuff, and getting confused why it didn't boot until I learned that.
Okay, back on the topic. Still no luck trying to decrypt it with standard `cryptsetup`, I also want to mention that I also have another private drive encrypted with LUKS that I have used `cryptsetup` on in the terminal, and that one also does not open using the same method...
So I'm still blaming the enter key, or something like that. Some other people have said that locale settings could be an issue. I'm not so sure... But typing `locale` shows normal output (I think) like this, at least for the US:
Code: Select all
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Interesting thing to note also, is that the newline isn't processed from a terminal, which is what I thought. So if it does process it, then it's a bug.
I then saw a section from the manpage of cryptsetup(8):
Code: Select all
NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE
Note that no iterated hashing or salting is done in plain mode. If hashing is done, it is a single direct hash. This means that low-entropy passphrases are easy to attack in plain mode.
From a terminal: The passphrase is read until the first newline, i.e. '\n'. The input without the newline character is processed with the default hash or the hash specified with --hash. The hash result will be truncated to
the key size of the used cipher, or the size specified with -s.
From stdin: Reading will continue until a newline (or until the maximum input size is reached), with the trailing newline stripped. The maximum input size is defined by the same compiled-in default as for the maximum key file
size and can be overwritten using --keyfile-size option.
The data read will be hashed with the default hash or the hash specified with --hash. The hash result will be truncated to the key size of the used cipher, or the size specified with -s.
Note that if --key-file=- is used for reading the key from stdin, trailing newlines are not stripped from the input.
If "plain" is used as argument to --hash, the input data will not be hashed. Instead, it will be zero padded (if shorter than the key size) or truncated (if longer than the key size) and used directly as the binary key. This is
useful for directly specifying a binary key. No warning will be given if the amount of data read from stdin is less than the key size.
From a key file: It will be truncated to the key size of the used cipher or the size given by -s and directly used as a binary key.
WARNING: The --hash argument is being ignored. The --hash option is usable only for stdin input in plain mode.
If the key file is shorter than the key, cryptsetup will quit with an error. The maximum input size is defined by the same compiled-in default as for the maximum key file size and can be overwritten using --keyfile-size op‐
Anyway, I'm still just using `cryptdisks_start` and `cryptdisks_stop` for now, since those actually work right.
Also, nice to see that the forums just got updated from HTTP to HTTPS! Cool.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Cryptsetup is not working right
Trying to figure out what could cause this behaviour...
- cryptsetup is redefined as an alias with a weird option
- your terminal (or some layer between it and the shell) translates the enter key into CR+LF (\r\n) instead of just LF, so cryptsetup treats CR as part of the passphrase.
- cryptsetup is redefined as an alias with a weird option
- your terminal (or some layer between it and the shell) translates the enter key into CR+LF (\r\n) instead of just LF, so cryptsetup treats CR as part of the passphrase.
Re: Cryptsetup is not working right
The first one is not it. I checked.p.H wrote: ↑2021-07-15 11:39 Trying to figure out what could cause this behaviour...
- cryptsetup is redefined as an alias with a weird option
- your terminal (or some layer between it and the shell) translates the enter key into CR+LF (\r\n) instead of just LF, so cryptsetup treats CR as part of the passphrase.
Second one is plausible, but how would I disable carriage return? Through `stty` or something similar?
Here is what mine looks like:
Code: Select all
# stty -a
speed 38400 baud; rows 61; columns 240; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Cryptsetup is not working right
Before looking for how to disable CR, you could check whether it is present or not. I guess a simple
should do it. Type some lines, then ctrl+d to quit. LF is hex 0a and CR is hex 0d.
Code: Select all
cat | hd
Re: Cryptsetup is not working right
I had the exact same problem on Ubuntu 20.04.3 LTS. I didn't update or reboot it since i installed it in November 2020. After doing apt upgrade and rebooting it today i was not able to mount the crypt volumes. Same error message.
It obviously was because something has been changed on the cryptsystem. When i create a new volume now then everything works as expected. I can mount it with cryptsetup luksopen. But the old volumes created before the update can not be mounted with cryptsetup luksopen.
Thanx for that /etc/crypttab solution!
That works for me as well.
It obviously was because something has been changed on the cryptsystem. When i create a new volume now then everything works as expected. I can mount it with cryptsetup luksopen. But the old volumes created before the update can not be mounted with cryptsetup luksopen.
Thanx for that /etc/crypttab solution!
That works for me as well.