Unlike loader (on UFS) that follows symlinks zfsloader chokes on them. How-To-Repeat: $ cd /boot $ mv kernel foo $ ln -s foo kernel $ qemu-system-x86_64 -nographic ... Consoles: serial port BIOS drive C: is disk0 BIOS 637kB/523252kB available memory FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 (root@build-amd64-fbsd.allbsd.org, Thu Jul 21 04:11:07 UTC 2011) Loading /boot/defaults/loader.conf ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable ZFS: i/o error - all block copies unavailable Unable to load a kernel! | can't load 'kernel'
I'm also experiencing this problem. However my understanding of the zfs code ended when I couldn't find documentation on ZFS system attributes (other than the comment in /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c). The problem seems (to my limited understanding) that symlinks are now stored in system attributes blocks instead of the physical znode. However the code in /sys/boot/zfs/zfsimpl.c uses some magical constants from /sys/cddl/boot/zfs/zfsimpl.h to determine e.g. the file type in zfs_dnode_stat(). However when zfs_lookup() hits a symlink, it doesn't check for the SA block. Instead it finds that the link target can't be in dn_bonus (even clang notices) and tries to read file contents for it. Of course there aren't any, which results in the error message. Now id anybody could point out how to get the link data offset in the SA block, I'd prepare a patch. The zfs_sa_readlink() function in /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_sa.c did not help :(
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
This should be fixed now.