Solved bsdinstall disables GPT identification for guided ZFS install

[memreflect]

When you install FreeBSD using the Auto ZFS option, GPT labels and GPT UUIDs are disabled in loader.conf(5):

kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"

The only reference to labels being disabled that I could find is from a 5-year-old PC-BSD bug report complaining that PC-BSD doesn't install properly on a multiboot machine, which makes sense if the installer doesn't feature a partition editor to customize which partition onto which you install FreeBSD. However, I have yet to find a reason for GPT UUIDs also being disabled as neither the commit message nor the comments above it indicate a problem with leaving them enabled.

As ZFS uses GUIDs already, it isn't a big deal that these are disabled until you shuffle disks around, and suddenly a UFS filesystem won't mount because it has been assigned a different geom identifier (e.g. ada7p2 becomes ada3p2). But if you're not on a multiboot system, then it should be safe to re-enable both of these settings, right? Or is there some other reason they're still disabled by default?

 

[memreflect]

So as it turns out, the GPT stuff isn't displayed.

With geom_label_enable="YES" in /boot/loader.conf, the /dev/gpt and /dev/gptid directories are populated, but the only things in there are the EFI System Partitions and freebsd-boot partitions in my mirrored BIOS+UEFI setup:

ROOT ~# ls /dev/gpt
efiboot0 efiboot1 gptboot0 gptboot1

My guess is that when the root ZFS system is found and booted, it seems like it takes over the GEOM providers required, essentially rendering GPT labels on ZFS partitions almost useless. I say "almost" because once a GEOM device provider is not in use, such as when you execute something like zpool detach zroot ada1p4, you can see the GEOM label provider (assuming geom_label.ko is loaded and one or both of the tunables mentioned in the original post is nonzero), which means you can add it to the pool by GPT label/ID instead of by the GEOM device provider name:

ROOT ~# zpool detach zroot ada1p4
ROOT ~# ls /dev/gpt
efiboot0 efiboot1 gptboot0 gptboot1 zfs1
ROOT ~# zpool attach zroot ada0p4 gpt/zfs1    # or gptid/`gpart list ada1 | sed -n '/ada1p4/,/rawuuid/p' | awk '/rawuuid/{print $2}'`

After that, zpool status should display your newly added vdev instead of the GEOM name. Detaching and reattaching the vdev unfortunately requires a resilver, but it could be worth it in some cases. I feel it is also worth mentioning to ZFS newbies like myself that if you want to do this for all of the vdevs in the pool, you'll want to detach and reattach them in their original order, else you'll see things like gpt/zfs1 before gpt/zfs0 when you use zpool status. This may not matter to you, but I just prefer things to be in order.

 

[Cath O'Deray]

Thanks,

… GPT UUIDs also being disabled as neither the commit message nor the comments above …

Corresponding lines in GitHub:

<https://github.com/freebsd/freebsd-...r.sbin/bsdinstall/scripts/zfsboot#L1260-L1261>
<https://github.com/freebsd/freebsd-...r.sbin/bsdinstall/scripts/zfsboot#L1271-L1273>

A cgit view of SVN revision 266107 r266107 (2014-05-15): <https://cgit.freebsd.org/src/commit/?id=2875e59f52f95d59ab7bf94ea67a98292f4f7775>

---

From a 2017 discussion, two posts by David Christensen:

<https://lists.freebsd.org/pipermail/freebsd-questions/2017-June/277651.html>

…

[1] pp. 30-35 and [3] pp. 4-8 discuss various choices for labels, and recommend meaningful GPT label strings set manually by the administrator. For example, [3] p. 6:

# gpart add -t freebsd-zfs -l zfs-mirror-1 da2

If you've used GPT partitioning on the drives in your zpool, it might be possible to add GPT labels now. For example, [3] p. 6:

# gpart modify -i 2 -l f01-serialnum da2

Both [1] and [3] discuss the fact that a given drive, partition, file system, etc., can be identified in various ways, manual or automatic, but the kernel will pick one and "wither" the rest. Once a GPT label is set manually, other methods should be disabled via settings in /boot/loader.conf and the system rebooted ([1] p. 35):

kern.geom.label.disk_ident.enable="0" kern.geom.label.gptid.enable="0"

I'd suggest experimenting with USB flash drives on another machine.

David

[1] Michael W. Lucas, 2014, "FreeBSD Mastery: Storage Essentials", <https://www.michaelwlucas.com/os/fmse>

[2] Michael W. Lucas & Allan Jude, 2015, "FreeBSD Mastery: ZFS", <https://www.michaelwlucas.com/os/fmzfs>

[3] Allan Jude & Michael W. Lucas, 2015, "FreeBSD Mastery: Advanced ZFS", <https://www.michaelwlucas.com/os/fmaz>

<https://lists.freebsd.org/pipermail/freebsd-questions/2017-June/277653.html>

…

Beware that all your disks need to have GPT labels, and those labels need to be carried forward into /etc/fstab, etc., before you reboot, as the kernel won't be able to find the disks using Disk ID or GPT GUID labels once those methods are disabled.

As far as I know: with FreeBSD 13.0-RELEASE and greater, fstab(5) is no longer strictly required (for ZFS). It may be used in edge cases.

---

… a 5-year-old PC-BSD bug report …

Unfortunately, not in archive.today or the Wayback Machine. Fortunately, we no longer need it :-)