Re: UEFI Boot with Grub-Experimental

[Stephen Kou <stephen@hyarros.com>]

  Most likely the disk enumeration is different than what you have in 
the grub list.

boot into a working system, plug your disk with the linux in, and then 
do sudo blkid

get the UUID of your root filesystem, and then put it as 
root=UUID=000000-0000-0000-0000-000000000 instead of /dev/sda4.

Hopefully that will work for you.

--Stephen

On 7/2/2010 11:46 AM, Reynald Lercier wrote:
> Hi Stephen,
>
> The situation is a little bit better in my side too...
>
> I recompile the 2.6.34 kernel following the instructions in 
> Documentation/x86/x86_64/uefi.txt, from the kernel linux package.
> Especially, I defined "CONFIG_FRAMEBUFFER_CONSOLE=y" int the .config 
> file instead of "CONFIG_FRAMEBUFFER_CONSOLE=m".
>
> (Do you have a difference in your side between 2.6.32 and 2.6.35 RC in 
> view of this variable ?)
>
> Kernel now boots, with the usual logs (YES !), with the noefi option,
> but I get a crash when the kernel try to access to the root device...
>
> Maybe,
> http://ubuntuforums.org/showthread.php?t=995704&highlight=framebuffer&page=112 
>
> can help.
>
> -reynald
>
> On Fri, 2 Jul 2010, stephen@hyarros.com wrote:
>
>>
>> Hi Reynold,
>>
>> I've made some progress past you recently!  I think there are bugs in
>> the Linux Kernel now that must be overcome by the folks over at kernel
>> development.  Did you try the 'noefi' kernl boot flag?  It allowed me to
>> get past the hang and my system would actually boot.
>>
>> Also, I'm using the new 2.6.35 RC kernel (the ubuntu-flavoured one,
>> acutally) -- i get a weird framebuffer hang (my screen turns orange) if
>> I use the kernel included in lucid (2.6.32).  I've yet to try 2.6.34;
>> let us know how it goes for you.
>>
>> -stephen
>>
>> On Fri, 2 Jul 2010 16:14:53 +0200 (CEST), Reynald Lercier
>> <reynald.lercier@m4x.org> wrote:
>>> I observed a similar beahaviour as stephen in my side.
>>>
>>> Especially I had no dificulty at all to switch to a 1680x1050x32
>>> graphic mode (following Piscium's advices) in the grub2 interface with
>>> what follows in grub.cfg
>>>
>>>     insmod efi_gop
>>>     insmod font
>>>     loadfont (hd1,gpt4)/usr/share/grub/unicode.pf2
>>>     insmod gfxterm
>>>     set gfxmode=1680x1050x32
>>>     set gfxpayload=1680x1050x32
>>>     terminal_output gfxterm
>>>
>>>     insmod part_gpt
>>>     insmod ext2
>>>
>>>     set timeout=10
>>>
>>>     menuentry "Linux (with fakebios + mbp62hd)" {
>>>           search  -s -f  /boot/vmlinuz-2.6.34-custom
>>>           fakebios
>>>           linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb
>>>           initrd /boot/initrd.img-2.6.34-custom
>>>     }
>>>
>>> When the power is on, rEFIt first runs, which then, when I select the
>>> corresponding icon, runs EFI grub2 (that I put in the EFI fat first
>>> partition), which in turn should boot a linux kernel. But, the laptop
>>> always hangs here, in the boot comand (black screen, no message).
>>>
>>> I tried several linux kernel, the lucid ubuntu's one
>>> (2.6.32-22-generic) and a recompiled 2.6.34-custom too. But, the
>>> laptop still always hangs at the boot up (black screen, no message).
>>> Unfortunataly, absolutely no output in any file of the /var/log
>>> directory too.
>>>
>>> Just to test further, I tried to patch the
>>> "linux-2.6.34/drivers/video/efifb.c" linux kernel file too, by adding
>>> information about my hardware (framebuffer address, stride, etc... of
>>> the GT330M nvidia crad, all obtained from rEFIt commands: pci,
>>> devices, dh, etc.) in the dmi_list[] variable as follows
>>>
>>>     static struct efifb_dmi_info {
>>>         char *optname;
>>>         unsigned long base;
>>>         int stride;
>>>         int width;
>>>         int height;
>>>     } dmi_list[] = {
>>>             ...
>>>     [M_MBP_6_2_HD] = { "mbp62hd", 0x90030000, 2048 * 4, 1680, 1050 },
>>>     [M_UNKNOWN] = { NULL, 0, 0, 0, 0 }
>>>     };
>>>
>>> I modified acordingly enum definitionw (for M_MBP_6_2_HD) and
>>> __initdata dmi_system_table.
>>>
>>> But,
>>>     linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 
>>> video=efifb:mbp62hd
>>> still behaves badly (black screen).
>>>
>>> Any idea about how I could understand further what's going on ?
>>>
>>>
>>> On Thu, 1 Jul 2010, stephen@hyarros.com wrote:
>>>
>>>>
>>>> Ah, yes -- the gfxpayload variable works.  But now after it
>>>> successfully initializes the video mode, it hangs at the boot with 
>>>> the _
>>>> (no output yet at all from kernel).
>>>>
>>>> I'm trying to boot ubuntu lucid (2.6.32-22-generic).  The EFI boot
>>>> works on some machines, one others it doesn't.
>>>>
>>>> Thanks
>>>>
>>>> On Thu, 1 Jul 2010 11:33:17 -0700, Seth Goldberg
>>>> <seth.goldberg@oracle.com> wrote:
>>>>> 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, <stephen@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, <stephen@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.lercier@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, stephen@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 
>>>>>>>>> <cjwatson@ubuntu.com>
>>>>>>>>> wrote:
>>>>>>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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