Bug 1618928 - grub2-2.02-50.fc29 shows error/debug messages in pager on x86_64, requires user input to complete boot
Summary: grub2-2.02-50.fc29 shows error/debug messages in pager on x86_64, requires us...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 29
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F29BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2018-08-18 12:01 UTC by Adam Williamson
Modified: 2018-08-20 17:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-20 17:04:28 UTC


Attachments (Terms of Use)

Description Adam Williamson 2018-08-18 12:01:06 UTC
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.

Comment 1 Andre Robatino 2018-08-18 13:05:33 UTC
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.

Comment 2 Adam Williamson 2018-08-18 13:11:51 UTC
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.

Comment 3 Andre Robatino 2018-08-18 14:21:53 UTC
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?).

Comment 4 Adam Williamson 2018-08-18 14:34:16 UTC
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!)

Comment 5 Adam Williamson 2018-08-19 16:16:43 UTC
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.

Comment 6 Ali Akcaagac 2018-08-19 16:24:39 UTC
I confirm that I've been having exactly the same issues with -50. Only liked to mention it for the record ;)

Comment 7 Andre Robatino 2018-08-19 16:39:31 UTC
-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.)

Comment 8 Andre Robatino 2018-08-19 16:50:37 UTC
Never mind, it seems to be working now. Not sure why it didn't before.

Comment 9 Andre Robatino 2018-08-19 17:09:46 UTC
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.

Comment 10 Hans de Goede 2018-08-20 09:57:52 UTC
(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.

Comment 11 Adam Williamson 2018-08-20 17:04:28 UTC
Since testers have confirmed the fix in -51, let's close this. Thanks folks!


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