Bug 235380 - gptzfsboot does not boot ZFS pool made from whole disks (regression)
Summary: gptzfsboot does not boot ZFS pool made from whole disks (regression)
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Toomas Soome
URL:
Keywords: patch, regression
Depends on:
Blocks:
 
Reported: 2019-02-01 13:44 UTC by reto.haeuptli
Modified: 2020-06-24 20:18 UTC (History)
4 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 13:44:06 UTC
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 release 12 this feature is broken. 

I found the reason in the source code: In the file /head/stand/i386/libi386/biosdisk.c a regression was introduced in the revisions base r37271, base r337317. Its about detecting the correct number of sectors/blocks for a block device. The change was introduced because a certain device (Mediasonic HD3-U2B PATA to USB enclosure) was not working. I tested various SASTA disks, even a 10TB disk, and USB Sticks, all detecting the wrong number of sectors instead. Reverting the change leaded to the correct detection of the number of sectors and therefore I was able to boot again. I tested also revision base r342785 of the file /head/stand/i386/libi386/biosdisk.c: The detection of the number of sectors is implemented the right way again and has improved of course.

I propose the following patch to fix the regression for FreeBSD 12

Index: stand/i386/libi386/biosdisk.c
===================================================================
--- stand/i386/libi386/biosdisk.c	(revision 343578)
+++ stand/i386/libi386/biosdisk.c	(working copy)
@@ -270,8 +270,8 @@
 
 		total = (uint64_t)params.cylinders *
 		    params.heads * params.sectors_per_track;
-		if (total > 0 && bd->bd_sectors > total)
-			bd->bd_sectors = total;
+                if (bd->bd_sectors < total)
+                        bd->bd_sectors = total;
 
 		ret = 1;
 	}
Comment 1 Ed Maste freebsd_committer freebsd_triage 2019-05-21 18:59:31 UTC
Already fixed (with a different patch) by r339321
https://reviews.freebsd.org/rS339321
Comment 2 Ed Maste freebsd_committer freebsd_triage 2019-05-21 19:01:26 UTC
Sorry closed wrong bug by accident, r339321 is not related.
Comment 3 Toomas Soome freebsd_committer freebsd_triage 2019-05-21 19:19:21 UTC
hi!

The problem there was that the device had actual size smaller than calculated and when there was an attempt to access the disk, the system did hung.

Anyhow, in your case, how the failure is manifesting? I mean, if you do have GPT on disk, the code should read the disk size from GPT and ignore the value from INT13 (see bd_disk_get_sectors() in biosdisk.c).
Comment 4 Allan Jude freebsd_committer freebsd_triage 2020-06-24 20:18:10 UTC
Is this resolved now?