BIOS与EFI模式下PXE网络启动差异及需不同加载器版本的原因咨询

Great question—this boils down to the fact that BIOS and EFI are completely distinct firmware ecosystems with different rules, instruction sets, and APIs. Let’s break down the key reasons the loaders can’t be one-size-fits-all:

1. The Execution Environment Is Night and Day #

• BIOS: When PXE hands off control, the system is running in 16-bit real-mode x86. This mode has strict limits—only the first 1MB of RAM is accessible, and you’re stuck using old BIOS interrupts for hardware interactions. BIOS loaders like syslinux (legacy version) or classic GRUB are built specifically for this: they start in real-mode, handle the messy work of switching to 32-bit protected mode, and work within those tight memory constraints.
• EFI: From the get-go, EFI runs in 32-bit or 64-bit protected mode with full access to all system memory. It also provides standardized, modern APIs (like EFI Boot Services) for network access, file I/O, and hardware control. EFI loaders (GRUB EFI, systemd-boot) are compiled as EFI applications—they rely on these APIs to do their work, and they can’t run at all in BIOS’s 16-bit real-mode environment.

2. PXE Boot Protocols Are Not the Same #

• BIOS PXE: Uses the legacy PXE spec, which leans heavily on BOOTP/DHCP for IP info and TFTP for fetching the loader. The loader has to handle a lot of low-level network initialization on its own because BIOS doesn’t offer much help here.
• EFI PXE: Uses the UEFI-specific PXE spec, which integrates with EFI’s native network stack. The firmware itself handles most of the network setup, so the loader just uses EFI’s network APIs to grab kernel/initrd files (even over HTTP, which many EFI implementations support natively). No mode-switching hacks needed—EFI is already in a modern execution mode.

3. Kernel Loading Works Differently #

• BIOS: Legacy loaders use BIOS interrupts to read files from network or storage and load the kernel into memory. They also have to pass legacy boot parameters (like root=/dev/sda1) that BIOS-era kernels expect. Loading a 64-bit kernel requires extra hoops (like switching to long mode) that the loader has to handle.
• EFI: EFI loaders use EFI Boot Services to directly load the kernel and initrd into memory. They can pass modern boot arguments, use EFI variables to store configs, and natively load 64-bit kernels without any workarounds. The kernel also has EFI-specific entry points that only EFI loaders can use.

4. File System and Partition Support Varies #

• BIOS: Legacy loaders are limited to file systems BIOS can recognize (mostly FAT32, sometimes ext2 with extra drivers). They can’t natively access GPT partitions—you’d need additional tools to make that work.
• EFI: EFI loaders can access GPT partitions and a wider range of file systems (NTFS, ext4, etc.) thanks to EFI’s native drivers. They rely on the EFI System Partition (ESP)—a mandatory FAT32 partition that BIOS doesn’t even recognize—to store boot files.

At the end of the day, BIOS and EFI speak different "languages" to boot software. An EFI loader would crash immediately in BIOS mode because it can’t handle real-mode, and a BIOS loader would be lost in EFI mode because it doesn’t know how to use EFI’s modern APIs. They’re built for two entirely different worlds.

内容的提问来源于stack exchange，提问作者Yurij Goncharuk