Updated one of my TW machines earlier today, 20201028 -> 20201029, zypper dup completed without any problem, issued “shutdown -r now” as is my normal habit even if a reboot isn’t strictly needed.
Machine rebooted, did it’s POST, gets to “GRUB loading” and then reboots, does it’s POST, gets to “GRUB loading” and then reboots… hmm… odd, I assume if I’d left it then it would continue that loop forever…
The reboot was immediately after the “GRUB loading” text, no delay whatsoever, indeed if I didn’t know the text displayed was “GRUB loading” I probably would have needed to see it two or three times before being able to read it!
Not really knowing what to do in this instance, and not having seen this before, I opted to boot from a live USB and reinstall GRUB. That cured the problem.
Rather hesitantly I did a zypper dup on my second TW machine, again 20201028 -> 20201029, no problem at all, (I’m pleased to say).
Anyone care to speculate what may have caused the endless reboot loop, I could understand being dropped to a rescue shell, or the system just hanging, but the reboot loop rather surprised me. Time of year or phase of the moon perhaps…
That is probably bug 1178278
Two of my systems still boot after that bad update. A third system just locks up during boot.
Actually, of the two that still boot, one has grub installed in the MBR and that’s probably not affected. The other has grub installed in a partition boot record, so I think it is just good luck that it still boots – but I do have an alternative way of booting it if that fails.
The third system has grub installed on a partition boot record, and just locks up. But I’m okay if I set the active partition to Leap 15.2 on that computer, and boot Tumbleweed from the Leap 15.2 boot menu. I’ll wait for it to be fixed, which I expect to be soon.
Maybe, thanks…
Although there’s no mention there of the GRUB loading → reboot → GRUB loading … loop I was seeing.
I think it was actually the 20201026 snapshot that broke grub. If grub is installed in a PBR, it uses block lists to access “core.img”. So it could still work by referencing disk blocks assigned to a file that no longer exists – but it will stop working when those free disk blocks are reassigned to another file. In your case that reassign probably happened with the update to 20201029. In my case, those free disk blocks have not yet been overwritten (for the system that still works).
You are using data from a disk block that has since been overwritten with other data. What happens is unpredictable.
It was, on both machines, so I guess I was lucky on one of them, think I’ll reinstall GRUB on that one too.
Unpredictable… indeed 