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 . . . ????

I have never had a regular update wipe out grub on any distribution or release. Other than my own tweaking I have not had a boot loader problem since the old LILO days. Could there be another reason that grub is failing to boot?
It looks to me like you are dual booting? In that instance I have removed one boot loader ( for you Ubuntu) and only used the the other boat loader (for you OpenSUSE). Then when Ubuntu installs a new kernel, boot into OpenSUSE and update grub there. Not an ideal solution, but it would work if only Ubuntu updates are giving you the problem. I did that for a different reason, that the OS that updates puts itself first in the boot order and I just didn't want to change that all the time. I now just use two laptops.

Thanks for the follow-up, albeit a day late, etc . . . had other problems with the U-MATE install and I moved on, it's now a Deb Bullseye . . . so I've lost track of the precise issue in this post. Problems with grub2 have been happening across the board of my various ubuntu installs.

So, yes, on the desktop this is a septet boot??? But a problem that seems like maybe it has to do with "shim" that wipes out grub menu?? I'm not the only person to have this or problems with grub2 in ubuntu, it goes back at least a year, and lately it even extended over into OpenSUSE distros as well.

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1863434?comments=all