Something has gone seriously wrong: import_mok_state() failed: Unsupported

Ten64 Forum
1

I bought two Ten64 devices. This happened on both and it’s unclear how I managed to resolve it. After mounting it to a case, I upgraded the firmware as requested. Everything seemed fine.

I then booted back into recovery, and set the wan port using set-wan eth7. After that I ran appstore-list and baremetal-deploy ubuntu-hirsute /dev/nvme0n1, provided only a password and the interface eth7 and accepted the default for everything else and then rebooted.

I could reboot Ubuntu in this state as many times as I wanted, however, the image provided has outstanding packages, so I ran sudo apt update and sudo apt upgrade -y which succeeded. After rebooting, I’d allow Ten64 to boot normally, which then powered off with the following messages being spit out via the serial port:

... is now current device
Scanning nvme 0:f...
** Unable to read file / **
Found EFI removable media binary efi/boot/bootaa64.efi
device 0 offset 0x580000, size 0x40000
SF: 262144 bytes @ 0x580000 Read: OK
device 0 offset 0x600000, size 0x40000
SF: 262144 bytes @ 0x600000 Read: OK
TEN64 ft_board_setup start, blob 0000000090000000
INFO:    RNG Desc SUCCESS with status 0
INFO:    result ece7fbf0d7a1f6c5
TEN64 ft_board_setup end
Card did not respond to voltage select!
mmc_init: -95, time 18
Scanning disk esdhc@2140000.blk...
Disk esdhc@2140000.blk not ready
Scanning disk nvme#0.blk#0...
** Unrecognized filesystem type **
Found 4 disks
TEN64 ft_board_setup start, blob 0000000087f00000
TEN64 ft_board_setup already run, not doing anything
BootOrder not defined
EFI boot manager: Cannot load any image
840024 bytes read in 1 ms (801.1 MiB/s)
TEN64 ft_board_setup start, blob 0000000087ee7000
TEN64 ft_board_setup already run, not doing anything
Could not get variable storage info: Unsupported
Could not create MokListRT: Unsupported
Could not get variable storage info: Unsupported
Could not create MokListXRT: Unsupported
Could not get variable storage info: Unsupported
Could not create MokListRT: Unsupported
Could not get variable storage info: Unsupported
Could not create MokListXRT: Unsupported
Something has gone seriously wrong: import_mok_state() failed: Unsupported
poweroff ...
INFO:    PSCI Power Domain Map:
INFO:      Domain Node : Level 2, parent_node -1, State ON (0x0)
INFO:      Domain Node : Level 1, parent_node 0, State ON (0x0)
INFO:      Domain Node : Level 1, parent_node 0, State OFF (0x2)
INFO:      CPU Node : MPID 0x0, parent_node 1, State ON (0x0)
INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)

The only recourse is to boot back into the recovery, and repeat steps.

Is this expected, and if so, how would one update Ubuntu 21.04?

2

Ubuntu recently added secure boot to their images, which the Ten64 firmware doesn’t support yet (once we rebase onto the latest U-Boot most of these issues should go away)

The ‘manipulator’ script baremetal-deploy runs replaces the secure boot ‘shim’ loader with plain GRUB as the ‘default’ EFI application, but the kernel upgrade puts the shim loader back. Doh!

The quickest workaround is to use the recovery firmware to move GRUB back into the default boot path:

mount /dev/nvme0n1p15 /mnt
cp /mnt/EFI/ubuntu/grubaa64.efi /mnt/EFI/BOOT/BOOTAA64.EFI
umount /mnt
/sbin/reboot

I’ll have to check if there is a way to prevent Ubuntu from ‘reinstalling’ the secure boot shim, if there is I can simply update the manipulator script to do that.
(edit: looks like removing the shim-signed package will do exactly that)

The other possibility is that we change the boot firmware to search for the ‘plain’ GRUB binary ahead of the default/standard BOOTAA64.EFI.