Re: 3.12 to 3.13 boot regression bisected - still applies to 3.16

From: Matt Fleming
Date: Mon Aug 04 2014 - 08:27:37 EST


On Mon, 04 Aug, at 11:34:35AM, Bruno Prémont wrote:
> Hi,
>
> Since 3.13 kernels with built-in initrd fail to boot on Fujitsu hardware
> in EFI mode (efi stub) though the exact same kernel binary does boot in
> BIOS mode (grub).
> Interestingly EFI kernels with different config do boot under VMWare.
>
> Your patch "initramfs: read CONFIG_RD_ variables for initramfs
> compression" is the trigger.
>
>
> Is something missing in EFI stub or why do things behave differently?

Nuts. I suspect it's an EFI boot stub bug. Have you definitely tried out
3.16? In particular the following commit might make a difference,

commit c7fb93ec51d4
Author: Michael Brown <mbrown@xxxxxxxxxxxxxxxx>
Date: Thu Jul 10 12:26:20 2014 +0100

x86/efi: Include a .bss section within the PE/COFF headers

The PE/COFF headers currently describe only the initialised-data
portions of the image, and result in no space being allocated for the
uninitialised-data portions. Consequently, the EFI boot stub will end
up overwriting unexpected areas of memory, with unpredictable results.

Fix by including a .bss section in the PE/COFF headers (functionally
equivalent to the init_size field in the bzImage header).

Signed-off-by: Michael Brown <mbrown@xxxxxxxxxxxxxxxx>
Cc: Thomas Bächler <thomas@xxxxxxxxxxxxx>
Cc: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Matt Fleming <matt.fleming@xxxxxxxxx>


> Looking at compiled kernel with and without this patch the resulting
> bzImage is similar in size but in build directory I get:

Could you send me the initrd image? I'd like to try and reproduce this
on my end, even though I regularly boot with a built-in initrd.

--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/