Problem Upgrading from 13.3-RELEASE to 14.1-RELEASE: Lua Error Upon Booting Kernel

L

linguae

Hello. I have an x86-64 machine running FreeBSD 13.3-RELEASE that I want to upgrade to 14.1-RELEASE. After running freebsd-update upgrade -r 14.1-RELEASE and freebsd-upgrade install, I rebooted my machine, only to encounter the error "Startup error in /boot/lua/loader.lua: LUA ERROR: /boot/lua/core.lua:68: attempt to concatenate a nil value (field 'lua_path'). I am able to boot in FreeBSD by typing boot /boot/kernel.old, but I don't know how to proceed with installing 14.1-RELEASE.

I have attached the full error message.
 

Attachments

  • GPNXPxdbEAAB-sc.jpg
    GPNXPxdbEAAB-sc.jpg
    117.4 KB · Views: 59
What's in /boot/loader.conf and /boot/loader.conf.local?
 
I don't have a /boot/loader.conf.local file, but /boot/loader.conf has the following contents:

Code: 
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
opensolaris_load="YES"
zfs_load="YES"
 
You can remove opensolaris_load, it's not needed for ZFS since the switch to OpenZFS with 13.0. Have you ever updated loader.efi in the efi partition?
 
Judging by the timestamps, /boot/loader.efi was last modified around the time I tried upgrading my system. I haven't edited the file directly. I'm going to try removing opensolaris_load.
 
I also just noticed that if I type boot at the console window instead of typing boot /boot/kernel.old, I'm able to boot into the FreeBSD 14.1-RELEASE kernel. After running uname -a I get a string that contains 14.1-RELEASE.
 
linguae said:
I am able to boot in FreeBSD by typing boot /boot/kernel.old
Click to expand...
Does it boot with the new kernel; boot /boot/kernel/kernel? I assume you only did freebsd-update install once, then rebooted as instructed?
 
linguae said:
I also just noticed that if I type boot at the console window instead of typing boot /boot/kernel.old, I'm able to boot into the FreeBSD 14.1-RELEASE kernel. After running uname -a I get a string that contains 14.1-RELEASE.
Click to expand...
You posted this mere seconds before my previous reply. Ok, that's good. I checked /boot/lua/core.lua on both 13.2 and 14.1. It's slightly different around line 68. I suspect it will eventually work correctly if you finish the upgrade. If you finished the entire upgrade procedure and you still get that error we may need to recheck your files in the /boot/lua/ directory.
 
SirDice said:
You posted this mere seconds before my previous reply. Ok, that's good. I checked /boot/lua/core.lua on both 13.2 and 14.1. It's slightly different around line 68. I suspect it will eventually work correctly if you finish the upgrade. If you finished the entire upgrade procedure and you still get that error we may need to recheck your files in the /boot/lua/ directory.
Click to expand...
I was able to finish the upgrade, but it still boots with the same error, though typing boot allows me to boot into the 14.1-RELEASE kernel. I'm going to look through the sources (unfortunately I don't have a backup of my 13.2 Lua boot files) and see how they differ between versions.
 
SirDice said:
You posted this mere seconds before my previous reply. Ok, that's good. I checked /boot/lua/core.lua on both 13.2 and 14.1. It's slightly different around line 68. I suspect it will eventually work correctly if you finish the upgrade. If you finished the entire upgrade procedure and you still get that error we may need to recheck your files in the /boot/lua/ directory.
Click to expand...
I was able to fix the problem by incorporating the code from the 13.3-RELEASE version of /boot/lua/core.lua into the affected try_include function in the Lua script. Now it boots into 14.1-RELEASE normally.
 
This is on 13.2:
Code: 
function try_include(module)
        if module:sub(1, 1) ~= "/" then
                local lua_path = loader.lua_path
                -- XXX Temporary compat shim; this should be removed once the
                -- loader.lua_path export has sufficiently spread.
                if lua_path == nil then
                        lua_path = "/boot/lua"
                end
                module = lua_path .. "/" .. module
                -- We only attempt to append an extension if an absolute path
                -- wasn't specified.  This assumes that the caller either wants
                -- to treat this like it would require() and specify just the
                -- base filename, or they know what they're doing as they've
                -- specified an absolute path and we shouldn't impede.
                if module:match(".lua$") == nil then
                        module = module .. ".lua"
                end
        end

This is on 14.1:
Code: 
function try_include(module)
        if module:sub(1, 1) ~= "/" then
                module = loader.lua_path .. "/" .. module
                -- We only attempt to append an extension if an absolute path
                -- wasn't specified.  This assumes that the caller either wants
                -- to treat this like it would require() and specify just the
                -- base filename, or they know what they're doing as they've
                -- specified an absolute path and we shouldn't impede.
                if module:match(".lua$") == nil then
                        module = module .. ".lua"
                end
        end
        if lfs.attributes(module, "mode") ~= "file" then
                return
        end

        return dofile(module)
end

This bit got removed:
Code: 
                local lua_path = loader.lua_path
                -- XXX Temporary compat shim; this should be removed once the
                -- loader.lua_path export has sufficiently spread.
                if lua_path == nil then
                        lua_path = "/boot/lua"
                end

I would have expected the first freebsd-update install to fix these scripts. But apparently something went wrong on your system.
 
While trying to upgrade the BIOS, as it was suggested in the bug I opened, I unfortunately bricked the device I was using.

Recently obtained a modern (2024) EFI box, reused the same drive and everything was working right. So, as referenced in the bug, probably the issue is due to outdated EFI firmware.

I have two other boxes, using legacy BIOS settings and they worked flawlessly too. So, probably if you're using an EFI system, updating the firmware may be the only way out, or if permitted, switch the BIOS to only use legacy mode only.

I can't help beyond this, but hope it clarifies a bit more.
 
You must log in or register to reply here.
Back
Top