amd64 kernels starting with 3.19.1 do not boot on Apple MacPro 1,1 with EFI32 (mixed-mode EFI) Everything up to 3.19.0 is bootable (tested several kernels from 2.6.31 to 4.5.1) Attempt to boot results in no messages from kernel or any other activity after [bzImage xxx] and fakebios-related lines. Steps to reproduce: * USB Stick formatted with GPT, bootable flag set * Extract contents of http://blog.christophersmart.com/2009/12/22/updated-efi-grub2-tarball-including-64bit/ - GRUB with bootia32.efi and several netinstall kernels * use the following line in grub.cfg to exclude any initrd influence: menuentry "test kernel 64bit" { fakebios linux /efi/boot/linux priority=low vga=normal video=efifb noinitrd } Looking at 3.19.1 changelist, the suspect change in is "x86/efi: Avoid triple faults during EFI mixed mode calls" I know MacPro 1,1 is an older machine, but it is affordable, has 4 SATA bays + 2 internal SATA ports, ECC memory, quiet fans and makes a beautiful piece of furniture as a home server.
Could you try reverting the suspected commit on top of 3.19.1 and see whether that results in a booting kernel? That will at least prove/disprove your hypothesis.
Good idea, will do. Meanwhile the workaround seems to be to use "noefi" kernel parameter at boot.
I've built 2 kernels using Ubuntu .config : 3.19.1 as is and 3.19.1 with "Avoid triple faults during EFI mixed mode calls" patch reverted. "as is" 3.19.1 kernel does not boot without noefi parameter 3.19.1 compiled with the patch reverted boots just fine.
Created attachment 219991 [details] skip SetVirtualAddressMap()
Could you try applying the attached patch to 3.19.1 and see if your machine boots or at least if you get *some* output on the screen. There have been reports that some Macbooks do not like it when EFI services are accessed via the 1:1 mapping that we setup, and it's possible that that is the issue here. The attached patch skips the call to SetVirtualAddressMap() when in mixed mode.
I tested the patch and it works. I booted: * 3.19.1 stock with skip SetVirtualAddressMap() patch only and it worked * for control - 3.19.1 stock, and it did not work, as expected * for control - 3.19.1 with efi patch reverted, and it worked, as expected sorry it took a while
This problem used to be avoidable with the kernel command line option "noefi", but this is no longer working reliably since 4.9
Problem persists with kernels 4.13 and 4.14
Problem persists with kernel 4.15
macpro1,1 with original firmware and SMC coding, upgraded processors from macpro2,1 (dual qc 3.0ghz procs) - don't think any of that matters, but just so you know what i'm running this on the noefi kernel parameter is working for me. tested a debian 9 multiarch installer, elementary 5 standard installer with 32bit bootia32.efi added to /efi/boot/ folder, and now running happily on kubuntu 18.04 prepared and installed the same way; i just had to add the noefi perameter to the kernel line. i'm pretty stoked this is working now, have been posting in various places for guidance on how to pull out what might have been happening for a while now.
i might have spoken too soon. i had an existing install of kubuntu that was able to boot using the noefi option, but now i can't get anything to finish installing, failing on grub-install with an error: "grub-installer: EFI variables are not supported on this system." installing ubuntu 14.04 worked first time, now going through upgrades to see if the noefi parameter works on later kernel versions for me.
dist upgrade to 18.04 worked fine starting from 14.04 *or* 16.04, and i have a bootable 18.04 w/kernel 4.15 by passing the noefi option or the noexec=off option. dist upgrade from 16.04 to 18.04 printed the same errors but since it's not also crashing the installer, the upgrade completes successfully and end up with a system that just needs one of the parameters passed.