Grub-install: error: failed to register?

Folks:

Keep seeming to have issues with this 20.10 edition of U-MATE . . . today, back into the "grub" "failing to update properly" vis EFI boot . . . keeps happening over and over . . . . Bug report filed.

https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1894242

Today both of my ubuntu 20.10 installs had "grub" packages to upgrade, Lubuntu & U-MATE . . . over the last year?? upgrading grub in ubuntu has managed to wipe the grub listings of the other systems I have installed, leaving only U-MATE to boot up. I've had to use SG2 disk to boot into OpenSUSE to repair the damages done by the ubuntu grub process . . . it keeps happening.

Today I ran the Lu apt dist-upgrade and it had a few grub packages to upgrade . . . I ran them . . . I rebooted and, yep, grub list was again wiped . . . and into U-MATE we went. I ran apt over here and it showed the same grub packages . . . since the damage was already done I ran it. This time it actually showed errors with "grub-install" . . . . I may have other bug reports on this problem, but it seems like ubuntu's grub doesn't get "EFI"??? Devs haven't gotten this issue addressed as of this date?? I copied the data in the console:

Setting up grub-pc (2.04-1ubuntu30) ...
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-42-generic
Found initrd image: /boot/initrd.img-5.4.0-42-generic
Found linux image: /boot/vmlinuz-5.4.0-9-generic
Found initrd image: /boot/initrd.img-5.4.0-9-generic
Found Manjaro Linux (20.1) on /dev/sdb7
Found openSUSE Tumbleweed on /dev/sdb8
Found openSUSE Tumbleweed on /dev/sdb9
Found Mac OS X on /dev/sdc2
Found Ubuntu Groovy Gorilla (development branch) (20.10) on /dev/sdc7
done
Setting up grub-efi-amd64-signed (1.151+2.04-1ubuntu30) ...
Installing grub to /var/lib/grub/esp.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Installing grub to /var/lib/grub/esp.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Installing grub to /var/lib/grub/esp.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Setting up shim-signed (1.43+15+1552672080.a4a1fbe-0ubuntu2) ...
Installing for x86_64-efi platform.
grub-install: warning: Cannot set EFI variable Boot0000.
grub-install: warning: efivarfs_set_variable: writing to fd 8 failed: Invalid ar
gument.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Inval
id argument.
grub-install: error: failed to register the EFI boot entry: Invalid argument.
dpkg: error processing package shim-signed (--configure):
 installed shim-signed package post-installation script subprocess returned erro
r exit status 1
Processing triggers for libc-bin (2.31-2ubuntu1) ...
Processing triggers for systemd (246.2-1ubuntu1) ...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for install-info (6.7.0.dfsg.2-5) ...
install-info: warning: no info dir entry in `/usr/share/info/automake-history.in
fo.gz'
Errors were encountered while processing:
 shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Whenever I have problems with grub, I try the Boot Repair Disk and most times it fixes the problem.

https://sourceforge.net/p/boot-repair-cd/home/Home/

OK . . . well I did post that I had to use SG2 to fix the problem, several times in recent weeks . . . the point is that it appears that "ubuntu" updates to grub are wiping out all other connections via grub except itself . . . and it's been happening for awhile . . . .
It shouldn't have to be that with regular apt updates that we should expect grub to be wiped and have to use SG2 or boot-repair-cd every month or whenever it happens . . . ????