Bug 235388 - gptzfsboot does not boot ZFS pool made from whole disks (regression), part two
Summary: gptzfsboot does not boot ZFS pool made from whole disks (regression), part two
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-02-01 14:35 UTC by reto.haeuptli
Modified: 2019-02-07 16:11 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description reto.haeuptli 2019-02-01 14:35:56 UTC
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.
Comment 1 Toomas Soome freebsd_committer 2019-02-02 18:08:52 UTC
(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.
Comment 2 raivo.hool 2019-02-04 12:46:27 UTC
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.
Comment 3 reto.haeuptli 2019-02-04 17:02:48 UTC
(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.