Hi guys, can anyone share lsblk -f output and kernel boot options to archive the password caching. I still have to input the password for the two encrypted devices, even using systemd and sd-encrypt hooks.
thanks
Sorry, but it just work now for me. Tks
]]>* The "ask-password" framework used to query for LUKS harddisk
passwords or SSL passwords during boot gained support for
caching passwords in the kernel keyring, if it is
available. This makes sure that the user only has to type in
a passphrase once if there are multiple objects to unlock
with the same one. Previously, such password caching was
available only when Plymouth was used; this moves the
caching logic into the systemd codebase itself. The
"systemd-ask-password" utility gained a new --keyname=
switch to control which kernel keyring key to use for
caching a password in. This functionality is also useful for
enabling display managers such as gdm to automatically
unlock the user's GNOME keyring if its passphrase, the
user's password and the harddisk password are the same, if
gdm-autologin is used.
All this was done using sd-encrypt hook. All my luks partions "boot" "root" "home" "swap" were encrypted with same password. So I changed the "home" partition password. After rebooting the system, I was asked to enter password for the "home" partition and the "crypt_home" ( both enteries are refering to the same partitions , I have named the home partition in crypttab file as crypt_home and not as home). On entering the password "home" partition got mapped as "home" and mapping to "crypt_home" got failed. Which is obvious since same partion cannot be mapped two times.
So I finally came to this conclusion ...
Systemd-boot (sd-encrypt hook) tries to automatically mount the swap and home partiton ( may be by scanning the type-codes ). For this it uses the password that was supplied to unlock the root partition. Now since the "home" partition gets automatically mapped as "home" (/dev/mapper/home) thats is why the "home" parititions entry in the crypttab file fails, as it was already mapped.
What do you guys think ?
]]>I changed my /etc/crypttab to:
# PART=sda4 LABEL=none WAS=home whatever UUID=8f9f6801-971a-48ae-9154-70930ca29e23 none luks # PART=sda1 LABEL=none WAS=test disk_123 UUID=9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2 none luks
* With /etc/fstab untouched (with /dev/mapper/home and /dev/mapper/test)
...boot fails as I could expect. screenshot* Updating /etc/fstab to reflect crypttab changes, it works and get me to this configuration:
# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda |-sda1 crypto_LUKS 9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2 | `-disk_123 ntfs 5F9F0FFC2E3D2419 /root/test |-sda2 vfat UEFI 77E0-9445 /boot |-sda3 crypto_LUKS 632a70ab-b2f3-46ee-95e1-f88b1e44e250 | `-luks-632a70ab-b2f3-46ee-95e1-f88b1e44e250 ext4 arch 8dbe352c-0b5e-4e6f-b296-b342b8df0821 / `-sda4 crypto_LUKS 8f9f6801-971a-48ae-9154-70930ca29e23 `-whatever ext4 home 5d35f3e0-01e4-4619-82a9-b40d30659035 /home
Did you tried this with sd-encrypt hooks ... because this problem is unique to systemd-boot and not init boot.
]]>/etc/mkinitcpio.conf:
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck"Things to check:
- make sure your initramfs doesn't contain weird things, like old copies of crypttab, other hooks etc
- permissions of /etc/crypttab* are 600
Thank @damjan but my (our) problem is not with 'encrypt' hook.
As I mentioned above, it does work like a charm prompting a password each luks device listed in /etc/crypttab.
Issue of "auto-unlocking home" happen with sd-encrypt hook (= systemd-cryptsetup).
And I'm curious to investigate the wierd behavior of systemd-cryptsetup...
]]>I have root and home luks partitions, root is decrypted from the initramfs - which asks for a password. in /etc on the root partition I have the key file for home, so only one password is needed.
/etc/crypttab:
home UUID=xyz-abc-.... /etc/crypttab.home discard
/etc/fstab:
/dev/mapper/home /home ext4 rw,noatime,data=ordered,discard 0 2
kernel command line is:
cryptdevice=UUID=yyy-ppprrr-xxx:root:allow-discards root=/dev/mapper/root rw elevator=noop quiet
/etc/mkinitcpio.conf:
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck"
Things to check:
- make sure your initramfs doesn't contain weird things, like old copies of crypttab, other hooks etc
- permissions of /etc/crypttab* are 600
Glad it worked... However there is something more to it ... Try going through the bootlogs with the cmd "journalctl -b" and see if there are any mapping error. The device mapped name problem that I was talking about might be there .. I saw your "crypttab" file you have named the device as "home" so you might not be noticing that problem. Try naming the "home" partion device name to something else in "crypttab" and "fstab" files and see if it still works. It is working in my case.
I changed my /etc/crypttab to:
# PART=sda4 LABEL=none WAS=home
whatever UUID=8f9f6801-971a-48ae-9154-70930ca29e23 none luks
# PART=sda1 LABEL=none WAS=test
disk_123 UUID=9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2 none luks
* With /etc/fstab untouched (with /dev/mapper/home and /dev/mapper/test)
...boot fails as I could expect. screenshot
* Updating /etc/fstab to reflect crypttab changes, it works and get me to this configuration:
# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
|-sda1 crypto_LUKS 9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2
| `-disk_123 ntfs 5F9F0FFC2E3D2419 /root/test
|-sda2 vfat UEFI 77E0-9445 /boot
|-sda3 crypto_LUKS 632a70ab-b2f3-46ee-95e1-f88b1e44e250
| `-luks-632a70ab-b2f3-46ee-95e1-f88b1e44e250 ext4 arch 8dbe352c-0b5e-4e6f-b296-b342b8df0821 /
`-sda4 crypto_LUKS 8f9f6801-971a-48ae-9154-70930ca29e23
`-whatever ext4 home 5d35f3e0-01e4-4619-82a9-b40d30659035 /home
Still remains my doubts about how 'home' is unlocked without password prompt or keyfile.
With these same /etc/crypttab and /etc/fstab, but with encrypt hook (instead of sd-encrypt one), I'm prompted for three passwords: first one for rootfs, then for 'whatever' (home) and then for disk_123.
]]>I really don't know how but 'home' get opened and mounted without password prompt
Instead I am asked my password for the second partition (as expected).
However, in no case, boot continues without waiting for complete password input.
]]>Seven.issimo wrote:However my problem is not root-related or mapping name related:
luks.uuid=<uuid> and root=/dev/mapper/luks-<uuid> handle my encrypted root with no issues.I think, again there is some confusion . specifying root partition with the parameter luks.uuid=<uuid of root partition > fails to mount home paritition . While on specifying the same parameter as rd.luks.uuid=<uuid of root partition> "home" gets mapped somehow.
Following is the quote from this page
Note: If you use luks.* kernel parameters for the rootfs while also using /etc/crypttab for the swap then systemd will complain about "Not creating device 'swap' because it was not specified on the kernel command line.". To fix this issue just use rd.luks.* parameters instead.
This works!
Thank @userak, I'm really sorry I misunderstood your suggestion. But I can't find any logic in systemd behaviour.
Moreover, imao, ArchWiki is not clear at all on this: it refers to 'rootfs' and 'swap' but, apparently, systemd ignores the entire crypttab if luks.uuid option is specified.
]]>userak wrote:Btw How many times it should ask me to enter password during boot , if I'm not using any password files and "boot" "root" "home" "swap" are separate partitions encrypted with luks .
@teateawhy can you confirm the case mentioned in above quote.
I added a second entry to crypttab as a test, but i can't really confirm or deny this quote, since the the first password entry isn't completed, i can't say what happens after that.
]]>Btw How many times it should ask me to enter password during boot , if I'm not using any password files and "boot" "root" "home" "swap" are separate partitions encrypted with luks .
@teateawhy can you confirm the case mentioned in above quote.
]]>