Re: UEFI Boot with Grub-Experimental

[Seth Goldberg]

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, <address@hidden> 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, <address@hidden> 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
>> <address@hidden> 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, address@hidden 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 <address@hidden>
>>>> wrote:
>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, address@hidden 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
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/grub-devel
>> 
>> 
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel