# kernel 3.8.x, efi stub, rEFInd boot issues

## khayyam

hello srs5694 ;) ... et al

I'm having the same issues as reported on the arch linux forums (here and here). Since 3.8.1 I haven't been able to boot efi_stub via rEFInd, having tried 3.8.1, 3.8.2, 3.8.4, 3.8.5 and now 3.8.6. I'm not able to use the gnu-efi built rEFInd posted as the machine is a macbook 1,1 and so 32bit EFI. I built a (0.6.8) refind_ia32.efi and drivers_ai32 using gnu-efi (sys-boot/gnu-efi-3.0s) but had some issues, the first of which is the Make.common searching /usr/lib64 and producing the following error:

```
/usr/bin/ld: cannot open linker script file /usr/lib64/elf_ia32_efi.lds: No such file or directory

make[1]: *** [refind_ia32.so] Error 1

make[1]: Leaving directory `/home/khayyam/src/refind-0.6.8/refind'

make: *** [gnuefi] Error 2
```

... which I fixed by editing the 'GNUEFILIB =' in Make.common and pointing it to /usr/lib, but the resulting binary wasn't recognised as a efi executable at boot.

I've spent a lot of time trying to figure out why the kernel wouldn't boot on each successive kernel release, and having built numerious kernels with various options enabled/disabled (including a defconfig with just the basics I needed for SATA, etc) I decided to try with grub2 to rule out the bootloader, and was supprised it booted ... though obviously not as an efi_stub. It was just by chance I stumbled on the above threads, and the issues are exactly the same, so its a relief that I'm not the only person who's run into this.

Currently the highest kernel I can boot with efi_stub is 3.7.10 anything beyond that is a no go, I assume the changes to efi are the cause, and not rEFInd directly, but I've been too busy for a git-bisect. Anyhow, I'm currently chainloading rEFInd => grub2 to boot 3.8.x so I can at least boot, but I'd like to get back to using rEFInd only if possible, so any suggestions welcome, ask if you need further information.

best ... khay

----------

## srs5694

Here's a link to my latest development rEFInd binary, compiled for IA-32 using GNU-EFI:

http://www.rodsbooks.com/refind_ia32.efi

Beyond that, my first recommendation is to begin experimenting with kernel compilation options -- both options set in the .config file and options like what version of GCC you're using to compile the kernel. Based on the fact that the problem seems to come and go between different kernel releases on Arch and the fact that under Arch different packagers (users) compile different versions of the kernel, I'm 80% convinced that the problem is caused by some such difference that's uncontrolled between Arch packagers. Unfortunately, when I tried to get the Arch community to study this issue, there were a few random and incomplete data points posted and no follow-through. Since I have yet to encounter this problem myself, I've been unable to investigate it.

It's also important that you try gummiboot and/or as many EFI shell versions as you can manage; the Arch users who've run into this problem have problems with gummiboot and some (but not all) EFI shells, so if you see a different pattern, it's conceivable you're seeing a different problem.

You could also try joining the Linux kernel mailing list and raising the issue there. I'm sure that if and when the people who wrote the EFI stub loader become aware of the problem, it will get solved quickly. I'd do this myself, but as I say, I haven't yet seen this problem, so I don't think I'm the one to file an upstream bug report.

----------

## khayyam

srs5694 ... thanks for the speedy reply, the gnu-efi refind, and the pointers.

Unfortunately the above linked refind_ia32.efi makes no difference, it hangs similarly with the same errors as the tianocore build: "failed to open initrd ..." or it just hangs if the initrd is built into the kernel. I don't think the errors are meaningful, I think they are all the result of not being able to exec the kernel. Gummiboot has the same issues, and identical errors. I've yet to try with efi shell which I guess I should trackdown and install.

As I said in my first post I've tried enabling/disabling various kernel options, including those that might have any relation to how the kernel is compiled (ie, 'Processor family', CONFIG_OPTIMIZE_INLINING), I've built vanilla-sources, geek-sources, and gentoo-sources, with practically the default options, and with any suspect options disabled (OPTIMIZE_INLINING, CGROUPS, as examples) and none has got any further than rEFInd/gummiboot. After a further 16 rebuilds yesterday after having read your pointer to a possible gcc issue I can't say I'm any the wiser.

My version of gcc is the current stable, 4.6.3, binutils is also the stable 2.22-r1, I've yet to try with other versions, though that said, Arch's toolchain is much more recent and that leads me to think that the toolchain is perhaps not at issue. Similarly my CFLAGS are fairly standard '-O2 -march=native -pipe', though that said I'm not sure exactly what the kernel does in terms of calculating KCFLAGS and KCPPFLAGS I imagine it uses whatever is passed as 'Processor family', but this is something I've tried (changing MCORE2 to MPENTIUM4) without results.

In all I'm inclined to think that the various efi changes that made their way into 3.8.0 are at issue ... but thats mostly guessing.

Time permitting I'll keep trying various things ... and post if anything suggestive should surface.

thanks again & best ... khay

----------

## srs5694

As it happens, I tried compiling a 3.8.6 kernel on my 32-bit Mac Mini yesterday, and it failed with the same symptoms others have been reporting. I traced the problem to the /usr/src/linux/arch/x86/boot/compressed/eboot.c file, and in particular to its exit_boot() call. Replacing the eboot.c file with one from a 3.6.0 kernel resulted in a bootable kernel. I haven't tried tracing the problem further than that, but I have filed a bug report with the developer of that code (Matt Fleming).

Incidentally, a message to the effect that the kernel was unable to load its initrd most likely indicates another problem. It could be that the initrd filename is getting corrupted somewhere within rEFInd, or it could be that you've got a filesystem problem that's preventing the EFI from loading the initrd. (Some EFIs seem to have flaky FAT drivers, particularly with FAT32 filesystems under 512MiB in size.)

----------

## khayyam

 *srs5694 wrote:*   

> Replacing the eboot.c file with one from a 3.6.0 kernel resulted in a bootable kernel. I haven't tried tracing the problem further than that, but I have filed a bug report with the developer of that code (Matt Fleming).

 

srs5694 ... ahh, and replacing eboot.c with the same from 3.7.10 also works here. Could you provide a link to the bug?

 *srs5694 wrote:*   

> Incidentally, a message to the effect that the kernel was unable to load its initrd most likely indicates another problem. It could be that the initrd filename is getting corrupted somewhere within rEFInd, or it could be that you've got a filesystem problem that's preventing the EFI from loading the initrd. (Some EFIs seem to have flaky FAT drivers, particularly with FAT32 filesystems under 512MiB in size.)

 

My ESP is 200MiB and FAT32, I ended up building the initramfs files into the kernel as on the first attempt after replacing eboot.c it failed with the same error. Would it be possible that having two initramfs would cause any issues ... ie, initramfs.cpio.gz and initramfs-3.8.6-geek-gnu.cpio.gz? As for the filesystem, it was something I had considered, and had reformated it a week or so back. If there are any issues with EFI then it doesn't explain why it came into effect with the jump to 3.8.x ... though it may be as I've only kept one initramfs on the volume ... something to investigate further. 

WRT the filename, is there some option in refind or refind_linux.conf to set a specific filename (initramfs.cpio.gz) for all vmlinux-{kversion}.efi? Its entriely generic and doesn't need rebuilt when updating the kernel.

Thanks again for your time & best ... khay

----------

## srs5694

There's no online bug-tracker; I'm just e-mailing Matt Fleming. (He has replied, BTW.)

I've not experimented much with multiple initrd files, so I can't offer much opinion on that. If rEFInd picks up the wrong one, of course, it won't work, but you wouldn't get the message about a missing file. You can specify a particular initrd file by including the appropriate "initrd=" option in refind_linux.conf or by creating a manual boot stanza in refind.conf.

----------

## ulenrich

 *khayyam wrote:*   

> If there are any issues with EFI then it doesn't explain why it came into effect with the jump to 3.8.x

 Hi khay, there is a patch regarding EFI coming up for linux- 3.8.7

 *Quote:*   

> commit 918708245e92941df16a634dc201b407d12bcd91 upstream.
> 
> eboot.o and efi_stub_$(BITS).o didn't get added to "targets", and hence
> 
> their .cmd files don't get included by the build machinery, leading to
> ...

  Should be released this week. I don't know if this helps. But to foster your hopes for the next compile ...

----------

## khayyam

 *ulenrich wrote:*   

> there is a patch regarding EFI coming up for linux- 3.8.7: commit 918708245e92941df16a634dc201b407d12bcd91 upstream.

 

ulenrich ... thanks for the pointer. I'm not sure this is the issue however as the patch effects only the Makefile and the 3.8.6's Makefile is identical to 3.7.10's, also if the build was at issue it wouldn't explain why swapping out eboot.c with the eboot.c from 3.7.10 would fix it, I've built both from entirely clean sources and so a "rebuild" (which the patch seems to be directed at) wouldn't factor in. That said, the patch is here should anyone reading need to find it.

I may try patching it latter today, time permitting.

Thanks again & best ... khay

----------

## srs5694

Unless the description is very poor, that patch shouldn't affect the bug. My interpretation of the description is that it prevents needless rebuilding of an already-built .o file. That shouldn't introduce a bug into a kernel, just speed up the build process (on rebuilds) by a second or so.

----------

