TomAoki<p><span class="h-card" translate="no"><a href="https://bsd.network/@dvl" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>dvl</span></a></span> <span class="h-card" translate="no"><a href="https://bsd.network/@dch" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>dch</span></a></span> <br>Not 100% sure about loader.efi, but at least boot1.efi would be affected if any read-incompatible feature(s) is/are enabled and active even on data-only pools.<br>This is because, in boot1.efi, it sniffs the existence of /boot/loader.efi to determine whether the pool is bootable or not.<br>loader.efi should need to sniff at least pool name(s), whether it's bootable or not by somehow reading the pool(s).</p><p>If you're 100% sure there's not at all a plan to have bootable ZFS (means, use UFS for boot throughout the future), and once confirmed it works as wanted, using gptboot.efi would be the way to go.<br>It does not sniff ZFS pools (not linked against ZFS codes) and (in contrast with boot1.efi) not obsoleted.</p><p><a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a> <a href="https://mastodon.bsd.cafe/tags/loader" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>loader</span></a> <a href="https://mastodon.bsd.cafe/tags/bootcode" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>bootcode</span></a> <a href="https://mastodon.bsd.cafe/tags/ZFS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ZFS</span></a> <a href="https://mastodon.bsd.cafe/tags/UFS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>UFS</span></a></p>