Bug 1626844 - grub2-2.02-54.fc29 fails to boot, drops to grub shell
Summary: grub2-2.02-54.fc29 fails to boot, drops to grub shell
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1626817 (view as bug list)
Depends On:
Blocks: F29BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2018-09-09 16:35 UTC by Branko Grubić
Modified: 2018-09-12 11:02 UTC (History)
15 users (show)

Fixed In Version: grub2-2.02-57.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-12 11:02:36 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1624532 None CLOSED Latest Rawhide grub2 fails to boot on UEFI installs: "cannot allocate kernel parameters" 2019-02-04 21:02:57 UTC
Red Hat Bugzilla 1626817 None CLOSED 2.02-54 still broken here with EFI/Lenovo x250 2019-02-04 21:02:56 UTC

Internal Links: 1624532 1626817

Description Branko Grubić 2018-09-09 16:35:33 UTC
Description of problem:
As mentioned in the rawhide bug 1624532 grub2 fails to start my system, after upgrade, it just shows the grub shell, no menu with boot entries. Downgrading to 2.02-51 I was again able to boot.

This is tested on real hardware, Thinkpad x220 in EFI mode (doesn't support secure boot), and on Thinkpad T440p in (U)EFI mode with secure boot enabled.

If there is any way to provide more information, please let me know.

Version-Release number of selected component (if applicable):
grub2*-2.02-51.fc29

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Fedora Blocker Bugs Application 2018-09-09 16:39:30 UTC
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"

Comment 2 Branko Grubić 2018-09-09 16:44:18 UTC
Linking rawhide bug

Comment 3 Adam Williamson 2018-09-09 16:53:21 UTC
Should the bug title say -52 or -54, not -51? AIUI, -51 works but both -52 and -54 do not (for you), right?

Comment 4 Branko Grubić 2018-09-09 16:55:46 UTC
(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.

Comment 5 František Zatloukal 2018-09-09 17:37:03 UTC
(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.

Comment 6 Adam Williamson 2018-09-09 17:39:33 UTC
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.

Comment 7 František Zatloukal 2018-09-09 17:48:42 UTC
(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 .

Comment 8 František Zatloukal 2018-09-09 20:19:16 UTC
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.

Comment 9 František Zatloukal 2018-09-09 22:07:51 UTC
Created BZ for my problem: https://bugzilla.redhat.com/show_bug.cgi?id=1626862

Sorry for the noise here :)

Comment 10 Vít Ondruch 2018-09-10 10:00:04 UTC
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.

Comment 11 Chris Murphy 2018-09-10 16:20:42 UTC
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.

Comment 12 Chris Murphy 2018-09-10 18:35:16 UTC
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.

Comment 13 Adam Williamson 2018-09-10 19:04:30 UTC
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.

Comment 14 Adam Williamson 2018-09-10 19:38:40 UTC
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!

Comment 15 Adam Williamson 2018-09-10 19:39:18 UTC
d'oh, copy/paste fail: Please replace "affected aarch64 systems" with "affected x86_64 systems" in previous comment.

Comment 16 Paul Whalen 2018-09-10 21:45:40 UTC
grub2-2.02-54.fc29 working as expected on an x220 laptop

Comment 17 Adam Williamson 2018-09-10 21:47:32 UTC
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.

Comment 18 Chris Murphy 2018-09-11 04:52:35 UTC
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

Comment 19 Onyeibo Oku 2018-09-11 05:05:58 UTC
(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

Comment 20 Adam Williamson 2018-09-11 07:08:57 UTC
*** Bug 1626817 has been marked as a duplicate of this bug. ***

Comment 21 Adam Williamson 2018-09-11 07:09:26 UTC
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.

Comment 22 Adam Williamson 2018-09-11 07:10:37 UTC
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!

Comment 23 Adam Williamson 2018-09-11 07:12:11 UTC
CCing pbrobinson and dgilmore who seemed to suggest on IRC they were running into something like this.

Comment 24 Lukas Ruzicka 2018-09-11 08:07:57 UTC
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.

Comment 25 Peter Robinson 2018-09-11 14:31:49 UTC
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

Comment 26 Adam Williamson 2018-09-11 14:59:54 UTC
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.

Comment 27 Adam Williamson 2018-09-11 15:01:49 UTC
There's one interesting note on the dupe bug:

"`ls` shows no partitions"

Comment 28 Chris Murphy 2018-09-11 17:24:30 UTC
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.

Comment 29 Chris Murphy 2018-09-11 17:41:07 UTC
No regression on x86_64. And reboot now works.
grub2-efi-x64-2.02-56.fc29.x86_64

Comment 30 Adam Williamson 2018-09-11 17:56:34 UTC
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.

Comment 31 Onyeibo Oku 2018-09-11 18:16:24 UTC
(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?

Comment 32 Adam Williamson 2018-09-11 18:27:35 UTC
yes, definitely. so, you get the grub prompt with -54 and -55? please test -56 and report. thanks.

Comment 33 Adam Williamson 2018-09-11 22:53:23 UTC
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.

Comment 34 Onyeibo Oku 2018-09-12 05:04:21 UTC
(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

Comment 35 Onyeibo Oku 2018-09-12 05:22:04 UTC
NOOOOOO!
Ignore that comment ... I tested -56
Grabbing -57 now

Comment 36 Adam Williamson 2018-09-12 05:41:31 UTC
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).

Comment 37 Onyeibo Oku 2018-09-12 09:48:08 UTC
57 Fixed my issue.  It was an educative experience.  Thanks all


Note You need to log in before you can comment on or make changes to this bug.