From owner-freebsd-hackers@freebsd.org Sat Feb 1 18:35:51 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 4C84E1FF4C8 for ; Sat, 1 Feb 2020 18:35:51 +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 4892pZ23HCz3NmP; Sat, 1 Feb 2020 18:35:49 +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 D35F955890; Sat, 1 Feb 2020 19:35:39 +0100 (CET) From: =?utf-8?Q?Peter_Rap=C4=8Dan?= Message-Id: <66180BBD-AB88-4DA0-9F0E-815578AA6925@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:35:38 +0100 In-Reply-To: <48f04506-b5bf-03b6-2ef8-9d8853961b07@freebsd.org> Cc: freebsd-hackers@freebsd.org To: Allan Jude References: <48f04506-b5bf-03b6-2ef8-9d8853961b07@freebsd.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 4892pZ23HCz3NmP 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 [5.86 / 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]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[savba.sk]; NEURAL_SPAM_MEDIUM(1.00)[0.997,0]; URI_COUNT_ODD(1.00)[3]; IP_SCORE(1.66)[ipnet: 147.213.0.0/16(4.28), asn: 2607(3.93), country: SK(0.09)]; MV_CASE(0.50)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; 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:35:51 -0000 Dear Allan,=20 Thanks for your reply. Assuming the said 512 is in bytes, the = 512*some_block_number are less then the size of the disk. The disk is a = 12TB one and the =E2=80=9Csome_block_numbers" shown are 32, 544, = 2929720352, 2929720864, 1.=20 Additional information: - 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). - 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=20 The whole situation seems mysterious to me, given the system was working = without the error messages previously... Best,=20 Peter > On 31 Jan 2020, at 18:39, Allan Jude wrote: >=20 > On 2020-01-30 10:09, Peter Rap=C4=8Dan wrote: >> Thanks for your reply! >>=20 >> I believe it is some kind of bug (maybe related to to = https://forums.freebsd.org/threads/gptzfsboot-error-128-after-adding-new-d= isks.65677/ but the solution provided there makes no difference in my = case). >>=20 >> 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=E2=80=9D = 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=E2=80=A6. I even tried installing freeBSD instead of = freeNAS :-). >>=20 >> I am new to freeBSD=E2=80=A6 could you perhaps give me some advice = how to troubleshoot this error? >>=20 >> Best, >> Peter >>=20 >>=20 > Is the 'some_block_number' at or past the end of the disk? >=20 > Multiply the number by 512 and compare it to the size of the disk. >=20 > --=20 > Allan Jude