Created attachment 588057 [details] Xorg.0.log after boot without explicit GRUB_GFXMODE line Description of problem: Without an explicit line "GRUB_GFXMODE=XxY" in /etc/default/grub, the monitor displays an "out of range" message when it's supposed to display the grub screen, and it stays that way until X starts. Putting in the explicit line works with 640x480, 1024x768, or 1280x1024. It does NOT work with 1920x1080, even though that's the native resolution of my monitor. Version-Release number of selected component (if applicable): grub2-2.0-0.25.beta4.fc17.x86_64 How reproducible: always Additional info: I am using the proprietary nVidia driver, which shouldn't matter since the problem starts at the grub screen. Smolt URL: http://www.smolts.org/client/show/pub_ca1da1bd-b1f2-4993-b39c-63a5394c5ca1
Created attachment 588058 [details] dmesg output after boot without explicit GRUB_GFXMODE line
What is the output of set pager=1 videoinfo on the grub command line?
The kernel says [ 0.521812] vesafb: mode is 2048x1536x32, linelength=8192, pages=0 - is that only when grub also doesn't work?
(In reply to comment #2) > What is the output of > set pager=1 > videoinfo > on the grub command line? It's a large amount of output (maybe 2 dozen lines). Is there a way to save the output to a file, or do I have to write it all down, or find a camera to take a screenshot? I looked online and couldn't find any way to write a file, or redirect the output of a grub2 command to a file.
I would recommend a photo - a phone camera should be good enough if you let it focus correctly. I guess the last handful of lines will give an indication of what grub see - they could perhaps be copied by hand.
(In reply to comment #3) > The kernel says > [ 0.521812] vesafb: mode is 2048x1536x32, linelength=8192, pages=0 > - is that only when grub also doesn't work? Right now I'm using the line "GRUB_GFXMODE=1280x1024", and the dmesg line is now [ 0.515931] vesafb: mode is 1280x1024x32, linelength=5120, pages=0 so the answer appears to be yes.
(In reply to comment #5) > I would recommend a photo - a phone camera should be good enough if you let > it focus correctly. > > I guess the last handful of lines will give an indication of what grub see - > they could perhaps be copied by hand. I don't have a phone camera. If you could tell me what specifically you're looking for, I could write it down. Is there a reason that there is no facility for writing a file from the grub2 prompt?
(In reply to comment #7) > Is there a reason that there is no > facility for writing a file from the grub2 prompt? grub2 try to be safe and will only read filesystems - not write to them.
What is the preferred video mode line in videoinfo?
Created attachment 588096 [details] videoinfo output when using "GRUB_GFXMODE=1280x1024" I transcribed the whole thing. I can't tell what the preferred line is without the GRUB_GFXMODE line since the monitor would be out of range.
Hmm. Apparently no EDID detected - perhaps because of the FREEDOM HATING HARDWARE ;-) Grub thus chose the "best" = "highest" resolution: 0x152 2048 x 1536 x 32 Direct color, mask: 8/8/8/8 pos: 16/8/0/24
Created attachment 588129 [details] Patch to get additional info
Could you apply attached patch and give the additional lines in videoinfo (it will add 2-3 lines)?
I applied the patch in grub2-2.0-0.25.beta4.fc17.src.rpm, used rpmbuild to build the new version, installed it, but the output is the same. I ran grub2-mkconfig again and the result is the same. What am I missing?
Created attachment 588149 [details] videoinfo output with patch Never mind, I had to run grub2-install.
Created attachment 588166 [details] Flat panel dump, possible fix Hm, your flat panel info is just garbage. I see now that memset is at wrong place which could cause your problem if cunjuncted with additional Video BIOS bugs. Attached patch may fix the problem. If not it will add a new line in videoinfo: flat panel info dump. It is 32-byte but I'll need only first 18.
Created attachment 588179 [details] videoinfo output with second patch and with "GRUB_GFXMODE=1280x1024" Does not fix the problem, still out of range without the GRUB_GFXMODE line.
Basically your VideoBIOS reports 65042x35564 flat panel. The worst thing is that other fields (panel type and color-bpp) actually make sense. It looks like first 4 bytes were overwritten by some kind of pointer. So we have to somehow check that the size makes sense. What about rejecting anything bigger than 4096x4096? Even if something like this is real, it would result in pretty slow GRUB anyway.
Created attachment 588180 [details] Reject huge flat panels and monitors over 4096x4096 Attached patch should fix your problem.
I'm not sure if I'm applying the patch properly, so am unwilling to test it. If you can provide a binary RPM I'll test that.
André, you have applied all the other patches correctly - I'm sure you can handle this the same way. Ok?
(In reply to comment #21) > André, you have applied all the other patches correctly - I'm sure you can > handle this the same way. Ok? Unlike the earlier patches, this one patches 3 different files in different directories, and looking at one of the files, I was unable to match up what the patch file claims to do with what it actually did. If you're willing to spend the time giving painstakingly detailed instructions on how I can do it, fine. I suspect it would be easier to just provide a binary RPM.
phcoder is the upstream maintainer and obviously working on the latest version. I will prepare a rpm with the patch.
I applied the patch to grub2-2.0-0.25.beta4.fc17.src.rpm (I don't know if this is the RPM the patch was intended for, but it ought to be, since that's the current F17 version) and got the following output: [andre@compaq-pc grub-2.00~beta4]$ patch -p0 < /tmp/grub2_patch3.txt patching file grub-core/video/efi_gop.c Hunk #1 succeeded at 335 (offset -33 lines). patching file grub-core/video/i386/pc/vbe.c patching file grub-core/video/video.c [andre@compaq-pc grub-2.00~beta4]$ Despite the fact that it looked like it was guessing (the patch itself said it was supposed to be applied at line 368), I built and installed the RPM, and it does seem to fix the problem. Without any GRUB_GFXMODE line, it goes into mode 0x112 (640x480x32) which works.
Tested the build at http://koji.fedoraproject.org/koji/taskinfo?taskID=4121699 and that works as well - without the GFXMODE line, goes into mode 0x112 (640x480x32), and with GRUB_GFXMODE=1280x1024, goes into mode 0x11b (1280x1024x32).
grub2-2.0-0.37.beta6.fc17 in updates-testing also fixes this bug.
(In reply to comment #26) > grub2-2.0-0.37.beta6.fc17 in updates-testing also fixes this bug. Actually, I did have grub2-2.0-0.37.beta6.fc17.i686 installed, but I had to use grub2-install to have this problem fixed.
(In reply to comment #27) > (In reply to comment #26) > > grub2-2.0-0.37.beta6.fc17 in updates-testing also fixes this bug. > > Actually, I did have grub2-2.0-0.37.beta6.fc17.i686 installed, but I had to > use grub2-install to have this problem fixed. I'm pretty sure that's expected - I was told by kiilerich on IRC that I should use both grub2-install and grub2-mkconfig during testing, and did so (see comment 15).
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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.