Date: Fri, 27 Dec 2019 00:19:30 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242899] zfsboot + geli does not handle installation on a glabeled device Message-ID: <bug-242899-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242899 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@FreeBSD.org Reporter: sproberts92@outlook.com Created attachment 210241 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D210241&action= =3Dedit 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=3D"label/boot_disk" export ZFSBOOT_BOOT_TYPE=3D"UEFI" export ZFSBOOT_BOOT_POOL=3D"YES" export ZFSBOOT_GELI_ENCRYPTION=3D"YES" bsdinstall zfsboot bsdinstall mount However, it appears that several points in the zfsboot script do not handle ZFSBOOT_DISKS=3D"label/boot_disk". /tmp/bsdinstall_log shows the following lines (full log attached): DEBUG: zfs_create_boot: retval=3D1 <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 enou= gh. I can get the installation to proceed by modifying line 1254 (in 12.1-RELEA= SE)=20 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 solut= ion. Examining geom -t looks reasonable at this point: # geom -t Geom Class Provider vtbd0 DISK vtbd0 vtbd0 LABEL label/boot_di= sk label/boot_disk PART label/boot_di= skp1 label/boot_diskp1 LABEL gpt/efiboot0 gpt/efiboot0 DEV=20=20=20=20=20=20=20 label/boot_diskp1 LABEL=20=20=20=20=20 gptid/06d7aa8b-2822-11ea-875a-2dd9cb0e9967 gptid/06d7aa8b-2822-11ea-875a-2dd9cb0e9967 DEV=20=20=20=20=20=20=20 label/boot_diskp1 LABEL msdosfs/EFISYS msdosfs/EFISYS DEV=20=20=20=20=20=20=20 label/boot_diskp1 DEV=20=20=20=20=20=20=20 label/boot_disk PART label/boot_di= skp2 label/boot_diskp2 DEV=20=20=20=20=20=20=20 zfs::vdev ZFS::VDEV=20 label/boot_disk PART label/boot_di= skp3 label/boot_diskp3 LABEL gpt/swap0 gpt/swap0 DEV=20=20=20=20=20=20=20 label/boot_diskp3 LABEL=20=20=20=20=20 gptid/06edbbf6-2822-11ea-875a-2dd9cb0e9967 gptid/06edbbf6-2822-11ea-875a-2dd9cb0e9967 DEV=20=20=20=20=20=20=20 label/boot_diskp3 DEV=20=20=20=20=20=20=20 label/boot_disk PART label/boot_di= skp4 label/boot_diskp4 DEV=20=20=20=20=20=20=20 label/boot_diskp4.eli ELI=20=20=20=20=20=20=20 label/boot_diskp4.eli label/boot_diskp4.eli DEV=20=20=20=20=20=20=20 zfs::vdev ZFS::VDEV=20 label/boot_disk DEV=20=20=20=20=20=20=20 vtbd0 DEV=20=20=20=20=20=20=20 cd0 DISK cd0 cd0 LABEL=20=20=20=20=20 iso9660/12_1_RELEASE_AMD64_BO cd9660.iso9660/12_1_RELEASE_AMD64_BO VFS=20=20=20=20=20=20=20 iso9660/12_1_RELEASE_AMD64_BO PART=20=20=20=20=20=20 iso9660/12_1_RELEASE_AMD64_BO DEV=20=20=20=20=20=20=20 cd0 PART=20=20=20=20=20=20 cd0 DEV=20=20=20=20=20=20=20 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 s= et 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_disk= p1 label/boot_diskp1 DEV=20=20=20=20=20=20=20 label/boot_disk PART label/boot_disk= p2 label/boot_diskp2 DEV=20=20=20=20=20=20=20 label/boot_disk PART label/boot_disk= p3 label/boot_diskp3 DEV=20=20=20=20=20=20=20 label/boot_disk PART label/boot_disk= p4 label/boot_diskp4 DEV=20=20=20=20=20=20=20 label/boot_disk DEV=20=20=20=20=20=20=20 vtbd0 PART vtbd0p1 vtbd0p1 LABEL gpt/efiboot0 gpt/efiboot0 DEV=20=20=20=20=20=20=20 vtbd0p1 LABEL=20=20=20=20=20 gptid/68b1d0f2-2839-11ea-80c7-93b078d4c544 gptid/68b1d0f2-2839-11ea-80c7-93b078d4c544 DEV=20=20=20=20=20=20=20 vtbd0p1 LABEL msdosfs/EFISYS msdosfs/EFISYS DEV=20=20=20=20=20=20=20 vtbd0p1 DEV=20=20=20=20=20=20=20 vtbd0 PART vtbd0p2 vtbd0p2 LABEL gpt/boot0 gpt/boot0 DEV=20=20=20=20=20=20=20 vtbd0p2 LABEL=20=20=20=20=20 gptid/68ca0fe1-2839-11ea-80c7-93b078d4c544 gptid/68ca0fe1-2839-11ea-80c7-93b078d4c544 DEV=20=20=20=20=20=20=20 vtbd0p2 DEV=20=20=20=20=20=20=20 vtbd0 PART vtbd0p3 vtbd0p3 LABEL gpt/swap0 gpt/swap0 DEV=20=20=20=20=20=20=20 vtbd0p3 LABEL=20=20=20=20=20 gptid/68d01e69-2839-11ea-80c7-93b078d4c544 gptid/68d01e69-2839-11ea-80c7-93b078d4c544 DEV=20=20=20=20=20=20=20 vtbd0p3 DEV=20=20=20=20=20=20=20 vtbd0 PART vtbd0p4 vtbd0p4 LABEL gpt/zfs0 gpt/zfs0 DEV=20=20=20=20=20=20=20 vtbd0p4 LABEL=20=20=20=20=20 gptid/68d56ca6-2839-11ea-80c7-93b078d4c544 gptid/68d56ca6-2839-11ea-80c7-93b078d4c544 DEV=20=20=20=20=20=20=20 vtbd0p4 DEV=20=20=20=20=20=20=20 vtbd0 DEV=20=20=20=20=20=20=20 cd0 DISK cd0 cd0 LABEL=20=20=20=20=20 iso9660/12_1_RELEASE_AMD64_BO cd9660.iso9660/12_1_RELEASE_AMD64_BO VFS=20=20=20=20=20=20=20 iso9660/12_1_RELEASE_AMD64_BO PART=20=20=20=20=20=20 iso9660/12_1_RELEASE_AMD64_BO DEV=20=20=20=20=20=20=20 cd0 PART=20=20=20=20=20=20 cd0 DEV=20=20=20 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-242899-227>