On 02/06/2011 05:57 AM, Nate Weibley wrote: > On Fri, Feb 4, 2011 at 12:01 PM, > wrote: > > Date: Fri, 04 Feb 2011 19:19:34 +0300 > From: Vladimir '?-coder/phcoder' Serbinenko > > Subject: Re: AMI Aptio EFI booting problems on ASUS G73SW-A1 > To: grub-devel@gnu.org > Message-ID: <4D4C2716.7080201@gmail.com > > > Content-Type: text/plain; charset="utf-8" > > On 02/04/2011 04:54 PM, Nate Weibley wrote: > > Hey GRUB devs, > > > > I've been having some trouble getting GRUB2 to load Arch x86_64 > on my > > ASUS G73SW-A1. Specifically, if I do not specify noefi on the kernel > > command line in my grub.cfg everything stalls at initrd. > I don't think that it gets so far as initrd and actually panics early. > > I'm building GRUB2 from the bzr repo, so to my knowledge it > should be > > up-to-date. > > > "noefi" isn't handled at all by GRUB itself. It's just a parameter > that > it transfers to linux. So if it makes a difference. It's either: > a) (most likely) Linux doesn't handle your EFI either because of > EFI or > Linux bugs > b) GRUB passes incorrect EFI pointers. Considering that this operation > is trivial, I think this is unlikely. > GRUB can't do anything for (a). Well it could but not anything in > a sane > way. I suggest trying different Linuxes (kernels) E.g. Ubuntu, Debian, > Red Hat, git. > > > I substituted noefi for add_efi_memmap and added set debug=all > before > > initrd is used. > > > add_efi_memmap should do any difference at all. It just makes > Linux redo > some of GRUB's job. > > The system stalled again, but I did get /some /debugging output. A > > link to the output is below; apologies for having to take a picture > > with my cell phone as the laptop does not have a usable serial port > > for capture. > > http://imgur.com/40lLO > > I should point out that adding set debug=all appears to stall the > > system at the same point even if noefi is still set for the > kernel... > > so perhaps this stall is not indicative of the initrd failure. I > read > > through the thread suggesting that there was a bug present with > system > > over 8GB, but it was my impression that the bug was patched. > Are you sure? It may be indicative of a failure when printing debug > output. Previously there was such bug when GRUB tried to use already > finalised EFI services to print debug output but AFAICT it's > already fixed. > > If I can provide any additional info or take any additional > debugging > > steps, please let me know. > > > > -- > > --Nate Weibley > > > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > http://lists.gnu.org/mailman/listinfo/grub-devel > > > > > -- > Regards > Vladimir 'φ-coder/phcoder' Serbinenko > > Vladimir, > Per your suggestion I tried other linux distros with various kernels. > So far none of the EFI enabled distros are working. They do work if > booted via BIOS though, of course. Windows 7 64bit /does / boot > appropriately via EFI, so it's hard to say where the fault is. If > Windows is booting though, it seems more likely something is going > wrong in the Linux kernel EFI handling, or perhaps as you say GRUB is > passing incorrect pointers. Either way, they all exhibit the exact > same behavior... the kernel is loaded, and at the point init should be > called, the system stalls with no debug or error message. On EFI Linux has no early printk other than to a serial. So you receive no messages unless you're connected to serial. It makes diagnosis much more difficult. > > > I will continue testing as kernel revisions are released, but I'm not > sure how else I can bang away at trying to get EFI to boot without any > sort of error message or debugging info. > > -- > --Nate Weibley > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko