grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UEFI Secureboot not succeeding with Grub 2.06 and later version


From: Daniel Kiper
Subject: Re: UEFI Secureboot not succeeding with Grub 2.06 and later version
Date: Wed, 14 Jul 2021 15:14:39 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Mon, Jul 12, 2021 at 04:20:56PM +0000, Sayanta Pattanayak wrote:
> Hi Daniel,
>
> Secureboot worked fine with the change(GRUB_FILE_TYPE_LINUX_KERNEL -> 
> GRUB_FILE_TYPE_NONE) you suggested.

Great!

> disk/efi/efidisk.c:531: opening hd0 succeeded
> partmap/gpt.c:93: Read a valid GPT header
> partmap/gpt.c:115: GPT entry 0: start=2048, length=40959
> partmap/gpt.c:115: GPT entry 1: start=43008, length=409599
> kern/fs.c:56: Detecting ext2...
> kern/verifiers.c:88: file: /Image type: 0
> disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xcc40 from hd0
> loader/arm64/linux.c:61: UEFI stub kernel:
> loader/arm64/linux.c:62: PE/COFF header @ 00000040
> loader/arm64/linux.c:316: kernel file size: 34054136
> loader/arm64/linux.c:318: kernel numpages: 8314
> disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xcc80 from hd0
> disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xccc0 from hd0
> ....
> loader/efi/fdt.c:63: allocating 1155 bytes for fdt
> loader/arm64/linux.c:89: Initrd @ 0xf6e20000-0xf6fffa00
> loader/efi/fdt.c:97: Installed/updated FDT configuration table @ 0xf71d0000
> Loading driver at 0x000F4D10000 EntryPoint=0x000F650EDD8
> Loading driver at 0x000F4D10000 EntryPoint=0x000F650EDD8
> loader/arm64/linux.c:144: linux command line: 'BOOT_IMAGE=/Image acpi=force
> console=ttyAMA0,115200 ip=dhcp
> root=PARTUUID=9c53a91b-e182-4ff1-aeac-6ee2c432ae94 rootwait verbose debug'
> loader/arm64/linux.c:159: starting image 0xfca9a798
> EFI stub: Booting Linux Kernel...
> EFI stub: EFI_RNG_PROTOCOL unavailable
> EFI stub: UEFI Secure Boot is enabled.
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
>
> We understand LoadImage() interface is used in our platform, but if
> the error scenario is not expected with LoadImage() interface then we
> need further investigation. We are trying to look into it.
>
> What can we infer from the change you suggested and that it worked? Do
> we need to make certain changes in our platform?

The change which I suggested was just a check for my theory. It is not
real fix. We have to fix this issue in the GRUB in a different way. This
is not your fault. When we have a fix we will ask you for some tests.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]