This bug report is related to bug #235380 and #220105, this is intentional and no duplicate. I used to boot zfs on whole disk(s) from a USB stick with a GPT partition scheme and gptzfsboot on it since FreeBSD version 9 on many testing machines and even production servers without any problems. With the current code base this feature is broken. I found the reason in the source code: In the file /head/stand/libsa/zfs/zfs.c the feature was disabled in the revisions base r342151 and base r342161. In r342151 disabled to ability to boot zfs from wholes disks. In r342161 is was refined for the UEFI case. I completely disagree with the reasoning in the commit comment of base r342151 and the comment in the source code. As I said in the introduction to this ticket I use and rely on this feature since many years. Furthermore I do not know many systems able to boot zfs from whole disks. FreeBSD is/was one of them. I think we should not give away this precious feature. I propose the following: - Revert base r342151 and base r342161 - Discuss whether the FreeBSD community should give away the feature of booting zfs from whole disks.
(In reply to reto.haeuptli from comment #0) In case you did not notice, the chain of events leading the patch to disable the boot from partitionless disk was about someone facing hung system. So, your proposal is that we should just step on those users and prefer partitionless boot (the "precious feature" which will be quite unusable when vendors are stopping to provide CSM - which is the reason why we are trying so hard to improve UEFI support). What we can do, we can provide an option to enable partitionless boot at build time, but it can not be default, unfortunately. Unfortunately, this also leads us to position where we need to choose between "fancy" feature and reliable boot.
So now I know why I recently spent four hours trying to fix an unbootable system (whole disk root zpool, much easier and cleaner to swap out hard disks for larger ones) after an ostensibly successful make installworld. Many things were tried. Finally grabbed the /boot directory from an 11-STABLE snapshot. While the 'UEFI in, CSM out' issue is understandable, the fix should not affect existing setups post-RELEASE and in the middle of a release cycle.
(In reply to Toomas Soome from comment #1) It seems that I need to clarify some things first. 1.) gptzfsboot + zpool from partitions This use case is still in use and very important for many users, because lots of i385/amd64 computers do not have a UEFI Bios or have CSM activated. 2.) gptzfsboot + zpool from whole disks This is a very important use case for me and probably also for some other people. With base r342151 its no longer possible to boot such pools. This use case is so important for me, because I use it on servers and testing machines with many hard disk drives and ssds. Is very convenient that there is no need to partition a disk when I have to replace them. I have tried this on hundreds of installations almost without any problem. I never had a problem with detecting the proper capacity of the disks, even if they had 10TB. With the notable exception of FreeBSD 12. I have filed this under Bug 235380, but this is another story. 3.) uefiboot + zpool from partitions This use case is important for actual computers and of course in the future when there are no CSM is available any more. I personally use this on computers with just one or thwo disk/ssd. 4.) uefiboot + zpool from whole disks This is, as it seems, not implemented yet, because the FreeBSD UEFI loader does not support it. There is a ticket about this use case in the system, Bug 220105. In the next few weeks I will investigate what is needed to supports this. When I succeed I will prepare a patch set. Of course I see that r342151 fixed a problem of someones computer and I estimate it. I do not know the circumstances of this hang of course. If its related to base r37271 by coincidence please let me know. But I want to point out again that r342151 breaks the booting of ZFS from whole disks independent of the booting method and/or platform. In my opinion the booting method (gptzfsboot, uefiboot, etc) and how the zpool is consisted from (whole disks, partitions) should be implemented orthogonally. Having the ability to boot zpool from whole disks back as a compile option, as You proposed, would be good enough for me and I would highy apreciate it.
zfs信息好像在/boot/zfs/zpool.cache里，应该把/boot目录放到ESP里，除了kernel
(In reply to yu shan wei from comment #4) Bugmeister note: Google Translate offers the following: The zfs information seems to be in /boot/zfs/zpool.cache. The /boot directory should be placed in the ESP, except for the kernel.