Re: [PATCH v2 5/8] linux/arm: account for COFF headers appearing at unexpected offsets

2021-04-08 Thread Heinrich Schuchardt
On 4/9/21 8:12 AM, Ard Biesheuvel wrote: On Thu, 8 Apr 2021 at 20:57, Heinrich Schuchardt wrote: On 10/25/20 2:49 PM, Ard Biesheuvel wrote: The way we load the Linux and PE/COFF image headers depends on a fixed placement of the COFF header at offset 0x40 into the file. This is a reasonable de

Re: [PATCH v2 3/8] efi: move MS-DOS stub out of generic PE header definition

2021-04-08 Thread Heinrich Schuchardt
On 4/9/21 8:10 AM, Ard Biesheuvel wrote: On Thu, 8 Apr 2021 at 20:45, Heinrich Schuchardt wrote: On 10/25/20 2:49 PM, Ard Biesheuvel wrote: The PE/COFF spec permits the COFF signature and file header to appear anywhere in the file, and the actual offset is recorded in 4 byte little endian fie

Re: [PATCH v2 5/8] linux/arm: account for COFF headers appearing at unexpected offsets

2021-04-08 Thread Ard Biesheuvel
On Thu, 8 Apr 2021 at 20:57, Heinrich Schuchardt wrote: > > On 10/25/20 2:49 PM, Ard Biesheuvel wrote: > > The way we load the Linux and PE/COFF image headers depends on a fixed > > placement of the COFF header at offset 0x40 into the file. This is a > > reasonable default, given that this is wher

Re: [PATCH v2 3/8] efi: move MS-DOS stub out of generic PE header definition

2021-04-08 Thread Ard Biesheuvel
On Thu, 8 Apr 2021 at 20:45, Heinrich Schuchardt wrote: > > On 10/25/20 2:49 PM, Ard Biesheuvel wrote: > > The PE/COFF spec permits the COFF signature and file header to appear > > anywhere in the file, and the actual offset is recorded in 4 byte > > little endian field at offset 0x3c of the image

Re: GRUB 2.06

2021-04-08 Thread Didier Spaier
Le 08/04/2021 à 21:28, Didier Spaier a écrit : I am fine with shipping GRUB up to some commit in Slint, but not all distributions accept to do that, or to carry a zillion patches as does Debian. As result, end users complain "GRUB is broken" whereas a patch that fix the issue of which they su

Re: [PATCH v2 5/8] linux/arm: account for COFF headers appearing at unexpected offsets

2021-04-08 Thread Heinrich Schuchardt
On 10/25/20 2:49 PM, Ard Biesheuvel wrote: The way we load the Linux and PE/COFF image headers depends on a fixed placement of the COFF header at offset 0x40 into the file. This is a reasonable default, given that this is where Linux emits it today. However, in order to comply with the PE/COFF sp

Re: [PATCH v2 3/8] efi: move MS-DOS stub out of generic PE header definition

2021-04-08 Thread Heinrich Schuchardt
On 10/25/20 2:49 PM, Ard Biesheuvel wrote: The PE/COFF spec permits the COFF signature and file header to appear anywhere in the file, and the actual offset is recorded in 4 byte little endian field at offset 0x3c of the image. When GRUB is emitted as a PE/COFF binary, we reuse the 128 byte MS-D

Re: GRUB error: unknown filesystem on ia64

2021-04-08 Thread John Paul Adrian Glaubitz
On 4/8/21 7:10 PM, Javier Martinez Canillas wrote: >> Any news on this? I assume this should be trivial to fix when considering >> just the > > Not yet, sorry. I discussed a little bit with Peter yesterday but it's strange > that only affects ia64 and not x64. I'll try to take a look at this next

GRUB 2.06

2021-04-08 Thread Didier Spaier
I am fine with shipping GRUB up to some commit in Slint, but not all distributions accept to do that, or to carry a zillion patches as does Debian. As result, end users complain "GRUB is broken" whereas a patch that fix the issue of which they suffer of has been committed upstream a long time a

Re: GRUB error: unknown filesystem on ia64

2021-04-08 Thread Javier Martinez Canillas
[ adding Peter Jones who authored the patch ] On 4/8/21 6:45 PM, John Paul Adrian Glaubitz wrote: > Hi Daniel! > > On 3/26/21 7:43 PM, Daniel Kiper wrote: >>> The address pointing to the modules within the GRUB core.img no longer >>> matches >>> the actual position of the modules. Hence, GRUB ca

Re: [PATCH 0/2] Misc doc changes

2021-04-08 Thread Daniel Kiper
On Wed, Mar 31, 2021 at 07:11:51PM -0500, Glenn Washburn wrote: > The first patch adds a long overdue note to the cryptomount command that UUIDs > should be specified without dash, differently than how fs uuids are specified. > > The second patch makes the indentation of command description text fo

Re: multiboot2 and module2 boot issues via GRUB2

2021-04-08 Thread Daniel Kiper
On Thu, Apr 01, 2021 at 08:43:46PM +0100, Andrew Cooper via Grub-devel wrote: > On 01/04/2021 09:44, Roger Pau Monné wrote: > > On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote: > >> On 01.04.2021 03:06, Roman Shaposhnik wrote: > >>> And the obvious next question: is my EVE usecase esote

Re: GRUB error: unknown filesystem on ia64

2021-04-08 Thread John Paul Adrian Glaubitz
Hi Daniel! On 3/26/21 7:43 PM, Daniel Kiper wrote: >> The address pointing to the modules within the GRUB core.img no longer >> matches >> the actual position of the modules. Hence, GRUB can't load the built-in >> modules >> anymore. > > Ahhh... OK, great. So, only one bug to fix... :-) Any ne

Re: [PATCH for 2.06] video/fbfill: use unsigned integers for width/height

2021-04-08 Thread Daniel Kiper
On Fri, Apr 02, 2021 at 02:22:04AM +1100, Daniel Axtens wrote: > Since commit 7ce3259f67ac ("video/fb/fbfill: Fix potential integer > overflow"), clang builds of grub-emu have failed with messages like: > > /usr/bin/ld: libgrubmods.a(libgrubmods_a-fbfill.o): in function > `grub_video_fbfill_direct

Re: GRUB loader support for RISC-V Linux

2021-04-08 Thread Daniel Kiper
Hey, On Wed, Apr 07, 2021 at 06:48:54PM +0300, Nikita Ermakov wrote: > Hi Atish, > > Thank you for the answer. > > On Sun, 4 Apr 2021 at 18:42, Atish Patra wrote: > > Hi Nikita, > > Yes. It was discussed earlier that we should consolidate riscv & > > ARM64 implementation as the ARM64 has a very g

Re: [PATCH 0/1] PRI* translation issues.

2021-04-08 Thread Daniel Kiper
Hey, On Sat, Apr 03, 2021 at 03:33:32PM +0200, Miguel Ángel Arruga Vivas wrote: > Hi, > > Daniel Kiper writes: > [...] > > Thank you for the report! > > You're welcome! Sorry for the delay again, I've been a bit busy. No problem. > [...] > > Could you send this patch using "git send-email"? > >