[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Upgraded stretch to buster, not booting



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


Reply to: