I have the same issue on bare metal (Ryzen 3600 on B550 MB) and --no-nvram also disables the error message by, presumably, *not* updating the EFI boot entries in NVRAM.
This was a working install and efibootmgr looked reasonable after attempting to upgrade grub-efi-amd64-signed:
I would swear those duplicates weren't present even after running efibootmgr *after* doing the grub-efi-amd64-signed upgrade. I can't identify *when* they were installed unless somehow they were masked until after I rebooted. In any case it seems *wrong* to have duplicate entries for the *same* operating system.
Perhaps this is a clue? Maybe the grub update is trying to install *new* entries when there are already entries present?
I have the same issue on bare metal (Ryzen 3600 on B550 MB) and --no-nvram also disables the error message by, presumably, *not* updating the EFI boot entries in NVRAM.
This was a working install and efibootmgr looked reasonable after attempting to upgrade grub-efi- amd64-signed:
[deneb:~]$ sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002
Boot0000* ubuntu
Boot0002* Windows Boot Manager
However, and I can't explain this, the boot entries are duplicated after rebooting (which, BTW, worked OK):
[deneb:~]$ sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0003,0004
Boot0000* ubuntu
Boot0002* Windows Boot Manager
Boot0003* Windows Boot Manager
Boot0004* ubuntu
I would swear those duplicates weren't present even after running efibootmgr *after* doing the grub-efi- amd64-signed upgrade. I can't identify *when* they were installed unless somehow they were masked until after I rebooted. In any case it seems *wrong* to have duplicate entries for the *same* operating system.
Perhaps this is a clue? Maybe the grub update is trying to install *new* entries when there are already entries present?