On 27.01.2024 00:40, Orion Poplawski wrote:
On 1/26/24 01:21, Lennart Poettering wrote:
On Do, 25.01.24 16:28, Orion Poplawski (or...@nwra.com) wrote:
We have various VMs that are back by luks encrypted LVs. At boot the volumes
are decrypted by clevis. The problem we are seeing at the moment
On 1/26/24 01:21, Lennart Poettering wrote:
> On Do, 25.01.24 16:28, Orion Poplawski (or...@nwra.com) wrote:
>
>> We have various VMs that are back by luks encrypted LVs. At boot the volumes
>> are decrypted by clevis. The problem we are seeing at the moment is that the
>> VMs are started before
On Do, 25.01.24 16:28, Orion Poplawski (or...@nwra.com) wrote:
> We have various VMs that are back by luks encrypted LVs. At boot the volumes
> are decrypted by clevis. The problem we are seeing at the moment is that the
> VMs are started before the block devices are decrypted. Our current
> so
On Fri, Jan 26, 2024 at 2:29 AM Orion Poplawski wrote:
>
> We have various VMs that are back by luks encrypted LVs. At boot the volumes
> are decrypted by clevis. The problem we are seeing at the moment is that the
> VMs are started before the block devices are decrypted. Our current solution
On Fri, Jan 26, 2024 at 1:29 AM Orion Poplawski wrote:
> We have various VMs that are back by luks encrypted LVs. At boot the
> volumes
> are decrypted by clevis. The problem we are seeing at the moment is that
> the
> VMs are started before the block devices are decrypted. Our current
> solut
We have various VMs that are back by luks encrypted LVs. At boot the volumes
are decrypted by clevis. The problem we are seeing at the moment is that the
VMs are started before the block devices are decrypted. Our current solution
is:
# cat /etc/systemd/system/virtqemud.service.d/override.conf
