Actual modules get require()'d in, rather than try_include(). All instances
of try_include should be provided with proper hooks/API in the rest of
loader to do the work they need to do, since we can't rely on them to exist.
Convert this now to lfs + dofile since we won't really be treating them as
modules.
lfs is required because dofile will properly throw an error if the file
doesn't exist, which is not in the spirit of 'optionally included'.
Getting out of the pcall game allows us to provide a loader.exit() style
call that backs out to the common bits of loader (autoboot sequence unless
disabled with a loader.setenv("autoboot_delay", "NO")). The most ideal way
identified so far to implement loader.exit() is to throw a special
abort-style error that indicates to the caller in interp_lua that we've not
actually errored out, just continue execution. Otherwise, we have to hack in
logic to bubble up and return from loader.lua without continuing further,
which gets kind of ugly depending on the context in which we're aborting.
A compat shim is provided temporarily in case the executing loader doesn't
yet have loader.lua_path, which was just added in r354246.
Multiple places coordinate to 'know' where lua scripts are installed. Knock
this down to being formally defined (and overridable) in exactly one spot,
defs.mk, and spread the knowledge to loaders and liblua alike. A future
commit will expose this to lua as loader.lua_path, so it can build absolute
paths to lua scripts as needed.
MFC after: 1 week
Previously color.disabled would be calculated at color module load time,
then never touched again. We can detect serial boots beyond just what we're
told by loader.conf(5) so this works out in many cases, but we must
re-evaluate the situation after the config is loaded to make sure we're not
supposed to be forcing it enabled/disabled.
Discovered while trying to test r353872.
When colors are disabled, color.escape{fg,bg} would return the passed in
color rather than the proper ANSI sequence for the color.
color.escape{fg,bg} would be wrong.
Instead return '', as the associated reset* functions will also return ''.
This should get rid of the funky '2' and '4' in the kernel selector if
you're booting serial.
Reported by: npn
It's not uncommon these days for the terminals attached to serial consoles
to support ANSI escape sequences. However, we assume escape sequences may
break some serial consoles and default to not using them when boot_serial or
boot_multicons (or if console contains "comconsole" in the forth loader) for
broader compatibility. We also have loader_color which can be explicitly set
to "NO" to disable the use of ANSI escape sequences.
The problem is that loader_color=YES gets ignored when boot_serial=YES or
boot_multicons=YES (or when console contains "comconsole" in the forth
loader).
To fix, the existing default behavior remains unchanged when loader_color is
unset, loader_color=NO explicitly disables the use of ANSI escape sequences
still, and the change is that loader_color=YES can now be used to explicitly
allow ANSI escapes when a serial console is enabled.
Submitted by: Ryan Moeller <ryan@ixsystems.com>
Reviewed by: tsoome (forth), kevans (lua)
MFC after: 1 week
Sponsored by: iXsystems, Inc. (Ryan)
Differential Revision: https://reviews.freebsd.org/D21732
This command will trigger a reload of the configuration from disk. This is
useful if you've changed currdev from recovery media to local disk as much
as I have over the past ~2 hours and are tired of the extra keystrokes.
This is really just a glorified shortcut, but reload-conf is likely easier
to remember for other people and does save some keystrokes when reloading
the configuration. It is also resilient to the underlying config method
changing interface, but this is unlikely to happen.
MFC after: 1 week
The box drawing characters we use aren't necessarily safe with a serial
console; for instance, in the report by npn@, these were causing his xterm
to send back a sequence that lua picked up as input and halted the boot.
This is less than ideal.
Fallback to ASCII frames for console with 'comconsole' in it. This is a
partial revert r338108 by imp@ -- instead of removing the menu entirely and
disabling color/cursor sequences, just reverting the default frame to ASCII
is enough to not break in this setup.
Reported by: npn
Triaged and recommended by: tsoome
Replace mini cons25 emulator with teken, this does enable us proper console
terminal for loader and will make it possible to implement different
back end callbacks to draw to screen.
At this time we still only "draw" in text mode.
Assuming that the autoboot sequence was interrupted, we've done enough
cursor manipulation that the prompt for the password will be sufficiently
obscured a couple of lines up. Clear the screen and reset the cursor
position here, too.
MFC after: 1 week
This was previously an unconditional screen clear, regardless of whether or
not we would be prompting for any passwords. This is pointless, given that
the screen clear is only there to put our screen into a consistent state
before we draw the prompts and do cursor manipulation.
This is also the only screen clear besides that to draw the menu. One can
now see early pre-loader and loader output with the menu disabled, which may
be useful for diagnostics.
Reported by: ian
MFC after: 3 days
The previous iteration of try_include attempted to be 'friendly' and error()
out if we hit an error that wasn't ENOENT. This was semi-OK, but fragile as
it relied on pattern matching the error message.
Move the responsibility for handling failure to the caller. Following
a common lua pattern, we'll return the return value of the underlying
require() on success, or false and an error message.
Reported by: bcran
MFC after: 3 days
If module_blacklist isn't specified, we have an empty blacklist; effectively
the same as if module_blacklist="" were specified in loader.conf(5).
This was reported when switching to a BE that predated the module_blacklist
introduction, but the problem is valid all the same and likely to be tripped
over in other scenarios.
Reported by: bwidawsk
MFC after: 3 days
Some fixes:
- Maintain historical behavior more accurately w.r.t verbose_loading;
verbose_loading strictly prints "${module_name...}" and later "failed!"
or "ok" based on load success
- With or without verbose_loading, dump command_errbuf on load failure.
This usually happens prior to ok/failed if we're verbose_loading
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D17694
Currently, a timeout in the menu autoboot sequence would effectively do
nothing. We would return from the autoboot handling, then begin processing
the menu without redrawing it.
This change makes the behavior a little more friendly. Returning the user to
the menu can't have any good effects, so abort the autoboot sequence and
drop to the loader prompt.
MFC after: 3 days
In the majority of cases, a kernel is not loaded before we hit the menu.
However, if a password is set, we'll trigger autoboot and have loadelf'd
beforehand. We also need to take into account one dropping to the loader
prompt and twiddling with things manually; if they try to toggle through
kernels, we'll assume they mean it.
Reported by: trasz
MFC after: 3 days
For non-UEFI systems, boot.config(5) may have -s or -v specified for
single-user and verbose boot respectively. These were not being properly
taken into account and reflected in the "Boot Options" submenu. When we
initialize core.lua, we'll record boot_single and boot_verbose as we do ACPI
and consider these the system defaults.
Reported by: David Wolfskill <david@catwhisker.org>
Approved by: re (kib)
This is a step in the process of easing migration into the new world order
of DRM drivers. Strongly encourage users towards loading DRM modules via
rc.conf(5) instead of loader.conf(5) by failing the load from loader(8).
Users so inclined may wipe out the blacklist via module_blacklist="" in
loader.conf(5), and it is expected that these modules will eventually be
removed from the blacklist. They may still be loaded as dependencies of
other modules or explicitly via the loader prompt, but this should not be a
major problem.
Approved by: re (rgrimes)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16914
This was mostly a cosmetic issue. autoboot_delay=-1 is documented to bypass
the loader menu and immediately execute the boot command, but lualoader
would draw the menu and immediately execute the boot command. No interaction
was possible with the menu.
The fix lifts autoboot_delay processing out of menu.autoboot, which now
takes a delay and does nothing if no delay is specified. This lines up with
my expectations of menu.autoboot's usage from a third party, which may
want more control over the process than the default behavior.
PR: 231610
Approved by: re (gjb)
1. Be clear about which password is being requested
2. Remove extraneous whitespace between the prompt and the cursor
3. Move the twiddle to where the prompt is, instead of two characters to the right
4. Fix erasing the 'incorrect password' message when retrying; previously it was erased partially
5. Remove the unneeded exclamation mark
Reviewed by: kevans
Approved by: re (gjb)
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D17236
The format for kernels is documented as being space-delimited, but
forthloader was more lenient on this and so people began to depend on it.
A later pass will be made to document all of the fun features that forthloader
allowed that may not be immediately obvious.
Reported by: mmacy
Approved by: re (kib)
Resetting to the default color scheme was done prior to reading the config.
This is bogus; colors may only be declined by the user with the
loader.conf(5) variable "loader_color", so such a request for no color will
not be completely honored as we reset to the default color scheme
unconditionally.
Approved by: re (rgrimes)
Earlier changes setup a config.module_path variable that was populated upon
reading of loader.conf(5) and used for restoring module_path to pristine
condition if multiple kernels are attempted. This broke the ability to
override module_path at the loader prompt in case of emergency.
Approved by: re (rgrimes)
While loader.conf(5) suggests that all values should be quoted, reality is
that this was never strictly enforced and it is used. We already make some
concession to this in number values, which aren't strictly quoted either.
The compromise here is that multi-word values must be quoted. This lets
things like `foo_load=YES` work, while denying more complex expressions on
the right hand side. This likely catches the vast majority of current usage.
A bit of a kludge is needed to accomplish this since Lua regex doesn't
support branching. I had considered splitting up expressions and generating
the right-hand side of the expressions completely in config.parse, but
deemed this too large of an overhaul to take given the current timing. This
should be re-worked shortly after the thaw.
Reported by: royger
lualoader was not respecting the 'xen_kernel' environment variable, which
hints to the interpreter that it should load a Xen kernel prior to loading
any other kernel that might be specified. If a Xen kernel is specified and
we fail to load it, we should not proceed to boot.
Reported by: royger
Tested by: royger
This includes some light rework to simplify the line parsing, as well. If
we hit a line match, we'll always either use the line and move on to the
next line, or we'll spew out malformed line errors.
We had multiple spots to output the error and set the status based on
whether we had a non-nil first capture group or failed EOL validation, but
it was always the same error. Light rework entails a small label jump to
skip error handling and elimination of 'found' local.
A couple of issues addressed:
1.) Modules with - in the name were not recognized as modules
2.) The module regex was repeated for each place a module name may appear
3.) The 'strip leading space' bits were repeated for each expression
4.) The trailing 'comment validation' stuff was repeated every expression
#4 still has some more work to be done. exec lines, for instance, don't
capture a 'value' -- there's only one capture pattern. This throws off the
'c' value that we match, so the trailing bits aren't *actually* being
validated. This isn't a new issue, though, so a future comit will address
this.
Remove a bunch of special cases for UEFI and serial consoles. We do
want to do curses and menu things here. This makes us match what we do
in FORTH, with the possible exception of boxes around menus.
Differential Revision: https://reviews.freebsd.org/D16816
Now that a complete set is written, save for one describing loader.lua,
install all of them. This was not previously done as they were written to
hopefully avoid confusion as bits and pieces of the overall system were
undocumented.
Uncovered while writing the documentation from this, we previously
explicitly fell back to orb or orbbw if an invalid or incompatible logodef
was selected -- in contrast to branddefs, which have an exported variable
that one can whip up a quick local.lua to override in a safe manner that
works regardless of whether or not loader.conf(5) successfully loads.
These are less controversial than the others, thus done in a separate
commit. These are all used internally and ways to override are provided via
soon-to-be-documented API or loader.conf(5) variables.
Ideally, all of the functionality to revamp the loader screen has associated
APIs that are flexible enough that third-party scripts wouldn't need to
override these.
Remove all cross references to zfsloader.8 and /boot/zfsloader.
Move ZFS specific info into loader.8.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16361
To recap the problem: with a black-on-white xterm, the menu draws terribly.
Ideally, we would try our best for a white-on-black context for the menu
since graphics and whatnot might not be tested for other setups and there's
no reasonable way to sample the terminal at this point for the used color
scheme.
This commit attempts to address that further in two ways:
- Instead of issuing CSI bg/fg resets (CSI 39m and CSI 49m respectively for
"default"), issue CSI bg/fg escape sequences for our expected color scheme
- Reset to *our* default color scheme before we even attempt to load the
local module, so that we personally don't have any earlier text with the
console default color scheme.
Reported by: emaste (again)
dteske@, I believe, had originally pointed out that lualoader failed to
allow logo-*.lua for new logos to be added. When correcting this mistake, I
failed to do the same for brands.
Correct the sub-mistake: creating new brands is almost identical to creating
new logos, except one must use `drawer.addBrand` and 'graphic' is the only
valid key for a branddef at the moment.
While here, I've added `drawer.default_brand` to be set to name of brand to
be used (e.g. 'fbsd', project default).
Eventually this whole goolash will be documented.
Reported by: kmoore, iXsystems
We support both of the following cases of substitution:
bar="y"
foo="${bar}"
foo="$bar"
The latter substitution syntax is, of course, not recommended- all
punctuation must be considered potential variable names, and we do not go
through the effort of searching the different combinations of, for instance,
"$x.y.z" to determine if the variable is $x, $x.y, or $x.y.z.
This is not officially documented as supported, but it has worked in
forthloader for what is most likely a long time as `evaluate` is used to
process the right hand side of the assignment.
loader.conf(5) documents loader_conf_files to mean "additional configuration
files to be processed right after the present file." However, lualoader
ignored loader_conf_files after processing /boot/defaults/loader.conf.
Rewrite these bits to process loader_conf_files after each loaded file.
This will not be executed on reload, though later work could allow for that.
It's intended/expected that later work won't generally need to happen on
every config load, just once (for, e.g., menu initialization) or just when
config is reloaded but not upon the initial load.
Earlier efforts to stop loading the menu broke the ability to skip the menu
with, e.g., beastie_disable in loader.conf(5) as it was decided before
configuration was read.
Defer bringing in the menu module until we've loaded configuration so that
we can make a more informed decision on whether the menu should be skipped
or not.
This commit splits all of the logodefs/graphics out into their own own files
and provides a method for these files to register their logodefs with the
drawer. Graphics are now loaded on demand if they don't exist in the current
set of logodefs.
The drawer module becomes a little easier to navigate through without all of
the graphics mixed in. It's also easy to do one-off graphics like the
9.2 Die Hard tribute by dteske@ without adding even more to our memory
requirements.
- No need for a 'goto' when our entire loop body is then wrapped in a
conditional.
- No need to leave commented out prints laying around
- If an expression is clearly going to be either nil or an expression that
isn't likely to be a boolean, we might as well use `or` to specify a
default value for the expression. e.g. `loader.getenv(...) or "no"`
The previous iteration of this assumed that {module}_load was set. In the
old world order of default loader.conf(5), this was probably a safe
assumption given that we had almost every module explicitly not-loaded in
it.
In the new world order, this is no longer the case, so one could delete a
_load line inadvertently while leaving a _name, _type, _flags, _before,
_after, or _error. This would have caused a confusing Lua error and borked
module loading.
It was previously only printed, but we do actually want to raise it as a
full blown error so that things don't look OK when they've actually gone
wrong.
The second parameter to error, level, is set to 2 here so that the error
message reflects the position of the try_include caller, rather than the
try_include itself. Example:
LUA ERROR: /boot/lua/loader.lua:46: /boot/lua/local.lua:1: attempt to call a
nil value (global 'cxcint').
This provides a way to optionally include a module without having to wrap it
in filesystem checks. try_include is a little more robust, using the lua
search path instead of forcing us to explicitly consider all of the places
we could want to include a module. Errors are still generally raised from
trying to load the module, but ENOENT will not get raised unless we're doing
a verbose load.
This will also be used to split out logo/brand graphics into their own files
so that we can safely scale up the number of graphics included without
worrying about the extra memory consumption- opting to lazily load graphics
instead.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D14658
This pertains exclusively to the set/restore functionality that we offer,
where any changes made by loader.conf previously will be effectively removed
upon reload of the configuration. We don't currently have a need to export
these, so don't bother.
boot1 is too early to be deciding a good resolution. Console modes don't map
cleanly/predictably to actual screen resolutions, and GOP does not reflect
the actual screen resolution after a console mode change. Rip it out.
Add an efi-autoresizecons command to loader to choose an optimal screen
resolution based on the current environment. We'll explicitly execute this
later, preferably before we draw anything of value but after we load config
and pick up any tunables we may need to decide where we're going.
This method also allows us to actually pass the correct framebuffer
information on to the kernel.
UGA autoresizing is not implemented because it doesn't have the kind of mode
enumeration that GOP does. If an interested person with relevant hardware
could get in contact, we can take a look at implementing UGA autoresize.
This effectively "fixes" the breakage caused by r327058, but doesn't
actually set the resolution correctly until the interpreter calls
efi-autoresizcons. The lualoader version of this has been included for
reference; the forth equivalent will follow.
Reviewed by: imp (with some hestitation), manu
Differential Revision: https://reviews.freebsd.org/D14788
In the original lualoader project, 'escapef' and 'escapeb' were chosen for
'escape fg' and 'escape bg'. We've carried on this naming convention, and as
our use of attributes grow the likeliness of 'escapeb'/'resetb' being
confused upon glance for 'escape bold'/'reset bold' increases.
Fix this by renaming these four functions to {escape,reset}{fg,bg} rather
than {escape,reset}{f,b} for clarity.
Reported by: dteske
See: comments in the hook module about intended usage, as well as the
introduced use for config.reloaded.
Use the newly introduced hook module to define a "config.reloaded" hook.
This is currently used to register core's clearKernelCache as a reload hook
to avoid a circular dependency and fix this functionality- it didn't
actually work out, and it isn't immediately obvious how it slipped into src.
Other hook types will be introduced into the core lualoader as useful hook
points are identified.
Previously, we sent a CSI 0m sequence to reset attributes, which also reset
the color scheme if the terminal defaults didn't match what we're expecting.
Go all-in and reset the color scheme, too, just in case.
Reported by: emaste
The console may have been set for different colors before lualoader kicks
in; notably, a black-on-white color scheme is not necessarily what we're
expecting.
While here, make color.default() a composition of color.escape() instead of
rewriting the escape sequence to make it more obvious what it's achieving: a
white-on-black color scheme with no attributes set.
Reported by: emaste, whose eyes may rest easily
With autodetection turned on, hitting the filesystem everytime we need to
calculate choices for the kernel carousel is kind of slow. Cache once on the
first listing and reload it anytime the config is reloaded in case any of
the loader.conf(5) changes that affect this (kernel, kernels,
kernels_autodetect) have changed. This also picks up the case where we've
changed currdev and the autodetected kernels could change.
cli_execute was changed to return the status, cascade that to
cli_execute_unparsed.
This fixes a lot of false "Failed to execute" errors following r330620; no
failures actually occurred, but [module]_error would've then promptly
executed (and also "failed")
This applies to:
- exec
- [module]_before
- [module]_error
- [module]_after
Before this commit, these used loader.perform to execute them as a pure,
unsalted loader command. This means that they were not able to take
advantage of any Lua-salted loader commands, like boot and autoboot, or pure
Lua loader commands (functions attached to the 'cli' module).
They now have access to the full arsenal, just shy of being able to execute
arbitrary Lua.
loader.interpret should not be used for executing loader commands from an
untrusted source (e.g. environment vars) as it will allow execution of
arbitrary Lua. Replace it with a call to the recently introduced
cli_execute_unparsed, which parses it out as a loader command and then
dispatches it as a loader command. This effectively filters out arbitrary
Lua.
This will be used for scenarios where the command to execute is coming in
via the environment (from, for example, loader.conf(5)) and is thus not
necessarily trusted.
cli_execute_unparsed will immediately be used for handling
module_{before,after,error} as well as menu_timeout_command. We still want
to offer these variables the ability to execute Lua-intercepted loader
commands, but we don't want them to be able to execute arbitrary Lua.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D14580
Back when I "fixed" the loading of kernel/modules to be deferred until
booting, I inadvertently broke the ability to manually load a set of kernels
and modules in case of something bad having happened. lualoader would
instead happily load whatever is specified in loader.conf(5) and go about
the boot, leading to a panic loop as you try to rediscover a way to stop the
panicky efirt module from loading and fail miserably.
Reported by: me, sadly
loader.command(...) will return whatever the executed function returns, so
follow suit and return whatever loader.command() returned or whatever the
Lua function returns.
- All of our default positions were offset from forth
- Our menu frame size was smaller than in forth
- Logo/brand drawing had an off-by-one, drawing one column lower on the
screen than they should have been.
- While here, switch a print() to printc() as it's expected that logos may
contain color and other escpae sequences that we'll need to honor.
It may be set to "left" or "right" -- any other value will cause the title
to be centered.
I've chosen to position these things just inside the vertical borders,
rather than overlapping the corners. This is an arbitrary choice and easily
amendable if this looks terrible.
Rather than before the menu is drawn. The drawer is going to reset the
crusor position as soon as it draws anything anyways, so doing it before
serves no purpose. Setting it after is needed so we don't clobber the menu
when we start booting.
r330282 registered loader.printc as printc, so use it instead. This makes
sense for a couple reasons, the major point being that it reads a little bit
easier and pairs nicely with the global 'print'.
Similar cases can not really be made for other loader.* functions as most of
them are either highly specific to our use-case or usually available in
other modules, such as `os`. printc does not have a standard implementation
in the Lua world(*), so we have a little more leeway with it, and it's kind
of a special case of the globally available 'print'.
(*) I've been in the Lua world for all of two weeks, so this could be wrong.
- Add drawer.frame_styles to map out the kinds of characters we need for the
different loader_menu_frame values
- Respect loader_menu_frame, default to double[*]
- (imp) Use loader.printc instead of print- print adds a newline to the
output, which is not the right thing we want to be doing.
- (imp) Draw horizontal frames a little more efficiently- setting the cursor
after every line segment is horribly inefficient, especially on serial
consoles. Halve the number of characters written at the expense of an
additional loop to draw the bottom frame, which is likely more efficient
in the long run for some of less ideal scenarios.
[*] menu.4th(8) claims that the default here was single, but unset
loader_menu_frame yielded double and we didn't have any overrides in the
default loader.conf(5), so double it is.
Distribution will be done after all of the lualoader manpages are created.
Reviewed by: rpokala
Differential Revision: https://reviews.freebsd.org/D14480
Distribution will be done after all of the lualoader manpages are created.
Reviewed by: rpokala
Differential Revision: https://reviews.freebsd.org/D14479
