grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AMI Aptio EFI booting problems on ASUS G73SW-A1


From: Nate Weibley
Subject: Re: AMI Aptio EFI booting problems on ASUS G73SW-A1
Date: Sat, 5 Feb 2011 21:57:06 -0500

On Fri, Feb 4, 2011 at 12:01 PM, <address@hidden> wrote:
Date: Fri, 04 Feb 2011 19:19:34 +0300
From: Vladimir '?-coder/phcoder' Serbinenko     <address@hidden>
Subject: Re: AMI Aptio EFI booting problems on ASUS G73SW-A1
To: address@hidden
Message-ID: <address@hidden>
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
> address@hidden
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]