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: 162
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.
 
Got the same problem with "lua" on the system with ZFS-mirror updated since 12.1-RELEASE. Struggled with different things until realized that the EFI partition with the loader which was installed at the very beginning, was not ever updated as it was not "visible" by the running system. The solution was pretty obvious (assume /dev/da0 and /dev/da1 are your physical devices):
for i in 0 1; do mkdir /mnt/${i}; mount -t msdosfs /dev/da${i}p1 /mnt/${i}; cp /boot/loader.efi /mnt/${i}/EFI/BOOT/BOOTX64.efi; umount /mnt/$[i}; done
Take into account `EFI/BOOT` may be or may not be uppercase
 
In my case this issue gone after updating loader.efi according to the manual: https://man.freebsd.org/cgi/man.cgi?loader.efi

Updating loader.efi on the ESP
The following example shows how to install a new loader.efi on the ESP.

First, find the partition of type "efi":

# gpart list | grep -Ew '(Name|efi)'
1. Name: nvd0p1
type: efi
2. ...

The name of the ESP on this system is nvd0p1.

Second, let's mount the ESP, copy loader.efi to the special location
reserved for FreeBSD EFI loaders, and unmount once finished:

# mount_msdosfs /dev/nvd0p1 /boot/efi
# cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
# umount /boot/efi
Click to expand...
 
You must log in or register to reply here.
Back
Top