We finally got a new Rawhide compose today. In it, all x86_64 UEFI installs fail to boot. After selecting an entry in grub, these error messages are displayed: error: ../../grub-core/loader/i386/efi/linux.c:217:cannot allocate kernel parameters. error: ../../grub-core/loader/i386/efi/linux.c:94:you need to load the kernel first. Press any key to continue... pressing a key returns to the grub menu. c2f7a5e9af6b58d8e1a6bf0d259820248ceda66a seems like the most likely culprit here.
Example: https://openqa.fedoraproject.org/tests/272637
Note, the error isn't visible in the screenshots (as openQA keeps typing, so it doesn't get snapshotted). It's visible briefly in the video, you can catch it if you step through the video frame by frame.
As I commented in the update FEDORA-2018-2756e3a374 2.02-52 breaks my f29 x86_64 EFI system (on thinkpad x220) I just get a grub commandline, I'm not sure is that the same issue as one found in automated testing. Downgrading to 2.02-51 I can boot again.
Having the same issue on my Thinkpad x1. I can't boot any of the kenrls even the rescue one. Branko what did you do to downgrade? is there some wiki somewhere I can follow to restore my main machine?
(In reply to Ludovic Hirlimann [:Paul-muadib] from comment #4) > Having the same issue on my Thinkpad x1. I can't boot any of the kenrls even > the rescue one. > > Branko what did you do to downgrade? is there some wiki somewhere I can > follow to restore my main machine? The way I did downgrade is, booted fedora live, mounted /, /boot,/boot/efi, also mounted /proc, bind mounted (with --rbind) /sys and /dev, chrooted to my fedora install (I mounted everything under /mnt), and run: dnf downgrade grub2-common For me it was easy because I keep old packages with 'keepcache=1' in /etc/dnf/dnf.conf, if you also have everything cached, you could use '-C' dnf option to use all from cache (metadata), not trying to get new one, but that's optional, if you have internet connection in live system, I guess you don't need that.
(In reply to Ludovic Hirlimann [:Paul-muadib] from comment #4) > Having the same issue on my Thinkpad x1. I can't boot any of the kenrls even > the rescue one. > > Branko what did you do to downgrade? is there some wiki somewhere I can > follow to restore my main machine? Replace grubx64.efi. See Bug 1624525
@adamw: Happens on F29 as well – see Bug 1624525 ; seems to happen to quite a few people, hansdegoede & me among them; should that bug be a F29BetaBlocker?
This is really the same issue as Bug 1624525 and should probably be closed as a duplicate of that bug.
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
@thorsten no, because it is not in f29 stable and will not be. It is only in updates-testing (and not there any more, as I unpushed it).
Hans: the scratch build looks like it fixes the problem. Note I didn't test whether it breaks any *other* boot scenario.
Created attachment 1481478 [details] grub screen photo
Adam, Why broken grub is still not excluded from the updates?Already as seven days as it is known about the problem, and broken grub gets on the LiveCD and shipped with updates !!! Any idea how fix broken system if no 'keepcache=1' parameter in dnf?
We can't block it from Rawhide once it's gone out in a compose. We can only untag things before they go out in a compose. We could revert the broken change and bump the version, but I guess I was kinda figuring Peter would fix it quite promptly, seeing as how it breaks the world and all. Hans, do you know when this is going to get fixed? "Any idea how fix broken system if no 'keepcache=1' parameter in dnf?" Boot from a live or rescue image, mount the installed system at e.g. /mnt/point (including the ESP at /mnt/point/boot/efi), chroot /mnt/point , downgrade grub2 packages.
(In reply to Adam Williamson from comment #14) > Boot from a live or rescue image Ok ,first question, where get bootable image? Latest image from site https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20180906.n.0.iso is also affected by grub issue too. > downgrade grub2 packages. Is it possible? AFAIK from: (1) https://bugzilla.redhat.com/show_bug.cgi?id=1607077 (2) https://bugzilla.redhat.com/show_bug.cgi?id=1611099 (3) https://bugzilla.redhat.com/show_bug.cgi?id=1615074 it is impossible because Rawhide repo storing only latest state. Or it already changed by my propose?
"Ok ,first question, where get bootable image?" You can use any image, it doesn't have to be a Rawhide one. F28 stable is fine. "Is it possible?" https://koji.fedoraproject.org/koji/buildinfo?buildID=1137570
(In reply to Mikhail from comment #15) > (In reply to Adam Williamson from comment #14) > > Boot from a live or rescue image > Ok ,first question, where get bootable image? It's not very picky at all - I used an RHEL 7.0 install disk in rescue mode, it was able to find and mount all 12 of my cryptLUKS LVM filesystems just fine. Get the rescue mode '#' prompt, 'chroot /mnt/sysimage' and go to town - at this point you're running off your production system so can do pretty much anything. I had 'keepcache=1' so I had a set of old grub2 RPMs on the system, but you can mount a USB memory stick with the images, or wget them (after some ifup commands and etc) or whatever.
I did a build with Han's patch applied for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1142745 and it works here to fix the issue. Please do file a new issue, or chime in here if you still are seeing anything...
(In reply to Branko Grubić from comment #3) I experience the same issues, testing with -54 did not help. It might be something different ...
Vit, Branko, can you file a new bug and perhaps propose it as a blocker? Can you provide details of your hardware or (if you're hitting this with a VM) what virt system you're using? Thanks!
Created attachment 1481890 [details] dnf output
Thanks for guide me. grub was successfully downgraded and system was reanimated. But during downgrading grub dnf was output a lot of error messages: RuntimeError: TransactionItem not found for key: grub2-common (In reply to Mikhail from comment #23) > Created attachment 1481890 [details] This is normal?
no, looks like a dnf bug. I'd file a bug against dnf if I were you. (I actually found dnf would completely fail to do a downgrade inside a chroot, so I just did rpm -Uvh --force instead...I didn't file this yet as it might've worked if I did dnf --installroot instead of using an actual chroot...)
(In reply to Adam Williamson from comment #22) > Vit, Branko, can you file a new bug and perhaps propose it as a blocker? Can > you provide details of your hardware or (if you're hitting this with a VM) > what virt system you're using? Thanks! Created bug #1626844 and proposed it as a blocker (beta (probably it's more like a final blocker)), I wasn't sure about blocker procedure but I found something similar there.
Confirming fixed. I pulled down grub2-common-2.02-58.fc30 from koji and it works on my Dell laptop.