Bug 1946969 - grub2 (2.06~rc1-3) unresponsive until visual artifact has completed
Summary: grub2 (2.06~rc1-3) unresponsive until visual artifact has completed
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1948300 2020950 (view as bug list)
Depends On: 2045456
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-07 11:50 UTC by thepiguy0
Modified: 2023-02-26 18:31 UTC (History)
10 users (show)

Fixed In Version: grub2-2.06-16.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-24 18:56:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description thepiguy0 2021-04-07 11:50:56 UTC
Description of problem:
Upon boot, grub does not respond to any keyboard commands until a visual artifact has completed. After this point, it will complete any key presses that were performed during the artifact and then become responsive.

The artifact is a small white dash that begins top left, flickers across to the right, drops down a bit and repeats until it reaches the bottom of the screen.

Version-Release number of selected component (if applicable):
grub2 2.06~rc1-3

How reproducible:
Every boot

Steps to Reproduce:
1. Boot the install media (latest tested was Fedora-34-20210407.n.0 netinst)

Actual results:
Not responsive until artifact finishes

Expected results:
Immediately responsive with no visual artifacts

Additional info:
Possibly related to bug no. 1900233

Comment 1 thepiguy0 2021-04-07 11:53:16 UTC
For additional information, an Arch Linux live usb does not have this issue. That is running on GRUB 2.04, however I believe this issue has also existed on 2.04 for Fedora

Comment 2 Javier Martinez Canillas 2021-06-29 23:33:13 UTC
*** Bug 1948300 has been marked as a duplicate of this bug. ***

Comment 3 thepiguy0 2021-08-07 17:42:49 UTC
I was wondering if there has been any progress on this bug and if not, is there anything I could do to help debug the issue? (Unfortunately since my reinstall of Fedora a few days ago, I do experience this on every boot).

Comment 4 Robbie Harwood 2021-09-01 14:44:18 UTC
It would probably help to have information about what your machine is.

Comment 5 thepiguy0 2021-09-01 16:53:40 UTC
I have a Lenovo Yoga S740-14IIL, i5-1035G4, Intel Iris Plus Graphics, 8GB RAM (I believe running at 3733MHz).

If there's any more information you want (or if you want any logs) please let me know.

Comment 6 thepiguy0 2021-09-10 22:12:52 UTC
I don't know if this helps at all, but it appears my screen redraws are incredibly slow when in grub. If I enter the command line (press c) and then run a command that draws a lot (e.g. ls /bin), it takes forever to draw.

I don't know if this is normal but could well be causing the other issue I'm experiencing (maybe grub normally draws this dash, but on most machines it's rendered so fast we don't get affected by it).

Comment 7 thepiguy0 2021-09-24 21:29:40 UTC
As an update, removing the line 'GRUB_TERMINAL_OUTPUT="console"' from /etc/default/grub and then rebuilding with "grub2-mkconfig -o /boot/grub2/grub.cfg" did actually stop this being an issue for me. Grub immediately loaded and was completely responsive.

It's worth noting that the font changes to what I would consider a less visually appealing font, and the arrow symbols in the "Use the <up> and <down> keys to change the selection" are replaced with a question mark inside a square

Comment 8 Hans de Goede 2022-01-28 12:46:33 UTC
Thank you for your bugreport. I hit the same issue while testing on a Tiger Lake laptop. I've written a set of patches fixing this and submitted it upstream and downstream:

https://lists.gnu.org/archive/html/grub-devel/2022-01/msg00169.html
https://github.com/rhboot/grub2/pull/95

If you want to test the fix, here is a build of the latest fedora-36 branch of grub with the fixes included:

https://fedorapeople.org/~jwrdegoede/rhbz1946969/grubx64.efi

To test this simply overwrite /boot/efi/EFI/fedora/grubx64.efi with it. Note this is not signed and as such you will need to disable secure-boot to test this. Warning disabling secureboot and running semi-random binaries from the internet is not the best idea from a security pov.

If you do decide to give this a test, please don't forget to restore the 'GRUB_TERMINAL_OUTPUT="console"' line in /etc/default/grub and then rebuild with "grub2-mkconfig -o /boot/grub2/grub.cfg".

Comment 9 Hans de Goede 2022-01-28 12:49:49 UTC
p.s.

1. The linked grubx64.efi binary should work fine, but just top be sure you may want to make a backup of the original grubx64.efi to restore if for some reason it does not work.

2. The menu looks slightly different in the fedora-36 branch, because a couple of downstream patches which tweak the menu look have been dropped to bring us closer to the upstream grub sources.

Comment 10 Hans de Goede 2022-01-28 13:07:58 UTC
*** Bug 2020950 has been marked as a duplicate of this bug. ***

Comment 11 youling257 2023-02-26 16:59:05 UTC
I last build grub is two years ago, grub does not respond to any keyboard commands, i revert these patches, https://github.com/youling257/grub/commits/revert
today, i build grub master, not revert these patches, still grub does not respond to any keyboard commands.

my grub.cfg is 
set gfxpayload=3840x2160
set timeout_style=hidden
set timeout=0
set default=0
loadfont /boot/grub/fonts/unicode.pf2
set gfxmode=3840x2160
terminal_output gfxterm
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

Comment 12 youling257 2023-02-26 18:31:20 UTC
“efi/console: Do not set text-mode until we actually need it” cause set 3840x2160 not work, revert it, grub menu gfxterm can 3840x2160.


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