13-stable, later adding geli disk with the same passphrase as

2021-12-13 Thread Holm Tiffe 
bootdisk
Reply-To: 

Hi all,
I hope here is still someone listening..

I have a new installed FreeBSD 13-stable machine with an
zfs raidz1 over fours sas disks configured at installtime
with geli.
Now I want to add 2 additional SATA disks as raid0 for data storage in
striped configuration, encrypted with geli also.

$ gpart show ada0
=>40  1953525088  ada0  GPT  (932G)
  40  1952448512 1  freebsd-zfs  (931G)
  1952448552 1076576- free -  (526M)

ada1 is the same, geli devices configured as stripe
 zpool status
  pool: zrdata
 state: ONLINE
config:

NAME  STATE READ WRITE CKSUM
zrdataONLINE   0 0 0
  ada0p1.eli  ONLINE   0 0 0
  ada1p1.eli  ONLINE   0 0 0

So far so good.

But how can I manage that I doesn't get asked a 2nd time for the geli
passphrase for the 2nd disks? How can I use the same credentials that
are used for the primary disk pool?
I know that is the case if I init all the geli disks at the same time,
but this isn't possible because I'm loosing all my data at this moment.
The data have to live somewhere at transition time from one computer to
the another and I want to reuse the SATA disks.
I've tried to add -bg to geli configure, this makes no difference,
besides of the fact that there is no bootable partition on those 2
disks.

Can someone pls. help here?

Regards,

Holm

-- 
   Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
 Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583
i...@tsht.de Fax +49 37292 709779 Tel +49 37292 709778 Mobil: 0172 8790 741

12.3:[ZFS pointer corruption] kernel crash exporting FreeBSD src repo

2021-12-13 Thread Peter 


Hija,

  I have a filesystem with the FreeBSD src repo clone.
 
When I do 
>  git checkout-index -a --prefix=/new-filesystem/
in 5 of 6 cases I get a kernel crash.

The repo otherwise looks sane:

# git status
On branch local.generic
Your branch is ahead of 'origin/releng/12.3' by 51 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
# git branch -v -v
* local.generic f99bc919533 [origin/releng/12.3: ahead 51] em/igb 
capabilities fix für 12.3
  local.generic.releng/11.4 95388afb572 [origin/releng/11.4: ahead 12] 
KERNCONF, make conf, sendmail mc
  local.generic.releng/12.2 63c868925fc [origin/releng/12.2: ahead 45] 
Kernelconfigs aktualisiert
  main  01bad87a76d [origin/main: behind 12250] UPDATING: 
add an entry for commit 875977314881


The filesystem is also responsive and in working order.
ZFS scrub does not see anything to complain.
No other error messages anywhere.
zdb runs through it and finds no error.

Everything else on the system (and there is a lot) appears to work
just fine.

In 2 of 5 cases a kernel dump is written, which is quite exactly the
same every time (in another case the name was not "HEAD", but
".arcconfig", another time "sys").


Fatal trap 12: page fault while in kernel mode
cpuid = 19; apic id = 19
fault virtual address   = 0x410
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808e9815
stack pointer   = 0x28:0xfe00e667bf50
frame pointer   = 0x28:0xfe00e667bff0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 18330 (git)
trap number = 12

#8  0x808e9815 in _sx_xlock_hard ()
#9  0x8039e35b in __dbuf_hold_impl ()
#10 0x8039e44f in dbuf_hold ()
#11 0x803bc152 in dnode_hold_impl ()
#12 0x803a597d in dmu_bonus_hold ()
#13 0x80468b16 in zfs_zget ()
#14 0x80443ccf in zfs_dirent_lookup ()
#15 0x80443d9b in zfs_dirlook ()
#16 0x8045ddb0 in zfs_lookup ()
#17 0x8045e569 in zfs_freebsd_cachedlookup ()
#18 0x80d5ac5c in VOP_CACHEDLOOKUP_APV ()
#19 0x8099e27c in vfs_cache_lookup ()
#20 0x80d5ab2c in VOP_LOOKUP_APV ()
#21 0x80835ba5 in null_lookup ()
#22 0x80d5ab2c in VOP_LOOKUP_APV ()
#23 0x809a7cc1 in lookup ()
#24 0x809a716f in namei ()
#25 0x809bff32 in kern_statat ()
#26 0x809c06cf in sys_fstatat ()
#27 0x80cd38b0 in amd64_syscall ()
#28 0x80caba8e in fast_syscall_common ()
--
#8  0x808e9815 in _sx_xlock_hard (sx=0xfe00ab1680a0, 
x=, opts=)
at /usr/src/sys/kern/kern_sx.c:682
#9  0x8039e35b in __dbuf_hold_impl (dh=0xf80018449000)
at src/sys/sys/sx.h:168
#10 0x8039e44f in dbuf_hold (dn=0xf800183918a0, blkid=5302, 
tag=0x80d7ef0b)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:3016
#11 0x803bc152 in dnode_hold_impl (os=0xf8001815e400, 
object=169684, flag=1, slots=0, dnp=0xfe00e667c150)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c:1329
#12 0x803a597d in dmu_bonus_hold (os=, 
object=, tag=, 
dbp=0xfe00e667c1e8)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:345
#13 0x80468b16 in zfs_zget (zfsvfs=0xfe00ba7fe000, obj_num=169684, 
zpp=0xfe00e667c298)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1165
#14 0x80443ccf in zfs_dirent_lookup (dzp=0xf80704c676c0, 
name=0xfe00e667c3c0 "HEAD", zpp=, flag=2)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:187
#15 0x80443d9b in zfs_dirlook (dzp=0xf80704c676c0, 
name=, zpp=0xfe00e667c338)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:238
#16 0x8045ddb0 in zfs_lookup (dvp=, 
nm=0xfe00e667c3c0 "HEAD", vpp=, 
cnp=, nameiop=0, cr=, flags=0, 
cached=1)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1671
#17 0x8045e569 in zfs_freebsd_cachedlookup (ap=0xfe00e667c520)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4973
#18 0x80d5ac5c in VOP_CACHEDLOOKUP_APV (vop=0x81067150, 
a=0xfe00e667c520) at src/sys/sys/signalvar.h:352
#19 0x8099e27c in vfs_cache_lookup (ap=)
at vnode_if.h:80
#20 0x80d5ab2c in VOP_LOOKUP_APV (vop=0x81067150, 
a=0xfe00e667c5a8) at src/sys/sys/signalvar.h:352
#21 0x80835ba5 in null_lookup (ap=0xfe00e667c690) at vnode_if.h:54
#22 0x80d5ab2c in VOP_LOOKUP_APV (vop=0x810a2cc0, 
a=0xfe00e667c690) at src/sys/sys/si