From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OUolC-00024g-FH for mharc-grub-devel@gnu.org; Fri, 02 Jul 2010 18:31:02 -0400 Received: from [140.186.70.92] (port=50681 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUol3-0001vG-Hn for grub-devel@gnu.org; Fri, 02 Jul 2010 18:31:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUol1-0004r1-Ov for grub-devel@gnu.org; Fri, 02 Jul 2010 18:30:53 -0400 Received: from mailbigip.dreamhost.com ([208.97.132.5]:50741 helo=homiemail-a25.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUol1-0004qk-CA for grub-devel@gnu.org; Fri, 02 Jul 2010 18:30:51 -0400 Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 5D6F6678083 for ; Fri, 2 Jul 2010 15:30:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hyarros.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=hyarros.com; b=r8mF8HUCtB8T73vXKd9OuzrbZUY5VqP26/pir8fb5ilCOgRRKy+Li9OHhA/H2 7Sect/Zuaoyc6226igI1n8AyGRRmB9ZhcHiP8f/iwPFx2vfo46bwCfUjuzX1+OvA hrzY2BAaRckXwMcKQtd40RrM/zuRCkKESXovI3YHxuef/Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hyarros.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=hyarros.com; bh=eOVOh DOaJ+M3QMAiMs4bn1SDhOc=; b=Z6jX8Cjv5GdCK3xu5/S1V/xDrRKgfELqIyPnF VhzZTdZCHGDJvTiSIgaVW6oZP+zM0ownVoaH/ttyH23xaSKjh2sFVkuV4kPg1Qe3 dQjyiwM+opVX634fFgv75+rXlFN9ym3ydUPm5rXKZSuktw3ANJHJkLRUytoyIcU5 BmnaSI= Received: from [192.168.10.149] (c-76-115-91-115.hsd1.wa.comcast.net [76.115.91.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: stephen@hyarros.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 1EE82678069 for ; Fri, 2 Jul 2010 15:30:49 -0700 (PDT) Message-ID: <4C2E6886.2040108@hyarros.com> Date: Fri, 02 Jul 2010 15:30:30 -0700 From: Stephen Kou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: The development of GNU GRUB References: <3939aba7614d81ab0dbb3b1cd5d35caa@mail.hyarros.com> <20100630094029.GN21862@riva.ucam.org> <812455549bed0694b404058d9ebde40a@mail.hyarros.com> <29469ec35f179518469146be812f293b@mail.hyarros.com> <06881849-C7DC-47DA-85CE-1F154C067354@oracle.com> <4887b11d3258f60d58afeba6f4bdb343@mail.hyarros.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: UEFI Boot with Grub-Experimental X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 22:31:00 -0000 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 >> 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 >>>> 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, 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, 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 >>>>>>> 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 >>>>>>>>> >>>>>>>>> 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