Hello David, initially I wondered if some data type could possibly overflow in Grub :-) Your volume of RAM is not necessarily all that mainstream...
I second Felix Miata's pointer to the launchpad bug entry. It does contain interesting tips. I'm not sure if Grub is a 32bit beast, or 64bit. Its UEFI interface should be ready for 64bit operation, IMO... because almost all modern UEFI "firmwares" are 64bit nowadays. Now... it would be interesting to take a look at your "e820 memory map". Which may be difficult to get, if you cannot boot Linux. Can you, actually? Can you at least start the installer of some distro, and get a copy of the early dmesg? Ahh... Google is telling me that the UEFI Shell contains the MEMMAP command - see here: https://support.hpe.com/hpesc/public/docDisplay?docId=sd00002251en_us&; page=GUID-D7147C7F-2016-0901-0A6D-0000000009DD.html Actually it is wrong to still call this the "e820 memory map", as this is a legacy real-mode BIOS service number. The UEFI equivalent is BootServices->GetMemoryMap(). https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/15_System_Address_Map_In terfaces/int-15h-e820h---query-system-address-map.html https://wiki.osdev.org/Detecting_Memory_(x86)#What_about_on_UEFI? Apparently, in Linux booting in UEFI mode, you still get e820 mentioned on the lines related to the memory map :-) Why I'm asking about the memory map: to this day, there seems to be a magical boundary at 4 GB (the 32bit address space). The physical memory space contains not only DRAM, but also many memory-mapped peripheral devices. Such as the IOMEM windows of graphical cards, bits related to the inner workings of PCI and PCI-e, and whatnot. During the years of evolution, the summary volume of memory space needed for these devices keeps growing. Traditionally, this was mapped under 4 GB (from the top of the memory space creeping down). Last time I investigated this, I've seen machines, about 8th-gen Core or thereabouts, that ended up booting with about 2 GB of available DRAM under 4 GB, the rest of the 32bit space being taken for various "IO resources", mostly coming from PCI-e. The rest of your physical DRAM gets mapped in one big chunk above 4 GB. Looking forward, it makes good sense to map the various IO resources above 4 GB, thus making more DRAM accessible under 4 GB (or in fact the 4GB boundary becomes irrelevant / no longer a boundary). Which is a problem for some OS and maybe bootloaders, that are still 32bit. I cannot give you a good example now - most of these could only boot in legacy BIOS mode anyway, and with the departure of the CSM, this would apper no longer to be a relevant issue... What I'm hinting at: even on 64bit x86 PC's, which is almost all nowadays, you can still sometimes find an option in the BIOS/UEFI setup, to boot with resources mapped under 4 GB of physical address space (avoid mapping IOMEM resources above 4 GB = reachable to 64b capable software only). If you can find this in your BIOS, it might make a difference. Then again, if your machine is UEFI-only, perhaps that option is no longer there... Actually, I've just downloaded a BIOS manual for your motherboard (the absolute URL is about 6 lines, not pasting it here). https://www.asus.com/cz/motherboards-components/motherboards/tuf-gamin g/tuf-gaming-z890-plus-wifi/helpdesk_manual?model2Name=TUF-GAMING-Z890 -PLUS-WIFI On page 59, chapter 6.3, there's an entry labeled System Agent (SA) Configuration Memory Configuration Memory Remap Enable/Disable Memory Remap above 4GB ... might be improper wording. They probably actually mean PCI IOMEM resources, rather than DRAM. The point should be, for you to decide, whether the drivers in your OS can cope with PCI-e IOMEM windows mapped above 4 GB. If not, and you allow the high mapping, your kernel probably won't boot. Probably because it's compiled for 32bit mode :-) If you have a 64b kermel, and you permit mapping of IOMEM resources above 4GB, you should end up with more contiguous DRAM mapped *under* 4 GB. Or just the system memory map being stacked in a different way, more casually. Which may or may not alleviate your issue. I recall reading a note, at the link mentioned by Mr. Miata, that GRUB is not good at looking for a bigger chunk of RAM available. That the catch really is, that the UEFI memory map contains some smaller chunks available at the start of the list, that happen to be too small for Grub + initrd... Which would be just a pesky algorithmic laziness, and could bite you even with loads of free RAM and even if your software is all 64bit -- provided that the UEFI happens to map a small chunk at the start of its "map" (a listing of memory blocks). Would you consider trying rEFInd ? https://sourceforge.net/projects/refind/ Apparently it can load a kernel directly = doesn't need grub... Frank
