stand/i386: fix booting over TFTP or NFS

[khorben_defora.org]

Summary

The current PXE loader does not work since it became too big. By removing ZFS support, it is no longer possible to replace the local boot loader with the PXE loader, but it becomes possible again to continue booting the kernel over TFTP or NFS as expected.

This is achieved by providing an additional subfolder and corresponding binary target for every loader supported, but where ZFS support is always disabled.

The kernel loaded over the network can then provide ZFS support and boot the local system if desired.

Test Plan

In /usr/local/etc/dhcpd.conf: (isc-dhcp44-server package)

next-server 192.168.2.1;
filename "FreeBSD/boot/pxeboot";
option root-path "nfs://192.168.2.1/tftpboot/FreeBSD/amd64";

In /etc/inetd.conf:

tftp  dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot

In /tftpboot/FreeBSD/boot:

-rw-r--r--  1 root    wheel   415744 Sep  5 21:11 pxeboot

[emaste]

stand/defs.mk

199 ↗

(On Diff #126923)

I'm not sure this makes it clearer - I'd probably just use loader_${LOADER_DEFAULT_INTERP}_pxe below

stand/i386/loader_simp_pxe/Makefile

4 ↗

(On Diff #126923)

I think all of these need INSTALL_LOADER_HELP_FILE=no

[imp]

So this is only needed for the lua loader. The 4th loader with zfs still fits since it is 64k smaller than the lua loader. And the simp loader is 120k smaller.... I'd rather not spawn 3 new variants... Especially since BIOS booting's days are numbered. I don't mind making them so much, but if we go that route I don't think we should install them all.

And none of the _pxe variants can actually be used for pxe booting: you still have to stuff it inside of the pxe wrapper to create pxeboot. We can avoid this confusion with a _nozfs variant name... It's also currently unfortunate that the mixing and matching requires a whole new build for one file that's different...

My GSoC sutdent last year was going to have fixing this as a stretch goal, and wound up not quite finishing the stated project of adding command line editing.

ZFS has too damn many crypto and compression options that aren't optional...

So tl;dr: let's just do loader_lua_nozfs, let's not install it and let's use either that or loader_${INTERP} for the build.

I've tilted at the 'size' windmill and got back about 24k a while ago.... But there's not a huge amount left w/o disabling certain things only for BIOS booting in general (like maybe support for ext2fs).

diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile
index de96e1329b2f..a54c8453303d 100644
--- a/stand/i386/loader/Makefile
+++ b/stand/i386/loader/Makefile
@@ -5,11 +5,11 @@ LOADER_NET_SUPPORT?=  yes
 LOADER_NFS_SUPPORT?=   yes
 LOADER_TFTP_SUPPORT?=  yes
 LOADER_CD9660_SUPPORT?=        yes
-LOADER_EXT2FS_SUPPORT?=        yes
-LOADER_MSDOS_SUPPORT?= yes
+LOADER_EXT2FS_SUPPORT?=        no
+LOADER_MSDOS_SUPPORT?= no
 LOADER_UFS_SUPPORT?=   yes
-LOADER_GZIP_SUPPORT?=  yes
-LOADER_BZIP2_SUPPORT?= yes
+LOADER_GZIP_SUPPORT?=  no
+LOADER_BZIP2_SUPPORT?= no

Will get us 25k, and ~nobody will complain or notice. Is that enough? How is your proposal better?

We also need to find a way to FREEZE all the crazy compression / crypto proliferation in ZFS... We have way too much junk already we don't need to support in the BIOS loader. But that's a different problem...

tl;dr: I'm unsure.

[khorben_defora.org]

• Created a single new loader variant, loader_lua_nozfs
• Hard-coded the PXE loader to use loader_lua_nozfs instead of loader_${LOADER_INTERP}

I still have the issue that loader_lua_nozfs gets installed into /boot, which from what I understood should be avoided. (Should I modify stand/i386/loader/Makefile?)

I do not consider myself familiar enough with FreeBSD's boot process (and with typical deployments) in order to evaluate if this proposal is better than disabling support for ext2, FAT, and GZIP or BZIP2 compression. I have the impression that compression could help with the slow performance when loading files over PXE.

[khorben_defora.org]

I have the impression that with these changes, pxeldr will fail to build if MK_LOADER_LUA is not enabled. I am preparing a new patch where SUBDIR_DEPEND_pxeldr+= loader_lua_nozfs is protected by .if ${MK_LOADER_LUA} != "no", but then pxeldr is still hard-coded to L=loader_lua_nozfs; that feels wrong.

[imp]

What I want to know: does it work if we disable msdos, ext2fs, gzip and bzip2 does pxe work. If so that's the easy button. We get enough space without having to uber uglify things which I only want do as a last resort. It's a hard no until I at least get an answer to that question.

[khorben_defora.org]

Focus on D42146 instead.