efi: Froze efi_rts_wq and disabled EFI Runtime Services

[geole0]

Hello
I think this problem has been around for many years.
For ubuntu, I only found this bug (https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1777228) which was closed.
I chose to open a new one.

The context is an ubuntu 20.04 installation
": Ign: 1 cdrom: // Ubuntu 20.04.1 LTS _Focal Fossa_ - Release amd64 (20200731) focal InRelease"

The incident noted in the DMESG is as follows
efi: Froze efi_rts_wq and disabled EFI Runtime Services

The contents of the Boot-install.txt file show the details.

In such an environment, I suggest you do the following development:
- Tell the user that the EFI variables cannot be read and that the secure mode will not be activated.
- Write the grubx64.efi file in the boot directory instead of the shimx64.efi file, renaming it also bootx64.efi. probably write the grub.cfg file there as well.
 It seems to me the minimum.

- Eventually
if the microsoft boot structure is not present, create it
 and transfer the corrected standard boot structure to it and rename the bootx64.efi file to bootmgfw.efi
It also seems possible to me.
For more details, please watch this French discussion carefully: https://forum.ubuntu-fr.org/viewtopic.php?id=2061619

-If the windows boot structure is present and the BKbootmgfw.efi file is missing and if you are brave, you can ask for permission to change the way you boot.
If it is granted to you, you must then duplicate the bootmgfw.efi file in BKbootmgfw.efi before starting the transfer of the files from ubuntu.

You will also find the attempt to repair "boot-repair" with a very large trace which encounters the same problem.

Thank you for improving the situation.

[geole0 (geole0)]

Hello

I remind you that at startup, the EFI computer is not in SECURE mode.
There is therefore no reason to require that the secure mode be installed.

 There is an installation option
                --n0-nvram
 Use it!

It is easy to do a read command of the NVRAM to see that it is refused in reading. This implies that writing will probably not be possible!

You could even set the noefi option in the options of the /etc/default/grub file !!!

Thank you for improving the situation.

This attached file contains the boot-repair trace with the content of dmesg trace