Bug 235040 - Lua-based loader(8) does not pick up /boot/loader.rc.local
Summary: Lua-based loader(8) does not pick up /boot/loader.rc.local
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2019-01-18 11:10 UTC by Alexey Dokuchaev
Modified: 2021-07-15 00:56 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Dokuchaev freebsd_committer 2019-01-18 11:10:27 UTC
Since the default loader(8) interpreter has been switched from 4th to Lua, settings in /boot/loader.rc.local are no longer picked up.  This is useful, for example, to overwrite "gop" value in order to fix garbled screen when booting on some laptop models (see bug #202309 for details).  Making loader.efi point back to loader_4th.efi fixes the issue.

grep(1) also suggests that Lua version is unaware about this file:

/usr/src/stand% grep -R loader.rc.local .
./i386/loader/loader.rc:try-include /boot/loader.rc.local
./forth/loader.rc:\ You should not edit this file! Put any overrides in loader.rc.local
./forth/loader.rc:try-include /boot/loader.rc.local
Comment 1 Kyle Evans freebsd_committer 2019-01-18 16:16:52 UTC
(In reply to Alexey Dokuchaev from comment #0)


Indeed, because reading loader.rc.local is a little bit of a rabbit hole. We could try to have some limited support by trying to process loader.rc.local as a series of loader commands, but the file is historically parsed as 4th so we can't claim to completely support it.

The loader-independent way to do this is probably best done with the `exec` loader.conf(5) variable. e.g.

exec="gop set 0"
exec="gop set 2"

but ideally we would have loader.conf(5) variables for these kinds of things to trim down the interpreter-dependent things being done by a standard sysadmin/user that isn't trying to modify core boot/menu behavior.
Comment 2 Warner Losh freebsd_committer 2019-01-18 16:59:17 UTC
It doesn't read in /boot/loader.rc either.

The problem is that while loader.rc and loader.rc.local started out with the notion they would be pure loader commands (whatever that means), over time forth leaked into the mix (because we setup words in such a way as to make the loader commands also forth  words, so that the interpreter really was forth, not some abstract loader language that was, at best poorly defined). The default loader.rc shipped on many platforms had forth code in it at different times in the past. And customer deployed loader.rc.local setups definitely had forth code in them.

The end result is that we can't have lua parsing loader.rc or loader.rc.local because it would need a forth interpreter to do so.

If this is highly desirable, we might be able to try to parse loader.rc and do something semi-sane when we hit forth, but it's unclear how to implement semi-sane.

And looking at loader.lua we see:


which will try to include /boot/local.lua, if it exists (or is it /boot/lua/local.lua, I forget). At the very least, we should document this features. And how to translate simple loader.rc.local files into this format.

As a last resort, we might be able to parse the loader.rc.local file (since we've translated the current loader.rc file into lua) and hope for the best, and have that controlled by a loader.conf variable, but that's not in my top 10 list of things to do with the loader.