In stable/13 and releng/13.4, core.lua has been updated to display a warning message if the bootloader version is either not set or less than 3. However, stand/lua/lutils.c does not set the version during initialization. The statement lua_pushinteger(L, bootprog_rev); is missing. As a result, the warning is always present.
It looks like commit a50d73d5782a3 was merged to stable/14 but not 13. There is a minor conflict, but I think it applies generally. Steve, Warner, can we merge this?
*** Bug 281921 has been marked as a duplicate of this bug. ***
In the meantime - may be good to mention this in the errata of 13.X Dw.
a50d73d5782a3 does not cleanly apply to the target branches, so I'd punted until now... Now that I look at it, it's easy enough to fix, which I'm testing now. The merge conflict is git being too conservative around context, which normally is fine, but made me thing it was going to be a hassle to resolve. Turns out no, and I'll push once I confirm. releng/13.4 shipped like this, and that's too bad. The warning is harmless there, though admittedly scary. We should add it as an erratum to the release notes, if it's not too late.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dac5a2024bc8bed379d3db861580056d0c670fdc commit dac5a2024bc8bed379d3db861580056d0c670fdc Author: Stephen J. Kiernan <stevek@FreeBSD.org> AuthorDate: 2023-04-17 23:27:54 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2024-10-17 19:08:21 +0000 loader: Change version calculation to be more consistent. Use 1000 * major + minor when calculating the version number that gets set in the Ficl environment or lua loader property. This allows for more room if the minor number needs to go above 9. Add loader.version property to lua loader. PR: 282001 Reviewed by: imp Obtained from: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D39631 (cherry picked from commit a50d73d5782a351ad83e8d1f84d11720a12e70d3) stand/common/bootstrap.h | 1 + stand/common/interp_forth.c | 1 - stand/common/newvers.sh | 2 +- stand/liblua/lutils.c | 2 ++ 4 files changed, 4 insertions(+), 2 deletions(-)
(In reply to Warner Losh from comment #4) Can the problem be fixed without updating boot media? That is, is it just a matter of updating /boot/loader_lua? If so, we can issue an EN with a binary patch to fix the problem for 13.4 users.
For bios, just /boot/loader and loader_lua. For UEFI we have to uodate the ESP. I'd seriously not do an EN and just issue an errata. An EN would cause more problems than it would fix.
(In reply to Warner Losh from comment #7) Ok. I'm not sure what our process is for issuing an erratum without a patch, so not sure how to push that forward.
You could patch core.lua to remove the warning.
(In reply to crahman from comment #9) > You could patch core.lua to remove the warning. That's a lot of work to remove a harmless warning that could be handled as an errata. It's not relevant to stable/13, stable/14, nor main. A direct commit is easy, but then we have to write the EN, and do the administrative work to get it pushed out in a lot of places. All for removing a warning that doesn't matter. That's the wrong approach. It's a lot of energy that the project should instead put towards making the actual updating of the ESP robust. There have been actual bugs, with actual hardware that cause panics that haven't been ENs, so it seems like this is "jumping the line" in a big way. ENs should be simple and easy (and if they were I'd say go for it). But they aren't: they are difficult and have way too much overhead. Just my HO. We should just close this and move on.
With 13.5 coming soon, I'm ok with simply closing this. > so it seems like this is "jumping the line" in a big way I don't really agree - we (secteam) release ENs for issues which generate a lot of bug reports, or if a bug is particularly severe somehow. It's mostly contingent on someone filling out the EN template and submitting it to secteam. We rarely reject ENs unless they truly seem trivial or the associated patch is too risky. In this case, there are some technical reasons for not releasing an EN, but if not for that, based on past experience I think we would go ahead with it.