Fix for aarch64 booting on some platforms, as well as loading of large initramfs images on x86_64 and aarch64.
Add patch from https://github.com/rhboot/grub2/pull/30 to fix uefi booting
Update conflicts on grubby.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2018-2756e3a374
Please login to add feedback.
This update has been submitted for testing by pjones.
Verified working on mustang and seattle.
Works on aarch64 on mustang
works as expected
This update has been pushed to testing.
This update has been submitted for batched by bodhi.
openQA testing of Rawhide indicates this is entirely broken for x86_64 UEFI.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
This update has been unpushed.
This update has been submitted for testing by adamwill.
I only wanted to unqueue this from the batched queue, but apparently if you hit 'unpush' when something's in testing and queued for batched, it unpushes it from testing :/
For me this update breaks boot on f29 system x86_64 EFI (older EFI without secure boot on thinkpad x220). I don't get the error message like in bug #1624532, but just get a grub commandline. Downgrading to 2.02-51 I can boot again.
Whether you see the error or not might depend a bit on your firmware, I think. It's probably the same bug.
Enough people have reported running into this now that I think we should just unpush it, let's stop breaking people's systems.
This update has been pushed to testing.
This update has been unpushed.
Tested it, per request in https://bugzilla.redhat.com/show_bug.cgi?id=1572126, doesn't seem to work here.
Throws: error: ../../grub-core/loader/i386/efi/linux.c:217:cannot allocate kernel parameters
When trying to load kernel (linuxefi (hd0,msdos1)/vmlinuz). I don't specify parameters (don't need any), didn't work with bogus ones either though.
Tested on Dell XPS 15 9550 with 16GB RAM. Didn't use a different shim (using the one currently in fc28).
kevin edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by kevin.
My UEFI VM seems to continue working just fine with -54.
This update has been pushed to testing.
Boots fine on my aarch64 Overdrive 1000.
karma: +1
For me 2.02-54 still breaks the boot on my thinkpad x220 (running in EFI mode, no secure boot on this system, doesn't support it). I still get the grub shell/commandline instead of booting the system or option to choose which entry to boot. Reverted back to 2.02-51.
For rawhide it's already reported as bug #1626817
So it works fine on my aarch64 mustang, pine64 and Raspberry Pi3/3B+.
It fails on my Intel based UP² board and i end up with just a grub prompt.
So, as my EFI VM worked fine, this broke my dualboot (Fedora + Windows 10 Desktop).
Booting Fedora entry ends up showing Windows Error Message instead of GRUB. Will create bug report for that with logs later.
For F29 filed #1626844
no regressions found
I end up with a grub prompt and an inability to load teh grub config with this update
As above
This update has been obsoleted.
adamwill edited this update.
New build(s):
Removed build(s):
Karma has been reset.
@ausil @pwalter @bitlord @pbrobinson - with some luck, -57 should solve the problems you hit. Can you please try it and report (and +1) if it boots OK? thanks a lot.
This update has been submitted for testing by pbrobinson.
tested grub2-efi-x64-2.02-57.fc29.x86_64 on my system which ihas a https://www.asus.com/us/Motherboards/RAMPAGE_IV_GENE/ motherboard and it booted fine
Tested grub2-efi-x64-2.02-57.fc29.x86_64 on my system which worked fine on -54. I see no regressions.
This update has been submitted for stable by adamwill.
This update has been pushed to stable.
Tested on UP² mustang and Raspberry Pi3B+
Hi, still seem to have some issues with grub2-efi-x64-2.02-57.fc29.x86_64.rpm
Both kernel (didn't load on the grub2-2.02-53.fc30 and grub2-2.02-52.fc30 versions) and initrd (had allocations issues with earlier versions) seem to load fine now. The prompt returns w/o any output after both linuxefi (hd0,msdos1)/vmlinuz initrdefi (hd0,msdos1)/initrd
Then issued boot
But it's been stuck there for quite some time now. No more output has appeared. Been waiting for ~10 minutes now. The initrd is xz compressed, should be unpacked in <30 secs on this system.
karma: -1