[Bug 264282] BIOS boot from GELI encrypted broken / 'currdev' set to wrong string

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282

            Bug ID: 264282
           Summary: BIOS boot from GELI encrypted broken / 'currdev' set
                    to wrong string
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: yamagi@yamagi.org

Hello,
in 13.1-RELEASE and -CURRENT as of 18054d0220cf it's impossible to boot from an
GELI encrypted root volume, because the 'currdev' loader variable is set to a
wrong string. Thus the loader is unable to load the boot data from the disk.
I've bisect this in 13.1-RELEASE. It was broken in commit bc9154a208248, which
was cherry picked from b4cb3fe0e39a.

Setup
-----
I've tested BIOS boot from GPT with / on GELI. / is decrypted by gptboot. The
bootchain is BIOS -> pmbr (read from the MBR) -> gptboot (read from a
freebsd-boot partition) -> /boot/loader.

geli show:
=>      40  41942960  vtbd0  GPT  (20G)
        40       256      1  freebsd-boot  (128K)
       296   4194304      2  freebsd-swap  (2.0G)
   4194600  37748400      3  freebsd-ufs  (18G)

It doesn't matter if it's real hardware or - like in this example - an VM. It
happens regardless how many devices are attached.

Problem
-------
Try to boot the system. /boot/loader errors out with "ERROR: cannot open
/boot/lua/loader.lua: no such file or directory." This is caused by the currdev
variable get set to the wrong string:

# show currdev
gelidisk0p3:

The 'geli' at the beginning of the string is wrong. lsdev lists the device with
its correct name, disk0p3. loaders build before bc9154a208248 are working fine,
currdev is set to disk0p3.

Impact
------
This makes it impossible to boot from an encrypted /. At least not without
manual interactions, like typing the correct path into the loader prompt.  I've
testes only BIOS with GPT and UFS. I don't know if other combinations are also
impacted.

-- 
You are receiving this mail because:
You are the assignee for the bug.