Bug 859632
Summary: | gfxterm hangs when editing boot entries with large font | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | drago01 |
Component: | grub2 | Assignee: | Peter Jones <pjones> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | awilliam, bcl, dcantrell, dennis, fabrice, fweimer, kparal, mads, nobody+295318, pjones, qcai, robatino, tflink, tilmann |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | AcceptedNTH RejectedBlocker | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-02-05 22:48:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 752665 | ||
Attachments: |
Description
drago01
2012-09-22 16:18:12 UTC
Please attach a photo / VM screenshot of the problem. Created attachment 616247 [details]
Screencast showing the bug
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? 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. Created attachment 617757 [details]
VM Config
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 ? (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). *** Bug 856277 has been marked as a duplicate of this bug. *** (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. Created attachment 620196 [details]
grub.cfg with the bug
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. mads: what if you set LANG=de.utf8 ? See https://bugzilla.redhat.com/show_bug.cgi?id=858591 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. (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 ... (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.) 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. :-)
(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.) *** Bug 863412 has been marked as a duplicate of this bug. *** *** Bug 870317 has been marked as a duplicate of this bug. *** 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. Created attachment 659265 [details]
gfxterm virtual_screen.rows=15 unpatched grub2-2.00-12.fc18 ibm-x3550m3.png
Created attachment 659266 [details]
gfxterm num_entries underflow patched grub2-2.00-12.fc18 qemu-ovmf.png
Created attachment 659267 [details]
fix-num_entries-underflow.patch
For demo only. Probably needs review on a greater picture.
(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. (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. (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? (In reply to comment #26) > Am I missing anything here? Agreed. Nobody should experience this issue if bug 885090 is fixed. (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. 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. *** Bug 903277 has been marked as a duplicate of this bug. *** As stated in bug 903277, I see this issue on Lenovo X220 with 1366x768 display. 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 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. 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. |