'grub_is_cli_need_auth' not found, how to resolve?

Hy!

Have here an older install of TW-KDE on an USB-stick, that came back from a zypper dup in DEC-2024 (had no time to repair yet…) with the error in the Topic, I guess Grub is broken.

Am I correct that I need to chroot into the system partition of the stick and re-install Grub?

And current How-to for TW on this?

I found these:

Need to repair GRUB

But not sure if they (still?) work (at all?).

Any help appreciated!

PS: Boot is legacy, installation is EXT4 for / and /home…

The bootloader location configured in your system does not match the location from which BIOS loads bootloader. You need to fix it, otherwise you will still be reinstalling in the wrong place.

Hmm, any suggestions? I boot this TW from the USB-stick on different machines from time to time. Doesn’t boot on various machines now, I tried 3 different…

And why do you expect any difference?

Start YaST, check bootloader location, make sure it is correct.

This may give some hints…
https://bugzilla.suse.com/show_bug.cgi?id=1234004

Hmm, the USB-stick does not boot, how to start YaST?

Quoting your own post:

When I boot the USB-stick, all other HDDs/SSD are disabled in BIOS or there are no other disks at all present in the notebooks used for booting. So it is unclear to me why the MBR should be on another disk at all…

When I chroot into the USB-stick you want me to run YaST from CLI and check where the MBR has been writen during the last zypper dup, correct?

I wanted to do the chroot on a computer with TW installed anyway, not in one of the notebooks booting a rescue-CD, that should work?

Show /etc/default/grub_installdevice.

Run bootinfoscript and upload RESULTS.txt to https://paste.opensuse.org/

OK, on my TW machine I did:

# fdisk -l  # determine /
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 870 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 61ABCC43-9F19-4545-84DC-E89ECAE21CE7

Device         Start       End   Sectors   Size Type
/dev/sda1       2048     18431     16384     8M BIOS boot
/dev/sda2      18432 310226943 310208512 147.9G Linux filesystem
/dev/sda3  310226944 972578815 662351872 315.8G Linux filesystem
/dev/sda4  972578816 976773134   4194319     2G Linux swap

...

Disk /dev/sdf: 57.28 GiB, 61505273856 bytes, 120127488 sectors
Disk model: Ultra Fit       
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2ab74234

((ooops, the info that /dev/sdf1 is / on the USB-stick got lost in copy&paste…))
Then I did:

# mkdir /mnt/usb-stick
# mount /dev/sdf1 /mnt/usb-stick/
# mount --bind /dev /mnt/usb-stick/dev
# mount --bind /proc /mnt/usb-stick/proc
# mount --bind /sys /mnt/usb-stick/sys
# chroot /mnt/usb-stick/

and I see then:

# cat /etc/default/grub_installdevice 
/dev/disk/by-uuid/1c45fbf6-2bf2-40aa-a3f2-4e4f1f8ea0f3
activate
generic_mbr

This bootinfoscript is beyond my paygrade… :wink:

According to “YaST - Bootloader” the Boot Code Location is “/dev/sdf1”

I changed to “Write to Master Boot Record (/dev/sdf)”

and did


grub2-install /dev/sdf

Now the USB-stick boots again!

Many thanks for help!

Which is the exact reason why it failed to boot. grub2 loaded by BIOS did not match the grub2 modules installed in /boot.

That is until the next incompatible grub changes.

Sorry, no Ph.D. in GRUB-eomics here.

I didn’t change anything from default there and your post is not very enlighting what I should have done better…

You most certainly did. Your system is configured to install GRUB on partition (you did not provide enough information to allow us to identify which partition) and to have generic MBR code that loads GRUB from the active partition. At some point you manually installed GRUB in the MBR following "helpful’ advices, Internet search hits or whatever. GRUB is split in two parts that must match. When GRUB was updated, the part under /boot/grub was updated but the part in MBR not (the part installed on partition was). So when BIOS loaded outdated GRUB code from MBR and it attempted to load other parts from /boot/grub these parts did not match the loaded code.

At this point the easiest way to avoid similar problems in the future is to reconfigure your system and set MBR as GRUB location so it matches the current state.

With all due respect, I installed TW to the USB-stick and did zypper dup from time to time. Nothing else. Why should I? I use the stick now and then, e.g. to connect to hotel wifi or to test some hardware.

After a zypper dup the stick came back with a GRUB console, unbootable.

As I wrote above:

According to “YaST - Bootloader” the Boot Code Location is “/dev/sdf1”

I changed to “Write to Master Boot Record (/dev/sdf)”

before I did

grub2-install /dev/sdf

So what can I do better this time? :slight_smile:

Just a guess, as i don’t install any grub anywhere on MBR disks except on one or more partition(s), and only use USB sticks for installing .isos, or for filesystems on partitions for storing data, not operating system installations equivalent to internal storage device installations:

/dev/sdf only applies to your USB stick on some systems, not on others, where it may be any of /dev/sdb, /dev/sdc, /dev/sdd, /dev/sde, /dev/sdg, etc., depending on how many HDDs, SSDs and/or USB card readers are in that system, and BIOS setup ordering among storage devices.

Hi mrmazda, while this might be correct: The USB-stick booted and was fine until after the next zypper dup yesterday. Afterwards I see on boot a GRUB message :

on two other notebook trying to boot the USB-stick I see “Welcome to GRUB” for some milliseconds, before rebooting (boot loop).

So will have to fix Grub again with chroot, but what to do different this time?

Check first for “removable” in Grub*'s man pages, and/or visit the WWW via search engine.

I rarely have need for USB stick booting, as all my PCs are multiboot. Thus for most cases, all I need to do if one installation refuses to boot, is boot something else, from the same Grub menu, from which to repair, using chroot, or otherwise.

This worked without any Google, manpage or alike for years and I have some more TW USB-sticks to boot from, just doing fine without any magic sauce. Sigh…

As mentioned above: the machines are legacy BIOS, not UEFI.

New chroot:

fdisk -l  
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 870 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 61ABCC43-9F19-4545-84DC-E89ECAE21CE7

Device         Start       End   Sectors   Size Type
/dev/sda1       2048     18431     16384     8M BIOS boot
/dev/sda2      18432 310226943 310208512 147.9G Linux filesystem
/dev/sda3  310226944 972578815 662351872 315.8G Linux filesystem
/dev/sda4  972578816 976773134   4194319     2G Linux swap

...
Disk /dev/sde: 57.28 GiB, 61505273856 bytes, 120127488 sectors
Disk model: Ultra Fit       
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2ab74234

Device     Boot    Start       End  Sectors  Size Id Type
/dev/sde1  *     4263936  67325951 63062016 30.1G 83 Linux
/dev/sde2       68050944 117202943 49152000 23.4G 83 Linux

then:

# mount /dev/sde1 /mnt/usb-stick/
# mount --bind /dev /mnt/usb-stick/dev
# mount --bind /proc /mnt/usb-stick/proc
# mount --bind /sys /mnt/usb-stick/sys
# chroot /mnt/usb-stick/

In YaST → Bootloader is complains that udev device /dev/sdf is unknown (from last chroot, apparently)

So what is the correct choice here for the Boot Code Location? :slight_smile: