I tried enabling GPU pass-through using this guide https://forum.proxmox.com/threads/p...x-ve-8-installation-and-configuration.130218/ before realising that it's probably pointless as my server only has an Intel HD 530 iGPU, but something in those steps seems to have broken systemd-cryptsetup.
I've setup crypttab and fstab to auto-decrypt and mount my 16TB USB HDD using a keyfile, and that was working but now it fails and the log shows:
It still works fine if I run 'cryptdisks_start 16TBUSB' and 'mount -a' after its finished booting. My OS SSD is encrypted with OPAL and cryptsetup prompts me for the password for that at boot and that works fine, so it seems that systemd-cryptsetup is just failing to find the keyfile for the 16TB HDD.
I've tried undoing all the steps I followed, so I've removed 'intel_iommu=on iommu=pt' from /etc/default/grub and run 'update grub'; I'm not using a ZFS pool at the moment so I didn't edit '/etc/kernel/cmdline' (which doesn't exist) or run 'pve-efiboot-tool refresh' when I was following the guide; I've commented out the vfio entries that I added to /etc/modules and run 'update-initramfs -u -k all', and I've commented out the line that I added to /etc/modprobe.d/vfio.conf and rebooted.
dmesg | grep 'remapping' still shows:
which seems a bit weird, but 'dmesg | grep -i vfio' returns nothing, which makes sense.
I hope it's possible to fix this, as I've only just finished copying PVE onto my encrypted SSD and restoring the backed up LXCs and VMs, so it will be a right pain if I have start from scratch and do all that again.
I've setup crypttab and fstab to auto-decrypt and mount my 16TB USB HDD using a keyfile, and that was working but now it fails and the log shows:
Oct 18 03:54:24 pve systemd-cryptsetup[782]: PBKDF2 hash algorithm stribog512 not available, skipping.Oct 18 03:54:24 pve systemd-cryptsetup[782]: Failed to activate using password file '/var/backup-logs/keyfile.bin'. (Key data not correct?)Oct 18 03:54:24 pve systemd[1]: systemd-cryptsetup@16TBUSB.service: Main process exited, code=exited, status=1/FAILUREOct 18 03:54:24 pve systemd[1]: systemd-cryptsetup@16TBUSB.service: Failed with result 'exit-code'.Oct 18 03:54:24 pve systemd[1]: Failed to start systemd-cryptsetup@16TBUSB.service - Cryptography Setup for 16TBUSB.Oct 18 03:54:24 pve systemd[1]: Dependency failed for dev-mapper-16TBUSB.device - /dev/mapper/16TBUSB.Oct 18 03:54:24 pve systemd[1]: Dependency failed for mnt-16TBUSB.mount - /mnt/16TBUSB.Oct 18 03:54:24 pve systemd[1]: mnt-16TBUSB.mount: Job mnt-16TBUSB.mount/start failed with result 'dependency'.Oct 18 03:54:24 pve systemd[1]: dev-mapper-16TBUSB.device: Job dev-mapper-16TBUSB.device/start failed with result 'dependency'.Oct 18 03:54:24 pve systemd[1]: Dependency failed for cryptsetup.target - Local Encrypted Volumes.Oct 18 03:54:24 pve systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.Oct 18 03:54:24 pve systemd[1]: systemd-cryptsetup@16TBUSB.service: Consumed 22.428s CPU time, 5.9M memory peak.Oct 18 03:54:24 pve systemd[1]: run-credentials-systemd\x2dcryptsetup\x4016TBUSB.service.mount: Deactivated successfully.Oct 18 03:54:24 pve systemd[1]: Reached target blockdev@dev-mapper-16TBUSB.target - Block Device Preparation for /dev/mapper/16TBUSB.It still works fine if I run 'cryptdisks_start 16TBUSB' and 'mount -a' after its finished booting. My OS SSD is encrypted with OPAL and cryptsetup prompts me for the password for that at boot and that works fine, so it seems that systemd-cryptsetup is just failing to find the keyfile for the 16TB HDD.
I've tried undoing all the steps I followed, so I've removed 'intel_iommu=on iommu=pt' from /etc/default/grub and run 'update grub'; I'm not using a ZFS pool at the moment so I didn't edit '/etc/kernel/cmdline' (which doesn't exist) or run 'pve-efiboot-tool refresh' when I was following the guide; I've commented out the vfio entries that I added to /etc/modules and run 'update-initramfs -u -k all', and I've commented out the line that I added to /etc/modprobe.d/vfio.conf and rebooted.
dmesg | grep 'remapping' still shows:
[ 0.177560] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.[ 0.179234] DMAR-IR: Enabled IRQ remapping in x2apic modewhich seems a bit weird, but 'dmesg | grep -i vfio' returns nothing, which makes sense.
I hope it's possible to fix this, as I've only just finished copying PVE onto my encrypted SSD and restoring the backed up LXCs and VMs, so it will be a right pain if I have start from scratch and do all that again.