Bug 1626844

Proposed as a Blocker for 29-beta by Fedora user bitlord using the blocker tracking app because:

 System fails to boot:
"Release-blocking images must boot"

Linking rawhide bug

Should the bug title say -52 or -54, not -51? AIUI, -51 works but both -52 and -54 do not (for you), right?

(In reply to Adam Williamson from comment #3)
> Should the bug title say -52 or -54, not -51? AIUI, -51 works but both -52
> and -54 do not (for you), right?

Thanks Adam, fixed it, c&p fail, sorry.

Yes, -51 is what I currently use and it works, and -52, -54 are not.

(In reply to Adam Williamson from comment #3)
> Should the bug title say -52 or -54, not -51? AIUI, -51 works but both -52
> and -54 do not (for you), right?

-54 worked for me in UEFI vm, but broke my bare metal desktop with dualboot (Fedora + Windows 10).

On VM, I've upgraded just grub2 from -51 (It was F29) and on bare metal, I've received the grub2-2.02-54.fc29 as part of upgrade from F28.

Frantisek: when you say "broke" - does it behave as Branko describes? Boots to the grub shell? Can you provide more details on the system? Thanks.

(In reply to Adam Williamson from comment #6)
> Frantisek: when you say "broke" - does it behave as Branko describes? Boots
> to the grub shell? Can you provide more details on the system? Thanks.

It actually might be something little bit different, I am still looking if I have any flash drive around to boot from Live, chroot and check what happened.

Before doing the upgrade I had Fedora 28 and Windows 10. After the upgrade, system stopped booting with some Windows 10 error message complaining about \Windows\system32\winload.exe .

If I choose to boot Windows directly from UEFI, it boots just fine. If I choose Fedora, it looks like it skips GRUB and dies trying to boot Windows with the Windows 10 bootloader error about \Windows\system32\winload.exe .

Well, I am hitting something else, I had to do a little of black magic to get it working, downgrading to -51 didn't help:

dnf downgrade grub2* --releasever=28
dnf remove efi-filesystem --releasever=28
dnf install shim-x64 efibootmgr --releasever=28
dnf reinstall grub2-efi shim --releasever=28
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Will create bug for that soon.

Created BZ for my problem: https://bugzilla.redhat.com/show_bug.cgi?id=1626862

Sorry for the noise here :)

I was testing this on Lenovo T440s. -53 and -54 dropped to the grub shell. I downgraded to some older version of I was using before, because I found it in DNF cache ;) Not sure which version is it from top of my head, though.

Can someone having this problem do the following at the grub prompt:
set pager=1
set

And then for each page, take a cell phone photo and post it? Ideally also I'd like to see the environment variables for working and non-working. So for the working case you'll have to interrupt the boot, type c to get to a prompt, then 'set pager=1', and then set and scroll and snap photos. And if you want, feel free to dial down the resolution on your cell phone camera app :-) smaller attachments. OH and while I'm at it, a dark closet or bathroom for taking laptop photos is often better, no glare.

As an alternative to cell phone photos, if you can compare all the environment key=value for the working and non-working case and note if you see anything that differs. Normally grub prompt means it can't find grub.cfg, so in particular I'm wondering about prefix= and root= values, if those are the same or different in the working vs non-working cases.

Discussed at 2018-09-10 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-09-10/f29-blocker-review.2018-09-10-16.01.html . We agreed to delay the decision on this one: it's clearly worrying, but we would like to figure out in more detail what's going on and what systems may be affected before deciding either way. We are actively attempting to gather this information, I will be posting more to this bug soon.

I did a couple of scratch builds of different possibilities to try and fix this while breaking anything else. If folks with affected aarch64 systems could try them, it'd be great. Here they are:

* https://koji.fedoraproject.org/koji/taskinfo?taskID=29603292
* https://koji.fedoraproject.org/koji/taskinfo?taskID=29603437

The first contains all the changes from -52, plus amartinez's fix for the x86_64 UEFI boot issue instead of Hans' that we shipped in -54.

The second contains only the bits from -51, plus the change that was intended to fix the aarch64 blocker bug (and one other that is a precursor for it). Other changes - including the ones I think caused all the x86_64 issues - were dropped.

It'd be useful to know how both of these work compared to -51 and to -54. Thanks!

d'oh, copy/paste fail: Please replace "affected aarch64 systems" with "affected x86_64 systems" in previous comment.

grub2-2.02-54.fc29 working as expected on an x220 laptop

Can affected folks also please test this build from pjones:

https://koji.fedoraproject.org/koji/taskinfo?taskID=29605028

? It has a change he believes may address the 'boot to grub shell' failure case.

Just as a data point for an HP Spectre x86_64
grub2-efi-x64-2.02-54.fc29.x86_64    works
grub2-efi-x64-2.02-55.fc29.x86_64    works

(In reply to Adam Williamson from comment #17)
> Can affected folks also please test this build from pjones:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=29605028
> 
> ? It has a change he believes may address the 'boot to grub shell' failure
> case.

Nope, that didn't work either. I performed a fresh installation from livecd.  Next update omits grub2 entirely. Its an ASUS N56V Laptop -- How does one obtain firmware information?  I see the following when I go to BIOS: "Aptio Setup Utility Ver. 2.15.1226. Copyright(c) 2012, American Megatrends, Inc" 

Hope that was helpful

*** Bug 1626817 has been marked as a duplicate of this bug. ***

Sorry, Onyeibo, I'm not quite understanding your report. You didn't post to this bug before, so I'm not sure what problem you're seeing. What do you mean by "Next update omits grub2 entirely"? Did you actually install the -55 scratch build and test it, and if so, how? What problem are you actually getting? What builds work for you, and what builds don't?

Thanks.

dac.override, as asked above, can you please test these three builds:

https://koji.fedoraproject.org/koji/taskinfo?taskID=29603292 ('amartinez')
https://koji.fedoraproject.org/koji/taskinfo?taskID=29603437 ('minimal')
https://koji.fedoraproject.org/koji/taskinfo?taskID=29605028 (-55)

and report which of them work for you? Thanks a lot!

CCing pbrobinson and dgilmore who seemed to suggest on IRC they were running into something like this.

As promised, I tested the latest version of grub2 in updates-testing, which was -54 at 20:30 on Sep 10, 2018. 

My setup:
- Lenovo Thinkpad t460s
- Fedora 29 as the only operating system
- separate /boot partition on /dev/sda1, swap on /dev/sda2 and eveyrthing else on /dev/sda3 ...
- I am not using LVM on this machine.

I updated via "dnf update --enablerepo updates-testing" and rebooted my computer. I did not experienced any regression, any errors or problems and I was able to boot my system properly.

The only difference, I spotted, was that now I am not getting the hidden grub menu, but I am getting the proper visible grub menu at every start. I am not sure whether hidden grub menu was to be a new feature though - in that case, that would be a the only problem.

So I saw this on -54 and it's still there on -55 on a UP² (http://www.up-board.org/upsquared/specifications-up2/) installed onto a EMMC.

Seems to be some standard commands missing too:
https://photos.app.goo.gl/aW6emPZHvYxcCdZY9

Peter: can you check whether https://koji.fedoraproject.org/koji/taskinfo?taskID=29603437 works for you? Can you provide any of the info cmurf requested?

Also, please don't cancel needinfo's for other people. Now we know what bug *you're* seeing, but we still don't know what bug *Onyeibo* is seeing.

There's one interesting note on the dupe bug:

"`ls` shows no partitions"

Ok even with -51 I'm seeing some commands don't work, e.g. 'version' and 'reboot'. Therefore I'm unconvinced the command failures are related to this grub prompt bug if -51 is working for you -54 and -55 are not.

No regression on x86_64. And reboot now works.
grub2-efi-x64-2.02-56.fc29.x86_64

OK, we now have a -56 build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=29618610

can someone *WITH AN x86_64 SYSTEM AFFECTED BY THIS PARTICULAR BUG* (the '-54 boots to grub shell' bug) please test that build and report whether or not it works for them? Thank you.

(In reply to Adam Williamson from comment #30)
> OK, we now have a -56 build:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=29618610
> 
> can someone *WITH AN x86_64 SYSTEM AFFECTED BY THIS PARTICULAR BUG* (the
> '-54 boots to grub shell' bug) please test that build and report whether or
> not it works for them? Thank you.

does this include those who experienced the grub prompt with -55?

yes, definitely. so, you get the grub prompt with -54 and -55? please test -56 and report. thanks.

There is now a -57 which pjones really thinks has a shot at solving the 'boots to grub shell' problem. Please, affected folks, try it out and report here or in the update:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-2756e3a374

thanks.

(In reply to Adam Williamson from comment #33)
> There is now a -57 which pjones really thinks has a shot at solving the
> 'boots to grub shell' problem. Please, affected folks, try it out and report
> here or in the update:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-2756e3a374
> 
> thanks.

Failed as well.  I got the prompt.
Machine: Asus N56J

NOOOOOO!
Ignore that comment ... I tested -56
Grabbing -57 now

Onyeibo: thanks, I know it's a lot of builds to keep track of - sorry! Peter thought he had it earlier in the day (that was -56), but it turned out to need more work (so -57).

57 Fixed my issue.  It was an educative experience.  Thanks all