https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247482
Bug ID: 247482
Summary: loader: geli-encryption zfs boot environments
[regression]
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: b...@freebsd.org
Reporter: cont...@evilham.com
Hello,
I just had some time to track this down. The loader has been wrong on CURRENT
with my setup for a couple days, particularly since this was merged:
https://reviews.freebsd.org/D25324
(If I revert the mentioned diff, HEAD's loader works just fine)
Judging by the messages I see when booting, the boot loader tries the disk
partitions one by one as expected, finds the one with the OS and tries the
active Boot Environment.
And then it bails out in this bit of code from vdev_clear_pad2(vdev_t *vdev):
+ if (vdev_write(vdev, vdev->v_read_priv, off, be, VDEV_PAD_SIZE)) {
+ printf("failed to clear be area of primary vdev: %d\n",
+ errno);
+ }
The errno given for the right boot environment is 45, which appears to be
EOPNOTSUPP.
This is the message I'm seeing (modulo typos, transcript):
Setting currdev to zfs:zroot/ROOT/13-current:
failed to clear be area of primary vdev: 45
zfs nextboot: zfs:zroot/ROOT/12-release:
ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
The setup is pretty simple, full disk geli-encrypted system created from the
installer with zfs on root with Boot Environments.
I'd try to fix this but ATM I don't feel too comfortable touching things that
appear to write to the disk :-D; can I help provide more information to fix
this?
Thank you,
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
