Re: grub2 + xen + lz4 kernels

2021-11-29 Thread Juergen Gross via Grub-devel
On 30.11.21 00:25, Shaun Reitan wrote: I currently use XEN to boot PV (paravirt) virtual server instances for our customers. Grub2 introduced support for booting a xen kernel directly from a guests disk image which has worked great for years. We use the following command to build our image

Re: grub2 + xen + lz4 kernels

2021-11-29 Thread Andy Smith
Hi Shaun, On Mon, Nov 29, 2021 at 11:25:22PM +, Shaun Reitan wrote: > There are a few workarounds out their, most involve a hook that decompresses > the kernel after an update but I'm not wanting to add complexity to the > kernel update process. Another option is to switch the guest to Xen

grub2 + xen + lz4 kernels

2021-11-29 Thread Shaun Reitan
I currently use XEN to boot PV (paravirt) virtual server instances for our customers. Grub2 introduced support for booting a xen kernel directly from a guests disk image which has worked great for years. We use the following command to build our image grub-mkstandalone -O x86_64-xen -o

Re: [PATCH] Drop gnulib fix-base64.patch

2021-11-29 Thread Robbie Harwood
Daniel Kiper writes: > Yeah, but I think it would require major overhaul. Does not it? If yes > then maybe we should consider move to the Kconfig or something like > that. Perhaps, but please don't mistake me as volunteering for build system hacking - I'm mostly just here to upstream patches :)

Re: [PATCH v2 2/2] Make a "gdb" dprintf that tells us load addresses

2021-11-29 Thread Robbie Harwood
Daniel Kiper writes: > On Wed, Nov 03, 2021 at 02:22:07PM -0400, Robbie Harwood wrote: >> From: Peter Jones >> >> Add a grub_dprintf() call during platform init and during module loading >> that tells us the virtual addresses of the .text and .data sections of >> grub-core/kernel.exec and any

[PATCH v2 1/2] efinet: correct closing of SNP protocol

2021-11-29 Thread Heinrich Schuchardt
In the context of the implementation of the EFI_LOAD_FILE2_PROTOCOL for the initial ramdisk it was observed that opening the SNP protocol failed. https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00020.html This is due to an incorrect call to CloseProtocol(). The first parameter of

[PATCH v2 2/2] efi: library function grub_efi_close_protocol()

2021-11-29 Thread Heinrich Schuchardt
Create a library function for CloseProtocol() and use it for the SNP driver. Signed-off-by: Heinrich Schuchardt --- v2: adjust code style --- grub-core/kern/efi/efi.c | 12 grub-core/net/drivers/efi/efinet.c | 8 ++-- include/grub/efi/efi.h | 3

[PATCH v2 0/2] efinet: correct closing of SNP protocol

2021-11-29 Thread Heinrich Schuchardt
In the context of the implementation of the EFI_LOAD_FILE2_PROTOCOL for the initial ramdisk it was observed that opening the SNP protocol failed (https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00020.html). This is due to an incorrect call to CloseProtocol(). This is corrected in the