On Fri, Feb 4, 2011 at 12:01 PM, <[email protected]> wrote:

> Date: Fri, 04 Feb 2011 19:19:34 +0300
> From: Vladimir '?-coder/phcoder' Serbinenko     <[email protected]>
> Subject: Re: AMI Aptio EFI booting problems on ASUS G73SW-A1
> To: [email protected]
> Message-ID: <[email protected]>
> 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
> > [email protected]
> > 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.

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
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to