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:

srs5694 · Posted: Tue Apr 09, 2013 3:48 pm Post subject:

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 · Posted: Wed Apr 10, 2013 7:50 am Post subject:

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 · Posted: Wed Apr 10, 2013 2:12 pm Post subject:

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 · Posted: Wed Apr 10, 2013 6:42 pm Post subject:

srs5694 · Posted: Thu Apr 11, 2013 4:20 pm Post subject:

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 · Veteran Joined: 10 Oct 2010 Posts: 1480

khayyam · Posted: Fri Apr 12, 2013 6:37 am Post subject:

srs5694 · Posted: Fri Apr 12, 2013 5:13 pm Post subject:

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.