This is an Acer netbook, a year or two old, no legacy BIOS, bought with Win10 installed. It has a hardwired SSD designated mmcblk0 and I installed another SSD which is /dev/sda. Stretch installed with no problem, and gives me a Windows entry in its menu. It's been OK for about 18 months, so I thought I'd try the upgrade in partial preparation for upgrading my Stretch server when I've worked up the courage.
Read the docs, did some minor cleanup, did the partial upgrade, no network, rebooted, OK. Did the full upgrade, all looked good, just the minor issue that the machine won't boot now. I can get into Win10 through the BIOS menu OK. On startup, it flashes a message for a few milliseconds, then restarts, and does this indefinitely. I eventually deciphered the message: System BootOrder not found. Initializing defaults Creating entry<xxxx> with <location of shimx64.efi> Reboot <xxxx> increments on every attempt. I've burned a Buster Netinstall USB stick and got to the stage where it opens a shell into the root partition. As far as I can see, the correct files (grubx64.efi, shimx64.efi, grub.cfg), are in the correct place (/boot/efi/EFI/debian/). The installer has chrooted into the SSD root, so I tried all the usual grub rebuilding/reinstalling, no success. I'm guessing that the partition layout, created by the stretch installer, of EFI stuff on sda3 and root on sda4 are unexpected, and the boot code is looking in the wrong place for shimx64.efi. I recall grub upgrades a few years ago that broke booting with a separate /boot partition, because someone hadn't allowed for it, I wonder if something similar is happening here. /boot/efi does exist under /, but it's just a mount point for /dev/sda3. The Buster installer certainly knows that, and mounts it correctly in the rescue mode. efibootmgr is active in this chroot, and returns sensible results, so the problem ought to be something fairly trivial. It's only a workstation, so there's nothing irreplaceable on it, but there is some stuff I'd like to keep. I've booted a Knoppix, and will copy what I want off and I can install from scratch if necessary. But I'd like to fix it if possible, and the Net really isn't being very helpful. This would have been a two-minute job with lilo and tomsrtbt, maybe half an hour with grub/grub2 and I've been hacking away at this for half a day so far. I think it's called progress... So, can anyone see at a glance what is wrong here? If not, where I should be looking next? I've found suggestions to make a new custom entry in the BIOS boot manager, but that doesn't seem to be an option here. OK, a bit further: if I use efibootmgr from the rescue chroot to set the next boot to one of these new entries, the computer boots OK. However, if I set the boot order to put one of these entries first, on the next boot, we're back to the same problem. Something has overridden my choice of boot order and put /dev/sda back as the first boot choice, which doesn't work. I suspect it's because the BIOS boot order puts this drive first. But it was always like that before the upgrade, and it worked then. -- Joe