nick/nickpegg.com
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

[post] "Key was rejected by service" error

Browse source
This commit is contained in:
Nick Pegg 2020-08-24 00:06:48 -07:00
parent 294b45589e
commit e53946f384
1 changed files with 37 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

37
posts/2020-08-23_key_rejected_by_service_error.yaml Normal file
View file

@ -0,0 +1,37 @@
date: 2020-08-23
title: '"Key was rejected by service" when loading kernel modules on VMs'
---
Here's a quick blurb about something I recently ran into and found a fix for, and
I'm hoping that the search indexing gods find this and help some other poor
soul who has run into this sort of thing.
I've been playing around with KVM virtual machines on my home server recently,
and have started using the `virt-sparsify` and `virt-resize` CLI tools
respectively to generate a compressed golden machine image and apply that image
to a new VM. After doing this and booting the new machine, I got this failure
after trying to load in a kernel module:
```
$ sudo modprobe bridge
modprobe: ERROR: could not insert 'bridge': Key was rejected by service
```
Uhhh, what? This seems to point to some secure boot signing-related thing, but
I'm pretty sure nothing has gone awry with that since all I did was make a disk
clone. After a bunch of experimenting, I discovered that cloning with
straight `dd` would work fine, and would somehow taint the target disk so that
future `virt-resize` runs would always result in a working target!
This was really weird, so I dug through the [`virt-resize`
manpage](https://libguestfs.org/virt-resize.1.html), and came across the
`--no-sparse` flag which has this in its description:
> The main time this can be a problem is if the target is a host partition (eg. virt-resize source.img /dev/sda4) because the usual partitioning tools tend to leave whatever data happened to be on the disk before.
>
> If you have to reuse a target which contains data already, you should use the --no-sparse option. Note this can be much slower.
Well shit. My target VM that's receiving the image is using a LVM logical
volume for its drive, which I'm sure has some leftover data on it.
**`virt-resize --no-sparse` fixes this issue for me, as does zeroing out the LV
before applying the image.** With the sparse copying, some old junk data must
have been lurking in the new VM's partition, causing the issues.