Bug 234031 - loader can't traverse filesystem, LUA ERROR: cannot open /boot/lua/loader.lua
Summary: loader can't traverse filesystem, LUA ERROR: cannot open /boot/lua/loader.lua
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2018-12-15 03:41 UTC by ultramage
Modified: 2019-08-16 11:19 UTC (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ultramage 2018-12-15 03:41:45 UTC
Booting from a clean copy of /boot obtained from FreeBSD-12.0-RELEASE-amd64-bootonly.iso does not work. The BTX loader seems to have issues traversing the filesystem - when I poke around with 'ls', it sees the root, but can't enter subdirectories. The system disk uses BSD/UFS scheme. The loader however has no trouble browsing the storage disk, which is GPT/UFS.

This has been previously reported a month ago in CURRENT as bug #233098 but was miscategorized and no additional info was provided. The issue is currently being discussed in https://forums.freebsd.org/threads/lua-error-can-not-open-boot-lua-loader-lua.68635/

I am currently working around this by booting off of the iso, then mounting the system disk. Interestingly, /dev/ada0 exists but dev/ada0a doesn't, and 'gpart list' does not even mention ada0. No idea what this means. I ran fsck just in case, all filesystems are clean.

  FreeBSD/x86 bootstrap loader. Revision 1.1
  Startup error in /boot/lua/loader.lua:
  LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
  can't load 'kernel'
  Type '?' for a list of commands, 'help' for more detailed help.

OK lsdev
  disk devices:
       disk0:   BIOS drive C (16514064 x 512):
         disk0a: FreeBSD UFS
       disk1:   BIOS drive D (3907029168 x 512):
         disk1p1: FreeBSD UFS

OK ls disk1p1:/example
  disk1p1:/example
   d  dir1
   d  dir2
OK ls disk0a:/boot
  open 'disk0a:/boot' failed: no such file or directory
OK ls disk0a:/root
  open 'disk0a:/root' failed: no such file or directory
Comment 1 Rodrigo N. Hernandez freebsd_triage 2018-12-15 07:27:18 UTC
Installing from media FreeBSD-12.0-RELEASE-amd64-disc1.iso in a VM (VirtualBox), legacy BIOS mode and BSD disklabel resulted in the same error: Can't boot with "LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory."
Comment 2 Kyle Evans freebsd_committer 2018-12-15 14:42:26 UTC
CCing tsoome@, since this is the one reported via IRC <= 24 hours ago -- looked like x86 loader may not be getting currdev set in some circumstances.
Comment 3 ultramage 2018-12-15 14:48:19 UTC
currdev and loaddev is set to 'disk0s4a'. This is maybe correct? (the size is weird tho')

# fdisk /dev/ada0
******* Working on device /dev/ada0 *******
parameters extracted from in-core disklabel are:
cylinders=58161 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=58161 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 0, size 50000 (24 Meg), flag 80 (active)
        beg: cyl 0/ head 0/ sector 1;
        end: cyl 1023/ head 254/ sector 63
Comment 4 former_user 2018-12-17 17:07:36 UTC
Have been able to reproduce the issue inside a VM - when GPT isn't used, the problems always happen. Once switching to GPT, everything works as expected.
Well, if you've an existing partition layout not using GPT, bad luck.

Oh, problem solved here by reinstalling but of course not freebsd - if I've to reinstall anyways I thought I can switch to something better tested before releasing.
Comment 5 Toomas Soome freebsd_committer 2018-12-17 19:40:48 UTC
(In reply to vollbluthengst from comment #4)

could you post:

 gpart list ada0
 gpart list adad0s4

This setup sounds like you intend to have MBR partition table (4 slices), and in one slice, BSD disk label, thats why loader lsdev -v will show letters at the end of the disk names, like disk0p1a:

however, in your example, you have something really weird going on with disk0, as we see disk0a:, with MBR + BSD I would expect the output like disk0s4a: 

in my test disk I have:
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 10474317 (5114 Meg), flag 80 (active)
	beg: cyl 0/ head 1/ sector 1;
	end: cyl 651/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

root@freebsd-2:~ # gpart list da3
Geom name: da3
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 10485759
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: da3s1
   Mediasize: 5362850304 (5.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r0w0e0
   efimedia: HD(1,MBR,0x90909090,0x3f,0x9fd34d)
   attrib: active
   rawtype: 165
   length: 5362850304
   offset: 32256
   type: freebsd
   index: 1
   end: 10474379
   start: 63
Consumers:
1. Name: da3
   Mediasize: 5368709120 (5.0G)
   Sectorsize: 512
   Mode: r0w0e0

root@freebsd-2:~ # gpart list da3s1
Geom name: da3s1
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 10474316
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: da3s1a
   Mediasize: 5362850304 (5.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r0w0e0
   rawtype: 7
   length: 5362850304
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 10474316
   start: 0
Consumers:
1. Name: da3s1
   Mediasize: 5362850304 (5.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r0w0e0
Comment 6 former_user 2018-12-17 20:11:30 UTC
To add, a VM running inside Qemu so there's no ada0 - instead the device is vtbd0 and the gpart output:

Geom name: vtbd0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 104857559
first: 0
entries: 2
scheme: BSD
Providers:
1. Name: vtbd0a
   Mediasize:  50465341440 (47G)
   Sectorsize: 512
   Mode: r1w1e1
   rawtype: 7
   length: 50465341440
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 10485759
   start: 0
2. Name: vtbd0b
   Mediasize: 2684354560 (2.5G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 3221245952
   Mode: r1w1e0
   rawtype: 1
   length: 2684354560
   offset: 50465886208
   type: freebsd-swap
   index: 2
   end: 103809063
   start: 10485760

A reinstall with explicitly choosing GPT and ignoring the installer wants to use BSD the layout:

Geom name: vtbd0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 104857559
first: 40
entries: 152
scheme: GPT
Providers:
1. Name: vtbd0p1
   Mediasize: 524288 (512K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   efimedia: HD(1,GPT,d9da6ff2-021d-11e9-b4eb-00163cfd496c,0x28,0x400)
   rawuuid: d9da6ff2-021d-11e9-b4eb-00163cfd496c
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 524288
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 1063
   start: 40
2. Name: vtbd0p2
   Mediasize: 50465341440 (47G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 544768
   Mode: r1w1e1
   efimedia: HD(2,GPT,d9e22632-021d-11e9-b4eb-00163cfd496c,0x428,0x5dffc00)
   rawuuid: d9e22632-021d-11e9-b4eb-00163cfd496c
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 50465341440
   offset: 544768
   type: freebsd-ufs
   index: 2
   end: 98566183
   start: 1064
3. Name: vtbd0p3
   Mediasize: 2684354560 (2.5G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 3221245952
   Mode: r1w1e0
   efimedia: HD(3,GPT,d9fa078e-021d-11e9-b4eb-00163cfd496c,0x5e00028,0x500000)
   rawuuid: d9fa078e-021d-11e9-b4eb-00163cfd496c
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 2684354560
   offset: 50465886208
   type: freebsd-swap
   index: 3
   end: 103809063
   start: 98566184
Consumers:
1. Name: vtbd0
   Mediasize: 53687091200 (50G)
   Sectorsize: 512
   Mode: r2w2e3

which works. Another system still affected by the issue:

Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 976773167
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: ada0a
   Mediasize: 5368709120 (5.0G)
   Sectorsize: 512
   Mode: r1w1e1
   rawtype: 7
   length: 5368709120
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 10485759
   start: 0
2. Name: ada0b
   Mediasize: 17179869184 (16G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1073741824
   Mode: r1w1e0
   rawtype: 1
   length: 17179869184
   offset: 5368709120
   type: freebsd-swap
   index: 2
   end: 44040191
   start: 10485760
3. Name: ada0d
   Mediasize: 5368709120 (5.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1073741824
   Mode: r1w1e1
   rawtype: 7
   length: 5368709120
   offset: 22548578304
   type: freebsd-ufs
   index: 4
   end: 54525951
   start: 44040192
4. Name: ada0e
   Mediasize: 53687091200 (50G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 2147483648
   Mode: r1w1e1
   rawtype: 7
   length: 53687091200
   offset: 27917287424
   type: freebsd-ufs
   index: 5
   end: 159383551
   start: 54525952
5. Name: ada0f
   Mediasize: 418503483392 (390G)
   Sectorsize: 512
   Mode: r1w1e1
   rawtype: 27
   length: 418503483392
   offset: 81604378624
   type: freebsd-zfs
   index: 6
   end: 976773167
   start: 159383552
Consumers:
1. Name: ada0
   Mediasize: 500107862016 (466G)
   Sectorsize: 512
   Mode: r5w5e9

In the non-working cases the loader gets stuck being unable to find lua, lsdev shows disk0a / disk0b etc. and one is able to do "ls /" but unable to "walk" into directories.
Manually setting currdev to e.g. disk0a still won't help. Booting from ISO, then setting currdev and loading the kernel helps as work-around.

To reproduce do an install of 11.2-RELEASE inside a VirtualBox / QEMU VM, choosing BSD disklabel as layout, let it use the entire disk and then upgrade to 12.0-RELEASE.
Comment 7 Toomas Soome freebsd_committer 2018-12-17 21:30:19 UTC
so, I did:

root@freebsd-2:~ # gpart list da3
Geom name: da3
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 10485759
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: da3a
   Mediasize: 5368709120 (5.0G)
   Sectorsize: 512
   Mode: r0w0e0
   rawtype: 7
   length: 5368709120
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 10485759
   start: 0
Consumers:
1. Name: da3
   Mediasize: 5368709120 (5.0G)
   Sectorsize: 512
   Mode: r0w0e0

root@freebsd-2:~ #

did put ufson it, did copy /boot and it is quite readable... even boot/lua :)

BUT, I did test it with current...  I can provide you binary loader so you can check if  it does fix it for you - if it does, then we have already fixed the issue:)
Comment 8 yani 2019-01-03 22:58:00 UTC
I'm having the same issue with 12.0-RELEASE. I've also tried to build the world with the "LOADER_DEFAULT_INTERP=4th" setting in src.conf. In this case, I've just received the "can't load 'kernel'" error message, with no reference to a missing  "loader.lua" file.

My gpart output is the following.

Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 468862127
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: ada0a
   Mediasize: 240057409536 (224G)
   Sectorsize: 512
   Mode: r1w1e1
   rawtype: 7
   length: 240057409536
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 468862127
   start: 0
Consumers:
1. Name: ada0
   Mediasize: 240057409536 (224G)
   Sectorsize: 512
   Mode: r1w1e2
Comment 9 Toomas Soome freebsd_committer 2019-01-05 14:24:15 UTC
The question is still up - is anyone experiencing this issue willing to test binary from 12 stable and current (I can build the binary) - so we can be sure the problem is not fixed already.
Comment 10 ultramage 2019-01-05 16:07:48 UTC
Well, wouldn't it be as simple as downloading latest CURRENT bootonly iso from https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ and transplanting /boot? If anyone still has a testing VM handy, maybe give it a try.
Comment 11 Toomas Soome freebsd_committer 2019-01-05 19:53:44 UTC
(In reply to ultramage from comment #10)

I just did install 12-release to vmware fusion:

root@freebsd-test:~ # uname -a
FreeBSD freebsd-test 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64
root@freebsd-test:~ #  gpart list
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 41943039
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: da0a
   Mediasize: 20401094656 (19G)
   Sectorsize: 512
   Mode: r1w1e1
   rawtype: 7
   length: 20401094656
   offset: 0
   type: freebsd-ufs
   index: 1
   end: 39845887
   start: 0
2. Name: da0b
   Mediasize: 1073741824 (1.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 3221225472
   Mode: r1w1e0
   rawtype: 1
   length: 1073741824
   offset: 20401094656
   type: freebsd-swap
   index: 2
   end: 41943039
   start: 39845888
Consumers:
1. Name: da0
   Mediasize: 21474836480 (20G)
   Sectorsize: 512
   Mode: r2w2e3

root@freebsd-test:~ # 


And unfortunately it does boot just fine... 

Then I did create exactly the same install on vbox, and again it does boot... also browsing disk manually with ls (from OK prompt) does not give errors.

Therefore I am in trouble with reproducing the error.
Comment 12 ultramage 2019-01-06 07:15:15 UTC
Right. I tried the posted instructions in vmware player 14, using both guided and manual partitioning, and using both freebsd-update and just copying /boot. In all cases, the loader could find the disk just fine. I used the -disc1 isos from the ftp server.

It's difficult for me to do live testing on the affected host at the moment. I hope the others posting here can reproduce this. More detailed steps (and perhaps a confirmation from the person who posted them) would be helpful.

> To reproduce do an install of 11.2-RELEASE inside a VirtualBox / QEMU VM, choosing BSD disklabel as layout, let it use the entire disk and then upgrade to 12.0-RELEASE.
Comment 13 Toomas Soome freebsd_committer 2019-01-06 07:24:13 UTC
(In reply to ultramage from comment #12)

I am not even sure the detailed instructions are possible - it is more about if you find the affected host, and can create disk image, such image would be helpful. This is because it seems to me, it is about some sort of corner case in ufs reader.
Comment 14 Rodrigo N. Hernandez freebsd_triage 2019-01-07 02:41:25 UTC
Hello. Installed again (fresh install) from FreeBSD-12.0-RELEASE-amd64-disc1.iso (MD5 9d3d2933390400918736fcdf46825ee3)in VirutalBox with same error result. Installed two times, one with default IDE controller other with SATA controller, both tries resulted with same broken boot. Installed with default installer options except scheme, choosing BSD disk label (entire disk). Windows10 Guest and VirtualBox 5.2.18 r124319(Qt5.6.2). I exported the appliance (.ova) so tell me if have interest. Unfortunately my internet is very, very bad atm (not at home) but I can try uploading (850Mb).
Comment 15 Rodrigo N. Hernandez freebsd_triage 2019-01-07 15:07:12 UTC
Ok. I've uploaded the exported virtualbox appliance in the case it helps in something: http://www.minasambiente.com.br/repo1/FreeBSDT2.ova (MD5 482f2e5489aa949af904cf49fa6ae9f9). Also, tell me what more I can do with this VM to help (if anything). Thanks!
Comment 16 ultramage 2019-01-07 17:25:52 UTC
Thank you. Your vm image reproduces the issue on VMWare Workstation 14 Player. And by booting off of and then copying /boot from FreeBSD-13.0-CURRENT-amd64-20181213-r342020-bootonly.iso I can get the VM to work properly. That's the oldest image I can find, but maybe the FreeBSD devs can use the VM to narrow down the regression window.

I then gave reproducing it another try, since I noticed the VM used slightly different options. I then determined that when using the default HDD controller mode, SCSI, or using SATA, it works. But when IDE mode is used, it doesn't. Well, at least for this virtual machine software. I'm fairly sure my server uses SATA+AHCI.
Comment 17 Toomas Soome freebsd_committer 2019-01-07 18:02:31 UTC
(In reply to ultramage from comment #16)

ok, I got the image and I can see the problem already - if you run show currdev, it will be quite apparent. I think I can guess whats wrong there, and if I'm correct, it should be fixed in 12-stable too.
Comment 18 Kyle Evans freebsd_committer 2019-01-07 18:05:03 UTC
(In reply to Toomas Soome from comment #17)

This would be worthy of an EN, yeah?
Comment 19 Toomas Soome freebsd_committer 2019-01-07 18:20:49 UTC
(In reply to ultramage from comment #16)

Did following checks:

booted from 12 release iso, OK ls disk0a:boot did gave an error.

booted from FreeBSD-12.0-STABLE-amd64-20181226-r342545-disc1.iso - no error from ls.
booted from FreeBSD-13.0-CURRENT-amd64-20190103-r342707-disc1.iso - no error from ls.

So we have fix in 12 stable. I think it likely is this fix: https://svnweb.freebsd.org/base?view=revision&revision=340240 but I have not verified it.
Comment 20 ultramage 2019-02-11 08:10:11 UTC
I have applied the change you linked to to releng/12.0 r343997 and the issue is still present. Manipulating the loader disk variable currdev does nothing and changing lodadev is not permitted. Which doesn't matter since the loader still can't traverse the filesystem.

I would like to request that this issue be escalated to critical and added to the 12.0 errata. Since STABLE is supposedly fixed, it should be possible to identify the exact code that causes this.

A brief note: In a VMWare VM, IDE fails but SATA and SCSI work. On my machine, SATA(AHCI) fails.
Comment 21 Toomas Soome freebsd_committer 2019-02-11 08:17:19 UTC
(In reply to ultramage from comment #20)
Could you check with stable/12? We have backported a list of updates from current to stable/12.
Comment 22 ultramage 2019-02-11 22:45:04 UTC
I have transplanted the contents of FreeBSD-12.0-STABLE-amd64-20190207-r343863-bootonly.iso's /boot directory, minus the kernel, into the 12.0-releng host that has the issue. The updated loader works and I am currently using it as a workaround.
Comment 23 Jeff Gibbons 2019-02-15 19:02:31 UTC
For me this issue occurs immediately when trying to boot from a CD, even without any hard disk present.  This is on a physical machine, not a VM, and with the hard disk disconnected.  I have tried FreeBSD-12.0-STABLE-i386-20190207-r343863-bootonly.iso, FreeBSD-12.0-STABLE-amd64-20190207-r343863-bootonly.iso, and FreeBSD-13.0-CURRENT-i386-20190207-r343862-bootonly.iso, and all 3 result in the loader stopping at the "OK" prompt after the same "LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory." error (despite the fact that that file is present in each of those CDs) -- and I am unable to traverse the CDROM filesystem from the loader prompt.  I have also tried FreeBSD-11.2-STABLE-i386-20190207-r343863-bootonly.iso, which works perfectly.
Comment 24 Trev 2019-04-16 10:10:57 UTC
This issue also occurs for me when booting from a CD-ROM installation image for 12.0-REL-i386 and 12-STABLE-i386 snapshot ISO of 20190207 on real hardware (Apple Mac mini 2,1).
Comment 25 Denis Polygalov 2019-08-10 11:57:57 UTC
Hit the same issue while trying to boot kernel and world compiled from
base/head sources (13-CURRENT) with TARGET_ARCH=aarch64 via
network. So the loader.efi is also somehow affected and this is
not only ISO-images and not only amd64 related issue.
Add it is still present :(

...(log skipped)...

BOOTP broadcast 1
DHCP client bound to address 192.168.1.201 (1 ms)
Using ethernet@ff540000 device
TFTP from server 192.168.1.102; our IP address is 192.168.1.201
Filename 'boot/loader.efi'.
Load address: 0x800800
Loading: #################################################################
         ##############################################################
         3.9 MiB/s
done
Bytes transferred = 646512 (9dd70 hex)
Speed: 1000, full duplex
Using ethernet@ff540000 device
TFTP from server 192.168.1.102; our IP address is 192.168.1.201
Filename 'boot/loader.efi'.
Load address: 0x2080000
Loading: #################################################################
         ##############################################################
         3.9 MiB/s
done
Bytes transferred = 646512 (9dd70 hex)
Speed: 1000, full duplex
Using ethernet@ff540000 device
TFTP from server 192.168.1.102; our IP address is 192.168.1.201
Filename 'boot/dtb/rockchip/rk3328-rock64.dtb'.
Load address: 0x1f00000
Loading: ##########
         3.4 MiB/s
done
Bytes transferred = 49194 (c02a hex)
Scanning disk rksdmmc@ff500000.blk...
Card did not respond to voltage select!
Scanning disk rksdmmc@ff520000.blk...
Disk rksdmmc@ff520000.blk not ready
Found 2 disks
Consoles: EFI console
    Reading loader env vars from /efi/freebsd/loader.env
FreeBSD/arm64 EFI loader, Revision 1.1
(Sat Aug 10 14:11:30 JST 2019 denis@buildarm)

   Command line arguments: loader.efi
   EFI version: 2.70
   EFI Firmware: Das U-Boot (rev 8217.1792)
   Console: efi (0)
   Load Path: /boot\dtb\rockchip\rk3328-rock64
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(82d605ceda87,0x1)
Setting currdev to net0:
Speed: 1000, full duplex
net0: cannot set rx. filters (status=3)
Setting currdev to net0:
Startup error in /boot/lua/loader.lua:
LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.

can't load 'kernel'

Type '?' for a list of commands, 'help' for more detailed help.
OK
Comment 26 Denis Polygalov 2019-08-16 11:19:02 UTC
Please ignore my previous message.
The error message:
LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
was due to mis-configuration of my NFS server, so the loader.efi
did not have access to the /boot directory.