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

[Peter Rapčan]

Thanks for your reply!

I believe it is some kind of bug (maybe related to 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).

The funny thing is that the same system with the same type of disks worked before (with 3 data HDDS and freeNAS [11.2-Ux]) there were no gptzfsboot errors and the boot time was fast. After I added a 4th data drive and upgraded the system (freeNAS) to new version, only then I started getting the "gptzfsboot: error 128 lba some_block_number” errors. However I was not able revert to the state without the errors, altough I tried the original version of freeNAS, with 3, 2, or 1 data HDD(s), I tried wiping the HDDS, removing the partition table, creating a new one, etc…. I even tried installing freeBSD instead of freeNAS :-).

I am new to freeBSD… could you perhaps give me some advice how to troubleshoot this error?

Best,
Peter


> On 30 Jan 2020, at 15:49, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
> On Thu, Jan 30, 2020 at 7:42 AM Peter Rapčan <peter.rapcan at savba.sk <mailto:peter.rapcan at savba.sk>> 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).
> 
> Short of hacking the code, there's really no way to do this. It's a feature that it finds all the disks in the pool so we can boot off zraid.
>  
> 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?
> 
> You should report this as a feature request. It's not a bug, per se, because we need to look for multiple drives in many cases. If you want it to only look at the one disk that the boot loader was loaded from, that would be your ask.
> 
> The other ask is to be more tolerant of this situation. A 7 minute lag to probe a single drive is 7 minutes too long... That's clearly some kind of bug, but without poking at your system in more detail, it's hard to know for sure.
> 
> Warner
>  
> Any help is greatly appreciated.
> 
> 
> Cheers, --Peter
> 
> 
> 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.
> _______________________________________________
> freebsd-hackers at freebsd.org <mailto:freebsd-hackers at freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org <mailto:freebsd-hackers-unsubscribe at freebsd.org>"