I had this issue when migrating to a new larger NVME a few years back, where there was technically 2 EFI partitions and it would fight which one was correct. I eventually just had to randomly nuke an EFI cause I wasn’t sure which one it was using.
Then my most recent was with the secure boot key update, windows would fail to update. By that I mean it would install updates, and then fail to update and rollback. So it never became unbootable, it just would stupidly keep trying the same update. So I investigated into it.
I found that when I did work about a year ago I expanded my EFI partition. Since EFI’s can’t be expanded that involved backing the partition up, nuking it then making a larger partition.
I apparently never marked the partition as an “EFI” ID when I did this, so it was marked EFI by type, but not via type id.
I never caught the issue because grub didn’t care that it lacked the proper typing, it knew where windows was, the EFI was “proper” in concept that it contained the right files to boot, and windows while didn’t accept it as an EFI, also didn’t care it didn’t actually have an EFI so it would just silently fail on any update events to it. It wasn’t until the update was pushed that forced the master key to change that it actually started to show signs of failing.
I was amazed that there was no warnings at all that the currently booted system has no valid EFI partition. It was insane it was even able to boot in the first place.
I had this issue when migrating to a new larger NVME a few years back, where there was technically 2 EFI partitions and it would fight which one was correct. I eventually just had to randomly nuke an EFI cause I wasn’t sure which one it was using.
Then my most recent was with the secure boot key update, windows would fail to update. By that I mean it would install updates, and then fail to update and rollback. So it never became unbootable, it just would stupidly keep trying the same update. So I investigated into it.
I found that when I did work about a year ago I expanded my EFI partition. Since EFI’s can’t be expanded that involved backing the partition up, nuking it then making a larger partition.
I apparently never marked the partition as an “EFI” ID when I did this, so it was marked EFI by type, but not via type id.
I never caught the issue because grub didn’t care that it lacked the proper typing, it knew where windows was, the EFI was “proper” in concept that it contained the right files to boot, and windows while didn’t accept it as an EFI, also didn’t care it didn’t actually have an EFI so it would just silently fail on any update events to it. It wasn’t until the update was pushed that forced the master key to change that it actually started to show signs of failing.
I was amazed that there was no warnings at all that the currently booted system has no valid EFI partition. It was insane it was even able to boot in the first place.