Bug 1624525

Just updated from f28 to f29 and ran into the same problem (exactly the same error messages). Dell XPS13 (9360)

I've been able to boot with the following workaround: Boot to an F28
live image, mount the boot partition on your system and then replace
grubx64.efi in Fedora's EFI subdirectory on the boot partition, which
had a timestamp of 30 August, with /boot/efi/EFI/fedora/grubx64.efi
found in the F28 image.

After that substitution I was able to boot with no problems. Making a
copy of that file on the boot partition might not be a bad idea since
it will get clobbered on the next update, and there's no guarantee
that the next update will fix the problem.

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

TWIMC: Seems to happen on rawhide as well: See Bug 1624532

Thank you for the bug-report. I've have hit the same issue myself. I've submitted a pull-req with a fix here:

https://github.com/rhboot/grub2/pull/30

As soon as the grub maintainers get around to doing a grub built with this fix included this bug should be resolved.

Proposing this as a beta freeze exception as it renders various Dell laptops (at least 3 different models) unbootable and the fix is quite simple and safe.

(In reply to Hans de Goede from comment #6)
> Proposing this as a beta freeze exception as it renders various Dell laptops
> (at least 3 different models) unbootable and the fix is quite simple and
> safe.

I see the broken grub-build was only ever in updates-testing and has been unpushed now, but we need the fix (+ the fix to the fix from https://github.com/rhboot/grub2/pull/30) to fix some other systems not booting, so the freeze exception request still stands.

Here is a scratch build (still building atm) including the fix for this, it would be great if people can give this a try and confirm that it fixes things.

Note this is an unsigned build, so it will only work if you've secureboot disabled:

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

(In reply to Hans de Goede from comment #8)
> Here is a scratch build (still building atm) including the fix for this

Works fine for me, thx! (and now I ran into the know dbus trouble; grrrrrr; :- / )

(In reply to Hans de Goede from comment #8)
> Here is a scratch build (still building atm) including the fix for this

Works for me as well (once I found grub2-pc-modules.noarch in the i686 build).

The bug has never reached stable and never will, so there is no need for a freeze exception.

FYI, I've hit this bug with VirtualBox 5.2.12

For the record, I've updated to grub2 2.02-54-fc29 and had no problems booting. The timestamp on grubx64.efi was changed (presumably by the upgrade) so boot success is not due to the workaround.  Also for the record, my system uses Dell BIOS version 1.12.2, 12 July 2018.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

the bug here never reached stable and was later fixed, IIRC.