C'est un espace de la NVRAM qui est exposé là sur /sys/firmware/efi/efivars/ ou un espace de la partition ESP ? (partition EFI System, d'une taille généralement de 500 Mo si on laisse Ubuntu la créer, qui est habituellement sur /dev/sda1)
Les variables EFI sont en NVRAM, c'est la façon dont tous les réglages UEFI sont stockés.
La taille dépend du système, et additionner la taille des variables ne suffit pas, ça peut être fragmenté (mais l'UEFI doit essayer de défragmenter si nécessaire).
On est donc plus sur un pb lié au serveur, que lié à l'OS (j'aurais le même bug avec un autre Linux, le fait que cela se soit produit lors de la mise à jour de début décembre n'est pas lié à la mise à jour proposée)
Il y a eu des vérifications ajoutées dans le kernel car certains PC portables se sont retrouvés HS quand il ne restait plus assez d'espace libre : la protection peut être désactivée avec "efi_no_storage_paranoia", mais il faut redémarrer pour ça...
Avec une autre distribution, tout dépend si elle lance efibootmgr automatiquement lors de mises à jour ou pas. La commande a peut-être supprimé l'ancienne entrée Ubuntu, avant d'échouer à en recréer une nouvelle
Est-ce que tu as essayé de supprimer les entrées de boot Windows avec efibootmgr ? Elles ne servent pas, et si ça fonctionne peut-être que la place libérée sera suffisante.
Sinon, tu peut essayer de copier EFI\ubuntu\shmix64.efi dans EFI\BOOT\BOOTX64.EFI puis tu active le boot sur le Fixed disk Boot Device 1 avec efibootmgr -o 5
Sur Fedora c'est le cas par défaut, et ça rajoute automatiquement l'entrée de boot pour pointer ensuite sur shimx64.efi, je ne sais pas si c'est le cas sur Ubuntu.
Si Boot5 corresponde bien à la partition EFI, ça pourrait effectivement fonctionner.