> This was caused by installing Debian, then restoring a full backup from the old laptop, which didn't use EFI yet, over the root filesystem.<p>This really isn't guaranteed to work. I'm surprised nothing else broke! This is why my laptop migration process looks something more like this:<p>1. Restore home directory 2. Restore /etc (taking care not to overwrite anything hardware-specific) 3. Install the same list of packages that were installed on old machine
There is rarely a need for GRUB on EFI systems. Create a unified kernel image, create a fat fs gpt partition, mount on /boot/efi and put the image there, then add it to efibootmgr. Sign and use systemd-stub and Shim for Secure Boot. No GRUB, no systemd-boot, just EFI firmware -> initrd -> kernel. Tried and tested on Debian 12 and Trixie. Can also dual boot Windows if the machine has a way to select an OS on boot, something most systems have these days.<p>I think the work required to do the above vs just using the standard installer is what holds people back, but it's hard to mess up once it's done.
Wasn't the 500 mile email [1] caused by something similar, i.e. software loading a config file made for a newer version loading it and behaving in an undesirable fashion?<p>[1] <a href="https://www.ibiblio.org/harris/500milemail.html" rel="nofollow">https://www.ibiblio.org/harris/500milemail.html</a>
In the early days of UEFI being on PCs, I had to coach a TON of IT admins on the changes that were happening. Lots of them assumed that if you just dunked a drive image onto a machine, it would Just Work:tm: without having to add anything into the boot menu or other such things.<p>Watching Norton Ghost from 2002 run on a brand new Skylake laptop was something else. Ghost still doesn't support EFI systems properly, but EFI systems became a lot less hardass about their boot menus after a while.
I hit something similar recently, after installing Debian 12.8 (I think it was 12.8) on my wife's computer, where another Linux version was already installed.<p>I didn't find the root cause. I know it's a system on which SecureBoot used to be on and was working fine (with an older Debian version). Anyway after installing Debian 12.8, somehow I ended up at that infamous GRUB boot prompt, unable to boot the system.<p>I "fixed" it by disabling SecureBoot from the UEFI: not my proudest fix but I didn't feel like troubleshooting what had gone wrong (which was certainly simple and dumb). So Kudos to TFA's author for spending the time to troubleshoot and solve a much more complicated issue.
This reminds me of why Firefox now refuses to load profiles previously used on newer versions of itself: it's generally unreasonable for older versions of programs to correctly support configuration data from newer versions of them.
I had a different GRUB2 upgrade breakage a couple years ago. Mine related to a hybrid ISO/MBR disk (extremely common for distro install disks); previously grub had silently just used the obvious partition table, but the new grub insisted on erroring out due to ambiguity. I had to do some really hairy "dd to back up the MBR; wipefs; dd to restore the MBR" to get a working system again; luckily I didn't lose power.<p>(note that many distros normally don't upgrade grub after the first install to avoid exactly this kind of breakage, but there was some "important security crap" at the time)
I don't use UEFI often. Last night after installing a new kernel, I noticed that updating-grub failed to add that kernel to (either of 2) GRUB bootlists. After consulting a Boot-Repair report, I found that deleting a partition on another drive flagged as 'boot,esp' resolved that problem. Moral: 1) don't leave skeletons in closets.