aboutsummaryrefslogtreecommitdiff
path: root/stand
diff options
context:
space:
mode:
authorWarner Losh <imp@FreeBSD.org>2018-08-19 18:18:19 +0000
committerWarner Losh <imp@FreeBSD.org>2018-08-19 18:18:19 +0000
commit295506bf9c871f873978f79ff282d63e0f2e347b (patch)
tree46ef032db87897e62225ebb2c5278d2441562c94 /stand
parent6112ee09cb8dd2f6734fb3d73c1ccb13d4cef4d5 (diff)
downloadsrc-295506bf9c871f873978f79ff282d63e0f2e347b.tar.gz
src-295506bf9c871f873978f79ff282d63e0f2e347b.zip
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
Notes
Notes: svn path=/head/; revision=338064
Diffstat (limited to 'stand')
-rw-r--r--stand/userboot/userboot/Makefile1
1 files changed, 1 insertions, 0 deletions
diff --git a/stand/userboot/userboot/Makefile b/stand/userboot/userboot/Makefile
index 1fc71782dfdf..b375083917f1 100644
--- a/stand/userboot/userboot/Makefile
+++ b/stand/userboot/userboot/Makefile
@@ -5,6 +5,7 @@ LOADER_UFS_SUPPORT?= yes
LOADER_CD9660_SUPPORT?= no
LOADER_EXT2FS_SUPPORT?= no
PIC=yes
+LOADER_INTERP=4th
.include <bsd.init.mk>