sdb 8:16 0 931,5G 0 disk
├─sdb1 8:17 0 499M 0 part /boot/efi
├─sdb2 8:18 0 100M 0 part (Windows bull****)
├─sdb3 8:19 0 540,3G 0 part (Windows)
├─sdb4 8:20 0 16M 0 part (some more bull**** windows created)
└─sdb5 8:21 0 390,6G 0 part
└─cr 254:0 0 390,6G 0 crypt
├─root 254:1 0 28,6G 0 lvm /
└─home 254:2 0 362G 0 lvm /home
So I have a efi grub which should decrypt boot (on root), that is working, but then the system is querying me again for the password.
I tried to add a keyfile and place it in boot and put it into the fstab / crypttab and also into the initramfs (which should be safe because the initram fs is located on the encrypted boot).
(tried to add this to dracut.conf *install_items+="/boot/crypt.key")
*After that I created a new initramfs, but it still does not work. Do you have some suggestions on what I have to change to get it run?
I don’t know why that isn’t working. I’ll just clarify a different point.
The first prompt for an encryption key is by “grub2”, so that it can read the boot menu. The second prompt is by the system (the running kernel).
I have one of my systems working that way, and I just enter the encryption key twice. I have not tried what you are doing. Maybe I should experiment with that.
NOTE: I tested with Leap 15.0 (not yet released, but release candidate is available). I did not test with Leap 42.3. My reason for testing with Leap 15.0, is that I already have most of the setup for that in place in a VM (virtual machine).
I needed to use:
install_items+=" /boot/crypt.key "
Note the space at the start and end of the quoted string.
I did not put that in “dracut.conf”. Rather, I put it in “/etc/dracut.conf.d/50-crypt.conf” (a new file that I had to create).
For the Luks encryption key: I created a new key which I put in “/boot/crypt.key”. And then I used
cryptsetup luksAddKey /dev/sda3 /boot/crypt.key
to add that key.
I later tried using that key (not the file, but the key that is in the file) with “cryptsetup” for testing manual setup. And it did not work. My conclusion: The newline character at the end of that “crypt.key” file is being used as part of the key. So it did not work manually, because I entered the key without that newline.
I later tried replacing what is in “crypt.key” with the key that I usually type in. But I did it so that the file does not end with a newline. (I used “echo -n” with “csh” as my shell to do that). I then ran “mkinitrd” to rebuild the “initrd” and it still worked.
My guess is that you are running into one or both of the same issues:
the need for spaces around the file path to add to the initrd
the issue of whether the line terminator in your “crypt.key” is being used as part of the key.
That does not really matter as long as you use the same file in all cases. What matters, initrd must be told to actually use this key file for decryption. It may be provided in /etc/crypttab (in which case it must be also present in root /etc/crypttab) or using rd.luks.XXX options (like rd.luks.key) but it needs to be present.
Just installed Opensuse leap 15 last night. I am a new user to OpenSuse but would rate myself a intermediate user of most of debian/ubuntu. I believe I have the same issue.
I got some key differences than OP: I’m using leap 15 instead of 42.3, there are more password prompts than encrypted partitions (three encrypted partitions courtesy of LVM, about 4-5 password prompts) and am a little unclear of how to do the solutions presented in that thread.
A question about the solutions:
nrickert
I did not put that in “dracut.conf”. Rather, I put it in “/etc/dracut.conf.d/50-crypt.conf” (a new file that I had to create).
Why should this matter? Did it just fail to generate this file? Otherwise how will it know to look here?
Hi, welcome to these forums. I’m not very familiar with disk encryption, but I’ve got some advice on data others that do have the knowledge are going to ask. Given yiour knowledge of debian based distros, provide as much ‘real’ info, i.e. output, either here, between CODE tags, either on paste.opensuse.org with a link here.
For me, I have one encrypted partition used for the LVM, with several volumes inside.
If you combined several encrypted partitions to form an LVM, then each of those has to be decrypted to access the LVM. If grub2 needs to read the LVM, then I suppose it needs to decrypt all of the partitions. I’ve never tried that. But if it asks for the password several times, you might be stuck with that.
Why should this matter?
That’s asking about part of my earlier answer (which forum software does not requote).
I don’t know that it does matter. I just included full details of what I did.
Yes, certainly, but I just don’t think it will be that much help.
When I first turn on the computer, it hangs for a little bit, and then prompts me for a password.
attempting to decrypt master key...
Enter passphrase for hd0.gpt2 (hash here):
When I enter in the encryption key… seems to reformat the text for the screen a little and then it prompts again with further text.
error: disk `lvm/system-home' not found.
error: disk `lvm/system-swap' not found.
Attempting to decrypt master key...
Enter passphrase for hd1,gpt2 (different hash):
Upon second password entering…
Slot 0 opened
error: disk `lvm/system-home' not found.
Attempting to decrypt master key...
Enter passphrase for hd2,gt1 (different hash):
Then, it opens boot and prompts me again in a nice gui for the passphrase.
This suggests that its looking for the lvm swap and system roots on my different partitions based on the ordering that it opens the partitions for lvm. That makes sense, but why ask for the gui encryption key after that? Also, this is a fresh install, so all of the config files are default. Should I post them or just go from there?
Thanks, nrickert. I was just wondering about your intuition on making the new file that didn’t exist by default. There is a separate boot partition that isn’t encrypted, so I figured that grub wouldn’t need to decrypt the other partitions before running.
As for the setup, I just ran the guided setup during installation.
Those all look like grub2 prompts. And grub2 needs those passwords to access the boot menu.
Then, it opens boot and prompts me again in a nice gui for the passphrase.
At this stage, the kernel should now have been loaded. There isn’t any secure way that grub2 can communicate those passwords to the kernel. So the kernel needs to ask for them again.
This time, though, if they are all the same password then you should only need to give it once…
The first three password prompts (by grub2) you most likely will not be able to avoid. That fourth prompt, you could possibly avoid with the dracut config changes as discussed earlier in this thread.
Maybe there’s a better way of partitioning/installing that would reduce the number of password entries that you need. But this would require reinstalling, if it is even possible. If you want to look into that possibility, start a new separate thread. And we would need to see the partition tables for each disk (it looks as if you have three disks (or more). You can get the partition tables with:
fdisk -l
or with
parted -l
Those will also give extraneous output. If you want to avoid that, you could use:
So what I’m getting here is that the first three are required because the kernel is spread across the three partitions (its true - I got three) because of lvm. Then, I have to unlock the kernel once its setup. I was looking to get rid of the first three password prompts to set up the kernel, looks like I’ll have to look for another way to encrypt.
I think I will run the reinstall and see if I can do it with the expert setup in the partitions. I’ll post another thread after that if I can’t get it or maybe I can just be diligent with encrypting the important things manually without encrypting the system wholesale.
See if you can find a way to do it, so that only one key is needed to access the kernel and boot menu. For example, you could use a smaller encrypted LVM for just root or for root+swap, and the other combined partitions for a larger LVM with the home partition. If you can get to the root partition with only a single password, then you can make this a lot easier to manage.
