In the F29 Branched compose we got last night, x86_64 install tests fail on the boot after install, with a screen looking like this: https://openqa.fedoraproject.org/tests/266864#step/_console_wait_login/4 This is not happening on Rawhide (most Rawhide tests are failing, but later and due to package signature issues when trying to install packages after boot). The obvious difference between Branched and Rawhide is that grub2-2.02-50.fc29 is tagged f29 but not f30; the failing Branched compose has it, the working Rawhide compose has -49.fc29. So, looks like -50 broke it.
I just did a minimal netinstall from https://dl.fedoraproject.org/pub/fedora/linux/development/29/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-29-20180817.n.0.iso (I had to manually use the URL "https://dl.fedoraproject.org/pub/fedora/linux/development/29/Everything/x86_64/os/" in the installer since the mirrors aren't available yet) and it DOES boot, though I got error messages piped through less that I had to ignore.
I'm at a conference so it's hard to download an ISO and confirm, but looking at the openQA video, that looks right - the messages do look like they're being shown in less. openQA just doesn't know to quit less and see if boot proceeds, so it fails.
When I see the error messages, I just hit the space bar repeatedly to scroll through. Eventually it starts booting by itself (maybe when I hit the end of the messages?).
It's probably actually running through `more`, not `less`. That's `more`'s behaviour - after you page to the end of the file it auto-quits (which is incredibly annoying!)
It seems grub2-2.02-51.fc{29,30} should fix this, thanks Peter. We'll find out for sure with the next successful compose of Rawhide or Branched.
I confirm that I've been having exactly the same issues with -50. Only liked to mention it for the record ;)
-51 appears to get rid of the error messages on F29. OTOH, I'd added "GRUB_HIDDEN_TIMEOUT=0" to /etc/default/grub to try to get the grub menu back by default, and it seems to be ignoring it now. Is that a regression, or am I doing it wrong? (It might also be a good idea to change /etc/default/grub to make it more obvious how to get the old behavior back.)
Never mind, it seems to be working now. Not sure why it didn't before.
Just checked that -51 works in Rawhide as well. Noticed the same behavior that I don't get the grub menu after rebooting for the first time after the update, but it works for cold starts or reboots after that.
(In reply to Andre Robatino from comment #7) > -51 appears to get rid of the error messages on F29. OTOH, I'd added > "GRUB_HIDDEN_TIMEOUT=0" to /etc/default/grub to try to get the grub menu > back by default, and it seems to be ignoring it now. Is that a regression, > or am I doing it wrong? (It might also be a good idea to change > /etc/default/grub to make it more obvious how to get the old behavior back.) To get the old behavior back do: sudo grub2-editenv - unset menu_auto_hide No need to edit /etc/default/grub and re-run grub2-mkconfig. Note though, that the menu will show if the previous boot has failed somehow, so you may want to try to just keep this as is. Which reminds now that now this has all stabilized I really need to write some documentation for this.
Since testers have confirmed the fix in -51, let's close this. Thanks folks!