Created attachment 210241 [details] Full /tmp/bsdinstall_log Same behaviour in 12.0-RELEASE, 12.1-RELEASE and 13.0-CURRENT-20191219. To reproduce, I have an install script containing the following (extract): glabel label "boot_disk" $install_disk export ZFSBOOT_DISKS="label/boot_disk" export ZFSBOOT_BOOT_TYPE="UEFI" export ZFSBOOT_BOOT_POOL="YES" export ZFSBOOT_GELI_ENCRYPTION="YES" bsdinstall zfsboot bsdinstall mount However, it appears that several points in the zfsboot script do not handle ZFSBOOT_DISKS="label/boot_disk". /tmp/bsdinstall_log shows the following lines (full log attached): DEBUG: zfs_create_boot: retval=1 <output below> geli: Unable to open /mnt/bootpool/boot/label/boot_diskp4.eli: No such file or directory. geli: There was an error with at least one provider. Which makes sense, as the / in label/boot_disk is interpreted as a separator for a directory which doesn't exist. I made some attempt at fixing the issue (outlined below), but it isn't enough. I can get the installation to proceed by modifying line 1254 (in 12.1-RELEASE) from $bootpool/boot/$disk$targetpart.eli to $bootpool/boot/$(basename $disk)$targetpart.eli and similar changes on 1496, 1501 and 1506 (although it looks like they're just temporary labels during installation). I went with basename for simplicity, although probably replacing / with _ or . would be a better long term solution. Examining geom -t looks reasonable at this point: # geom -t Geom Class Provider vtbd0 DISK vtbd0 vtbd0 LABEL label/boot_disk label/boot_disk PART label/boot_diskp1 label/boot_diskp1 LABEL gpt/efiboot0 gpt/efiboot0 DEV label/boot_diskp1 LABEL gptid/06d7aa8b-2822-11ea-875a-2dd9cb0e9967 gptid/06d7aa8b-2822-11ea-875a-2dd9cb0e9967 DEV label/boot_diskp1 LABEL msdosfs/EFISYS msdosfs/EFISYS DEV label/boot_diskp1 DEV label/boot_disk PART label/boot_diskp2 label/boot_diskp2 DEV zfs::vdev ZFS::VDEV label/boot_disk PART label/boot_diskp3 label/boot_diskp3 LABEL gpt/swap0 gpt/swap0 DEV label/boot_diskp3 LABEL gptid/06edbbf6-2822-11ea-875a-2dd9cb0e9967 gptid/06edbbf6-2822-11ea-875a-2dd9cb0e9967 DEV label/boot_diskp3 DEV label/boot_disk PART label/boot_diskp4 label/boot_diskp4 DEV label/boot_diskp4.eli ELI label/boot_diskp4.eli label/boot_diskp4.eli DEV zfs::vdev ZFS::VDEV label/boot_disk DEV vtbd0 DEV cd0 DISK cd0 cd0 LABEL iso9660/12_1_RELEASE_AMD64_BO cd9660.iso9660/12_1_RELEASE_AMD64_BO VFS iso9660/12_1_RELEASE_AMD64_BO PART iso9660/12_1_RELEASE_AMD64_BO DEV cd0 PART cd0 DEV With these changes I can get the boot process to start - I get prompted for the geli passphrase and I get the FreeBSD splash screen, however shortly after I get prompted for another passphrase, which does not accept the passphrase set during installation: Enter passphrase for vtbd0p4: Rebooting into the install iso once again and examining geom -t again: # geom -t Geom Class Provider vtbd0 DISK vtbd0 vtbd0 LABEL label/boot_disk label/boot_disk PART label/boot_diskp1 label/boot_diskp1 DEV label/boot_disk PART label/boot_diskp2 label/boot_diskp2 DEV label/boot_disk PART label/boot_diskp3 label/boot_diskp3 DEV label/boot_disk PART label/boot_diskp4 label/boot_diskp4 DEV label/boot_disk DEV vtbd0 PART vtbd0p1 vtbd0p1 LABEL gpt/efiboot0 gpt/efiboot0 DEV vtbd0p1 LABEL gptid/68b1d0f2-2839-11ea-80c7-93b078d4c544 gptid/68b1d0f2-2839-11ea-80c7-93b078d4c544 DEV vtbd0p1 LABEL msdosfs/EFISYS msdosfs/EFISYS DEV vtbd0p1 DEV vtbd0 PART vtbd0p2 vtbd0p2 LABEL gpt/boot0 gpt/boot0 DEV vtbd0p2 LABEL gptid/68ca0fe1-2839-11ea-80c7-93b078d4c544 gptid/68ca0fe1-2839-11ea-80c7-93b078d4c544 DEV vtbd0p2 DEV vtbd0 PART vtbd0p3 vtbd0p3 LABEL gpt/swap0 gpt/swap0 DEV vtbd0p3 LABEL gptid/68d01e69-2839-11ea-80c7-93b078d4c544 gptid/68d01e69-2839-11ea-80c7-93b078d4c544 DEV vtbd0p3 DEV vtbd0 PART vtbd0p4 vtbd0p4 LABEL gpt/zfs0 gpt/zfs0 DEV vtbd0p4 LABEL gptid/68d56ca6-2839-11ea-80c7-93b078d4c544 gptid/68d56ca6-2839-11ea-80c7-93b078d4c544 DEV vtbd0p4 DEV vtbd0 DEV cd0 DISK cd0 cd0 LABEL iso9660/12_1_RELEASE_AMD64_BO cd9660.iso9660/12_1_RELEASE_AMD64_BO VFS iso9660/12_1_RELEASE_AMD64_BO PART iso9660/12_1_RELEASE_AMD64_BO DEV cd0 PART cd0 DEV Which doesn't look good to me, all of the structure has been created under vtbd0, separate from label/boot_disk. So clearly my basename hack was insufficient. Happy to provide any extra diagnostic info you need.