`zpool create -t` fails to emit `zpool history` entry for create command

[delan]

System information

Type	Version/Name
Distribution Name	NixOS
Distribution Version	25.11.20250830.d7600c7
Kernel Version	6.12.44
Architecture	x86_64
OpenZFS Version	zfs-2.3.4-1 zfs-kmod-2.3.4-1

Describe the problem you're observing

in #16408, the reporter’s pool did not have an entry for the zpool create command in zpool history, even though that was in theory a special case that should never get evicted from the history. zpool history -i entries for create pool version 5000 and set feature@... and so on were present as expected.

i ran into those exact symptoms today, just after creating a pool. zpool history was empty, with no entry for the zpool create command, but zpool history -i entries for create pool version 5000 and set feature@... and so on were present as expected.

Describe how to reproduce the problem

$ truncate -s 1G test.img

zpool create without -t works as expected:

$ zpool create test ./test.img
$ zpool history test
History for 'test':
2026-01-01.14:59:54 zpool create test ./test.img

zpool create with -t that does not rename the pool, also works as expected:

$ zpool destroy test
$ zpool create -t test test ./test.img
$ zpool history test
History for 'test':
2026-01-01.15:00:15 zpool create -t test test ./test.img

zpool create with -t that does rename the pool, fails to create the history entry:

$ zpool destroy test
$ zpool create -t test2 test ./test.img
$ zpool history test
cannot open 'test': no such pool
$ zpool history test2
History for 'test2':

zpool history -i still contains the internal entries as expected:

$ zpool history -i test2
2026-01-01.15:00:29 [txg:4] create pool version 5000; software version unknown; uts venus 6.12.44 #1-NixOS SMP PREEMPT_DYNAMIC Thu Aug 28 14:31:16 UTC 2025 x86_64
2026-01-01.15:00:29 [txg:4] set tname=test2
2026-01-01.15:00:29 [txg:4] set feature@async_destroy=enabled
[...]
2026-01-01.15:00:29 [txg:4] set feature@large_microzap=enabled

[delan]

zpool create -t (83e9986) and zpool import -t (26b42f3) are both designed to override the on-disk zpool property name with an in-core “temporary” name, but they work somewhat differently under the hood.

importing with a temporary name sets spa->spa_import_flags |= ZFS_IMPORT_TEMP_NAME in ZFS_IOC_POOL_IMPORT, which tells spa_write_cachefile() and spa_config_generate() to use the ZPOOL_CONFIG_POOL_NAME in spa->spa_config instead of spa->spa_name.

creating with a temporary name permanently(!) sets the internal zpool property tname (ZPOOL_PROP_TNAME) in the zc->zc_nvlist_src of ZFS_IOC_POOL_CREATE, which tells zfs_ioc_pool_create() (4ceb8dd) and spa_create() to use that name instead of zc->zc_name, then sets spa->spa_import_flags |= ZFS_IMPORT_TEMP_NAME like an import.

but zfsdev_ioctl_common() fails to check for tname when saving the pool name to zfs_allow_log_key, so when we call ZFS_IOC_LOG_HISTORY, we call spa_open() on the wrong pool name and get ENOENT, so the logging silently fails.

i’ll send a patch to fix this, but i think the design of tname feels weird. it only seems to exist to influence the pool creation logic between ZFS_IOC_POOL_CREATE and spa_add(), but it gets stored in the pool permanently, despite the comment that says Temporary pool names should never be written to disk.…