Description of problem: When the system starts on a Lenovo t61 laptop the grub2 menu is illegible. The entries are there though, and after 5 seconds f17 starts without problems. And also If I blindly move the cursor down, I'm able to start another OS present on my disk. Version-Release number of selected component (if applicable): Fedora 17 x86_64 RC2, Fedora 17 x86_64 RC4, Grub2 How reproducible: Install f17, and reboot. Steps to Reproduce: 1. 2. 3. Actual results: After reading bug #796690, I opened my /etc/default/grub and found there's no 'GRUB_GFXMODE' entry: ==begin of old /etc/default/grub file==== GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True rd.luks=0 KEYTABLE=la-latin1 LANG=en_US.UTF-8 rhgb quiet" #GRUB_THEME="/boot/grub2/themes/system/theme.txt" ==end of old /etc/default/grub file==== So, I added that entry manually ==begin of actual /etc/default/grub file==== GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True rd.luks=0 KEYTABLE=la-latin1 LANG=en_US.UTF-8 rhgb quiet" GRUB_GFXMODE="1024x768" #GRUB_THEME="/boot/grub2/themes/system/theme.txt" ==end of actual /etc/default/grub file==== Updated grub2: # grub2-mkconfig -o /boot/grub2/grub.cfg And now the grub2 menu is perfectly readable. Expected results: Additional info:
grub2 will use one of the resolutions proposed by the bios/firmware - and they do apparently propose a resolution that doesn't work. Please verify that you are running the latest firmware update for your machine. If you are running the latest firmware then please file a bug report and ask them for an update. It would be unfortunate for the vendor if grub2 had to blacklist their hardware as broken and implement a workaround.
(In reply to comment #1) > grub2 will use one of the resolutions proposed by the bios/firmware - and > they do apparently propose a resolution that doesn't work. > > Please verify that you are running the latest firmware update for your > machine. If you are running the latest firmware then please file a bug > report and ask them for an update. > > It would be unfortunate for the vendor if grub2 had to blacklist their > hardware as broken and implement a workaround. Mads, I've just updated the BIOS to the last version, and unfortunately the resolution is still wrong (thanks for improving the title) Do you think installing again f17 could solve this? Regards, daniel.
It still looks like a BIOS/firmware issue to me. You should file a bug with your hardware vendor. I doubt reinstalling f17 will make any difference. You didn't tell which f17 prerelease you installed and which grub2 package you are using (and if grub2-install and grub2-mkconfig has been run with that version) so I can't tell.
(In reply to comment #3) > It still looks like a BIOS/firmware issue to me. You should file a bug with > your hardware vendor. > > I doubt reinstalling f17 will make any difference. You didn't tell which f17 > prerelease you installed and which grub2 package you are using (and if > grub2-install and grub2-mkconfig has been run with that version) so I can't > tell. I thought I had done it on my first post: This issue arise after installing F17 x86_64 RC2, and F17 x86_64 RC4. Now I'm using RC4, and the actual grub2 version is 2.0-0.25beta4.fc17 x86_64. After any changes have always updated the grub with # grub2-mkconfig -o /boot/grub2/grub.cfg However I'm not really sure how to report this to Lenovo. Regards, Daniel.
(In reply to comment #4) > This issue arise after installing F17 x86_64 RC2, and F17 x86_64 RC4. Now > I'm using RC4, and the actual grub2 version is 2.0-0.25beta4.fc17 x86_64. > After any changes have always updated the grub with > # grub2-mkconfig -o /boot/grub2/grub.cfg That will just generate a new configuration - it will not put the boot loader in place. You should grub grub2-install /dev/sdX first.
(In reply to comment #5) > > That will just generate a new configuration - it will not put the boot > loader in place. You should grub grub2-install /dev/sdX first. Mads, thanks for your patience, but unfortunately the problem remains. I reinstalled the grub, without success, and I made a new installation of the final version of F17. The results are always the same. Regards, daniel.
Could you tell what Preffered mode in the output of "videoinfo" command in the shell is. What is the resolution of the panel in question? Could you try the patch I've attached to the bug report #827003 ?
The patch is included in the unofficial beta6 scratch build on http://koji.fedoraproject.org/koji/taskinfo?taskID=4121699 Install grub2 and grub2-tools rpms, grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg
(In reply to comment #7) > Could you tell what Preffered mode in the output of "videoinfo" command in > the shell is. What is the resolution of the panel in question? Could you try > the patch I've attached to the bug report #827003 ? phcoder, The Preferred mode of "videoinfo" command is: 1440x900 The resolution of the monitor is 1440x900, but it doesn't work if I give that value to the 'GRUB_GFXMODE' entry manually added to the /etc/default/grub file. It only works with "1024x768" resolution, or lower. The patch attached in bug report #827003 didn't work for me. Below I give one more detail. (In reply to comment #8) > The patch is included in the unofficial beta6 scratch build on > http://koji.fedoraproject.org/koji/taskinfo?taskID=4121699 > > Install grub2 and grub2-tools rpms, > grub2-install /dev/sda > grub2-mkconfig -o /boot/grub2/grub.cfg Mads, Thanks for building those rpms, but they didn't work for this laptop. Also, after installing them, reinstall grub and generate the new configuration, the file /etc/default/grub was gone.
(In reply to comment #9) > Thanks for building those rpms, but they didn't work for this laptop. Please clarify in what way they didn't work. Or did they work just as well as the f17 grub - only not better? > Also, > after installing them, reinstall grub and generate the new configuration, > the file /etc/default/grub was gone. /etc/default/grub is marked as a configuration file, customizations should never be touched when grub2 is installed or upgraded or removed. (The f17 rpm contains a sample file that always is overwritten by anaconda - the scratch rpm do not have that sample file.) Please show the commands that can reproduce the problem.
(In reply to comment #10) > > Please clarify in what way they didn't work. Or did they work just as well > as the f17 grub - only not better? Sorry for that. The rpms worked just as well as the previous f17 grub: The lines of the menu can't be seen on the screen. Its all fuzzy. > > /etc/default/grub is marked as a configuration file, customizations should > never be touched when grub2 is installed or upgraded or removed. (The f17 > rpm contains a sample file that always is overwritten by anaconda - the > scratch rpm do not have that sample file.) Please show the commands that can > reproduce the problem. Here's the complete transaction I've made: http://fpaste.org/FeMs/
(In reply to comment #11) > The lines of the menu can't be seen on the screen. Its all fuzzy. Please attach a photo to illustrate what kind of fuzziness you get. > Here's the complete transaction I've made: http://fpaste.org/FeMs/ Ok. When you remove the beta4 rpm it will (re)move its configuration file. It should be saved as grub.rpmsave ... unless multiple testing has overwritten it. If upgrading without uninstalling the old version first then everything should be fine. I'm sorry I said 'install' - shouldn't have been taken that literally.
Created attachment 588991 [details] Grub2 menu on a Lenovo t61 laptop.
(In reply to comment #12) > Please attach a photo to illustrate what kind of fuzziness you get. Done > Ok. When you remove the beta4 rpm it will (re)move its configuration file. > It should be saved as grub.rpmsave ... unless multiple testing has > overwritten it. > > If upgrading without uninstalling the old version first then everything > should be fine. I'm sorry I said 'install' - shouldn't have been taken that > literally. Perfect. Upgraded it without uninstalling and the /etc/default/grub remains. Thanks.
Some kind of horizontal sync problem. Please attach the output of dmesg and /var/log/Xorg.0.log from a system booted from the fuzzy grub2. That might tell which resolution grub used and what options it had.
Created attachment 588993 [details] Info collecting patch Looks like wrong pitch. About 1/8 off. Can you apply the attached patch and copy the lines (or, preferably, take a picture of) for 1440x900 modes?
I meant the lines in "videoinfo" as run from console.
I meant the lines in "videoinfo" as run from GRUB console.
(In reply to comment #18) > I meant the lines in "videoinfo" as run from GRUB console. phcoder, I'm sorry but I'm afraid I can't apply the patch. I downloaded the attachment as plain text, extract grub2-2.0-0.32.beta6.fc17.x86_64.rpm and within the directory created ran $ patch -p0 < /path/to/downloaded/attachment This is the output: "can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |=== modified file 'grub-core/commands/videoinfo.c' |--- grub-core/commands/videoinfo.c 2012-03-10 12:19:46 +0000 |+++ grub-core/commands/videoinfo.c 2012-06-04 01:11:55 +0000 -------------------------- File to patch:" Could you please be so kind to give me the propper commands to do this? And also any other instructions I may need.
You have to patch source, not binary.
I had the same issue and popped onto #grub. I hope this photo of "videoinfo" with a patched grub is of use..
Created attachment 590748 [details] Screenshot
A unofficial scratch build with the patch can currently be found on http://koji.fedoraproject.org/koji/taskinfo?taskID=4145986
Created attachment 591042 [details] 'videoinfo' output using grub2-2.0-0.36.beta6+4419
(In reply to comment #22) > Created attachment 590748 [details] > Screenshot Thanks David, I wasn't able to build the rpm after applying the patch. (In reply to comment #23) > A unofficial scratch build with the patch can currently be found on > http://koji.fedoraproject.org/koji/taskinfo?taskID=4145986 Mads, thanks again but unfortunately still not working. Atached I leave a photo of my 'videoinfo'.
I have same behaviour on lenovo T400. Smolt profile at http://www.smolts.org/client/show/pub_763c7014-7669-4415-bb05-ea8873eb3aba
(In reply to comment #26) > I have same behaviour on lenovo T400. Please state explicitly which grub2 version you are using - and that you have run something like grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg Please also give http://koji.fedoraproject.org/koji/buildinfo?buildID=345565 a try.
Grub2 is the version which currently comes when one does fedora17 network install. [jani ~]$ grub2-install -v grub2-install (GRUB) 2.00~beta6 Installed Packages grub2.x86_64 1:2.0-0.37.beta6.fc17 @updates grub2-tools.x86_64 1:2.0-0.37.beta6.fc17 @updates grubby.x86_64 8.12-1.fc17 @updates Will try the suggested version and let you know how it goes.
Unfortunately, the packages suggested didn't solve the issue. Downloaded, installed, executed: grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg and restarted. The issue was not solved. [jani ~]$ yum list installed grub* Loaded plugins: langpacks, presto, refresh-packagekit fedora/primary_db | 14 MB 00:14 Installed Packages grub2.x86_64 1:2.0-0.38.beta6.fc17 @/grub2-2.0-0.38.beta6.fc17.x86_64 grub2-debuginfo.x86_64 1:2.0-0.38.beta6.fc17 @/grub2-debuginfo-2.0-0.38.beta6.fc17.x86_64 grub2-efi.x86_64 1:2.0-0.38.beta6.fc17 @/grub2-efi-2.0-0.38.beta6.fc17.x86_64 grub2-tools.x86_64 1:2.0-0.38.beta6.fc17 @/grub2-tools-2.0-0.38.beta6.fc17.x86_64 grubby.x86_64 8.12-1.fc17 @updates
Created attachment 630498 [details] Xorg.0.log for T400 Xorg.0.log was requested at some point, but never attached.
*** Bug 875347 has been marked as a duplicate of this bug. ***
Just to get a stable point of reference (and test a possible workaround): Please report back if the final 2.0 works. The f18 package with 2.0 can be used on f17 with: yum --releasever=18 update grub2-tools --nogpgcheck and grub2-install and grub2-mkconfig.
(In reply to comment #32) > Just to get a stable point of reference (and test a possible workaround): > Please report back if the final 2.0 works. The f18 package with 2.0 can be > used on f17 with: > yum --releasever=18 update grub2-tools --nogpgcheck > and grub2-install and grub2-mkconfig. grub2-2.00-12.fc18.x86_64 does NOT fix the problem.
Same with my T400 - issue not fixed grub2.x86_64 1:2.00-12.fc18 grub2-tools.x86_64 1:2.00-12.fc18
Hello Folks, Same issue on T400 as well. On my T530 the grub2 worked as expected probably because the monitor support a higher resolution than my T400. Setting the resolution at /etc/default/grub addressed the issue.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 17'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.
Issue still persists: Fedora 18 grub2.x86_64 1:2.00-15.fc18 Lenovo T400 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 20e4 Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at f4400000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Subsystem: Lenovo Device 20e4 Flags: bus master, fast devsel, latency 0 Memory at f4200000 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3
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.