Notes on VM building
What is says in the title.
Here's what I run to start a Debian install with a virtio storage and network enabled UEFI virtual machine:
$ sudo qemu-img create -f qcow2 /srv/vm-backing-store/padmeamadeus-0-vda.qcow2 64G $ sudo virt-install --name padmeamadeus-0 --memory 5120 --vcpus 2 --cpu host --cdrom ~/Downloads/debian-testing-amd64-20250726-netinst.iso \ --boot uefi --osinfo debian11 --disk /srv/vm-backing-store/padmeamadeus-0-vda.qcow2,bus=virtio --network bridge=br0,model=virtio \ --graphics=spice
5 Gbytes of RAM provisioned. The VM's disk will (eventually) be encrypted with LUKS and 4Gibytes of RAM will be needed for the disk encryption passphrase operation (argon2id) that unlocks the data.
Now that there is a UEFI VM created, it is time to build some ZFS DKMS modules. Firstly, what kernel are we running?
$ dpkg -l linux-image-\* | grep ^ii ii linux-image-6.12.38+deb13-amd64 6.12.38-1 amd64 Linux 6.12 for 64-bit PCs (signed) ii linux-image-amd64 6.12.38-1 amd64 Linux for 64-bit PCs (meta-package) $
Next up, we need to install the matching kernel headers package, the DKMS package, and the ZFS DKMS source package:
$ sudo apt-get install linux-headers-6.12.38+deb13-amd64 dkms zfs-dkms [lots of output elided] $
And try to see about getting the ZFS code inserted into the running kernel:
$ sudo modprobe zfs modprobe: ERROR: could not insert 'zfs': Key was rejected by service $
Well, that's irritating. The interwebs say this is related to secure boot. And normally, I'd fix that by just turning secure boot off. But maybe the time has come to learn how to deal with it?
Secure boot blah blah blah
OK, so secure boot requires cryptographically signed code from the boot loader (GRUB and its components) to the kernel. And runtime loadable kernel modules need some signing, too. At least with Linux. Maybe not so much with other OSes? It looks like maybe DKMS did actually sign the module, but the VM does not know about the key used:
$ /sbin/modinfo zfs filename: /lib/modules/6.12.38+deb13-amd64/updates/dkms/zfs.ko.xz version: 2.3.2-2 license: CDDL license: Dual BSD/GPL license: Dual MIT/GPL author: OpenZFS description: ZFS alias: zzstd alias: zcommon alias: zunicode alias: znvpair alias: zlua alias: icp alias: zavl alias: devname:zfs alias: char-major-10-249 srcversion: A955C79D4F11DB309BB8F3C depends: spl name: zfs retpoline: Y vermagic: 6.12.38+deb13-amd64 SMP preempt mod_unload modversions sig_id: PKCS#7 signer: DKMS module signing key sig_key: 7C:77:72:2A:2C:03:2E:02:3D:9F:FE:76:83:7F:20:F5:1E:79:0C:F0 sig_hashalgo: sha256 signature: 3B:77:18:7B:AC:B2:C8:8F:E5:E4:05:CA:3B:09:19:CD:4C:27:6D:98: 35:33:11:F1:58:D1:73:70:B4:CE:52:1A:9D:59:E2:5C:D2:5E:A6:65: EF:88:6C:4E:3B:13:33:50:FC:48:BA:1A:5F:FB:62:51:4B:6C:39:56: 3B:EC:DD:9F:18:5B:6D:AC:6C:43:4A:FF:97:3D:5C:EC:83:13:CE:7D: AF:E6:70:9C:6D:4E:E7:00:3F:F9:53:51:87:B7:99:95:A1:A7:74:D6: 8A:B7:4A:55:3F:4E:57:08:99:2B:8A:6B:1A:DA:1D:33:5C:3E:E2:37: 00:42:BA:9D:81:AE:7D:12:BC:75:64:55:B4:75:F9:F5:3D:90:4C:E5: AB:5D:FF:98:A2:B1:0C:C5:0F:D5:5D:D2:73:78:21:78:CD:74:C4:34: 35:32:C9:4B:E5:3A:6F:CE:B5:75:B0:F0:56:4F:49:B3:71:CB:9A:48: 91:D2:D2:9E:19:AF:3B:68:87:42:F7:93:5A:E3:73:53:48:20:64:37: 0D:33:CD:29:1A:73:B4:77:26:6D:B9:E4:54:46:F9:ED:50:BA:DA:DB: 42:6F:D3:9E:19:86:A1:75:01:55:9F:A6:77:CA:58:1F:C6:2F:BC:02: B0:1F:16:2D:2B:21:39:47:DB:60:B7:02:A3:7A:5F:0C [lots of info about ZFS code tunables removed for brevity] $
So, yeah. The locally built ZFS module was signed by DKMS module signing key
. How do we tell the VM that key is allowed?
Machine Owner Keys
A secure boot enabled computer's owner can install new keys for code signing. Reading the documentation at Debian's Secure Boot wiki page, it would appear I missed a step. Should have generated a local DKMS Machine Owner Key before installing the zfs-dkms
package.