Am Tue, Dec 30, 2025 at 09:15:55AM -0800, schrieb Elliott Mitchell: > > Yes, that's the main motivation. Unlike grub, it only supports UEFI > > boot but this is the only boot method supported by recent x86 hardware. > > The motherboard on this system is 3 years old yet will still boot using > the traditional bootsector. Some things are disabled in that mode, but > it can still boot without UEFI. This though isn't a bottom tier > motherboard bought with price as the only criterion, nor is this a laptop > which comes with fewer options.
"Starting with server platforms launching in 2020, Intel began phasing out support for Legacy Boot Mode. Starting with server platforms launching in 2024, Intel has discontinued support of Legacy Boot Mode in all segments." [1] > Depends on the hypervisor and its configuration. Both GRUB and > Tianocore/EDK2 have been ported to be directly loadable by at least one > hypervisor and serve as the first stage loader. If GRUB is the first > stage, then grub.cfg is the first OpenWRT built piece to be loaded. > If Tianocore/EDK2 is the first stage, then it will be UEFI-only. I know the theoretical option of loading grub as first stage in hypervisors and early in physical hardware. I never saw this beeing used in practice. > On the surface the patch didn't look too problematic, but beware of > making needless changes with booting. Of note SuSE chose to use > "grub2.cfg" and has invested significant energy in keeping that. > Resulting in pull #3791 which I'm unsure of working around a SuSE bug in > OpenWRT. That's why this is a new independent image type. Hybrid booting grub for legacy systems and systemd-boot for uefi would be possible, but useless. PR #3791 [2] is for using other grub builds? I would absolutely avoid that. It's like booting one distribution with another ones grub. It can work for a moment, but I would not expect it to be stable. I consider basic things like efi files the best possible entry point. The linux kernel itself can be executed by the uefi, but then I can not specify the command line parameters while still using the default path. systemd-boot is just used as a helper to fill this gap - read a config file and tell the uefi to load the actual kernel. It is possible to develop an own solution for this step - but it's not worth it. [1] https://cdrdv2-public.intel.com/630266/630266_WW31_2023.pdf [2] https://github.com/openwrt/openwrt/pull/3791/files _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
