Bug 1104850 - Wrong prefix in GRUB at aarch64
Wrong prefix in GRUB at aarch64
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader
aarch64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: Alexander Graf
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2018-08-14 18:42 UTC by Matwey Kornilov
Modified: 2019-04-22 17:53 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Matwey Kornilov 2018-08-14 18:42:13 UTC

I see at the following two JeOS the similar issue.


The following happens with GRUB in misses its config.

                            GNU GRUB  version 2.02

 Minimal BASH-like line editing is supported. For the first word, TAB
   lists possible command completions. Anywhere else TAB lists possible
   device or file completions.


The issue is that the prefix is predefined to (hd0)/efi/boot, instead of (hd0,gpt1)/efi/boot.

There is workaround for the issue:

> set prefix='(hd0,gpt1)/efi/boot'
> normal
Comment 1 Alexander Graf 2018-08-15 12:42:12 UTC
This is most likely a U-Boot bug. Which version of U-Boot are you using?
Comment 2 Matwey Kornilov 2018-08-16 15:31:55 UTC
I use 2017.03 and 2017.09 correspondingly. The issue here that I was able to boot JeOS with the same binary u-boot at EspressoBin in the past. Could you please share the u-boot commit which fixes the issue you meant? Probably, some update in Grub triggered this bug.
Comment 4 Alexander Graf 2019-01-10 07:26:54 UTC
Could you please just try with a recent upstream U-Boot version? I don't remember exactly which commit fixed it, but there were a lot of fixes in the last 1 1/2 years on device path logic which is what results in the breakage you're seeing.

If it helps, there is a person in the #u-boot irc channel on freenode (pulecaca) who has a similar issue on his espressobin and is working on making a more recent upstream u-boot version work on it.

The bug here really was in U-Boot's device path handling. so I see little we can/should do on the grub side. Hence I'll close the bug for now. Please reopen if you still see an issue with a recent U-Boot version.
Comment 5 Matwey Kornilov 2019-04-22 16:02:11 UTC
I've found that the same issue is for BeagleBone Black when I try to use u-boot 2017 with Tubmleweed JeOS. I think this can become an issue for our users when they will make dist update to something bringing new grub2. The u-boot loader image is only flashed at KIWI stage, so its version is fixed forever for end user and not related to u-boot package version is OS.
Comment 6 Matwey Kornilov 2019-04-22 17:53:32 UTC
I've bisected that the following commit fixes the issue from u-boot side: