Recently grub updated to version 2.06 (previously was 2.04) – in Tumbleweed.
This is the kind of error you can get if there is a version mismatch between the grub installed in a boot sector and the grub installed under “/boot/grub2” .
The “unknown” might only mean that grub has been unable to identify the file system because of the first failure. The file system might not be damaged. You need to boot rescue media to check that.
From what is shown there, you cannot tell whether there is a “/home”.
You have two Tumbleweed installations (on sda and sdb) and both sda and sdb are theoretically bootable. Your BIOS is most probably configured to boot from sda; sda1 is BIOS boot partition.
We cannot know which of two installations is the correct one. Boot from any live medium, mount TW partition where you performed update mentioned in original post and show output of
There is normally a secondary HDD drive, which I unplugged in the very beginning of the debugging to exclude this potential source of errors. Should I plug it in now again?
(I wonder where grub knows disks by /dev/sdX names in this very, very early stage of the boot process… but tbh I have no idea of the grub thing at all).
If it’s listed in fstab I’d definitely say yes!
I have had a similar issue some time ago. After unplugging an external backup drive which I have added to /etc/fstab for more convenience, system would only boot to rescue mode, just as yours.
Worth a try at least, I think.
Huh? So you changed configuration which means we are now chasing wild goose. When you have a problem you need to present evidences of this problem, not of something entirely different.
Should I plug it in now again?
Educated guess is this other disk is actually /dev/sda so the last grub update installed bootloader on this disk. This is sort of confirmed by the fact that grub.cfg sets default root to hd1, which means disk with /boot/grub2 is seen as the second disk. So yes, plugging it in may allow you to boot. Again, it depends on BIOS settings.
I wonder where grub knows disks by /dev/sdX names in this very, very early stage of the boot process
grub does not. This file is for tools that install grub. And yes, /dev/sda is rather poor choice because it does not unambiguously identify disk. Better would be by-id reference.
As I wrote, I unplugged the additional HDD only AFTER the error occured. Plugging it in again doesn’t help anything, I end up with the very same error as in the opening post.
Apparently the SSD is GPT (no idea why, I thought that’s only necessary for large disks…) and I’m not sure the mobo supports EFI (older Gigabyte Celeron miniITX board iirc).
Would be nice to know how to fix this “I install grub whereever I want” behaviour for TW updates. I have remote machines that could be severely harmed by such an event.
Yes. And you collected diagnostic information AFTER you unplugged additional HDD. And you never mentioned that you had additional HDD before I hinted at it. How do you expect someone to troubleshoot the problem without complete picture?
As I already told you - replace /dev/sda in /etc/default/grub_installdevice with stable device name. Like /dev/disk/by-id/ata-KINGSTON_SS200S330G_50026B72590E11D9 (according to previous BIS results; verify that it actually points to your correct disk). This makes sure grub is always installed on the correct disk. Then run “update-bootloader --reinit”, reboot and change boot order back in BIOS.
Without this modification grub will continue to be installed on “another HDD” as long as this HDD remains /dev/sda. You can theoretically replace /dev/sda with /dev/sdb, and it will work now, but experience shows that after some time users forget about it, add new disks and disk names change …