Bug 859632 - gfxterm hangs when editing boot entries with large font
gfxterm hangs when editing boot entries with large font
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker
: Reopened
: 856277 863412 870317 903277 (view as bug list)
Depends On:
Blocks: F18-accepted/F18FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-09-22 12:18 EDT by drago01
Modified: 2014-02-05 17:48 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 17:48:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Screencast showing the bug (546.54 KB, video/webm)
2012-09-23 17:04 EDT, drago01
no flags Details
VM Config (2.79 KB, text/plain)
2012-09-26 16:20 EDT, drago01
no flags Details
grub.cfg with the bug (6.36 KB, text/plain)
2012-10-02 05:11 EDT, drago01
no flags Details
Screenshot showing working "edit box" but with LARGE font (234.48 KB, image/png)
2012-10-04 04:59 EDT, Dr. Tilmann Bubeck
no flags Details
gfxterm virtual_screen.rows=15 unpatched grub2-2.00-12.fc18 ibm-x3550m3.png (131.30 KB, image/png)
2012-12-07 04:33 EST, Lingzhu Xiang
no flags Details
gfxterm num_entries underflow patched grub2-2.00-12.fc18 qemu-ovmf.png (105.80 KB, image/png)
2012-12-07 04:34 EST, Lingzhu Xiang
no flags Details
fix-num_entries-underflow.patch (608 bytes, patch)
2012-12-07 04:37 EST, Lingzhu Xiang
no flags Details | Diff

  None (edit)
Description drago01 2012-09-22 12:18:12 EDT
Description of problem:
On F18 I cannot edit the boot entries in grub by pressing "e" and then F10 to continue booting. When pressing "e" a black rectangle is shown but not the boot commands to edit.

Version-Release number of selected component (if applicable):
2.00-5.fc18

How reproducible:
Always


Steps to Reproduce:
1. Power system on
2. Press "e" at the grub screen
  
Actual results:
Black rectangle instead of boot commands.

Expected results:
Allow editing the boot commands.
Comment 1 Mads Kiilerich 2012-09-23 16:21:59 EDT
Please attach a photo / VM screenshot of the problem.
Comment 2 drago01 2012-09-23 17:04:40 EDT
Created attachment 616247 [details]
Screencast showing the bug
Comment 3 Adam Williamson 2012-09-26 16:13:58 EDT
So interestingly, from the screencast, this looks different from https://bugzilla.redhat.com/show_bug.cgi?id=850783 , which is the bug most of us have seen when trying to do this. Could you provide more details of the VM configuration? Perhaps attach the XML file?
Comment 4 Adam Williamson 2012-09-26 16:14:49 EDT
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . We agreed that we need more data to evaluate this issue, including that requested in comment #3.
Comment 5 drago01 2012-09-26 16:20:34 EDT
Created attachment 617757 [details]
VM Config
Comment 6 Mads Kiilerich 2012-09-26 16:45:16 EDT
Fedora-18-Alpha-TC5-x86_64-Live-Desktop.iso is mounted.
Can you reproduce with a fully updated f18 after running
  grub2-install /dev/vda
  LANG=C grub2-mkconfig -o /boot/grub2/grub.cfg
?
Comment 7 drago01 2012-09-26 16:47:44 EDT
(In reply to comment #6)
> Fedora-18-Alpha-TC5-x86_64-Live-Desktop.iso is mounted.

Yes never bothered to unmount it ... it is unrelated though.

> Can you reproduce with a fully updated f18 after running
>   grub2-install /dev/vda
>   LANG=C grub2-mkconfig -o /boot/grub2/grub.cfg
> ?

Yes (actually did that before reporting the bug).
Comment 8 Dr. Tilmann Bubeck 2012-10-02 04:57:41 EDT
*** Bug 856277 has been marked as a duplicate of this bug. ***
Comment 9 drago01 2012-10-02 05:10:44 EDT
(In reply to comment #6)
>
>   LANG=C grub2-mkconfig -o /boot/grub2/grub.cfg

Sorry I somehow missed the LANG=C part ... after looking at Tills Screenshot I noticed that his grub is in german as well. So I run "LANG=C grub2-mkconfig -o /boot/grub2/grub.cfg" the result was a working edit mode.

So the bug seems to be caused by non-english or german locale.
Comment 10 drago01 2012-10-02 05:11:11 EDT
Created attachment 620196 [details]
grub.cfg with the bug
Comment 11 Mads Kiilerich 2012-10-02 10:25:09 EDT
I cannot reproduce the problem by setting LANG=de_DE. Can you control it 100% by setting LANG?

(The translated "help" text is however so long and with unfortunate and wrong line wrapping that only a few lines are left for editing. That would be a separate bug if anyone cared to file it...)

(The translation will also only be correct if an .utf8 language such as de_DE.utf8 is used.)

The video and the attached grub.cfg do however show a grub.cfg that has been patched by grubby. It is not the result of running grub2-mkconfig. The report might be valid anyway, but there is some noise and no clear proof.
Comment 12 Adam Williamson 2012-10-03 13:03:39 EDT
mads: what if you set LANG=de.utf8 ? See https://bugzilla.redhat.com/show_bug.cgi?id=858591
Comment 13 Adam Williamson 2012-10-03 13:25:42 EDT
Discussed at 2012-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-03/f18-beta-blocker-review-2.2012-10-03-16.00.log.txt . This is a significant issue, but we'd like more data on the cause and whether it affects other languages before making a decision. We'd also like to know if it's a consequence of 858591, which it may well be. We will consider it again at the next review meeting, if it isn't marked as a duplicate by then.
Comment 14 drago01 2012-10-03 13:51:42 EDT
(In reply to comment #11)
> I cannot reproduce the problem by setting LANG=de_DE. Can you control it
> 100% by setting LANG?

No, does not seem to happen after rebuilding the config again ...
Comment 15 Mads Kiilerich 2012-10-03 18:28:13 EDT
(In reply to comment #12)
> mads: what if you set LANG=de.utf8 ?

That doesn't make any difference. Grub do things its own way and will strip .utf8 on mkconfig time and strip _DE on runtime when it doesn't find a de_DE translation.

(Some of the texts in grub.cfg are however translated on mkconfig time and read on runtime as utf8, so they will be wrong if the locale doesn't include .utf8 . That could be considered a different bug.)

(In reply to comment #14)

So
* the video and the attached grub.cfg showed evidence of a setup that had been mangled by grubby and thus not a fresh install/mkconfig with the current grub version
* the problem cannot (no longer) be reproduced

I do thus feel inclined to file this under "there might have been a problem but it seems to have gone".

Till, do that match your experience?


(Note that the unfortunate decision to use different grub.cfg locations for BIOS and EFI probably will cause some confusion like this.)
Comment 16 Dr. Tilmann Bubeck 2012-10-04 04:59:45 EDT
Created attachment 621463 [details]
Screenshot showing working "edit box" but with LARGE font

I installed using Fedora-18-Beta-TC1-x86_64-DVD.iso, choosing "German" as my language and keyboard.

After installation, pressing "e" in GRUB showed a working edit view. However, the font is still huge (see attachment), but this is already reported under bugzilla #850783. 

Please note, that I did not do any "yum update" resulting in mkconfig being run, because there are no packages available yet. This will show, if updating the system will lead to the above error or not. But currently it looks good. :-)
Comment 17 Mads Kiilerich 2012-10-04 05:29:49 EDT
(In reply to comment #16)
> Please note, that I did not do any "yum update" resulting in mkconfig being
> run, because there are no packages available yet.

Package installation will never run grub2-mkconfig - it must be run manually (or by anaconda). (Just like grub2-install must be run manually first ... unless you are using EFI and immediately will get a new bootloader without getting a new configuration.)

Conclusion: The problem is solved for correctly installed/upgraded systems. (And upgrading unreleased versions might be a bit tricky.)
Comment 18 Mads Kiilerich 2012-10-05 10:38:50 EDT
*** Bug 863412 has been marked as a duplicate of this bug. ***
Comment 19 Lingzhu Xiang 2012-12-07 01:37:52 EST
*** Bug 870317 has been marked as a duplicate of this bug. ***
Comment 20 Lingzhu Xiang 2012-12-07 04:30:05 EST
Reproduced this with -12 from F18 public Beta, on QEMU/OVMF instances and a IBM x3550 M3 box (all UEFI systems).

This bug causes grub to hang after reproduction. The user can't take any actions except rebooting the system.

This only happens under certain configurations of screen size and font size, when the screen is too small or the font is too large. Cf. bug 850783.

The root cause is an integer underflow in grub code.

In normal/menu_text.c, grub_menu_init_page(), grub dynamically determines how many lines are available for the edit box.

     /* 3 lines for timeout message and bottom margin.  2 lines for the border.  */
     *num_entries = grub_term_height (term) - GRUB_TERM_TOP_BORDER_Y
       - (print_message (nested, edit, term, 1) + 3) - 2;

On my systems, grub_term_height(term) is 15, GRUB_TERM_TOP_BORDER_Y is 3, print_message will print "Minimum Emacs-like..." for 10 lines, so num_entries here will be -3.

Unfortunately num_entries will be used to draw the borders of the edit box, and in draw_border():

static void
draw_border (struct grub_term_output *term, int num_entries)
{
  unsigned i;

[...]

  for (i = 0; i < (unsigned) num_entries; i++)
    {
      grub_term_gotoxy (term, GRUB_TERM_MARGIN, GRUB_TERM_TOP_BORDER_Y + i + 1);
      grub_putcode (GRUB_UNICODE_VLINE, term);
      grub_term_gotoxy (term, GRUB_TERM_MARGIN + grub_term_border_width (term)
                        - 1,
                        GRUB_TERM_TOP_BORDER_Y + i + 1);
      grub_putcode (GRUB_UNICODE_VLINE, term);
    }

So grub hangs here. I crafted a minimal patch to prevent negative edit box height, and it stopped hanging. Details about making the font small enough to be usable are in bug 850783.
Comment 21 Lingzhu Xiang 2012-12-07 04:33:41 EST
Created attachment 659265 [details]
gfxterm virtual_screen.rows=15 unpatched grub2-2.00-12.fc18 ibm-x3550m3.png
Comment 22 Lingzhu Xiang 2012-12-07 04:34:25 EST
Created attachment 659266 [details]
gfxterm num_entries underflow patched grub2-2.00-12.fc18 qemu-ovmf.png
Comment 23 Lingzhu Xiang 2012-12-07 04:37:45 EST
Created attachment 659267 [details]
fix-num_entries-underflow.patch

For demo only. Probably needs review on a greater picture.
Comment 24 Mads Kiilerich 2012-12-07 05:06:25 EST
(In reply to comment #20)

Grub becomes very unstable after a missing font load. I suggest filing another bug for that specific problem.

As mentioned on the other bug: It seems like EFI grub has a font problem. That is the real problem.
Comment 25 Lingzhu Xiang 2012-12-07 09:01:28 EST
(In reply to comment #24)
> Grub becomes very unstable after a missing font load. I suggest filing
> another bug for that specific problem.
> 
> As mentioned on the other bug: It seems like EFI grub has a font problem.
> That is the real problem.

You are right. I filed bug 885090. It is like a precursor to this bug.

I would like to add more information on reproducibility:

With a default F18 beta pxeboot installation on a QEMU/BIOS instance, the hang can be triggered with grub.cfg looking like this (adding the comment):

loadfont ($root)/grub2/themes/system/DejaVuSans-10.pf2
loadfont ($root)/grub2/themes/system/DejaVuSans-12.pf2
loadfont ($root)/grub2/themes/system/DejaVuSans-Bold-14.pf2
#loadfont ($root)/grub2/fonts/unicode.pf2

The screen of QEMU instance is 800x600.
Comment 26 Tim Flink 2012-12-07 11:24:25 EST
(In reply to comment #24)
> (In reply to comment #20)
> 
> Grub becomes very unstable after a missing font load. I suggest filing
> another bug for that specific problem.
> 
> As mentioned on the other bug: It seems like EFI grub has a font problem.
> That is the real problem.

Restating to make sure that I'm understanding what's going on here. It sounds like there are two issues here that have similar results but different root causes.

The original report is about instability that is fixed when grub is properly updated post-upgrade.

The second issue from c#20 is about efi grub becoming very unstable if a font is missing which has been filed as #885090.

Am I missing anything here?
Comment 27 Mads Kiilerich 2012-12-07 21:14:59 EST
(In reply to comment #26)
> Am I missing anything here?

Agreed. Nobody should experience this issue if bug 885090 is fixed.
Comment 28 Lingzhu Xiang 2012-12-08 03:21:46 EST
(In reply to comment #26)
> (In reply to comment #24)
> > (In reply to comment #20)
> > 
> > Grub becomes very unstable after a missing font load. I suggest filing
> > another bug for that specific problem.
> > 
> > As mentioned on the other bug: It seems like EFI grub has a font problem.
> > That is the real problem.
> 
> Restating to make sure that I'm understanding what's going on here. It
> sounds like there are two issues here that have similar results but
> different root causes.

There are indeed two issues:

- The default font being large cripples usability. Making the default font smaller fixes that. It is addressed in bug 850783 and bug 885090.
- Whatever the default font is, grub hangs when font is large, which is this bug.

> The original report is about instability that is fixed when grub is properly
> updated post-upgrade.
> 
> The second issue from c#20 is about efi grub becoming very unstable if a
> font is missing which has been filed as #885090.

What particular is being unstable? Grub will hang if font is large. This is deterministic. Grub hanging has nothing to do with missing font. The user can specify a large font then grub will hang and prevent user from any more usage.

The integer underflow is an inherent logic error in grub code as shown in comment 20. It happens to get exposed under the current default configuration which makes the font large and when resolution is small. Getting the default font size small to reduce the probability of this bug happening in the wild isn't really fixing this bug.
Comment 29 Adam Williamson 2012-12-10 13:56:33 EST
Discussed at 2012-12-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-10/f18final-blocker-review-3.2012-12-10-17.13.log.txt . For now we decided this is too much of a corner case to be a release blocker. If we're counting right, here are the triggers:

* UEFI native install (still a small minority)
* At a low resolution (looks like 800x600) (also a minority, esp on UEFI hardware - probably only VMs)
* Needing to edit the kernel parameters to boot (another minority)

So this is really a showstopper only for a minority of a minority of a minority of users. For a minority of a minority it's an inconvenience that can be fixed with an update, and for everyone else it's not a problem at all.

if anyone sees a problem with this reasoning, please speak up, and we'll re-discuss the bug at the next meeting. Thanks!

It's accepted as NTH as it *is* a showstopper for that tiny minority.
Comment 30 Kamil Páral 2013-01-28 03:46:20 EST
*** Bug 903277 has been marked as a duplicate of this bug. ***
Comment 31 Kamil Páral 2013-01-28 03:50:56 EST
As stated in bug 903277, I see this issue on Lenovo X220 with 1366x768 display.
Comment 32 Lingzhu Xiang 2013-01-28 04:45:29 EST
Another data point: Thinkpad T520 with 1920x1080 display.

Firmware GOP driver provides a default 640x480 resolution.

fs0:\EFI\redhat> modelist.efi
GOP reports MaxMode 6
 0: 768x480 BGRR pitch 768
 1: 960x600 BGRR pitch 960
 2: 1280x1024 BGRR pitch 1280
 3: 1024x768 BGRR pitch 1024
*4: 640x480 BGRR pitch 640
 5: 800x600 BGRR pitch 800

Grub's default set gfxmode=auto just inherits this. With set debug=video:

video/efi-gop.c:388: GOP: keeping mode 4
video/efi-gop.c:496: GOP: initialising FB @ 0xe0000000 640x480x32
video/efi-gop.c:521: GOP: Success
Comment 33 Fedora End Of Life 2013-12-21 10:06:34 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 34 Fedora End Of Life 2014-02-05 17:48:21 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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