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 <mbr...@fensystems.co.uk>
  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 <mbr...@fensystems.co.uk>
      Cc: Thomas Bächler <tho...@archlinux.org>
      Cc: Josh Boyer <jwbo...@fedoraproject.org>
      Cc: <sta...@vger.kernel.org>
      Signed-off-by: Matt Fleming <matt.flem...@intel.com>


> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to