loader: Fully reset terminal settings, not just colors Reviewed by: kevans, tsoome Approved by: mav (mentor)
r357103: loader.lua: re-arrange to load local.lua *after* config loading The major problem with the current ordering is that loader.conf may contain all of the magic we need to actually setup the console, so loading local.lua prior to that can make it excessively difficult and annoying to debug (whoops, sorry Ravi & Warner). The new ordering has some implications, but I suspect they are a non-issue. The first is that it's no longer possible for the local module to inject any logic prior to loading config -- I suspect no one has relied on this. The second implication is that the config.loaded hook is now useless, as the local module will always be included after that hook would have fired. For config.loaded, I will opt to leave it in, just in case we add an early point for local lua to get injected or in case one wants to schedule some deferred logic in a custom loader.lua. The overhead of having it if no hooks will be invoked is relatively minimal. r357104: lua: add modules.loaded hook This may be used for the local module to hook in and load any additional modules that it wants, since it can't modify the modules table internal to config. We may consider adding API to do so at a later time, but I suspect it will be more complicated to use with little return. status is captured but ignored for the purpose of loading the hook. status will be false if *any* module failed to load, but we typically don't let that halt the boot so there's no reason to let it halt hooks. Some vendors or setups may have expected fails that would be actively thwarted by checking it. We may, at a later date, consider adding an API for letting non-config modules check which modules have successfully (or not) loaded in case an unexpected failure *should* halt whatever they are doing.
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)
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)
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 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
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
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
This is motivated by a want to reduce heap usage if the menu is being skipped. Currently, the menu module must be loaded regardless of whether it's being skipped or not, which adds a cool ~50-100KB worth of memory usage. Move the menu skip logic out to core (and remove a debug print), then check in loader.lua if we should be skipping the menu and avoid loading the menu module entirely if so. This keeps our memory usage below ~115KB for a boot with the menu stripped. Also worth noting: with this change, we no longer explicitly invoke autoboot if we're skipping the menu. Instead, we let the standard loader behavior apply: try to autoboot if we need to, then drop to a loader prompt if not or if the autoboot sequence is interrupted. The only thing we still handle before dropping to the loader autoboot sequence is loadelf(), so that we can still apply any of our kernel loading behavior.