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

[Daniel Kiper]

On Mon, Nov 29, 2021 at 06:11:36PM -0500, Robbie Harwood wrote:
> 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 modules it loads.
> >>
> >> Specifically, it displays them in the gdb "add-symbol-file" syntax, with
> >> the presumption that there's a variable $grubdir that reflects the path
> >> to any such binaries.
> >
> > Could you tell us why this thing has to be displayed as a part of debug
> > messages? Could you create a separate command which would do the same?
>
> I don't follow what you're suggesting.  It's debug output and gdb is a
> debugger.  What would you have it do instead?

I cannot see any reason of displaying this kind of stuff as a part of
debug messages. I think we should have a separate command, e.g.
give_me_these_load_addresses ;-), in the GRUB which will produce list
of commands needed to be executed in the gdb.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Daniel Kiper]

On Mon, Nov 29, 2021 at 06:21:46PM -0500, Robbie Harwood wrote:
> 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

I do not... I am not sure how you inferred I do.

> hacking - I'm mostly just here to upstream patches :)

Cool! I have just asked you to investigate how to improve your patch.
Currently I am not happy with it. I still hope you will send me some
proposals (I do not expect patches immediately; if you prefer just tell
me how do you want to fix the issue in better way). If I get them then
we can continue discussion...

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] minilzo: Update to minilzo-2.10

[Daniel Kiper]

On Sun, Nov 28, 2021 at 11:54:28PM +, Colin Watson wrote:
> minilzo fails to build on a number of Debian release architectures
> (armel, mips64el, mipsel, ppc64el) with errors such as:
>
>   ../../grub-core/lib/minilzo/minilzo.c: In function 'lzo_memops_get_le16':
>   ../../grub-core/lib/minilzo/minilzo.c:3479:11: error: dereferencing 
> type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
>3479 | * (lzo_memops_TU2p) (lzo_memops_TU0p) (dd) = * (const 
> lzo_memops_TU2p) (const lzo_memops_TU0p) (ss); \
> |   ^~~~
>   ../../grub-core/lib/minilzo/minilzo.c:3530:5: note: in expansion of macro 
> 'LZO_MEMOPS_COPY2'
>3530 | LZO_MEMOPS_COPY2(&v, ss);
> | ^~~~
>
> The latest upstream version is 2.10, so updating to it seems like a good
> idea on general principles, and it fixes builds on all the above
> architectures.
>
> The update procedure documented in the GRUB Developers Manual worked; I
> just updated the version numbers to make it clear that it's been
> executed recently.
>
> Signed-off-by: Colin Watson 

Reviewed-by: Daniel Kiper 

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Daniel Kiper]

On Mon, Nov 29, 2021 at 04:00:27PM +0100, Heinrich Schuchardt wrote:
> 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 first patch.
>
> The second patch provides a new function grub_efi_close_protocol() to
> simplify the coding.
>
> v2:
>   do not open SNP protocol non-exclusively
>   adjust code style
>
> Heinrich Schuchardt (2):
>   efinet: correct closing of SNP protocol
>   efi: library function grub_efi_close_protocol()

For both Reviewed-by: Daniel Kiper 

Thank you for fixing this issue.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub2 + xen + lz4 kernels

[Daniel Kiper]

On Tue, Nov 30, 2021 at 07:21:42AM +0100, Juergen Gross via Grub-devel wrote:
> 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
> >
> > grub-mkstandalone -O x86_64-xen -o grub2-x86_64.gz boot/grub/grub.cfg
> >
> > What we have been seeing more and more is newer distros like Ubuntu
> > 20.04 using lz4 compressed kernel images which will not boot and
> > displays the error "not xen image."
> >
> > If i use the 
> > https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux
> >  
> > 
> >  utility
> > to decompress the kernel image I am able to boot it without any issues
> > using our current grub2 xen loader.
> >
> > My question is how can I get lz4 support added into grub2 for xen? We
> > are willing to pay for a dev to add this support if needed as I have
> > limited time to really dig into this.
> >
> > 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. It leaves too much room for
> > error and the possibility of a clients server failing to boot after what
> > should of been a simple kernel upgrade.
> >
> > Any help, even if just pointing me in the right direction would be
> > appreciated!
>
> Hmm, Grub2 already supports some compression methods, so adding LZ4
> shouldn't be that hard. Especially as there already is some LZ4
> support hidden in the ZFS handling.
>
> I guess this LZ4 support wants to be put into a grub module of its
> own and then be added to the filter list.
>
> You should have a look at:
>
> - GRUB_FILE_FILTER_GZIO for an example how a compression filter is
>   added via grub_file_filter_register()
>
> - the file grub-core/fs/zfs/zfs_lz4.c for current LZ4 support in
>   Grub2
>
> This should basically do the job.
>
> I've added Daniel to Cc: as he might have some more thoughts.

Yeah, in general I agree. However, I would look for an LZ4 library which
could be merged with the GRUB code, licensing compatibility is important
here, and is under active development/maintenance. If there is no such
we can reuse ZFS LZ4 code.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel