Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find out the whys and wherefores of the GRUB 2.00 size limit.
In the process of doing this I noticed a strange behavior. The code has a
ceiling (addr_max) and a floor (addr_min) for the initrd. The initrd is loaded
high, so that it ends at the ceiling and grows toward the floor as the size of
the initrd increases. The odd behavior, or at least the one that I don't
understand, is that the floor grows upward toward the ceiling at the same time.
The lines in question:
addr_min = (grub_addr_t) prot_mode_target + prot_init_space
+ page_align (size);
/* Put the initrd as high as possible, 4KiB aligned. */
addr = (addr_max - size) & ~0xFFF;
page_align(size) returns a rounded-up alignment of size; i.e., if size is
0x2335b728, it returns 0x2335c000. Consequently, if the initrd size doubles,
the distance between the ceiling and the first byte doubles (expected), AND the
distance between the floor and the first byte halves because both are
proportional to the size. I would expect the floor to remain relatively
constant based on the memory map. Maybe be adjusted between 1-4k bytes for
alignment, but not by the whole size of the initrd.
I'm wondering if this is a bug, or if my modest and cursory understanding of
the code is incorrect.
If I am incorrect, can someone explain the page_align calculus, and also
explain how the value of GRUB_LINUX_INITRD_MAX_ADDRESS (0x37FFFFFF) was
determined, whether it is hard or might be revisable upward on some systems,
and what the implications are of changing it (i.e. will it either work or not
boot at all, or whether I might silently hose something).
Thanks,
Eric Ewanco
<<attachment: Eric J Ewanco.vcf>>
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
