Turn back the clock just a little: make userboot.so always be 4th

Turns out there was a hidden dependency we hasn't counted upon.  The
host load /boot/userboot.so to boot the VMs it runs. This means that
the change to lua meant suddently that nobody could run their older
VMs because LUA wasn't in 10.0, last month's HardenedBSD, 11.2 or
whatever.  Even more than for the /boot/loader* binaries, we need a
good coexistance strategy for this. While that's being designed and
implemented, drop back to always 4th for userboot.so. This will fail
safe in all but the most extreme environments (but lua-only hacks
to .lua files won't be processes in VMs until we fix it).

Differential Review: https://reviews.freebsd.org/D16805
This commit is contained in:
imp 2018-08-19 18:18:19 +00:00
parent 52441319cb
commit 4a0a4907ec
2 changed files with 4 additions and 0 deletions

View File

@ -40,6 +40,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
loader and loader_4th instead of loader and loader_lua, the new default. loader and loader_4th instead of loader and loader_lua, the new default.
If you are using UEFI it will create the proper hard link to loader.efi. If you are using UEFI it will create the proper hard link to loader.efi.
bhyve uses userboot.so. It remains 4th-only until some issues are solved
regarding coexisting with multiple versions of FreeBSD are resolved.
20180815: 20180815:
ls(1) now respects the COLORTERM environment variable used in other ls(1) now respects the COLORTERM environment variable used in other
systems and software to indicate that a colored terminal is both systems and software to indicate that a colored terminal is both

View File

@ -5,6 +5,7 @@ LOADER_UFS_SUPPORT?= yes
LOADER_CD9660_SUPPORT?= no LOADER_CD9660_SUPPORT?= no
LOADER_EXT2FS_SUPPORT?= no LOADER_EXT2FS_SUPPORT?= no
PIC=yes PIC=yes
LOADER_INTERP=4th
.include <bsd.init.mk> .include <bsd.init.mk>