I can’t boot with this error coming up right below the first line “Loading Linux 5.8.0-1-default …”
"error: verification requested but nobody cares:
(hd2,gpt3)/boot/grub2/x86_64-efi/linux.mod.
Loading initial ramdisk …
error: verification requested but nobody cares:
(hd2,gpt3)/boot/grub2/x86_64-efi/linux.mod.
Press any key to continue…"
In addition, I tried to boot from live USB but today it’s not recognized by my machine even though it worked before.
I can boot live DVD, I have a couple working ones from five years ago, and they are able to see and mount my internal drives, including the root partition, so if I need to manually switch or disable something it should be possible. They also do not recognize USB drives when inserted and dmesg complained about hub errors, inability to assign address or something like that - I need to boot into live DVD again to see exact errors, there were a lot of lines there. USB keyboard and USB mouse receiver work, however.
So, is my “verification requested” boot failure caused by possible hardware problem with USB hub or is it latest tumbleweed update got screwed up or something? By USB hub I mean something inside, not anything I plug externally.
It’s my primary machine so it’s like my life depends on it working.
Edit: I should have put thread title in quotes - now it looks like nobody cares about my requests but it’s just an error message. It seems I can’t edit the title, sorry.
Additional info - turns out that it’s only USB3 ports don’t work on my machine, a few old USB2 ports are okay and plugging into one of them I was able to boot from live Ubuntu stick, which means I can create a live OpenSuse stick, too, or live DVD, for that matter.
Do you have secureboot enabled in your UEFI?
Will you be able to boot your openSUSE system when you disable secureboot in your UEFI?
May be your problem is related to https://www.suse.com/support/kb/doc/?id=000019673.
If you can boot the openSUSE Tumbleweed rescue system from the installation media you could try to chroot into your installed system and update GRUB2.
Regards
susejunky
Secureboot is disabled in my BIOS.
Occasionally there’s a weird screen that shows up before booting and says something about performing shim management but I can’t see it today. It always goes away on its own and I have no idea how to call it up.
Right now I’m in openSUSE tumbleweed rescue booted from USB drive. How can I chroot and upgrade Grub2 from here?
All the following is based on the assumptions that
- you are using the rescue system from the openSUSE Tumbleweed installation media and are logged in as “root” (no password needed)
- your installed openSUSE Tumbleweed system uses ext4 as root filesystem
- you have a working network connection (cable connection should be setup automatically, for WLAN connections you can use nmtui
or nmcli)
Mount the root partition of your installed openSUSE Tumbleweed system with
# mount /dev/xxxx /mnt
The “xxxx” depends on your system. It might be something like “sda1” or “nvme0n1p1”.
Mount your ESP with
# mount /dev/yyyy /mnt/boot/efi
Again “yyyy” depends on your system. Be careful if you use several ESPs (e.g. for MS Windows and Linux) to choose the correct one.
# parted -l
or
# lsblk -f
can help you to find the correct values for “xxxx” and “yyyy”.
Then do
# mount -o bind /dev /mnt/dev
# mount -o bind /dev /mnt/sys
# mount -o bind /dev /mnt/run
# mount -o bind /dev /mnt/proc
# chroot /mnt
Then update your installed openSUSE Tumbleweed system
# zypper dup
This will probably install the latest GRUB2 automatically. However if you want to be really sure you can re-install GRUB2 with
# grub2-install
Then update the GRUB2 configuration file
# grub2-mkconfig -o /boot/grub2/grub.cfg
Check your UEFI NVRAM with
# efibootmgr -v
You can adjust the boot order with
# efibootmgr -o nnnn,mmmm
where nnnn and mmmm are the Bootnnnn displayed by efibootmgr. Then exit the chroot environment
# exit
and reboot your system …
… and if you are lucky your system will start up as normal. If not, please report any errors here.
Regards
susejunky
I used chroot instructions here: https://www.suse.com/support/kb/doc/?id=000018770
Didn’t get any errors and I see all my files from “root” mounted in /mnt but the last command, “mount -a”, does not show any results. Nevertheless, “ls /home/linux” (home on live USB) gives “no such file or directory” in the terminal window I used to chroot. Altogether I think chroot was successful and I’ll keep that window open just in case.
What’s next?
Just saw the post above, will read through.
I didn’t do mounting “ESP”. I don’t know what it means but I guess it’s a small, 150mb partition that is reported as “vfat” or “boot” or “esp”, depending on what program is used.
Just in case, I installed grub2 etc and let’s see what happens after reboot. If it doesn’t work I’ll do chroot again. It’s not persistent, is it?
This will just mount all filesystems given in fstab (of your installed openSUSE Tumbleweed system).
So if /home (of your installed openSUSE Tumbleweed system) resides on a separate partition you should - after mount -a completed - be able to do
ls /home/USER
where USER must be a valid user name of your installed openSUSE Tumbleweed system.
Regards
susejunky
ESP means EFI system partition and should be formatted in FAT32 (150MB sounds reasonable) and it is the place where the bootloader files have to go.
So if you did not mount it grub2-install will not work correctly.
Regards
susejunky
My original system booted fine so that doesn’t matter much anymore. Apparently mounting ESP wasn’t strictly necessary.
Big thanks for your help, it’s very much appreciated.
So, to recapitulate - I needed to boot live rescue Tumbleweed CD, do the chroot, and update grub2 and its configuration files. Exact commands are impossible to remember but this thread is here for reference anyway.
Do I need to do anything to prevent such mishaps in the future?
Recently there have been changes to GRUB2 in openSUSE which - as far as i understand - caused problems on some systems (i did not experience any problems).
I think the best you can do is to monitor some of the openSUSE mailing lists (https://lists.opensuse.org/opensuse-factory/, https://lists.opensuse.org/opensuse-support/, https://lists.opensuse.org/opensuse/). You will not have to actively participate but if there are any problems with a Tumbleweed snapshot then those are the places where they will be discussed quite early.
Regards
susejunky
Having secure boot disabled is (part of) the condition to trigger the failure.
That bug report does not give much information on the cause of the problem so far.
However on my system (openSUSE Tumbleweed 20200819) secureboot is disabled and i never saw the error described by OP.
Regards
susejunky
The patch I linked above arrived with 20200823. That is, it’s not a random failure, it’s due to this patch.
I have been able to reliably reproduce this problem in a virtual machine.
If secure-boot is enabled, it does not boot at all (it silently does nothing).
If secure-boot is disabled, you get this problem.
If you run into the problem, then hit ‘e’ on the grub menu line.
Scroll down until you find a line that starts with “linux”.
Change that linux to “linuxefi”
Go down one or two lines to find “initrd” and change that to “initrdefi”
Use CTRL-X to continue to boot.
To prevent this from happening in future:
Either
(1) edit “/etc/default/grub”
Make sure that there is a line
GRUB_USE_LINUXEFI="true"
If that line is commented out, then uncomment it.
Run
grub2-mkconfig -o /boot/grub2/grub.cfg
or
(2) Go into Yast bootloader, and uncheck the box “Enable Secure Boot Support”
This seems to be a change due to the new shim.
When booting with shim, you can only use “linuxefi”. You cannot use “linux”.
This supposedly changed with grub2.04, where grub itself can now use either linux or linuxefi, whichever seems appropriate. That’s probably why the “nobody cares” part of the message is there. But apparently the new shim does care and refuses to allow the linux command to be used, even if secure-boot is disabled.
That explains why i was not hit by this.
Regards
susejunky
