Which kernel or os are you loading? Did you try setting the gfxpayload env var to 1024x768?
--S On Jul 1, 2010, at 10:54 AM, <step...@hyarros.com> wrote: > Something I forgot to mention that's important -- (sorry for the spam) > -- GRUB tries to initalize with 800x600 regardless of what $gfxmode is > set to. > > set gfxmode=1024x768 > > will still result in GRUB trying to initalize the video as 800x600 > after the 'boot' command is issued. > > -stephen > > On Thu, 01 Jul 2010 10:49:59 -0700, <step...@hyarros.com> wrote: >> Hi everyone, >> >> I've had some interesting discoveries / success with this problem in >> the past couple of days. Where I am I have several machines to try out. >> On some of the machines, it works; while on others, it doesn't. I'm >> pretty sure this all has to do with the video modes now. >> >> On my laptop (which also supports UEFI), there is only one video mode >> supported as reported by efi_video_modes: 1024x768. However, when GRUB >> is booting, it calls grub_video_set_mode with the string "800x600". It >> then fails to initialize the GOP adapter (which reports it only supports >> 1024x768). Then it complains that no suitable mode is found, and tries >> to boot nayways without a video mode set. >> >> Does anyone know why it would be trying to boot as 800x600 only and not >> the 1024? >> >> I'll be looking into the code more, but thought I'd let those who are >> interested know. >> >> -stephen >> >> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier >> <reynald.lerc...@m4x.org> wrote: >>> Hi, >>> >>> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2. >>> >>> (I need full EFI booting on this machine in order to use under linux >>> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally >>> increase a lot the battery run time) >>> >>> >>> In my case efi_video_info returns >>> >>> GOP info: >>> List of video modes: >>> 0: 1680 x 1050, BGRA8, scan line 1680 >>> Current mode: 0 >>> >>> Same question, what to do now with this ? >>> >>> Thanks. >>> >>> On Wed, 30 Jun 2010, step...@hyarros.com wrote: >>> >>>> Hi, >>>> >>>> Thanks for the response. >>>> >>>> After trying terminal_output, the computer screen would simply go black >>>> and the machine would hang (the numlock key would not respond) after the >>>> terminal_output gfx command was executed; this would happen regardless >>>> of whether or not set gfxmode was called before. >>>> >>>> I also have just tried the efi_video_info patch; the system reports: >>>> >>>> GOP info: >>>> List of video modes: >>>> 0: 1024 x 768, bitonly, scan line 1024 >>>> Current mode: 0 >>>> >>>> Do i need to pass this information on to the kernel somehow? >>>> >>>> Thanks. >>>> >>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwat...@ubuntu.com> >>>> wrote: >>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, step...@hyarros.com wrote: >>>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the >>>>>> grub trunk, I've started trying to compile my own grub and getting it to >>>>>> boot on a new Intel motherboard which supports EFI. I've not been able >>>>>> to get any output yet from the acutal linux kernel; usually the system >>>>>> will simply hang after the boot menu option is selected, or the 'boot' >>>>>> command is issued from the grub command line. >>>>>> >>>>>> Currently the farthest I've gotten is using the grub command line and >>>>>> typing in the following commands: >>>>>> >>>>>> insmod efi_gop # no impact on result >>>>>> insmod ext2 >>>>>> insmod part_gpt >>>>>> >>>>>> set root=(hd0,gpt3) >>>>>> fakeroot # optional, no impact on result >>>>> >>>>> I guess that should be 'fakebios'. >>>>> >>>>>> error: no suitable mode found >>>>> >>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then >>>>> 'terminal_output gfxterm', and see what happens? Before the >>>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set >>>>> gfxmode=1024x768') to change its mode selection. gfxterm can help >>>>> matters here, as that way you have a working video mode that the kernel >>>>> can be told to inherit, rather than having to probe its own. >>>>> >>>>> Unfortunately right now it's hard to get debugging information on EFI >>>>> video modes. Since you're building your own GRUB anyway, though, you >>>>> could try this patch against trunk: >>>>> >>>>> http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch >>>>> >>>>> That will give you an 'efi_video_info' command, which should dump out >>>>> the available GOP modes, and might be useful to get a slightly better >>>>> idea of what's going on. >>>>> >>>>>> booting however >>>>>> _ >>>>>> >>>>>> And then nothing else happens. >>>>> >>>>> It's possible that the kernel may have booted successfully, but that you >>>>> simply don't have a working console. It would be useful to try pinging >>>>> the machine to test that. >>>>> >>>>>> I've also tried newreloc, but I don't think this has anything to do with >>>>>> relocations. >>>>> >>>>> Agreed. >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Grub-devel mailing list >>> Grub-devel@gnu.org >>> http://lists.gnu.org/mailman/listinfo/grub-devel >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
