| 2021-10-24 20:18:35 |
Niclas Morin |
bug |
|
|
added bug |
| 2021-10-24 20:23:37 |
Niclas Morin |
description |
It is not possible to unlock multiple devices in the initramfs phase, for example when having a zfs mirror as the root filesystem. This makes the package unusable in that case.
This has been fixed in upstream (latchset/clevis, version 18, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7) |
It is not possible to unlock multiple devices in the initramfs phase, for example when having a zfs mirror as the root filesystem. This makes the package unusable in that case.
This has been fixed in upstream (latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7) |
|
| 2021-10-25 15:33:46 |
dann frazier |
clevis (Ubuntu): status |
New |
Fix Committed |
|
| 2021-10-25 18:40:45 |
dann frazier |
nominated for series |
|
Ubuntu Impish |
|
| 2021-10-25 18:40:45 |
dann frazier |
bug task added |
|
clevis (Ubuntu Impish) |
|
| 2021-10-25 18:40:45 |
dann frazier |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-10-25 18:40:45 |
dann frazier |
bug task added |
|
clevis (Ubuntu Hirsute) |
|
| 2021-10-25 18:40:45 |
dann frazier |
nominated for series |
|
Ubuntu Jammy |
|
| 2021-10-25 18:40:45 |
dann frazier |
bug task added |
|
clevis (Ubuntu Jammy) |
|
| 2021-10-25 18:40:45 |
dann frazier |
nominated for series |
|
Ubuntu Focal |
|
| 2021-10-25 18:40:45 |
dann frazier |
bug task added |
|
clevis (Ubuntu Focal) |
|
| 2021-10-25 19:54:22 |
Niclas Morin |
description |
It is not possible to unlock multiple devices in the initramfs phase, for example when having a zfs mirror as the root filesystem. This makes the package unusable in that case.
This has been fixed in upstream (latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7) |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by monitoring for the processes that send up the interactive prompts "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7) |
|
| 2021-10-25 19:55:25 |
Niclas Morin |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2021-10-25 20:02:07 |
Niclas Morin |
description |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by monitoring for the processes that send up the interactive prompts "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7) |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by monitoring for the processes that send up the interactive prompts "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
|
| 2021-10-25 20:02:42 |
Niclas Morin |
description |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by monitoring for the processes that send up the interactive prompts "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by monitoring for the processes that send up the interactive prompts "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
|
| 2021-10-25 20:06:11 |
Niclas Morin |
description |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by monitoring for the processes that send up the interactive prompts "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by finding the PID of the process that send up the interactive prompt "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
|
| 2021-10-25 20:06:20 |
Niclas Morin |
description |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by finding the PID of the process that send up the interactive prompt "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear a saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by finding the PID of the process that send up the interactive prompt "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear the saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
|
| 2021-10-25 20:06:54 |
Niclas Morin |
description |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by finding the PID of the process that send up the interactive prompt "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear the saved PID-variable (used to store the PID of the process that creates the prompt for the user), so when the PID of the first process has been found it won't look for more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by finding the PID of the process that send up the interactive prompt "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear the saved PID-variable, so when the PID of the first process has been found it won't find any more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
|
| 2021-10-25 20:07:11 |
Niclas Morin |
description |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by finding the PID of the process that send up the interactive prompt "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear the saved PID-variable, so when the PID of the first process has been found it won't find any more processes of this type. This means it can only unlock one device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
[Impact]
clevis can be used to automatically unlock LUKS-encrypted devices during boot by asking a remote server for the key (sort of). It does so by finding the PID of the process that send up the interactive prompt "Please unlock disk xxx:" and then sends a key to that process through a fifo that the process has opened.
The bug that existed in clevis versions prior to version 17 forgot to clear the saved PID-variable, so when the PID of the first process has been found it won't find any more processes of this type. This means it can only unlock the first device. If you have for example some sort of RAID root filesystem with multiple disks (or a ZFS mirror as me) then clevis does not work at all.
[Test Plan]
- Setup a tang server on a different host:
# sudo apt install tang
# sudo systemctl enable tangd.socket --now
# reboot
- Setup two LUKS-disks that shall be decrypted during early boot (append option initramfs to them in /etc/crypttab)
- Setup clevis:
# sudo apt install clevis
# sudo apt install clevis-luks
# sudo apt install clevis-initramfs
- Bind the encrypted disks to the tang server:
# sudo clevis luks bind -d /dev/<disk1> tang '{"url": "http://<tang-server>"}'
# sudo clevis luks bind -d /dev/<disk2> tang '{"url": "http://<tang-server>"}'
- Regenerate initramfs
# sudo update-initramfs -u -k 'all'
- Reboot
# reboot
After the reboot you will be stuck at "Please unlock disk xxx:" until you enter the passphrase manually.
If you perform all the steps using only one disk it will work.
[Where problems could occur]
If something is wrong with the patch it will show up when clevis is unlocking a LUKS-encrypted disk during initramfs.
[Other Info]
This has been fixed in upstream (https://github.com/latchset/clevis, version 17, commit 0abdfbc7812c8ef588ee22fd35941b5e831fdce7 on Feb 24, 2021) |
|
| 2021-10-25 21:24:55 |
Mathew Hodson |
clevis (Ubuntu Focal): importance |
Undecided |
Low |
|
| 2021-10-25 21:24:57 |
Mathew Hodson |
clevis (Ubuntu Hirsute): importance |
Undecided |
Low |
|
| 2021-10-25 21:24:59 |
Mathew Hodson |
clevis (Ubuntu Impish): importance |
Undecided |
Low |
|
| 2021-10-25 21:25:02 |
Mathew Hodson |
clevis (Ubuntu Jammy): importance |
Undecided |
Low |
|
| 2021-10-26 20:54:29 |
dann frazier |
clevis (Ubuntu Impish): status |
New |
Fix Released |
|
| 2021-10-26 22:34:05 |
dann frazier |
clevis (Ubuntu Hirsute): status |
New |
In Progress |
|
| 2021-10-26 22:34:08 |
dann frazier |
clevis (Ubuntu Focal): status |
New |
In Progress |
|
| 2021-10-26 22:34:10 |
dann frazier |
clevis (Ubuntu Focal): assignee |
|
dann frazier (dannf) |
|
| 2021-10-26 22:34:12 |
dann frazier |
clevis (Ubuntu Hirsute): assignee |
|
dann frazier (dannf) |
|
| 2021-10-27 17:22:22 |
Robie Basak |
clevis (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-10-27 17:22:25 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-10-27 17:22:26 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2021-10-27 17:22:29 |
Robie Basak |
tags |
|
verification-needed verification-needed-hirsute |
|
| 2021-10-27 17:22:53 |
Robie Basak |
clevis (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-10-27 17:22:56 |
Robie Basak |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2021-10-27 17:22:58 |
Robie Basak |
tags |
verification-needed verification-needed-hirsute |
verification-needed verification-needed-focal verification-needed-hirsute |
|
| 2021-10-28 17:51:44 |
Niclas Morin |
tags |
verification-needed verification-needed-focal verification-needed-hirsute |
verification-done-focal verification-needed verification-needed-hirsute |
|
| 2021-10-28 19:40:54 |
Niclas Morin |
tags |
verification-done-focal verification-needed verification-needed-hirsute |
verification-done-focal verification-done-hirsute verification-needed |
|
| 2021-10-28 21:52:52 |
dann frazier |
tags |
verification-done-focal verification-done-hirsute verification-needed |
verification-done verification-done-focal verification-done-hirsute |
|
| 2021-11-03 20:52:40 |
Launchpad Janitor |
clevis (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
| 2021-11-03 20:52:44 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-11-03 20:53:07 |
Launchpad Janitor |
clevis (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2022-02-04 16:34:57 |
dann frazier |
nominated for series |
|
Ubuntu Bionic |
|
| 2022-02-04 16:34:57 |
dann frazier |
bug task added |
|
clevis (Ubuntu Bionic) |
|
| 2022-02-07 17:00:18 |
dann frazier |
clevis (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-02-07 17:00:30 |
dann frazier |
clevis (Ubuntu Bionic): status |
New |
Triaged |
|
