2025-05.

After upgrading from FreeBSD 13.x to 14.2, one of four encrypted partitions just wouldn't open. 
It seemed I must have tried the right password (among many efforts and careful repeats), but: 

# geli attach /dev/nvd0p6 
Enter passphrase: 
geli: Provider not found: "/dev/nvd0p6"
geli: There was an error with at least one provider.

The partition was seen to have a geli format:

# geli version /dev/nvd0p6
/dev/nvd0p6: 7

And it (apparently) worked to restore from the metadata backup:

# geli restore -v /var/backups/nvd0p6.eli /dev/nvd0p6 
Done.

But still the same problem as above:  provider not found.


We note by comparison with a working geli-encrypted partition, when we 
give the wrong password, that the message is different: it's not just that 
we've forgotten the passphrase for the above partition. 
# geli attach /dev/ada0p1
Enter passphrase: 
geli: Wrong key for ada0p1 
geli: There was an error with at least one provider.


Finally, clues were found here:

https://muc.lists.freebsd.fs.narkive.com/yhxuWtXg/nvd-nda-change-breaks-geli
https://forums.freebsd.org/threads/after-geli-restore-metadata-cant-fsck-or-mount.57747/#post-330387


It seems the nvd* names are old, and are just compatibility symlinks to nda* names. 

# ll /dev/nda* /dev/nvd*
crw-r-----  1 root operator 0x6e 17 Apr 19:57 /dev/nda0
crw-r-----  1 root operator 0x70 17 Apr 19:57 /dev/nda0p1
crw-r-----  1 root operator 0x72 17 Apr 19:57 /dev/nda0p2
crw-r-----  1 root operator 0x74 17 Apr 19:57 /dev/nda0p3
crw-r-----  1 root operator 0x76 17 Apr 19:57 /dev/nda0p4
crw-r-----  1 root operator 0x78 17 Apr 19:57 /dev/nda0p5
crw-r-----  1 root operator 0x7a 17 May 14:37 /dev/nda0p6
lrwxr-xr-x  1 root wheel       4 17 Apr 19:57 /dev/nvd0 -> nda0
lrwxr-xr-x  1 root wheel       6 17 Apr 19:57 /dev/nvd0p1 -> nda0p1
lrwxr-xr-x  1 root wheel       6 17 Apr 19:57 /dev/nvd0p2 -> nda0p2
lrwxr-xr-x  1 root wheel       6 17 Apr 19:57 /dev/nvd0p3 -> nda0p3
lrwxr-xr-x  1 root wheel       6 17 Apr 19:57 /dev/nvd0p4 -> nda0p4
lrwxr-xr-x  1 root wheel       6 17 Apr 19:57 /dev/nvd0p5 -> nda0p5
lrwxr-xr-x  1 root wheel       6 17 Apr 19:57 /dev/nvd0p6 -> nda0p6

If using the new names, that are character devices rather than symlinks, it works!
# geli attach /dev/nvd0p6

Strange .. it accepted the link for the version-check and restore, but not for opening. 
Well made to confuse! 

Addition in  /boot/loader.conf of:
kern.cam.nda.nvd_compat=0
should stop the confusing symlinks from existing. 



The other three of four encrypted partitions were on plain SSD disks rather than NVME, 
which is why they didn't have the problem.