I installed the gpu-support application this morning on IncusOS v202601100100, and shortly after issued a reboot, because I suspected this was required prior to #797 being available in the stable channel. Boot then hanged with a message indicating that IncusOS cannot boot with secure boot in audit mode. I checked bios settings, but I could not find a related setting. Previous reboots (ie. into the image of the 10th) went fine, so this was new to me.
I wonder if:
I was too quick with the reboot, and if this is somehow related to the installation of the gpu-support application being incomplete
am running into the annual rollover; I did notice when troubleshooting that 202601141549 was in the B partition already.
this is something locally to do with a wrong configuration or bug in the local secure boot implementation, ie. completely outside of IncusOS
While trying to resolve the issue, I toggled the secure boot settings from ‘normal’ to ‘custom’ and back which subsequently caused a signature failure. Looks like my BIOS immediately effectuate changes when exploring menus. That went away after I manully re-added the hash of the boot64 image and the relevant kernel in this custom mode. That got me to the cryptsetup recovery prompt, but the keyboard didn’t work
I’ll have more time later to understand how far I get. I don’t mind twiddeling some more and/or reinstalling; but the goal of this post is not so much to ask for support as to share the experience in case there is something to be learned here.
I ran into the same error this morning, and this was the only thing that effectively changed in between reboots. I’m still able to run 202601100100, so that’s my workaround for now.
I’m trying to do my first install - have been trying to enroll with secure boot but have been having issues with it saying my SecureBoot is in audit mode. Even with secure boot off it’s saying that - 202601141549 as well. Is there any way to build an older image to test if it’s related somehow?
I believe I have some hurdles ahead of me to recover from this situation, some of which might be useful to others.
For starters, as soon as Incus boots, the keyboard ceases to function. Could it be that the initramfs has only some of the usb drivers? The keyboard is perfectly functional in the BIOS and for the version selector. But once I select a version, the num lock light turns off / power appears to be cut. Not having keyboard input prevents me from inputting a recovery passphrase
The second hurdle is that I appear to have wiped the secure boot config. I’ll try to use the installer to get it back in the right state. Perhaps that’ll return the auto-unlock to its normal state, solving #1.
OK, that worked. I used the installer to provision secure boot keys, then aborted the installation. That allowed me to boot normally, with the partition auto-unlocking.
The keyboard issue means I do not have a recovery path for future issues though. Should I file an issue?
