I installed Manjaro with Kernel 6.17 on my brand new Framework Laptop 12 (13th Gen Intel® Core™, 16GB RAM), but I did not use the graphical installer but installed it the manual way as you would do with a standard Arch Linux.
I wanted to use file system encryption including the /boot directory. As far as I know GRUB is the only bootloader that can load a kernel from an encrypted volume, so I set it up in a similar way as is described here, but I don’t use LVM, I just created a single btrfs volume inside the LUKS container.
In the beginning it worked. Just sometimes on boot after unlocking the LUKS container grub threw this error:
error: loader/efi/linux.c:grub_cmd_linux:542:out of memory.
error: loader/efi/linux.c:grub_cmd_initrd:412:you need to load the kernel first.
Originally it was sufficient to just turn the laptop off and on again and it usually worked on the next try. It was not ideal, but not a showstopper at that moment. But about two days later the problem started to appear on every boot and as a consequence booting the installed operating system was not possible any more.
I did look up the problem and most answers I found on the internet were about the size and the compression of the initramfs. I tried different compression algorithms and also uncompressed initramfs, but nothing made a difference and I don’t really see why an initramfs that is about 40MiB uncompressed and 25MiB when compressed using zstd should be too big.
As the error message shows file names and line numbers I had a look in the source code and it seems that the “out of memory” happens when GRUB tries to allocate the memory to copy the kernel image into. This happens before the initramfs is loaded so I believe it is very unlikely it has anything to do with the initramfs. The kernel image is 15.7MiB and when I enabled debug messages in GRUB they said it is trying to allocate 4013 pages which checks out with the size of the kernel image if pages are 4kiB.
Does anyone have an idea how I could solve this, or is this maybe a bug in the BIOS (some online sources sugessted it could be)? I have version LFR20.03.04 which should be the current version as fwupdmgr is not offering me updates for it.
The GRUB version is 2.14rc1 and I tried reinstall it to the ESP and regenerate the config several times without success.
I had this same issue trying to boot the arch iso via loopback on Arch. I reported the issue but it was subsequently closed here.
The Ubuntu version of GRUB works properly but I don’t know what patch or patches fix the issue.
I have subsequently switched to using Unified Kernel Images with GRUB which doesn’t have the same issue, but also required me to write scripts to generate my own menuentries. I’d share however at the moment everything is in a private repo and don’t have the time to clean it up to a level I’d be happy with publicly releasing.
Good luck.
It seems to be quite an elusive issue. I have other machines running Manjaro booting the same kernel version from btrfs with GRUB without issue. The difference is that they are not encrypted and are very different hardware.
I already tried to manually build a UKI using ukify and then to manually boot it via the GRUB console. But when I tried to execute the chainloader command, after a short moment I just got a prompt again without any error message.
But the information, that it worked for you, now encourages me to go further in this direction and maybe try to create a proper GRUB configuration for this.
I should clarify that what while I got the same error as you, I was only having problems with the arch iso and not the regular arch kernels themselves. Using a UKI likely solved it because instead of loading the ISO into memory and then loading the kernel and initramfs from there, it’s now just loading a generated UKI directly. I did also switch the regular arch kernels to UKIs however those technically weren’t a problem.
That’s weird, I’d expect an error message if there was a failure to load it. Perhaps the UKI wasn’t generated properly? You should be able to add the UKI to the boot loader directly using efibootmgr or another tool and then boot it straight from the bios. If it doesn’t boot properly from there then it won’t boot properly from GRUB either.
It could also be that your boot partition is encrypted, if that’s what you meant. I personally keep my boot partitions unencrypted but encrypt everything else.
I don’t know what went wrong with my first test with UKI. Now i tried it properly and it worked. 
Here is what I did:
First I copied the kernel command line from /boot/grub/grub.cfg to /etc/kernel/cmdline.
Then I edited the preset file in /etc/mkinitcpio.d/. Uncommenting the line with default_uki and changing the path to /boot/ instead of /efi/EFI/Linux/ was everything I had to do and now mkinitcpio creates a UKI every time it creates a new initramfs. Only downside on Manjaro is, that I will have to manually repeat this step every time I install a new major kernel version.
Keep in mind, while the grub.cfg generated by grub-mkconfig will load the intel-ucode.img and the initramfs-*.img on boot, mkinitcpio will only include the initramfs-*.img it generated into the UKI, so make sure the microcode hook is enabled in your /etc/mkinitcpio.conf. With this hook mkinitcpio will include the microcode updates directly into the initramfs-*.img
The most complicated part was having a menu entry for the UKI in the GRUB menu. For this is created a script in /etc/grub.d/ that looks for UKIs in my /boot directory and automatically creates a menu entry for every UKI it finds there.
So now I have a workaround for my problem, but I don’t see it as a final solution. My grub menu still contains the “normal” boot entry that causes the error and I will try if it started working from time to time, especially if there was an update for GRUB.
One of the reasons why I went trough all these troubles and didn’t just use an unencrypted /bootvolume and a different bootloader is: I use btrfs snapshots that are autogenerated by a pacman hook when updates are installed so I can roll back when there is a update that breaks my system (I use the manjaro testing branch) and that only works if if all files that are installed by pacman are on the same subvolume, so I can’t have the kernels on a separate volume.
If you want to remove them you could either:
- Remove
/etc/grub.d/10_linux, however this will come back any time you update grub.
- Add
/etc/grub.d/10_aa_linux_disable with contents echo 'if false; then', and /etc/grub.d/10_zz_linux_disable with the contents echo 'fi'; the menu entires will still be generated but will never show up due to being in an if statement that will never evaluate to true.