On Wed, 20 Aug 2025 18:07:10 +0200 "Frantisek Rysanek" <frantisek.rysa...@post.cz> wrote: > > 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?
As this is my main PC, I can't reboot a bunch at this time, but I'd certainly be willing to do so in time. But how would I do that? > 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 Hmm, IDR seeing a UEFI shell option, so I'll have to find a UEFI shell file to test with. Do you know of a good option? I'm rather hesitant to just google it as it's a big security risk to use random SW from the internet. > 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 :-) lol > 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. There is no CSM on this system, although I have seen that before. > 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 :-) I'll try changing that. My kernel is 64 bit. > If you have a 64b kernel, 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. Exercises in futility are always fun. ;) > 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 I'll try that and get back to you. Thanks, David PS: Felix, "grub loading initial ramdisk error out of memory" was my search string on DDG. It makes a big difference what you search with sometimes.
