I added a line to the menu, but didn't adjust so things were a
line off. Make the necessary adjustments.
Fixes: 7cb65be96d
Sponsored by: Netflix
MFC After: 3 days
Use the correct loader code that adds an inactive highlighted menu item
indicating that an update is needed.
My laptop is the only machine that I have a boot menu. I'd debugged the
menu part there, but had all the other changes, including my original
menu code, on my server and hadn't copied it back before pushing.
Fixes: 0eac99f76e
Sponsored by: Netflix
When the boot loader version is too old, add a warning to the boot menu
to maybe catch people's attention.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D45890
If the loader is < 3.0, print a warning that it's too old and needs to
be upgraded.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45889
This reverts commit 552f3072af.
loader.command_error was added just after 11.2, but appears to not have
been back ported to 11.x. 11.0 was the first lua loader release, so keep
this compat shim until we sort out what to do.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45883
This reverts commit ab97d42add.
There's too many people in the field with FreeBSD 12.0 loader.efi that
stubbed their toe on upgrading to 14.1 since they'd not updated
loader.efi. While we sort out that mess, add back this workaround. Can
revisit after 14.2 maybe.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45882
This reverts commit 8b9178cd0d.
Really old loader.efi files persist in the field. Revert this to support
it. We need to support this through at least 14.2 now, alas.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45881
loader.command_error was available prior to stable/12 branching. No need
to check if it is available or not.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44144
loader.lua_path was committed before stable/13 was branched, and merged
in to for 12.2. Remove workaround for it not being present.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44143
Just after 12.2 and before the stable/13 branch, kevans added lpager.c
to provide a pager interface for commands written in lua. It was merged
into 12.3. Now that 12.2 is long since EOL, we can remove the pager shim
here. Nobody needs that old loader + new lua scripts. Plus only one
command is affected.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44142
Add loader.exit(status). While one can get alomst this behavior with
loader.perform("quit"), quit doesn't allow a value to be returned to the
firmware. The interpretation of 'status' is firmware specific. This can
be used when autobooting doesn't work in scripts, for example, to allow
the firmware to try something else...
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44094
Drawer.lua is the only bit of lua code in the base that uses any of the
functons moved from the loader table to the gfx table. Move the main
code to using the gfx dispatch. Add compat code for running on old
loaders that creates the newer-style gfx table with the term_* functions
we call in it populated. This will even work on the super old versions
of the loader that don't have them (we'll still skip using them).
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D43908
Now that the fb_* and term_* functions are available in the gfx table,
move the documentation to gfx.lua.8. Add information about backwards
compatibility.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D43907
Document all the public functions from the "loader" table.
Sponsored by: Netflix
Reviewed by: pauamma_gundo.com, tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D43701
Loader now also read configuration files listed in local_loader_conf_files.
Files listed here are the last ones read. And /boot/loader.conf.local was
moved from loader_conf_files to local_loader_conf_files leaving only
loader.conf and device.hints in loader_conf_files by default.
The idea is to ensure local_loader_conf_files, i.e., /boot/loader.conf.local,
can always be used to override other user defined settings.
So the sequencing is now as follow:
1. Bootstrap:
/boot/defaults/loader.conf
2. Read loader_conf_files files:
/boot/device.hints
/boot/loader.conf
3. Read loader_conf_dirs files:
/boot/loader.conf.d/*.conf
4. And finally, rread local_loader_conf_files files:
/boot/loader.conf.local
Reviewed by: imp, kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/759
If product_vars is set, it must be a space separated list of environment
variable names to walk through to guess the product. Each time a product can be
guessed (i.e., the corresponding variable is defined), prepend
/boot/loader.conf.d/PRODUCT/ to loader_conf_dirs.
It can be typically used as follow:
smbios.system.planar.maker="PLANAR_MAKER"
smbios.system.planar.product="PLANAR_PRODUCT"
smbios.system.product="PRODUCT"
uboot.m_product="M_PRODUCT"
product_vars="smbios.system.planar.maker smbios.system.planar.product smbios.system.product uboot.m_product"
to read files found in the following directories, in that order:
/boot/loader.conf.d/PLANAR_MAKER
/boot/loader.conf.d/PLANAR_PRODUCT
/boot/loader.conf.d/PRODUCT
/boot/loader.conf.d/M_PRODUCT
Reviewed by: imp, kevans
Pull Request: https://github.com/freebsd/freebsd-src/pull/759
Loader now also read configuration files listed in local_loader_conf_files.
Files listed here are the last ones read. And /boot/loader.conf.local was
moved from loader_conf_files to local_loader_conf_files leaving only
loader.conf and device.hints in loader_conf_files by default.
The idea is to ensure local_loader_conf_files, i.e., /boot/loader.conf.local,
can always be used to override other user defined settings.
So the sequencing is now as follow:
1. Bootstrap:
/boot/defaults/loader.conf
2. Read loader_conf_files files:
/boot/device.hints
/boot/loader.conf
3. Read loader_conf_dirs files:
/boot/loader.conf.d/*.conf
4. And finally, rread local_loader_conf_files files:
/boot/loader.conf.local
If product_vars is set, it must be a space separated list of environment
variable names to walk through to guess the product. Each time a product can be
guessed (i.e., the corresponding variable is defined), prepend
/boot/loader.conf.d/PRODUCT/ to loader_conf_dirs.
It can be typically used as follow:
smbios.system.planar.maker="PLANAR_MAKER"
smbios.system.planar.product="PLANAR_PRODUCT"
smbios.system.product="PRODUCT"
uboot.m_product="M_PRODUCT"
product_vars="smbios.system.planar.maker smbios.system.planar.product smbios.system.product uboot.m_product"
to read files found in the following directories, in that order:
/boot/loader.conf.d/PLANAR_MAKER
/boot/loader.conf.d/PLANAR_PRODUCT
/boot/loader.conf.d/PRODUCT
/boot/loader.conf.d/M_PRODUCT
The `kernel` env var provides the default kernel, usually "kernel". It
may be the case that the user doesn't have a "kernel" kernel, just
"kernel.*" kernels, but have left `kernel` to the default because we
autodetect entries by default anyways.
If we're doing autodetection, take note of whether the default kernel
exists or not and remove it from the list if it doesn't and we had found
any other kernels. We avoid it in the #kernels == 1 case because
something fishy has likely happened and we should just trust the
configuration.
Reviewed by: imp, manu
Differential Revision: https://reviews.freebsd.org/D42967
While we're here, enable the feature in the places we detect ACPI. This
lets us side-step the existing issues and provide a path forward for
folks upgrading from previous releases that haven't updated their ESP
yet.
Let's also fix core.setACPI: the hint already indicates that the
user's disabled it more consistently than loader.acpi_disabled_by_user.
Even more, the latter is wrong because we set it by default if we did
not detect ACPI. The ACPI hint remains even when we're setting defaults
because ACPI loaded into the kernel will make some noise if it's not
hinted off, even when we didn't detect it.
imp notes that this will result in some relatively harmless noise on
platforms that don't support ACPI but aren't using the UEFI loader, as
we would enable the ACPI module for loading on them and then loader
would not be able to find it. These are non-fatal, but should probably
be fixed by just declaring support for EARLY_ACPI in those loaders since
we know they won't have ACPI early on -- punting on this for the time
being, though, in favor of providing a safer upgrade path sooner.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42727
liblua now provides a loader.has_feature() function to probe the loader
binary for features advertised. name => desc mappings are provided in
loader.features to get a list of all of the features loader *can*
support. core.hasFeature is provided as a shim to loader.has_feature
so that individual consumers don't need to think about the logic of the
loader module not providing has_feature; we know that means the feature
isn't enabled.
The first consumer of this will be EARLY_ACPI to advertise that the
loader binary probes for ACPI presence before the interpreter has
started, so that we know whether we can trust the presence of acpi.rsdp
as relatively authoritative. In general, it's intended to be used to
avoid breaking new scripts on older loaders within reason.
This will be used in lua as `core.hasFeature("EARLY_ACPI")`, while the
C bits of loader will `feature_enable(FEATURE_EARLY_ACPI)`.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42695
hw.ata.wc was disconnected as part ot the 2013 cam-ification of ata. No
need to continue setting it. It's been unused in FreeBSD 10.x and newer.
Sponsored by: Netflix
When the eisa code was removed in 2017, prior to the stable/12 branch,
setting hw.eisa_slots became a nop. The oldest supported branch doesn't
have eisa at all. The need to set it manually on boot disappeared
largely by 2000...
Sponsored by: Netflix
Old binaries do not set acpi.rsdp early enough. So when we boot with an
older loader.efi from an ESP that's not been updated, we assume there's
no ACPI on this system. This is unwise. Put a band-aide on this until we
can implement a proper 'feature' variable that the binary reports so we
can do conditionals for things like this in the future.
This is at best a rapid-response stop-gap.
Glanced at by: kevans
Sponsored by: Netflix
This is a follow-up patch to https://reviews.freebsd.org/D42459
that modifies the loader lua to use the correct loader variables
for determining ACPI availability.
This also fixes a bug where ACPI can be inadvertently disabled when
setting System Defaults at the loader menu.
Reviewed by: imp, kevans
Approved by: kp
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D42483
The module entries should generally allow whatever is allowed as an
env_var in the pattern table. Notably, we're missing periods which
would allow proper entries for .dtb files in loader.conf that don't need
to specify a module_name entry for it.
%d in this expression is actually redundant as %w is actually
"all alphanumerics," but I've included it for now to match the env_var
entry. We should really remove it from both.
Reported by: "aribi" on the forums via allanjude@
MFC after: 1 week
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
If a file is specified in loader_conf_files that ends in '.lua', lualoader
will now load and execute that file. These may be used in place of a
traditional loader.conf to use more complicated logic, where some values
may be set based on others or based on the environment that the C bits has
left us with.
Lua scripts are run in a limited environment. In particular, it does not get
access to any modules or, in-fact, anything except environment variable.
A config.buildenv hook has been added so that a local module can add
whatever it may need to to the environment.
When a global var is set in the lua script, it does not immediately alter
the loader environment. Instead, the script's environment is initially
empty and processed only if the whole script executes successfully.
Effectively, a lua configuration file either takes effect or it does not,
an error will not leave it in a half-baked state.
Reviewed by: bcr (manpages), imp
Differential Revision: https://reviews.freebsd.org/D28450
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 timer expires.
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 the system.
PR: 265472
Reviewed by: kevans
MFC after: 3 days
Usually the kernel is loaded later, but there are circumstances where it
could have been loaded earlier than changing BEs. Unload anything that
is already there so that we know we're using artifacts from the proper
environment.
PR: 265471
Reviewed by: kevans
MFC after: 3 days
To make auditing and debugging easier, export foo_load=XXX foo_name=yyy
etc to the loader env that we export to the kernel.
Original by: dhw
Sponsored by: Netflix
Discussed with: kevans
Differential Revsion: https://reviews.freebsd.org/D38466
This allows the "Multi user" in "[B]oot Multi user" to be substituted
with another string, for example with "Installer" in installer media.
Note that this is lua-only at the moment, since loader.4th's menu.rc
defines the alternate name as Boot [M]ulti User, unlike lualoader which
leaves it as [B]oot Multi user. Ideally loader.4th would adopt the newer
and simpler lualoader behaviour and then it could gain support for this
option, but loader.4th is on the way out and isn't used by any official
installer media so this is not a significant concern.
Reviewed by: kevans, rpokala
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36418
UEFI provides a protocol for accessing randomness. This is a good way
to gather early entropy, especially when there's no driver for the RNG
on the platform (as is the case on the Marvell Armada8k (MACCHIATObin)
for now).
If the entropy_efi_seed option is enabled in loader.conf (default: YES)
obtain 2048 bytes of entropy from UEFI and pass is to the kernel as a
"module" of name "efi_rng_seed" and type "boot_entropy_platform"; if
present, ingest it into the kernel RNG.
Submitted by: Greg V
Reviewed by: markm, kevans
Approved by: csprng (markm)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D20780
Otherwise on fs like tftp where no directory listing is possible we fail
on the .dir method.
Reviewed by: imp, kevans
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33414
When the timer drops from double to single digits, a spare 'e' is left
on the end of the line as we don't overwrite it. Include an extra space
at the end to account for this and overwrite the leftover character.
PR: 259429
MFC after: 3 days
Reviewed by: emaste
The behavior remains the same, but lualoader now uses the more concise
verbiage that forthloader used. This is particularly important because
the previous line would exceed the right boundary of the menu and run
straight into space that would typically be allowed for the logo.
This makes it slightly easier to port logos from forthloader to
lualoader.
disable-device fooX will set hint.foo.X.disabled=1 as a way to easily
disable a device attaching during boot.
Reviewed by: tsoome
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D31297
As we output spaces around the menu title, we should also check,
if the title is actually empty string.
PR: 255299
Submitted by: Jose Luis Duran
Reported by: Jose Luis Duran
MFC after: 1 week
Add a dummy vendor menu entry on the main welcome menu. Vendors can override
this in their local.lua file to create whatever sub-menu they need for their
products.
Also fix the adding a 'welcome' entry as well based on a suggestion from Kyle.
Silly option menu code also from Kyle. They seem to work for me, but any
transcription error is likely mine.
Reviewed by: kevans@ (the vendor stuff)
