How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)?

[Peter Rapčan]

Dear Andryi,

Thank you for your input. However:

- when putting the harddrives in a different PC, the gptzfsboot: error 128 lba some_block_number changed into gptzfsboot: error 32 [if I remeber the number correctly] lba some_block_number
- the same disk(s) worked in the same system without errors previously (prior version of freeNAS with less disks of the same type) - I have not been able to revert to the errorless configuration though (I think I tried all versions of freeNAS I think I could have used and seen working, with the original number of the harddrives).

So I am reluctant believing the disk timeout would be the cause… Although the disks are kind of large [HGST HUH721212ALN600, 12TB] and the system is rather old (IBM x3200), and yes, the disk gave a problem ty my oldish MacPRO (macOS could see the disk only on fresh start but not on restart).... nevertheless I have specifically checked the disks worked OK in the IBM machine before ordering (more of) them and they did (initially).

There is no power-up-in-standby option/toggle in the BIOS :-(

Best, 
Peter

> On 30 Jan 2020, at 18:14, Andriy Gapon <avg at FreeBSD.org> wrote:
> 
> On 30/01/2020 16:42, Peter Rapčan wrote:
>> Hi,
>> 
>> 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).
>> 
>> I am asking this to get around the following problem (bug?) I encountered
>> (tried both freeBSD 12.1 and freeNAS [11.2-U4 though 11.3-RC2]): 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).
>> 
>> Note: installer CD boots the installer system just fine. Also, once the
>> system is installed, and the system has booted from HDD (this 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.
>> 
>> Anyway, should this be reported as a bug?
>> 
>> Any help is greatly appreciated.
> 
> 
> FWIW, error 128 is likely "Disk timeout (failed to respond)" according to this
> resource: http://www.bioscentral.com/misc/biosint13.htm <http://www.bioscentral.com/misc/biosint13.htm>
> That may explain why the boot takes so long.
> Could it be that something like power-up-in-standby is configured for SATA disks?
> It's possible that disks are detectable and thus reported by BIOS, but they are
> not spinning and timing out on reads.
> Later, FreeBSD kernel knows to send a special command to spin them up.
> This is just a speculation on my part.
> 
> 
> -- 
> Andriy Gapon