Bug 825506 - wrong video mode pitch on Lenovo T61
wrong video mode pitch on Lenovo T61
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
18
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 875347 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-26 21:16 EDT by Daniel Cabrera
Modified: 2014-02-05 06:59 EST (History)
11 users (show)

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


Attachments (Terms of Use)
Grub2 menu on a Lenovo t61 laptop. (91.54 KB, image/jpeg)
2012-06-03 21:03 EDT, Daniel Cabrera
no flags Details
Info collecting patch (546 bytes, patch)
2012-06-03 21:15 EDT, Vladimir Serbinenko
no flags Details | Diff
Screenshot (843.65 KB, image/jpeg)
2012-06-10 10:07 EDT, David Riches
no flags Details
'videoinfo' output using grub2-2.0-0.36.beta6+4419 (251.86 KB, image/jpeg)
2012-06-11 19:56 EDT, Daniel Cabrera
no flags Details
Xorg.0.log for T400 (36.26 KB, text/plain)
2012-10-20 13:17 EDT, japa-fi
no flags Details

  None (edit)
Description Daniel Cabrera 2012-05-26 21:16:13 EDT
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:
Comment 1 Mads Kiilerich 2012-05-27 18:48:06 EDT
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.
Comment 2 Daniel Cabrera 2012-05-28 19:40:21 EDT
(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.
Comment 3 Mads Kiilerich 2012-05-29 05:09:30 EDT
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.
Comment 4 Daniel Cabrera 2012-05-29 21:49:59 EDT
(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.
Comment 5 Mads Kiilerich 2012-05-30 08:33:37 EDT
(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.
Comment 6 Daniel Cabrera 2012-05-31 21:19:17 EDT
(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.
Comment 7 Vladimir Serbinenko 2012-06-02 05:34:51 EDT
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 ?
Comment 8 Mads Kiilerich 2012-06-02 14:51:12 EDT
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
Comment 9 Daniel Cabrera 2012-06-03 14:41:30 EDT
(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.
Comment 10 Mads Kiilerich 2012-06-03 18:14:52 EDT
(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.
Comment 11 Daniel Cabrera 2012-06-03 19:54:00 EDT
(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/
Comment 12 Mads Kiilerich 2012-06-03 20:24:31 EDT
(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.
Comment 13 Daniel Cabrera 2012-06-03 21:03:11 EDT
Created attachment 588991 [details]
Grub2 menu on a Lenovo t61 laptop.
Comment 14 Daniel Cabrera 2012-06-03 21:05:13 EDT
(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.
Comment 15 Mads Kiilerich 2012-06-03 21:10:42 EDT
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.
Comment 16 Vladimir Serbinenko 2012-06-03 21:15:47 EDT
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?
Comment 17 Vladimir Serbinenko 2012-06-04 06:12:09 EDT
I meant the lines in "videoinfo" as run from console.
Comment 18 Vladimir Serbinenko 2012-06-04 06:12:32 EDT
I meant the lines in "videoinfo" as run from GRUB console.
Comment 19 Daniel Cabrera 2012-06-04 19:21:31 EDT
(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.
Comment 20 Vladimir Serbinenko 2012-06-04 19:32:52 EDT
You have to patch source, not binary.
Comment 21 David Riches 2012-06-10 10:06:30 EDT
I had the same issue and popped onto #grub.

I hope this photo of "videoinfo" with a patched grub is of use..
Comment 22 David Riches 2012-06-10 10:07:19 EDT
Created attachment 590748 [details]
Screenshot
Comment 23 Mads Kiilerich 2012-06-10 10:10:50 EDT
A unofficial scratch build with the patch can currently be found on http://koji.fedoraproject.org/koji/taskinfo?taskID=4145986
Comment 24 Daniel Cabrera 2012-06-11 19:56:55 EDT
Created attachment 591042 [details]
'videoinfo' output using grub2-2.0-0.36.beta6+4419
Comment 25 Daniel Cabrera 2012-06-11 19:57:51 EDT
(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'.
Comment 26 japa-fi 2012-08-10 08:51:19 EDT
I have same behaviour on lenovo T400.

Smolt profile at http://www.smolts.org/client/show/pub_763c7014-7669-4415-bb05-ea8873eb3aba
Comment 27 Mads Kiilerich 2012-08-10 09:30:09 EDT
(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.
Comment 28 japa-fi 2012-08-12 06:58:12 EDT
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.
Comment 29 japa-fi 2012-08-12 10:50:44 EDT
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
Comment 30 japa-fi 2012-10-20 13:17:02 EDT
Created attachment 630498 [details]
Xorg.0.log for T400

Xorg.0.log was requested at some point, but never attached.
Comment 31 Account closed by user 2012-11-10 12:31:00 EST
*** Bug 875347 has been marked as a duplicate of this bug. ***
Comment 32 Mads Kiilerich 2012-11-10 16:26:59 EST
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.
Comment 33 Account closed by user 2012-11-10 17:05:04 EST
(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.
Comment 34 japa-fi 2012-11-11 05:42:42 EST
Same with my T400 - issue not fixed
grub2.x86_64 1:2.00-12.fc18
grub2-tools.x86_64 1:2.00-12.fc18
Comment 35 Marcelo Moreira de Mello 2013-01-22 11:21:41 EST
  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.
Comment 36 Fedora End Of Life 2013-07-03 22:37:11 EDT
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.
Comment 37 japa-fi 2013-07-17 08:19:48 EDT
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
Comment 38 Fedora End Of Life 2013-12-21 03:37:00 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 39 Fedora End Of Life 2014-02-05 06:59:00 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.