New FreeBSD 15.1 installation: Cannot open /boot/lua/loader.lua

F

fax668

I am stuck on a new FreeBSD 15.1 installation on a new system and none of the hints in this forum or elsewhere have brought me closer to a resolution. When booting the system in EFI mode (CSM legacy mode is disabled), the ESP loader is giving me this:
Code: 
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk5p1:
FreeBSD/amd64 EFI loader, Revision 3.0

    Command line arguments: rootdev=disk5p2:
    Image base: 0xb5409000
    EFI version: 2.70
    EFI Firmware: American Megatrends (rev 5.17)
    Console: efi (0)
    Load Path: \EFI\FREEBSD\LOADER.EFI
    Load Device: PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,8F58E360-8B7B-11F1-BD3D-9C6B009FDCB5,0x28,0x82000)
    BootCurrent: 0000
    BootOrder: 0000[*] 0002
     Setting currdev to configured rootdev disk5p2:
ERROR: cannot open /boot/lua/loader.lua: no such file or directory.

The system has one NVMe SSD for the system installation and four SATA HDDs. Only the NVMe drive has a ESP, i.e. "currdev disk5p1:" clearly is the correct ESP. The system drive has the following partitions:
  • p1: ESP, 260 MB
  • p2: UFS /boot, unencrypted
  • p3: Swap
  • p4: ZFS root, GELI encrypted
  • p5: ZFS L2ARC
Since that partitioning layout isn't fully supported by the installer, I created it manually using a FreeBSD 15.1 live image before running the installer.

Clearly the ESP loader from p1 is being loaded and then it fails to find p2 or the Lua loader on p2. The rootdev setting is obviously picked up and I tried all sorts of combinations from disk1p1: to disk5p5: but disk5p2: should be correct AFAICT.

When I mount p2, I can definitely see the loader.lua file, which is a valid text file that contains a Lua script:
Code: 
-r--r--r--  1 root wheel  2.3K Jun 12 00:37 /tmp/boot/lua/loader.lua

I am wondering one thing now however, because the root of the filesystem on p2 would be /lua/loader.lua, not /boot/lua/loader.lua as it says in the error in the boot console. Did I accidentally screw up the directory levels in p2 when I manually partitioned and created the file systems? Any other hints how to debug this or what I could be looking into before I give up and wipe it all and start over from scratch?
 
Your issue is primarily caused by putting /boot on its own partition. That's common on Linux but the FreeBSD boot process is entirely different.

The FreeBSD boot loaders (loader.efi or gptzfsboot(8)) have enough knowledge of ZFS to be able to boot from it.
 
Alright, I have been trying to emulate how OpenBSD does full disk encryption with a key file on a USB stick, so that the system can boot automatically without waiting for a password. My understanding is that the FreeBSD loader does not support ZFS native encryption with a key file on a USB stick. So I ended up with this unencrypted UFS /boot partition that should then be able to use GELI and decrypt zroot. I skipped that explanation initially because we are not even getting to the stage where the boat loader from the unencrypted /boot partition is invoked. So am I completely on the wrong track here or should that work in principle?
 
fax668 said:
My understanding is that the FreeBSD loader does not support ZFS native encryption with a key file on a USB stick. So I ended up with this unencrypted UFS /boot partition that should then be able to use GELI and decrypt zroot.
Click to expand...
It's possible to boot the encrypted Root-on-ZFS partition with a keyfile from the unencrypted /boot partition. I've done it many time in test setups in VMs.

The loader is looking for /boot/lua/loader.lua, so the root of the boot partitions file system must be /boot. The keyfile configuration is configure in (unencrypted) /boot/loader.conf. See

geli(8) EXAMPLES.
Code: 
           geli_da0_keyfile0_load="YES"
           geli_da0_keyfile0_type="da0:geli_keyfile0"
           geli_da0_keyfile0_name="/boot/keys/da0.key0"
           geli_da0_keyfile1_load="YES"
           geli_da0_keyfile1_type="da0:geli_keyfile1"
           geli_da0_keyfile1_name="/boot/keys/da0.key1"
           geli_da0_keyfile2_load="YES"
           geli_da0_keyfile2_type="da0:geli_keyfile2"
           geli_da0_keyfile2_name="/boot/keys/da0.key2"

           geli_da1s3a_keyfile0_load="YES"
           geli_da1s3a_keyfile0_type="da1s3a:geli_keyfile0"
           geli_da1s3a_keyfile0_name="/boot/keys/da1s3a.key"

     If there is only one keyfile, the index might be omitted:

           geli_da1s3a_keyfile_load="YES"
           geli_da1s3a_keyfile_type="da1s3a:geli_keyfile"
           geli_da1s3a_keyfile_name="/boot/keys/da1s3a.key"
 
Yep, thanks, I have a similar config in loader.conf but clearly the boot is not even getting there.

(Putting a keyfile to an unencrypted partition on the same drive as the zroot seems a bit pointless however.)
 
fax668 said:
(Putting a keyfile to an unencrypted partition on the same drive as the zroot seems a bit pointless however.)
Click to expand...
The keyfile would be on a removable USB stick (e.g. da0, file system partition labeled "usbkeyf"), the loader would read it from the un-encrypted /boot/loader.conf. Example:
Code: 
geli_usb_keyfile_load="YES"
geli_usb_keyfile_type="gpt/usbkeyf:geli_keyfile"
geli_usb_keyfile_name="/keys/keyfile.key"

fax668 said:
The system has one NVMe SSD for the system installation and four SATA HDDs. Only the NVMe drive has a ESP, i.e. "currdev disk5p1:" clearly is the correct ESP.
Click to expand...
The number of disks don't add up. "one NVMe SSD" + "four SATA HDDs" makes 5 disks, "currdev disk5p1:" disk numbering starting at "0" makes disk5 a sixth disk.

Please clarify the discrepancy. Perhaps you meant the fifth disk ( disk4p1 )?
 
That's a smart question. I realized that the FreeBSD EFI boot loader console has a lsdev command. Unfortunately, it doesn't really provide any new information:
Code: 
disk devices:
    disk0:    60620800 X 512 blocks (removable)
      disk0p1: FreeBSD UFS
    disk1:    3907029168 X 512 blocks
    disk2:    3907029168 X 512 blocks
    disk3:    3907029168 X 512 blocks
    disk4:    3907029168 X 512 blocks
    disk5:    1000215126 X 512 blocks
      disk5p1: EFI
      disk5p2: FreeBSD UFS
      disk5p3: FreeBSD swap
      disk5p4: FreeBSD ZFS
      disk5p5: FreeBSD ZFS
http: (unknown)
net devices:

disk0 must be the USB stick with the keyfile. disk1 - disk4 are the HDDs. disk5 obviously is the NVMe SSD with the system installation.
 
When I try ls in the EFI boot loader console, I am getting this (honestly don't know how to select the partition on which to run these commands):
Code: 
OK ls /boot
    /boot
OK ls /boot/lua
open '/boot/lua' failed: no such file or directory
OK ls /lua
/lua
    cli.lua
    ....
    loader.lua
    ....
OK

Looks to me like I have the wrong directory structure on the boot partition?
 
You must log in or register to reply here.
Back
Top