After r296963 (tested with a system based on r297146), I get additional, but bogus password prompts while booting from a disk with the following layout: fk@r500 ~ $gpart show => 63 488397105 ada0 MBR (233G) 63 488397105 1 freebsd [active] (233G) => 0 488397105 ada0s1 BSD (233G) 0 16 - free - (8.0K) 16 2097152 1 !0 (1.0G) 2097168 4194304 2 freebsd-swap (2.0G) 6291472 482105633 4 !0 (230G) ada0s1d is geli-encrypted and contains the system's ZFS pool. ada0s1a is the unencrypted boot partition (UFS) which also holds a geli keyfile for ada0s1d. Instead of asking for the passphrase for ada0s1d, the new passphrase prompt asks for a passphrase for disk0p1, presumably because the geli metadata on ada0s1d is misinterpreted as metadata for ada0s1. Entering the correct passphrase results in the message "Bad GELI key: -1" and the prompt is repeated. After three failed attempts I get the passphrase prompt from the loader (due to geom_eli_passphrase_prompt="YES") and the system boots fine. My other systems use a GPT layout and continue to work as expected.
I encountered the same issue, ZFS with 3 drives on RAIDZ 1. So I actually get it worse - it prompts me 3 times for each drive (9 total). Finally after 9 times, I can enter my passphrase and boot normally. This is the commit I'm at https://github.com/freebsd/freebsd/commit/b3d0b783231bcda426057a9ea78a3929ed3cfc46.
I just noticed that I was wrong about my GPT-using systems being unaffected, they were just not actually using the affected boot code yet. Most of my systems use the cloudiatr layout: [fk@elektrobier ~]$ gpart show ada0 => 34 976773101 ada0 GPT (466G) 34 128 1 freebsd-boot (64K) 162 1886 - free - (943K) 2048 409600 2 freebsd-zfs (200M) 411648 16777216 3 freebsd-zfs (8.0G) 17188864 8388608 4 freebsd-swap (4.0G) 25577472 951195648 5 freebsd-zfs (454G) 976773120 15 - free - (7.5K) ada0p2 is the unencrypted boot pool that can be deleted after the system is up. It contains parts of the kernel and a keyfile that is required to geli-attach ada0p3 which contains the root pool. On systems that have to be rebooted unattended no passphrase is being used. After r296963 the systems can no longer be booted unattended as there's nobody to skip the bogus passphrase prompts. On the bright side, the partition with the metadata is detected correctly ...
Created attachment 168646 [details] sys/boot: Don't request GELI passphrases for passphrase-less boot devices The attached patch seems to fix the issue for passphrase-less GELI boot devices on disks with GPT layout.
A commit references this bug: Author: allanjude Date: Sat Mar 26 15:39:48 UTC 2016 New revision: 297293 URL: https://svnweb.freebsd.org/changeset/base/297293 Log: Do not prompt for GELI passphrase is encrypted with keys only PR: 208251 Submitted by: Fabian Keil <fk@fabiankeil.de> Sponsored by: ScaleEngine Inc. Changes: head/sys/boot/geli/geliboot.c
Thanks for the report and the patch.
Reopen as the patch only solves the problem for GELI boot partitions without passphrase. From the commit message (which bugzilla seems to hide really well): "r296963 added support for GELI boot devices with passphrases and without keyfiles but the passphrase prompt was shown for all boot devices, including those that only required a keyfile, or that required both a keyfile and a passphrase. Attaching such devices (obviously) did not work and as a result r296963 broke unattended booting from these configurations. This commit suppresses the promt for passphrase-less boot devices but does not suppress it for boot devices that require both a passphrase and a keyfile as this currently can't be deduced from the GELI metadata. Probably a new GELI on-disk flag should be added to solve this." https://bz-attachments.freebsd.org/attachment.cgi?id=168646 The problem that geli-encrypted partitions on slices aren't detected properly has not been solved either.
Confirmed this needs a re-open. The earlier fix base r297293 made no difference on my machine. I still get a prompt for a passphrase on each drive (on an encrypted Raid-Z). So I get prompted for password 10 times. 3 times per each (3 drives), then (as usual) once before the boot loader.
(In reply to Tony Narlock from comment #7) Tony: Can you please include the 'gpart show' output from your system
(In reply to Allan Jude from comment #8) ❯ gpart show => 40 1000215136 ada0 GPT (477G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-zfs (2.0G) 4196352 4194304 3 freebsd-swap (2.0G) 8390656 991823872 4 freebsd-zfs (473G) 1000214528 648 - free - (324K) => 40 1000215136 ada1 GPT (477G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-zfs (2.0G) 4196352 4194304 3 freebsd-swap (2.0G) 8390656 991823872 4 freebsd-zfs (473G) 1000214528 648 - free - (324K) => 40 1000215136 ada2 GPT (477G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-zfs (2.0G) 4196352 4194304 3 freebsd-swap (2.0G) 8390656 991823872 4 freebsd-zfs (473G) 1000214528 648 - free - (324K) => 63 500118129 ada3 MBR (238G) 63 500118129 - free - (238G)
A commit references this bug: Author: allanjude Date: Fri Apr 8 01:25:26 UTC 2016 New revision: 297691 URL: https://svnweb.freebsd.org/changeset/base/297691 Log: Create the GELIBOOT GEOM_ELI flag This flag indicates that the user wishes to use the GELIBOOT feature to boot from a fully encrypted root file system. Currently, GELIBOOT does not support key files, and in the future when it does, they will be loaded differently. Due to the design of GELI, and the desire for secrecy, the GELI metadata does not know if key files are used or not, it just adds the key material (if any) to the HMAC before the optional passphrase, so there is no way to tell if a GELI partition requires key files or not. Since the GELIBOOT code in boot2 and the loader does not support keys, they will now only attempt to attach if this flag is set. This will stop GELIBOOT from prompting for passwords to GELIs that it cannot decrypt, disrupting the boot process PR: 208251 Reviewed by: ed, oshogbo, wblock Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D5867 Changes: head/sbin/geom/class/eli/geli.8 head/sbin/geom/class/eli/geom_eli.c head/sys/geom/eli/g_eli.c head/sys/geom/eli/g_eli.h head/sys/geom/eli/g_eli_ctl.c
A commit references this bug: Author: allanjude Date: Fri Apr 8 01:27:40 UTC 2016 New revision: 297692 URL: https://svnweb.freebsd.org/changeset/base/297692 Log: GELIBoot should only prompt for the GELI passphrase if the provider has the G_ELI_FLAG_GELIBOOT set PR: 208251 Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D5870 Changes: head/sys/boot/geli/geliboot.c
The situation with the redundant passphrase inputs with my partition / geli is now fixed for me after these last patches. I am only prompted once for passphrase, as expected. Thank you.
Fixed in 297692 .
Are encrypted partitions on slices properly detected now if the G_ELI_FLAG_GELIBOOT flag is set? My impression is that they aren't, while the geli.8 change from r297692 seems to imply that partitions are supported in general.
(In reply to Fabian Keil from comment #14) The flag is only meant for use by configurations that specifically support the 'geliboot protocol', which currently has a number of restrictions. An upcoming patch to bsdinstall will have the ability to create a supported configuration. geliboot itself does not support MBR partitions at all, only GPT, because an MBR partition cannot contain the geliboot support code.