https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296130
--- Comment #4 from [email protected] --- My primary intention with this report was to ensure this behavioral change gets mentioned in the errata so administrators upgrading from 14.x aren't caught off guard by broken boot sequences. However, looking at this from a UX perspective, that is a great question. Reading D36081, the consensus was clearly to make the console prompt explicit. Unfortunately, for headless servers and automated workflows, this breaks the principle of least surprise. A global rc.conf toggle like zfskeys_prompt="NO" makes perfect sense as a way to opt-in or opt-out of the default behavior. Taking the UX discussion a step further, I think a clean and robust approach would be to handle this via a ZFS user property. Something like this: zfs set org.freebsd:zfskeys=skip backuppool In my specific use case (a zero-knowledge backup pool receiving raw streams via zfs send -w), the receiving datasets naturally inherit keylocation=prompt. These datasets are never meant to be mounted or unlocked on this machine. Prompting for a key here is functionally useless and breaks unattended reboots. A global toggle in rc.conf is a good failsafe, but a user property would allow administrators to granularly skip datasets that shouldn't block the boot sequence, while still allowing the system to prompt for local encrypted pools that do need unlocking at the console. I'm not sure, however, how this fits into the bigger picture and if similar approaches are implemented elsewhere. -- You are receiving this mail because: You are the assignee for the bug.
