Date: Thu, 30 Jan 2020 19:14:58 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: =?UTF-8?Q?Peter_Rap=c4=8dan?= <peter.rapcan@savba.sk>, freebsd-hackers@freebsd.org Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? Message-ID: <035de243-caf1-f812-23d2-6efed8e5ee15@FreeBSD.org> In-Reply-To: <EC3F4FDB-7186-4F24-9EC9-771ED239510D@savba.sk> References: <EC3F4FDB-7186-4F24-9EC9-771ED239510D@savba.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?035de243-caf1-f812-23d2-6efed8e5ee15>