Hmm, yes that’s a regression in building locally. A while back we reworked how the various SecureBoot certificates are baked into the final image, and the output you’re seeing is basically what happens when the VM tries to boot with an untrusted SecureBoot signature because the corresponding certificate isn’t present.
should work as expected. (Generating the test certificates only needs to be done once.) This matches my normal development environment, so it’s pretty well tested.
I’ll see about fixing the Makefile logic to properly work with the default mkosi certificate if the full-blown test certificates aren’t generated before building.
I did the instruction you mentioned but I still got the same output. However, a clean install of debian vm seems to have resolved the problem.
I also tried make clean and rm -rf certs but it didn’t seem to help.
I was wondering what might have caused the problem?
The only difference that I can think of is that I installed incus directly from debian’s repo before changing it to zabbly’s. I also installed golang from debian’s repo which runs a version of 1.24 but changing it to golang’s offical one didn’t help either.
You likely had a cached mkosi.{crt,key} present which had been generated by mkosi without being trusted properly. Glad that a clean start got things working for you.
Any Incus 6.x feature release or 6.0.x LTS release should work fine on the host-side; I’ve got development systems setup with both.