From owner-freebsd-hackers@freebsd.org Thu Jan 30 14:49:14 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 D557823B7B4 for ; Thu, 30 Jan 2020 14:49:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 487jt20fqQz4C4p for ; Thu, 30 Jan 2020 14:49:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id v25so2636821qto.7 for ; Thu, 30 Jan 2020 06:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R5Hj7GpsyT3Niesq8QX8mr+5KQ0N4mCNCScpCn04iTg=; b=eP2eUprG6PDVJR53Ys/kXqWM2YoTqOGwALMPKAlfoMcEsLRqFe4hj5ye+hlwLjiNSy F5WGn3HnZYo61bAFjJc9VtLiqGGY7ZVaTw20dizahKZO5oW0eU0AuBx/8oW3oKw7OuTF z2ZBHkPJojDci0E/pUAr6uG+GdApkgIaUNG4COvCy7cxx+9nmVaIXX3ywyRTXyKDhnRl hcAPU919JUTZlHOJZHDXqbqKWsi8jzWWJVehS618tBQ+XaGiQvkBmwxDTJNdp5VVvGTN /p0xrS2WJ3mmRs4OpNuOZ4bgGmScYEkM1qLNIcS3ukSuNXeTPm8iQ+tMzfR0bb93v1ni yv/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R5Hj7GpsyT3Niesq8QX8mr+5KQ0N4mCNCScpCn04iTg=; b=RleElg6GxQRnZit/kK0CtKnQYfiA2g0i4OdnXnDmyDGnVoiVoMVAdbu1zGktkgl+JF LUVoAN+AcPdPUtW/Ggyzop2HHdwhjb63Wo2piHc2Ehls6LYk1MP8//Ouf/BJpOeAjFml UCKnWpSiv48hWBE/hucmPoXMpFVKDiQbR/eySZvyw3EYiOhyvECgZIP2tlvHbBcq6LP0 1dXH2Ep3QOd841FSh0+GgwYF4qHFi5Tiy2iR6IpkSENNWm87lw9j19TChOAdaJUbIphP MC3sFhl/dx3+/E5mGkbpQGOprL2Ull4LKFfvqnzalrnJBVCUaVcQe+MH6osOV7Rox9OE AJcw== X-Gm-Message-State: APjAAAUNGPa7oY/+dWdochf2htM0hLLOTY7/tbwbFYt2+GFT7uLhlXIW 50LsAh+Od1kVzFOj591cds/tk92li9YTEwFHdJb6ajfy X-Google-Smtp-Source: APXvYqxxJh8LCQ2h+6KXTOVVufTza62Mn+oC78JxYcryXFU4PlDh5MZyLnz7BYiHdbM4ztV16HF6FOFhS5e0tHkv5Qc= X-Received: by 2002:ac8:1aa6:: with SMTP id x35mr4984829qtj.32.1580395753059; Thu, 30 Jan 2020 06:49:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 30 Jan 2020 07:49:02 -0700 Message-ID: Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? To: =?UTF-8?Q?Peter_Rap=C4=8Dan?= Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 487jt20fqQz4C4p X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=eP2eUprG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.63 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-2.64)[ip: (-9.32), ipnet: 2607:f8b0::/32(-2.03), asn: 15169(-1.78), country: US(-0.05)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; 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: Thu, 30 Jan 2020 14:49:14 -0000 On Thu, Jan 30, 2020 at 7:42 AM Peter Rap=C4=8Dan w= rote: > 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 dis= ks > 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 n= o > 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 ea= ch > 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 ea= ch > 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: erro= r > 32 [if I remember the number correctly] lba some_block_number. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >