Bug#1000648: clevis: unlocking 2nd device doesn't happen

2022-05-08 Thread Christoph Biedl
Control: tags 1000648 pending

Paul Slootman wrote...

> Perhaps this info could be added to a README.Debian in the clevis-luks
> package? I looked for any documentation but unfortunately there isn't
> any... I'd consider this bug closed if the initramfs option for crypttab
> was mentioned in a README.

Thanks for that input, it shouldn't hurt to do this. The typo fix
is also on its way.

Christoph


signature.asc
Description: PGP signature


Bug#1000648: clevis: unlocking 2nd device doesn't happen

2021-11-26 Thread Paul Slootman
On Fri 26 Nov 2021, Paul Slootman wrote:
> 
> The reason I think is that the second device is not needed to boot the
> system. Presumably there is some way that the initrd scripts determine
> what devices need to be decrypted; my problem would probably go away if
> the second device gets added to that list.

I see in /usr/share/initramfs-tools/hooks/cryptroot around line 182 that
the needed lines from /etc/crypttab are selected and copied to the
initrd image.

Ah! I need to add ",initramfs" to the end of the "extra" encrypted
device entries in /etc/crypttab (and re-run update-initramfs -u -v).
Now it works!

Perhaps this info could be added to a README.Debian in the clevis-luks
package? I looked for any documentation but unfortunately there isn't
any... I'd consider this bug closed if the initramfs option for crypttab
was mentioned in a README.

Thanks,
Paul



Bug#1000648: clevis: unlocking 2nd device doesn't happen

2021-11-26 Thread Paul Slootman
On Fri 26 Nov 2021, Christoph Biedl wrote:
> Paul Slootman wrote...
> 
> > I have 2 MD raid devices which are encrypted.
> (...)
> > I can't find any hints on how to proceed from here, to have the second
> > device also automatically unlocked. Do you have any idea?
> > I can't be the only person with more than one LUKS-encrypted device.
> 
> Strange - at a first glance it seems this is
> 
> https://github.com/latchset/clevis/commit/v16-2-g0abdfbc
> 
> That change however was included in 16-2, the version you're using.
> Actually, that change was the reason for 16-2.

That would trigger if at that moment both devices are decrypted at the
same stage. Before I installed clevis, I would first get the passphrase
prompt for the first device during the initrd step, and then after the
root filesystem is decrypted and mounted, only _then_ did I get asked
for the passphrase for the second device. That happens via the
/etc/init.d/cryptdisks-early script which is linked to
/etc/rcS.d/S08cryptdisks-early .

The reason I think is that the second device is not needed to boot the
system. Presumably there is some way that the initrd scripts determine
what devices need to be decrypted; my problem would probably go away if
the second device gets added to that list.

Note that I'm one of those old beardy unix people that don't want to
like systemd... I see that there is a clevis-systemd package that
perhaps should need a clevis-sysvinit counterpart. If that is indeed the
case, then I understand if you'd want to tag this "wontfix". However it
would be nice if there was some way to unlock all devices during the
initrd step.


Thanks,
Paul



Bug#1000648: clevis: unlocking 2nd device doesn't happen

2021-11-26 Thread Christoph Biedl
Paul Slootman wrote...

> I have 2 MD raid devices which are encrypted.
(...)
> I can't find any hints on how to proceed from here, to have the second
> device also automatically unlocked. Do you have any idea?
> I can't be the only person with more than one LUKS-encrypted device.

Strange - at a first glance it seems this is

https://github.com/latchset/clevis/commit/v16-2-g0abdfbc

That change however was included in 16-2, the version you're using.
Actually, that change was the reason for 16-2.

Will try to reproduce the issue, this might take some time, though.

> PS: dpkg -s clevis-luks
(...)
> "encrytped" is a typo.

Thanks for reporting, will be fixed in the next upload to unstable.
Possibly lintian will report that one in the future, it happened
at more places in the archive.

Christoph


signature.asc
Description: PGP signature


Bug#1000648: clevis: unlocking 2nd device doesn't happen

2021-11-26 Thread Paul Slootman
Source: clevis
Version: 16-2
Severity: normal

I have 2 MD raid devices which are encrypted.
/dev/md1 is a PV for LVM which contains basically the root filesystem
and separate /var and /tmp filesystems.
/dev/md2 is also a PV for LVM contains /home and other filesystems.

I have bound both to the tpm2 pin. /dev/md1 gets succesfully
unlocked by the initd.img scripts, but /dev/md2 is not touched there.

After the root has been mounted and the cryptdisks-early script runs,
that script sees that /dev/md1 has been unlocked, and then proceeds
to ask the passphrase for /dev/md2; clevis seems to do nothing for that
second device, while it's been bound in an identical manner.

I can't find any hints on how to proceed from here, to have the second
device also automatically unlocked. Do you have any idea?
I can't be the only person with more than one LUKS-encrypted device.

PS: dpkg -s clevis-luks
...
Description: LUKS integration for clevis
 This package allows binding a LUKS encrytped volume to a clevis

"encrytped" is a typo.


Thanks,
Paul

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages clevis depends on:
ii  cracklib-runtime2.9.6-3.4
ii  curl7.74.0-1.3+b1
ii  jose10-3
ii  libc6   2.31-13+deb11u2
ii  libjansson4 2.13.1-1.1
ii  libjose010-3
ii  libpwquality-tools  1.4.4-1
ii  libssl1.1   1.1.1k-1+deb11u1
ii  luksmeta9-3

Versions of packages clevis recommends:
ii  cryptsetup-bin  2:2.3.5-1

clevis suggests no packages.

-- no debconf information