ZFS Is there a way to tell gptzfsboot to skip probing *other* HDDs?

[p.r.]

I have a problem (tried both freeNAS [11.2-U4 though 11.3-RC2] and freeBSD 12.1): When booting, I get gptzfsboot: error 128 lba some_block_number errors in the phase when gptzfsboot is probing my data HDDs (on which there is no bootloader, nor system, the drives can be even empty, with or without a partition table). The system boots eventually but the boot takes cca N x 7 minutes, where N is the number of data disks gptzfsboot is trying to analyze (there are several gptzfsboot: error 128 lba some_block_number lines per disk and each takes some time to appear).

Is there a way to tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? (My system is on PATA disk(s) while the data disks are SATA, hence there is no use to probe the SATA disks to search for a bootable system).

According to gptzfsboot manpage:
"gptzfsboot looks for ZFS device labels on all visible disks and in discovered supported partitions for all supported partition scheme types. The search starts with the disk from which gptzfsboot itself was loaded. Other disks are probed in BIOS defined order. After a disk is probed and gptzfsboot determines that the whole disk is not a ZFS pool member, the individual partitions are probed in their partition table order. Currently GPT and MBR partition schemes are supported. With the GPT scheme, only partitions of type freebsd-zfs are probed. The first pool seen during probing is used as a default boot pool.
The filesystem specified by the bootfs property of the pool is used as a default boot filesystem. If the bootfs property is not set, then the root filesystem of the pool is used as the default".

Note: installer CD boots the system just fine. Also, once my systen has booted (takes ~30 minutes with multiple gptzfsboot: error 128 lba some_block_number for each disk) the system works just fine, including the very same data disks that "produce" the errors. I am including a photo of the boot process screen when single system HDD and a single data HDD are present.

Anyway, should this be reported as a bug?

Any help is greatly appreciated.

P.S.: When putting the drives in another PC, the behavior is the same, only gptzfsboot: error 128 lba some_block_number becomes gptzfsboot: error 32 [if I remember the number correctly] lba some_block_number.
P.P.S.: This bug could be related to https://forums.freebsd.org/threads/gptzfsboot-error-128-after-adding-new-disks.65677/ but the solution provided there makes no difference in my case.

 

[eshwayri]

I have the same exact problem with FreeNAS11.2U7, and it scales up with the number of disks. I have 14, and it took me 45 minutes to jut get past the gptzfsboot phase. I shudder to think how long it would take my 22 drive system if I upgraded it. I haven't added any disks since this system was installed in March 2016 (FreeNAS 9.3). I have had to replace a couple of failed disks, but none in the past year. I have also not updated the BIOS on the system or any other component in the last year. Since gptzfsboot comes before the ZFS boot environments, rolling back to any prior release environment isn't going to help at all. Something about gptzfsboot's operation has changed, but I have no idea where to start looking. It is unacceptable for an OS to take an hour to boot, and copying the TB of data off to re-install everything is a ridiculous fix. Can someone please explain why this is happening, and how it can be fixed or worked around. Attached are screenshots of some of the endless 128 lba errors, followed by its triumphant list of all 14 drives -- 45 minutes later. It assigned them drive letters C through P, but I am not running DOS, so what it's doing is beyond me.