Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
That appears to have issues with loading the initrd over network. I can see the RRQ packet for the initrd arriving at the tftp server, the first DATA packet sent out by the sever, which is acknowleged by the client. But all subsequent DATA packages are never acknowleged by the client, which just times out. The kernel is loaded without problem. Loading kernel ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table error: ../../grub-core/net/drivers/efi/efinet.c:81:couldn't send network packet. EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path EFI stub: Exiting boot services and installing virtual address map... Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] docs/grub-dev.texi: fix typos
Hello, I found and fixed some typos in development documentation. Please consider applying. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] docs/grub-dev.texi: fix typos
From: Nikolai Kostrigin
Signed-off-by: Nikolai Kostrigin
---
docs/grub-dev.texi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/docs/grub-dev.texi b/docs/grub-dev.texi
index 6c629a23e..fb2cc965e 100644
--- a/docs/grub-dev.texi
+++ b/docs/grub-dev.texi
@@ -760,7 +760,7 @@ void grub_arch_sync_caches (void *address, grub_size_t len)
(cache.S). They
won't be used for now.
You will need to create directory include/$cpu/$platform and a file
-include/$cpu/types.h. The later folowing this template:
+include/$cpu/types.h. The latter following this template:
@example
#ifndef GRUB_TYPES_CPU_HEADER
@@ -1034,15 +1034,15 @@ On emu stack and heap are just normal host OS stack and
heap. Stack is typically
On i386-pc, i386-coreboot, i386-qemu and i386-multiboot the stack is 60KiB.
All available space between 1MiB and 4GiB marks is part of heap.
-On *-xen stack is 4MiB. If compiled for x86-64 with GCC 4.4 or later adressable
-space is unlimited. When compiled for x86-64 with older GCC version adressable
-space is limited to 2GiB. When compiling for i386 adressable space is limited
-to 4GiB. All adressable pages except the ones for stack, GRUB binary, special
+On *-xen stack is 4MiB. If compiled for x86-64 with GCC 4.4 or later
addressable
+space is unlimited. When compiled for x86-64 with older GCC version addressable
+space is limited to 2GiB. When compiling for i386 addressable space is limited
+to 4GiB. All addressable pages except the ones for stack, GRUB binary, special
pages and page table are in the heap.
On *-efi GRUB uses same stack as EFI. If compiled for x86-64 with GCC 4.4 or
-later adressable space is unlimited. When compiled for x86-64 with older GCC
-version adressable space is limited to 2GiB. For all other platforms adressable
+later addressable space is unlimited. When compiled for x86-64 with older GCC
+version addressable space is limited to 2GiB. For all other platforms
addressable
space is limited to 4GiB. GRUB allocates pages from EFI for its heap, at most
1.6 GiB.
@@ -2036,7 +2036,7 @@ functions (defined in @file{gfxmenu/gui_util.c}) that are
particularly useful:
@item @code{grub_gui_find_by_id (root, id, callback, userdata)}:
-This function ecursively traverses the component tree rooted at @var{root}, and
+This function recursively traverses the component tree rooted at @var{root},
and
for every component that has an ID equal to @var{id}, calls the function
pointed
to by @var{callback} with the matching component and the void pointer
@var{userdata}
as arguments. The callback function can do whatever is desired to use the
--
2.33.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: RFC: A partition for grubenv, etc.
On Wed, Jul 28, 2021 at 6:23 AM Daniel Kiper wrote: > > At this point I am not fully convinced the /boot/grub should be on > a separate filesystem. Though after going through this thread it seems > to me we should add full write support to the GRUB for a simple file > system. The FAT looks like a good candidate. Does not it? This way we > will be able to support writable grubenv without any limitations and have > flexibility to add other writable files without bigger hassle if needed. On UEFI, the firmware's FAT driver should be write capable, but I don't know if GRUB can make use of it directly rather than using GRUB's own FAT driver? On non-UEFI systems, we still need GRUB to have its own read-write capable driver. I think parity between BIOS and UEFI is important, but I'd also say if there's a faster/easier/more maintainable path with some other file system for other bootloaders, that'd be even more preferred. I don't know of such a file system. But UDF is in the same ballpark, long since supported in the kernel, supports optical, removable, hard drive use cases. > Additionally, it is worth mentioning the [1] work which adds a save_env > redirection layer. It allows us to choose target for grubenv. However, > if we want make it more generic then we could redirect any writes to any > target which can be potentially useful. Btrfs has two fairly large areas for exclusive bootloader usage, ~64KiB from partition start to the superblock. And ~1-2 MiB after the first superblock and before the first block group. But no other file system I'm aware of has such a large reservation for the bootloader. XFS has none. ext4 might have 512 bytes. I think it's valid to ask for an explicit reservation for bootloader usage, but this is just more of the same issue as grubenv and BIOS Boot. There is no file system in such a location so in effect it's up to GRUB to internally implement something, in which case it might as well just have a dedicated partition for grubfs or whatever it'd be. > Last but not least, I think we do not need to change anything in current > partitions usage. In particular it seems to me the BIOS Boot Partition > usage should stay as is. I don't mind just retasking BIOS Boot into a general "bootloader" partition that bootloaders can use. Or even make it explicitly a GRUB bootloader partition type GUID. It's better if each bootloader has its own? Originally BIOS Boot wasn't "owned" by GRUB, any bootloader can use it, but insofar as I'm aware it's the only bootloader that uses this partition type GUID. -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
