Bug 221275

Summary: Unable to use zfsbootcfg
Product: Base System Reporter: Shane <FreeBSD>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me CC: allanjude, fk, vsasjason
Priority: ---    
Version: 11.1-STABLE   
Hardware: Any   
OS: Any   

Description Shane 2017-08-06 09:34:49 UTC 
zfsbootcfg fails to work for me, which appears to be from the lack of sysctl values vfs.zfs.boot.primary_pool and vfs.zfs.boot.primary_vdev -

# zfsbootcfg "zfs:zrpleader:"
can't get vfs.zfs.boot.primary_pool: No such file or directory
# sysctl vfs.zfs.boot.primary_pool
sysctl: unknown oid 'vfs.zfs.boot.primary_pool'
# sysctl vfs.zfs.boot.primary_vdev
sysctl: unknown oid 'vfs.zfs.boot.primary_vdev'

FreeBSD leader.local 11.1-STABLE FreeBSD 11.1-STABLE #3 r321620: Wed Aug  2 14:55:49 ACST 2017     root@leader.local:/usr/obj/usr/src/sys/GENERIC  amd64

I am seeing the same issue with a bhyve instance running 12-current -

FreeBSD pkgbuilder.local 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r321405M: Tue Jul 25 06:34:22 ACST 2017     shane@pkgbuilder.local:/usr/obj/usr/src/sys/GENERIC  amd64
Comment 1 Fabian Keil 2017-08-08 11:35:05 UTC 
zfsbootcfg actually checks for kenv(1) variables (which sysctl(8) doesn't show).

Having said that, I can reproduce the problem that the variables aren't
set when running in bhyve.

They are set on all the physical systems I checked, though.

You can still set them manually with kenv(1) using the values from the
vdev label:

[fk@test-vm ~]sudo zdb -l /dev/gpt/bpool-vtbd1
[...]
    name: 'bpool'                                                                                                                                                                                                              
[...]
    pool_guid: 14860026282992656750                                                                                                                                                                                            
[...]
    guid: 6160965258301852628                                                                                                                                                                                                  
[...]
[fk@test-vm ~]sudo kenv vfs.zfs.boot.primary_pool=14860026282992656750
vfs.zfs.boot.primary_pool="14860026282992656750"
[fk@test-vm ~]sudo kenv vfs.zfs.boot.primary_vdev=6160965258301852628
vfs.zfs.boot.primary_vdev="6160965258301852628"

At least for me this resulted in zfsbootcfg reporting success:

[fk@test-vm ~]$ sudo zfsbootcfg zfs:rpool
zfs next boot options are successfully written

As I currently don't use boot environments (not yet supported by cloudiatr),
I couldn't easily test if this has any effect in bhyve, though.
Comment 2 Allan Jude freebsd_committer freebsd_triage 2021-04-05 15:34:42 UTC 
zfsbootcfg was written last year, and 13.0 and later include the new functionality, which does work with EFI, and fixes this issue.

https://cgit.freebsd.org/src/commit/?id=e307eb94ae520d98dc1d346a0c53667a41beab5d