Am Tue, Dec 30, 2025 at 01:43:15PM -0800, schrieb Elliott Mitchell: > I'm well-aware x86 bootsector booting is being killed. UEFI is better in > several ways, but rather higher overhead. Yet it was still possible to > purchase current-generation hardware with bootsector support. I also > note that is *Intel*, not every company which has ever produced an > x86-compatible processor. > > Not a strong argument, merely a comment bootsector will be around a long > time. OpenWRT x86 images in theory support hardware manufactured in > 1995, so bootsector support will need to stick around a long time.
I don't have the goal to remove grub based booting - so legacy booting will continue working. > > 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. > > I guess this shows we're in different circles. GRUB-PV is recommended > for booting Linux images on Xen, most Linux distributions document this > and have packages available. I found a description from Debian and it does not sound like a recommendation but like one possible solution [1]. I am working with KVM for virtualization. > Such is quite stable. Unlike Python, GRUBv2's configuration file syntax > has been quite stable. Since 2.0 most changes have been bugfixes and > module additions. There was talk of chainloading the VM's version of > GRUB to ensure compatibility, but to my knowledge that has merely been > proposed. The grub version and the provided modules and the modules included by the grub.cfg differ between distributions. I remember beeing able to boot Fedora from a f2fs partition using Debians grub, but not using Fedoras grub. If you load a kernel from a efi partition, then all distributions should be able to handle it - but then you don't need grub at all. > > 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. > > There is one key thing which GRUB allows, but this doesn't claim to. > GRUB allows having multiple kernels installed and choosing between them. > Not too urgent for most OpenWRT targets, but critical kernel bugs do > show up. Being able to keep an older known working kernel around has > been extremely helpful. systemd-boot allows that too. With boot counting [2], it can automatically fall back to an older kernel if the new one has problems. [1] https://wiki.debian.org/PvGrub [2] https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
