[Bug 242899] zfsboot + geli does not handle installation on a glabeled device
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Dec 27 00:19:31 UTC 2019
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242899
Bug ID: 242899
Summary: zfsboot + geli does not handle installation on a
glabeled device
Product: Base System
Version: 12.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: bugs at FreeBSD.org
Reporter: sproberts92 at outlook.com
Created attachment 210241
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210241&action=edit
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.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list