#3227 Issue `closed`: What comes after SYSLINUX? Support modern PXE booting via iPXE¶

Labels: enhancement, discuss / RFC, no-issue-activity

schlomo opened issue at 2024-05-21 08:26:¶

Discussed in https://github.com/rear/rear/discussions/3099 ¶

^{Originally posted by **@robertdahlem** December 4, 2023} Hi, Syslinux seems to be pretty much abandoned: last official binary from Oct 2014, last testing binary from Mar 2016, last commit Feb 2019. Rear supports OUTPUT=PXE, which I like that very much because it allows me to prepare a complete backup environment und to use it by simply booting the system from the network. But OUTPUT=PXE heavily depends on Syslinux and seems to have no future, especially with all the UEFI stuff coming up. What is the preferred way to replace OUTPUT=PXE to produce a network bootable backup environment? Is there any replacement yet? I read nice things about [iPXE](https://ipxe.org) (hint, hint :-).

schlomo commented at 2024-05-21 08:32:¶

@robertdahlem the OUTPUT=PXE mode actually only creates a pxelinux configuration. You can also use OUTPUT=RAMDISK to get the same kernel and initrd without that to use in your own PXE boot environment.

I agree with you that pxelinux is dated and that ReaR could benefit from better support for modern PXE booting, but - to be honest - this is something that will have to be developed by people who make use of it, either as a contribution or as professional support engagement. That would be the only way to ensure that it actually works, because there would be sufficient testing done.

schlomo commented at 2024-06-19 07:26:¶

Another thought would be to consolidate all ReaR booting into using only grub2. It seems to support all architectures where we currently use SYSLINUX and even more (e.g. arm). I also see support for multi-arch network boot, as illustrated in https://linuxguideandhints.com/el/pxeboot/#dhcp-isc

## EFI Client Catch
        class "pxeclients" {
                match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
                if option pxe-system-type = 00:07 {
                        filename "boot/grub2/x86_64-efi/core.efi";
                } else if option pxe-system-type = 00:08 {
                        filename "boot/grub2/x86_64-efi/core.efi";
                } else if option pxe-system-type = 00:09 {
                        filename "boot/grub2/x86_64-efi/core.efi";
                } else if option pxe-system-type = 00:0a {
                        filename "boot/grub2/armv7a-efi/core.efi";
                } else if option pxe-system-type = 00:0b {
                        filename "boot/grub2/aarch64-efi/core.efi";
                } else {
                        filename "boot/grub2/i386-pc/core.0";
                }
        }

I'd hope that consolidating on a single tool (e.g. grub2) will significantly simplify our code base and make it trivial to support the same features across all boot methods.

I suppose that for s390 and other "special" architectures this discussion is irrelevant as they have their own standard way of booting.

@pcahyna what do you think about that thought? How does that fit in with Red Hat / Fedora booting strategy?

@jsmeix how does that fit in with SUSE booting strategy?

github-actions commented at 2025-02-15 02:33:¶

Stale issue message

github-actions commented at 2025-04-19 02:43:¶