Bug 265471 - loader: /boot/lua/menu.lua boots kernel from original bootenv
when bootenv is changed.
This is related to a bug fixed by Kyle Evans <kevans@FreeBSD.org> in commit
If a password is set for the loader, when the boot environment is changed in the lua menu, the kernel originally loaded before the menu was brought up is booted in the new boot environment.
This fixes the problem by unloading any previously loaded kernel when
changing the boot environment.
If the problem isn't fixed, when a password is used for the loader's boot
menu, if an alternate bootenv is chosen from the menu, the original bootenv's
selected kernel will be booted but the new bootenv will be mounted on /.
The kernel's /boot/kernel directory won't be mounted, which will prevent
modules from being loaded during boot. In addition, if the reason for using
the boot environment is to provide a known good kernel and environment while
experimenting with a new kernel, the resulting confusion will be unhelpful.
The problem only occurs when a loader password is set in /boot/loader.conf. However
given that important and dangerous functions such as the restoration of a zpool
checkpoint are now in the boot menu. such a password has become important.
Bug 265472 - /boot/loader: lua autoboot timer restarts if menu password is set
In the lua loader, if one sets a password in loader.conf, the autoboot_delay
timer will start before the menu is displayed. One can interrupt the
autoboot and bring up the menu by entering a keyboard character before the
If this is done a prompt for the password is displayed. Entering the
password will bring up the menu, but the timer will again start and another
keyboard character must be entered or autoboot will abort the menu and boot
It's common to use a short timeout and enter a key before the password prompt
when you need to enter the menu. Having done this, if you are now studying
the menu trying to decide what to do, the system will autoboot before you do.
Bug 265001 - loader: Lines containing a comment that contains a '"' in
loader.conf are ignored.
A comment is an unexpected and difficult to find cause of breakage.
Consider the example /boot/loader.conf entry:
test_directive_b="test b" # This is "test_directive_b"
The problem is that the lua parser in /boot/lua/config.lua is splitting the
line on the '=', sending the first match to the key and the second to the
In the problem case, the value becomes:
"test b" # This is "test_directive_b"
Then this value gets matched against QVALEXPR = '"(.*)"'.
This cleans up the value by removing the first and last '"', but in this case
turns it into:
test b" # This is "test_directive_b
which then gets rejected in processEnvVar() with MSG_FAILSYN_QUOTE, since
values aren't allowed to contain '"'.
Changing QVALEXPR to '([-%w_]+)' fixes this problem. Since the value is
explicitly prevented from containing quotes, it's not unreasonable to load it
from an expression that excludes them. The only other place QVALEXPR is used
is in the 'exec="command"' expression, which also should not contain '"' in
the command value.