Re: [gentoo-user] snafu: the update

2017-01-27 Thread Tom H
On Wed, Jan 25, 2017 at 6:58 PM, Alan Grimes  wrote:
> Tom H wrote:


>> AFAIK, when you load the kernel directly from the EFI firmware, it has
>> to have the ".efi" suffix. But that doesn't explain why it would stall
>> when loaded from grub...
>>
>> Somewhat OT: Regarding grub, your "/boot/" is messy. It might not be
>> making a difference for (efi)-grub2's functioning but you have grub1
>> files (*stage1_5), grub2 bios files (i386-pc/), as well as grub2 efi
>> files (x86_64-efi/).
>
> Yeah, I've been using that directory for many many long years, I ended
> up removing the grub directory completely and re-installing, it's much
> cleaner now.

ACK. I just thought that I'd point it out.


> I think there's something with how I'm compiling the kernel and the EFI
> boot requirements aren't quite being met and the loader is trying to
> execute non-code or some other error of that general nature. But that's
> just a brainstorm, I really hate it when my machine gives me this kind
> of problem where I don't even have an error message.

If you're loading the kernel from grub, you don't have to compile the
efi stub/stuff into the kernel.


>  FROM GRUB.CFG #
>
> echo 'Loading Linux 4.6.7 ...'
>  it successfully executes this line
> linux /vmlinuz-4.6.7 root=/dev/sda2 ro
>  but fails before the first output from the kernel
>
> 

Looking at your grub.cfg, I wonder whether "linux /vmlinuz-4.6.7 ..."
is correct.

Looking at your original "tree" output, it looks like you're mounting
the ESP at "/boot" and that grub's being loaded from
"/boot/EFI/gentoo/grubx64.efi".

What are the grub.cfg lines that start with "search" and "set root"?



Re: [gentoo-user] snafu: the update

2017-01-25 Thread Alan Grimes
Tom H wrote:
> On Wed, Jan 25, 2017 at 1:05 PM, Alan Grimes  wrote:
>> The linux kernel stalls stone cold dead in either direct from firmware
>> or pass through grub mode.
> AFAIK, when you load the kernel directly from the EFI firmware, it has
> to have the ".efi" suffix. But that doesn't explain why it would stall
> when loaded from grub...
>
> Somewhat OT: Regarding grub, your "/boot/" is messy. It might not be
> making a difference for (efi)-grub2's functioning but you have grub1
> files (*stage1_5), grub2 bios files (i386-pc/), as well as grub2 efi
> files (x86_64-efi/).

Yeah, I've been using that directory for many many long years, I ended
up removing the grub directory completely and re-installing, it's much
cleaner now.

I think there's something with how I'm compiling the kernel and the EFI
boot requirements aren't quite being met and the loader is trying to
execute non-code or some other error of that general nature. But that's
just a brainstorm, I really hate it when my machine gives me this kind
of problem where I don't even have an error message.

 FROM GRUB.CFG #

echo'Loading Linux 4.6.7
...'    it successfully executes
this line.
linux   /vmlinuz-4.6.7 root=/dev/sda2 ro
check_enable_amd_mmconf amd_iommu=fullflush iommu=soft

 but fails before the first output from the kernel.


Hmm, I just realized that I had been assuming my machine had a proper 64
bit loader, maybe it's 32 bit for some stupid reason, enabling kernel
flag and doing another test (after dinner and some youtube vids...)

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.




Re: [gentoo-user] snafu: the update

2017-01-25 Thread Tom H
On Wed, Jan 25, 2017 at 1:05 PM, Alan Grimes  wrote:
>
> The linux kernel stalls stone cold dead in either direct from firmware
> or pass through grub mode.

AFAIK, when you load the kernel directly from the EFI firmware, it has
to have the ".efi" suffix. But that doesn't explain why it would stall
when loaded from grub...

Somewhat OT: Regarding grub, your "/boot/" is messy. It might not be
making a difference for (efi)-grub2's functioning but you have grub1
files (*stage1_5), grub2 bios files (i386-pc/), as well as grub2 efi
files (x86_64-efi/).



[gentoo-user] snafu: the update

2017-01-25 Thread Alan Grimes
I re-installed grub and now it boots through the grub menu to the point
of handing off to the linux kernel. The linux kernel stalls stone cold
dead in either direct from firmware or pass through grub mode.

So I think Grub is 97.6% exonerated at this point.

This is my standard kernel.org pure vanilla 4.6.7 kernel, the obvious
EFI config variables have been set... No idea, will be trolling the
##linux channel for the next few hours...

-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.