i am trying to boot Linux 4.19 as an EFI stub on my laptop. the problem is that due to a bug in the motherboard’s firmware, no parameters can be passed to linux when booting as an EFI stub.
the motherboard’s firmware only allows boot options to specify the filesystem (my ESP partition), and the EFI executable to boot (my vmlinuz file).
when it boots, it immediately kernel panics because it cant find any root filesystem. because that is usually specified in the boot parameters.
is there any workarounds to this issue? or do i have to use a separate bootloader because of this firmware bug?
if it helps, i am more than willing to rebuild Linux from source, i already have to for an unrelated hardware oddity that requires a patch.
One more quick question. What distro? Maybe something is misxonfigired if its one of those manual DIY distros like arch.
Did you also custom compile a kernel? Because that may be also what is causing problems. As a necessary module may not be a module or selected at all.
Has Linux ever worked on this computer at all ever?
And by parameters do you mean initramfs? If so. initramfs can be bypassed if you load all necessary kernel modules into the kernel itself.
Boot process on Linux:
The main purpose of initramfs is to enable mounting of the root filesystem. It is a complete set of directories that you would find on a normal root filesystem. It is bundled into a single compressed cpio archive. If you can tell the kernel which filesystem and which filesystem type to mount, you can mostly eliminate the need for an initramfs .
At boot time, the boot loader loads the kernel and the initramfs image into memory and starts the kernel. The kernel checks for the presence of the initramfs and, if found, mounts it as / and runs /init which is typically a shell script. For most distributions, kernel modules are the biggest reason to have an initramfs
this is using Debian GNU/Linux 10
yes it works when i use a bootloader, but I’d prefer to use the one built into Linux.
its current using Linux 4.19.37 compiled from Debian’s “Linux-source” package. with the only modification being the patch i applied to get the valve index to work.
im very new to making my own custom Linux builds.
instead of configuring each module i need to be built into the kernel, is there a way i could configure Linux to include it’s initial ramdisk into the kernel?
not sure if it makes a difference, but i do use SystemD.
I think that you are confused with how things work when booting an OS. You have to pass parameters to boot the Linux Kernel. Essentially you are high jacking the BIOS and inserting your own code to load. You need to specify what to load for the second stage after the initramfs loads, what is the rootfs, whether you want to load modules at boot, and etc. You can build everything in the kernel so that you do not need to load the modules on boot, but that means that you could introduce issues if the dependent item is not there. Also, why use the 4.19 Kernel instead of building with the 5.2 or 5.3rc kernel. The sources are available for Debian. Regardless, there is no reason that hardware or a custom compiled kernel will prevent you from passing arguments on boot. Something must be misconfigured in your custom kernel. At least I have never heard of this, ever.
Why is it that you cannot use grub2-efi? That is officially the way to boot Debian stable at the moment. Otherwise the ArchWiki and GentooWiki are your best bet at getting this working.
just for the record, I use Grub2-efi on Debian unstable and I use system-boot on ArchLinux
i can use bootloaders like grub2 perfectly fine. and they do pass parameters to my kernel.
i would simply prefer to use the bootloader built into linux.
the reason i cannot pass any parameters to linux when booting it as an EFI stub is because a bug in the motherboard’s firmware prevents it.
I guess I am the one confused. What do you mean about using the boot loader built into “Linux”. The ones that I mentioned are part of the GNU/Linux world but the Linux Kernel only understands EFI, it does not have a built in EFI boot loader.
It sounds like you are trying to use your motherboard’s built in EFI/ESP boot loader, which is broken. If you cannot boot from your ESP partition, then that means that you need to boot to an intermediate image (using kexec, uboot, moboot, and etc) to then load your vmlinuz. If that is the case, save yourself the hassle and just use on of the boot loaders that I mentioned above. With grub and system-boot, you can make the boot silent so you never see the boot loader menu. Outside of that, I think the only way that you will get this to work is to contact the vendor for a better bios, or a viable solution. Only they can fix the bug.
what i mean by “the bootloader built into Linux” is the EFI stub bootloader it comes with. eliminating the need for a separate bootloader.
i am well aware that separate bootloaders exist, and grub2 works perfectly on this machine, I’d just rather boot the kernel as an EFI stub.
the motherboard does load the kernel from my ESP partition. it just immediately panics because the motherboard wont pass any parameters to it, because the motherboard’s firmware is bugged.
the kernel loads fine, i just need a way to get it to boot properly while being unable to pass parameters to it at boot time.
i dont think Dell would do anything if i contacted them about this bug. their customer support was very incompetent every time ive dealt with them.
Out of curiosity, have you ever gotten this to work on any other machines that don’t have this firmware bug? The only option I can see to make this work would be to find a BIOS hacker that can fix the bug for you.
@KleerKut You learn something new every day. I wonder when this was implemented into the kernel. So essentially this is not a bootloader, it is just a kernel hack to get the uEFI to launch the kernel directly without using a boot loader or intermediate stage. That’s cool.
@mathew2214 I think it goes back to my point. It looks like you need to build an intermediate stage to make this work. Your intermediate stage would be hardcoded to load your actual vmlinuz with boot parameters and allow you to carry on. Unfortunately, you are asking in the wrong place for how to do this. Rene Rebe may be able to help you here. He makes T2 Linux and does the above to get it to boot on unsupported platforms like PS3.
If this is for a learning exercise, I encourage you to continue and then share your solution. I would honestly like to know. If you are just wanting to make the thing boot correctly, then as I mentioned, with as much effort as you would need to put into this, using an efi boot loader and setting it to silent boot so that you do not see the boot menu would be a lot quicker and easier. You are trying to work around a vendor bug. Why make it harder on yourself? You are already deviating from the CM of your AGESA based systems.
