From owner-freebsd-bugs@freebsd.org Fri Dec 27 00:19:31 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBFBA1DCB5F for ; Fri, 27 Dec 2019 00:19:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47kSBC4XXxz4TNW for ; Fri, 27 Dec 2019 00:19:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 99E961DCB5C; Fri, 27 Dec 2019 00:19:31 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 99A9E1DCB5A for ; Fri, 27 Dec 2019 00:19:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47kSBC300lz4TNV for ; Fri, 27 Dec 2019 00:19:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5DD3389AF for ; Fri, 27 Dec 2019 00:19:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xBR0JVt3037995 for ; Fri, 27 Dec 2019 00:19:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xBR0JVEW037986 for bugs@FreeBSD.org; Fri, 27 Dec 2019 00:19:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242899] zfsboot + geli does not handle installation on a glabeled device Date: Fri, 27 Dec 2019 00:19:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sproberts92@outlook.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 00:19:31 -0000 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 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.=