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

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

[Nate Weibley]

[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]

On Fri, Feb 4, 2011 at 12:01 PM, <grub-devel-request@gnu.org> wrote:

> Date: Fri, 04 Feb 2011 19:19:34 +0300
> From: Vladimir '?-coder/phcoder' Serbinenko     <phcoder@gmail.com>
> 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.

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

[-- Attachment #2: Type: text/html, Size: 4554 bytes --]

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

[Bruce Dubbs]

Nate Weibley wrote:

> 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.

I am not an expert in GRUB or EFI, but what it sounds like to me is that 
the initrd for the systems you are using does not have EFI support.

Personally, I never use initrd but build my own kernels with all 
capabilities needed built in (not modules).  You can test this by 
building your own kernel and ensure EFI_PARTITION is built in during the 
configure phase.

   -> File systems 

      -> Partition Types 

          -> Advanced partition selection (PARTITION_ADVANCED [=y])

Then if the kernel image is, say, /boot/linux-2.6.37, an entry in 
boot.cfg like:

menuentry "My test kernel" {
         set root=(hd0,<your partition>)
         linux   /boot/linux-2.6.37 root=/dev/<your partition> ro
}

would be all that's needed.

That may not be your final answer, but if it does boot, then GRUB is 
doing it's job and the problem is in the distro you are using.

   -- Bruce

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On 02/06/2011 07:56 AM, Bruce Dubbs wrote:
> Nate Weibley wrote:
>
>> 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.
>
> I am not an expert in GRUB or EFI, but what it sounds like to me is
> that the initrd for the systems you are using does not have EFI support.
>
> Personally, I never use initrd but build my own kernels with all
> capabilities needed built in (not modules).  You can test this by
> building your own kernel and ensure EFI_PARTITION is built in during
> the configure phase.
>
>   -> File systems
>      -> Partition Types
>          -> Advanced partition selection (PARTITION_ADVANCED [=y])
>
This answer is 100 % irrelevant. Don't confuse EFI and GPT.
> Then if the kernel image is, say, /boot/linux-2.6.37, an entry in
> boot.cfg like:
>
> menuentry "My test kernel" {
>         set root=(hd0,<your partition>)
>         linux   /boot/linux-2.6.37 root=/dev/<your partition> ro
> }
>
> would be all that's needed.
>
> That may not be your final answer, but if it does boot, then GRUB is
> doing it's job and the problem is in the distro you are using.
>
>   -- Bruce
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]

On 02/06/2011 05:57 AM, Nate Weibley wrote:
> On Fri, Feb 4, 2011 at 12:01 PM, <grub-devel-request@gnu.org
> <mailto:grub-devel-request@gnu.org>> wrote:
>
>     Date: Fri, 04 Feb 2011 19:19:34 +0300
>     From: Vladimir '?-coder/phcoder' Serbinenko     <phcoder@gmail.com
>     <mailto:phcoder@gmail.com>>
>     Subject: Re: AMI Aptio EFI booting problems on ASUS G73SW-A1
>     To: grub-devel@gnu.org <mailto:grub-devel@gnu.org>
>     Message-ID: <4D4C2716.7080201@gmail.com
>     <mailto: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 <mailto: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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

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

[Nate Weibley]

[-- Attachment #1: Type: text/plain, Size: 5042 bytes --]

2011/2/6 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>

> On 02/06/2011 05:57 AM, Nate Weibley wrote:
> > On Fri, Feb 4, 2011 at 12:01 PM, <grub-devel-request@gnu.org
> > <mailto:grub-devel-request@gnu.org>> wrote:
> >
> >     Date: Fri, 04 Feb 2011 19:19:34 +0300
> >     From: Vladimir '?-coder/phcoder' Serbinenko     <phcoder@gmail.com
> >     <mailto:phcoder@gmail.com>>
> >     Subject: Re: AMI Aptio EFI booting problems on ASUS G73SW-A1
> >     To: grub-devel@gnu.org <mailto:grub-devel@gnu.org>
> >     Message-ID: <4D4C2716.7080201@gmail.com
> >     <mailto: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 <mailto: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.
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
> I'll say! I was hoping there would be a way to pass messages back through
grub like some sort of virtual serial port or to virtualize this but allow
interaction with my actual system EFI. Barring that, I can't even fathom how
I'd approach the next step of debugging. AFAIK this chipset doesn't
even *support
*legacy serial, so I couldn't even open my laptop and tap into some
traces/pads to get RS-232 out. I guess the best I can do is wait and see if
future kernels adhere more closely to the pure EFI spec and hope that's what
is allowing windows to boot.




-- 
--Nate Weibley

[-- Attachment #2: Type: text/html, Size: 6968 bytes --]

AMI Aptio EFI booting problems on ASUS G73SW-A1

[Nate Weibley]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

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'm building GRUB2 from the bzr
repo, so to my knowledge it should be up-to-date.

I substituted noefi for add_efi_memmap and added set debug=all before initrd
is used.

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.

If I can provide any additional info or take any additional debugging steps,
please let me know.

-- 
--Nate Weibley

[-- Attachment #2: Type: text/html, Size: 1440 bytes --]

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

AMI Aptio EFI booting problems on ASUS G73SW-A1

[Nate Weibley]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

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 linux command line
in my grub.cfg everything stalls at initrd.

I substituted noefi for add_efi_memmap and added set debug=all before initrd
is used.

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

If I can provide any additional info or take any additional debugging steps,
please let me know.

-- 
--Nate Weibley

[-- Attachment #2: Type: text/html, Size: 839 bytes --]