From owner-freebsd-hackers@freebsd.org Sat Feb 1 18:46:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 98E071FF836 for ; Sat, 1 Feb 2020 18:46:17 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from smtp.savba.sk (smtp.savba.sk [147.213.1.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48932c5Qsbz3PCt; Sat, 1 Feb 2020 18:46:16 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from [192.168.1.132] (188-167-170-187.static.chello.sk [188.167.170.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fyziprap) by smtp.savba.sk (Postfix) with ESMTPSA id 1DF7155890; Sat, 1 Feb 2020 19:46:15 +0100 (CET) From: =?utf-8?Q?Peter_Rap=C4=8Dan?= Message-Id: <531110E5-7C45-46ED-8881-728204CFFA17@savba.sk> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? Date: Sat, 1 Feb 2020 19:46:14 +0100 In-Reply-To: <035de243-caf1-f812-23d2-6efed8e5ee15@FreeBSD.org> Cc: freebsd-hackers@freebsd.org To: Andriy Gapon References: <035de243-caf1-f812-23d2-6efed8e5ee15@FreeBSD.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 48932c5Qsbz3PCt X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.rapcan@savba.sk designates 147.213.1.2 as permitted sender) smtp.mailfrom=peter.rapcan@savba.sk X-Spamd-Result: default: False [4.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:147.213.1.0/27:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[savba.sk]; NEURAL_SPAM_MEDIUM(0.98)[0.975,0]; SUBJECT_ENDS_QUESTION(1.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[0.998,0]; IP_SCORE(1.64)[ipnet: 147.213.0.0/16(4.18), asn: 2607(3.93), country: SK(0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:2607, ipnet:147.213.0.0/16, country:SK]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 18:46:17 -0000 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=E2=80=A6 = 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,=20 Peter > On 30 Jan 2020, at 18:14, Andriy Gapon wrote: >=20 > On 30/01/2020 16:42, Peter Rap=C4=8Dan wrote: >> Hi, >>=20 >> 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). >>=20 >> 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). >>=20 >> 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. >>=20 >> Anyway, should this be reported as a bug? >>=20 >> Any help is greatly appreciated. >=20 >=20 > 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. >=20 >=20 > --=20 > Andriy Gapon