On 21/08/2022 21.35, Daniel Axtens wrote:
> Hi Hector,
>
> Thanks for your patch and for taking the trouble to put it together.
>
>> GRUB is already running out of memory on Apple M1 systems, causing
>> graphics init to fail, as of the latest Git changes. Since dynamic
>> growing of the heap
Hi Hector,
Thanks for your patch and for taking the trouble to put it together.
> GRUB is already running out of memory on Apple M1 systems, causing
> graphics init to fail, as of the latest Git changes. Since dynamic
> growing of the heap isn't done yet, double the default heap size for
> now.
This is 'belt and braces' with the last fix: we end up trying to use
too much memory in situations like corrupted Linux software raid setups
purporting to usew a huge number of disks. Simply refuse to permit such
configurations.
1024 is a bit arbitrary, yes, and I feel a bit like I'm tempting
With wildly corrupt inputs, we can end up trying to calloc a very
large amount of memory, which will fail and give us a NULL pointer.
We need to check that to avoid a crash. (And, even if we blocked
such inputs, it is good practice to check the results of allocations
anyway.)
Signed-off-by:
A user may wish to use an image that is not sorted as the "latest"
version as the top-level entry. For example, in Arch Linux, if a user
has the LTS and regular kernels installed, `/boot/vmlinuz-linux-lts`
gets sorted as the "latest" compared to `/boot/vmlinuz-linux`. However,
a user may wish to
