From nobody Mon Sep 13 12:59:25 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7A53317C0FA5 for ; Mon, 13 Sep 2021 12:59:37 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7RQJ1cmCz4rcw for ; Mon, 13 Sep 2021 12:59:36 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4H7RQ86Sl1z6g1x for ; Mon, 13 Sep 2021 14:59:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-language:content-type :content-type:date:date:message-id:subject:subject:from:from :received; s=bjowvop61wgh; t=1631537966; x=1633352367; bh=2anhCq zdtq80sbZZwckBDYURlqfSOERgzJ/MH8lEy6I=; b=OyK+vw5MW++FnqS62CHCVK ccM2l+/j6G4jDekAJ9NRV5WZ/osxO8R0WQvOs4J8PCOMCpUUxM1KhjPXQrap701L SQ56Ls3TyFHZCaInAHtivp0K7WiYb9Ac+q0fGLwFCuPyByDr5BD1UlA/sbf2QV3W H/KuD7D/QzVJKjy5NpmCLdLzeRl6TJHFr6axmeJNMKAeu6VA1sS6HwEhaqulUBFM c6j/O2AYhQdXBy+OcwHp5VZRYfGAz8R+03X3niDqPmbU+yc4SDAEIaMpSXUoTTkb VAcFf/luNQTUfMGvdERATDkXKuKxny4H7PPnKwhvU4Kihtf4500x0bnbx1eGt90w == Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id KWRI1QUTMbOu for ; Mon, 13 Sep 2021 14:59:26 +0200 (CEST) To: FreeBSD Current Subject: recent head having significantly less "avail memory" Message-ID: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> Date: Mon, 13 Sep 2021 14:59:25 +0200 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H7RQJ1cmCz4rcw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b=OyK+vw5M; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; MISSING_MIME_VERSION(2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: mad@madpilot.net From: Guido Falsi via freebsd-current X-Original-From: Guido Falsi X-ThisMailContainsUnwantedMimeParts: N List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? [1] https://cgit.freebsd.org/src/commit/?id=71fbc6faed62e8eb5864f7c40839740f5e9f5558 [2] https://cgit.freebsd.org/src/commit/?id=7955efd574b98601a95da45d6d8e7f452631fddd [3] https://cgit.freebsd.org/src/commit/?id=6032b6ba9596927aba15a8004ade521a593a7d58 -- Guido Falsi From nobody Mon Sep 13 17:08:25 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 32F2B17BF40E for ; Mon, 13 Sep 2021 17:08:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7XxX69xNz3JdN for ; Mon, 13 Sep 2021 17:08:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 18DH8Qnh060277 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 13 Sep 2021 20:08:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 18DH8Qnh060277 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 18DH8PF1060276; Mon, 13 Sep 2021 20:08:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Sep 2021 20:08:25 +0300 From: Konstantin Belousov To: mad@madpilot.net Cc: FreeBSD Current Subject: Re: recent head having significantly less "avail memory" Message-ID: References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4H7XxX69xNz3JdN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: > Hi, > > I updated head recently and today I noticed a difference which looks wrong. > > At boodt the new head shows signifcantly less avail memory than before, > around 3 GiB less. > > I moved from commit 71fbc6faed6 [1] where I got: > > Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) > Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) > > to commit 7955efd574b [2] where I get: > > Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) > Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) > > I'm seeing this on multiple machines. > > Unluckily bisecting and trying an older loader.efi in sseparate tests did > not give me any more insight. > > The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look > like a possible trigger to this, but I have been unable to confirm it. > > Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could > be? Is this UEFI or bios boot? Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots. From nobody Mon Sep 13 18:11:41 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EBD5D17B4492 for ; Mon, 13 Sep 2021 18:11:44 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7ZLS5kM3z3t2r for ; Mon, 13 Sep 2021 18:11:44 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4H7ZLR33wsz6g2B; Mon, 13 Sep 2021 20:11:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:date:date:message-id:from:from :references:subject:subject:received; s=bjowvop61wgh; t= 1631556701; x=1633371102; bh=hbE/ieZYTU/HGZZoISjGuTiM3/a1lys0L27 sj/VSPRU=; b=WLri7pI9CHadSpmFv4XqS3ea6VeR0R/jE00/JlcQR8wuSFl8CM1 x03W63x48vf0OQdaJUIBEfMNkEgUMluwHyHOngeu6tbsaVwKh9ag+/u+3jS+kNk3 MF74FtIw/BO64EdjZ+ArxnPRI4kUzfs9fkC2y6Bkc242dAdVqH00B7htlr9XV32C fgr6T1WtkFNjgoIv+KlmUsv3pBZMhZCopdFusD+EZoXsvlJ8zBaKRQgAFzQdBbKD 9nPWH0uuWoWzDL6JesXqMJb1e2X/67UPee8QVQVAfsFT5fxXfczGHfXtHj0LKwHN /9r51fkmqggGm+dYyojlwdvY+PJ9EHmL+Dw== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id Wi7eVwZLS0gG; Mon, 13 Sep 2021 20:11:41 +0200 (CEST) Subject: Re: recent head having significantly less "avail memory" To: Konstantin Belousov Cc: FreeBSD Current References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> Message-ID: <6ea7c339-1b8e-9764-4d28-5a98756e05ff@madpilot.net> Date: Mon, 13 Sep 2021 20:11:41 +0200 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H7ZLS5kM3z3t2r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: mad@madpilot.net From: Guido Falsi via freebsd-current X-Original-From: Guido Falsi X-ThisMailContainsUnwantedMimeParts: N List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org On 13/09/21 19:08, Konstantin Belousov wrote: > On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: >> Hi, >> >> I updated head recently and today I noticed a difference which looks wrong. >> >> At boodt the new head shows signifcantly less avail memory than before, >> around 3 GiB less. >> >> I moved from commit 71fbc6faed6 [1] where I got: >> >> Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) >> Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) >> >> to commit 7955efd574b [2] where I get: >> >> Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) >> Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) >> >> I'm seeing this on multiple machines. >> >> Unluckily bisecting and trying an older loader.efi in sseparate tests did >> not give me any more insight. >> >> The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look >> like a possible trigger to this, but I have been unable to confirm it. >> >> Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could >> be? > > Is this UEFI or bios boot? Machine is UEFI > Provide verbose dmesg for old and new boots on the same machine. > For UEFI boot, show output of 'sysctl machdep.efi_map', again for old > and new boots. > I'm not sure how to get the verbose data for the old boot, since I've been unable to revert the machine to the old state. I'll try anyway though. Anyway this is happening on tree different machines. I forgot to mention they are using a custom kernel. I don't think it makes a difference but I'll also test GENERIC, just in case. -- Guido Falsi From nobody Mon Sep 13 18:17:27 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C42B117B85C2 for ; Mon, 13 Sep 2021 18:17:44 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4H7ZTN4pb2z4RVK for ; Mon, 13 Sep 2021 18:17:44 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-pj1-x1031.google.com with SMTP id t20so6956391pju.5 for ; Mon, 13 Sep 2021 11:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JRbdPswfQZ/TKiqh8Z9A5Oe2/2WvjKtW7cDwqdyPsmU=; b=bZnbMdkIxXNhZWgz1vl/dUU4kPOzjI/MfIfz2P8rVSwzgxi+8Hzg6QQ+khQ7/kVhuP 5c+kzd86nQMIgCyq7KoksqyTeBZF0K3z8Vr/kLewWKHbuyhYqqvdtjblo+R90RM1sExE 9GP02h0Bosxu4RiCSXbfwfb8bQQpBE1TWgxQiabdydxKb6Dwq3sHjoV/LKowZmbSdn4/ Lpgaw2SlALCaNV6fr8e0fTe9h3Vmf/67xs2UVF5FBE/T0UbtV84vu1KCIf4Z/ELfMlIz 0yItecIXKZAphBgP8PrHJUkK9bpWnO8v5MPw4G2ko7AzQwnutxGZjMdKoLnDg6dKjrtv Gjwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JRbdPswfQZ/TKiqh8Z9A5Oe2/2WvjKtW7cDwqdyPsmU=; b=vTJ9Zd8MGTOU2tlN9lrJQGH+09RVTtCkLv0MBJsBE7HSdWAcl9XhU18oiPVjqFzX71 wI/TIHaPaOKZSLUcfkh5RFdUjoj0hqa7OYirkUpG8GVe3Q3swgDMnwvOuB4o0uuli2XV eZwEG8DlWurnlWfa850sdu7tdqeWX8rIUfmKZD/WsfGN2kJgKuzvJRhukmem7zDS4O+X Fr1u9UK1CbbWqG1YGD4qTBk/iCQlZWiKCk82FeiV/WZK0+ipBzPFn0S8oWoE440xmabk OBTVvlywmWPQjkFvHmFYMZYfycvX4Kydg465Lnel/87iFt8zk27cGpSCSAtD9ADI0JBE /VRw== X-Gm-Message-State: AOAM531wYUaiLX5bl4buCiinR9ZHNKjB5ZMDVC7u0cFE3ClCqfilAAZz 3Av58PhffujTTf74Df4wdM2hFa/ym3LreDanvCZgqVcHcZE= X-Google-Smtp-Source: ABdhPJyDvgH4Le/KUMZ4GMKkAaEAzqL9TAIcEmoAWT46Qbdg5K4tXkKTSSDg1rVLDIWkgbq3b26vDc0nHI/o+O9c2RY= X-Received: by 2002:a17:90a:9511:: with SMTP id t17mr946715pjo.194.1631557058173; Mon, 13 Sep 2021 11:17:38 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> <6ea7c339-1b8e-9764-4d28-5a98756e05ff@madpilot.net> In-Reply-To: <6ea7c339-1b8e-9764-4d28-5a98756e05ff@madpilot.net> From: Ryan Stone Date: Mon, 13 Sep 2021 14:17:27 -0400 Message-ID: Subject: Re: recent head having significantly less "avail memory" To: mad@madpilot.net Cc: Konstantin Belousov , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4H7ZTN4pb2z4RVK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Sep 13, 2021 at 2:13 PM Guido Falsi via freebsd-current wrote: > I'm not sure how to get the verbose data for the old boot, since I've > been unable to revert the machine to the old state. I'll try anyway though. Do you have physical access to the machine? It might be easiest to grab a snapshot image, stick it on a USB drive and boot from that. From nobody Mon Sep 13 19:33:15 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A8EF317B4123 for ; Mon, 13 Sep 2021 19:33:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7c8b3ljrz4rDf for ; Mon, 13 Sep 2021 19:33:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4H7c8Z2RbBz6g2B; Mon, 13 Sep 2021 21:33:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:date:date:message-id:from:from :references:subject:subject:received; s=bjowvop61wgh; t= 1631561596; x=1633375997; bh=qNKqUtNYDg0elEFYjWuDbeB9VJBpLopjUAc fL/tSE8o=; b=sVyt5GMSpf/D2sekM18Psd5t8g+s7aOq5B2tvN2grEl2CVqIqB3 Je7mqQHROFSHg0SHF3OD3+F+ikl0BrLAAUB9K5G+mrY3LKFuUpGUwbvO2Bxz+KNu 9rSvue2QXfxE8dvRtnPswDK51Mxx1q2x0AnOW+2KHjp4/T2CXiMgWGOzPB1WxU10 GMA61vb6rd8kZHvNajwbABUhjkTzpKm1taLksd+JFScdvgSl9H85KYVFD/S6Nhkt vfP/dHttMv4VN1MN+k7YmzzXXuLaxHIeZlbWrv8iRc8jVzWFChhfN29fWgiuX/Wo CuvFUA7QIHQGYHNfRmwnMVEBH3Byc76PbJA== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id JZGbDY4PvKj0; Mon, 13 Sep 2021 21:33:16 +0200 (CEST) Subject: Re: recent head having significantly less "avail memory" To: Ryan Stone Cc: Konstantin Belousov , FreeBSD Current References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> <6ea7c339-1b8e-9764-4d28-5a98756e05ff@madpilot.net> Message-ID: Date: Mon, 13 Sep 2021 21:33:15 +0200 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H7c8b3ljrz4rDf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: mad@madpilot.net From: Guido Falsi via freebsd-current X-Original-From: Guido Falsi X-ThisMailContainsUnwantedMimeParts: N List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org On 13/09/21 20:17, Ryan Stone wrote: > On Mon, Sep 13, 2021 at 2:13 PM Guido Falsi via freebsd-current > wrote: >> I'm not sure how to get the verbose data for the old boot, since I've >> been unable to revert the machine to the old state. I'll try anyway though. > > Do you have physical access to the machine? It might be easiest to > grab a snapshot image, stick it on a USB drive and boot from that. > I definitely have physical access, it's my desktop, laptop and build machines. First thing I'm doing is disable cron job removing old zfs snapshots, so state is not lost. Since this is involving only UEFI, loader and kernel, I've recovered the old parts and now I have the machine reporting the usual amount of memory, so I should be able to extract the requested data and post it shortly. Thanks for your help anyway! -- Guido Falsi From nobody Mon Sep 13 20:07:46 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C2C3E17C4DD9 for ; Mon, 13 Sep 2021 20:07:49 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7cwP4XTbz52Ym for ; Mon, 13 Sep 2021 20:07:49 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4H7cwN5CHwz6dqg; Mon, 13 Sep 2021 22:07:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:date:date:message-id:from:from :references:subject:subject:received; s=bjowvop61wgh; t= 1631563666; x=1633378067; bh=yFDRuhFvpyerpCI7mnuLWY1biMLtRV5qWxO qCIV1tmM=; b=y5Mv+t0M6nu2vYdoHq9s/tvNSXPFIm+/JIaDqW25ZjYjyD2JWK5 R3VIbOQM8PeCA7XE51caMLK/To/b+Eti1Xba/I1d7xeiIkq4UWTbqCeP7xBUZKim G+sBRA/K7v77V7CqyWcOC6jQ9aUOdJ8aTFri1u6X4d135DGp7DMpp27wTdONNWgH E5Iwb54ym4SrLtkVaBb4gQbrh3Kp72ccBmrTIglrTXSl2nURnwZ2401/yxK7FCBv X7cMVZmsl46UklBJzRtRe4kYq5eTL+r4xFj6Lh6ATsaBK4BNbTfper5ZyqJOJpAR 4nTylnuWbDaUb0gEzMfUx+Rqs7V+Ix8JBIA== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id 8NEjbOA5t4vc; Mon, 13 Sep 2021 22:07:46 +0200 (CEST) Subject: Re: recent head having significantly less "avail memory" To: Konstantin Belousov Cc: FreeBSD Current References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> Message-ID: <9e40483c-29e0-303a-eaa4-86d294403868@madpilot.net> Date: Mon, 13 Sep 2021 22:07:46 +0200 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H7cwP4XTbz52Ym X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: mad@madpilot.net From: Guido Falsi via freebsd-current X-Original-From: Guido Falsi X-ThisMailContainsUnwantedMimeParts: N List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org On 13/09/21 19:08, Konstantin Belousov wrote: > On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: >> Hi, >> >> I updated head recently and today I noticed a difference which looks wrong. >> >> At boodt the new head shows signifcantly less avail memory than before, >> around 3 GiB less. >> >> I moved from commit 71fbc6faed6 [1] where I got: >> >> Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) >> Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) >> >> to commit 7955efd574b [2] where I get: >> >> Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) >> Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) >> >> I'm seeing this on multiple machines. >> >> Unluckily bisecting and trying an older loader.efi in sseparate tests did >> not give me any more insight. >> >> The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look >> like a possible trigger to this, but I have been unable to confirm it. >> >> Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could >> be? > > Is this UEFI or bios boot? > Provide verbose dmesg for old and new boots on the same machine. > For UEFI boot, show output of 'sysctl machdep.efi_map', again for old > and new boots. > I shared the data you request here: https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG -- Guido Falsi From nobody Mon Sep 13 22:12:33 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C9D1917B4CF9 for ; Mon, 13 Sep 2021 22:12:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7ghV1Lc1z3vkC for ; Mon, 13 Sep 2021 22:12:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 18DMCYRi036565 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Sep 2021 01:12:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 18DMCYRi036565 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 18DMCX0A036564; Tue, 14 Sep 2021 01:12:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 Sep 2021 01:12:33 +0300 From: Konstantin Belousov To: Guido Falsi Cc: FreeBSD Current Subject: Re: recent head having significantly less "avail memory" Message-ID: References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> <9e40483c-29e0-303a-eaa4-86d294403868@madpilot.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e40483c-29e0-303a-eaa4-86d294403868@madpilot.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4H7ghV1Lc1z3vkC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote: > On 13/09/21 19:08, Konstantin Belousov wrote: > > On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: > > > Hi, > > > > > > I updated head recently and today I noticed a difference which looks wrong. > > > > > > At boodt the new head shows signifcantly less avail memory than before, > > > around 3 GiB less. > > > > > > I moved from commit 71fbc6faed6 [1] where I got: > > > > > > Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) > > > Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) > > > > > > to commit 7955efd574b [2] where I get: > > > > > > Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) > > > Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) > > > > > > I'm seeing this on multiple machines. > > > > > > Unluckily bisecting and trying an older loader.efi in sseparate tests did > > > not give me any more insight. > > > > > > The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look > > > like a possible trigger to this, but I have been unable to confirm it. > > > > > > Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could > > > be? > > > > Is this UEFI or bios boot? > > Provide verbose dmesg for old and new boots on the same machine. > > For UEFI boot, show output of 'sysctl machdep.efi_map', again for old > > and new boots. > > > > I shared the data you request here: > > https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG Thanks. If you do on the loader prompt for the new (AKA bad) kernel copy_staging enable and then boot, does the report of avail memory becomes good? From nobody Mon Sep 13 22:25:55 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BC1E817BC105 for ; Mon, 13 Sep 2021 22:25:59 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7gzq4KVwz4V7G for ; Mon, 13 Sep 2021 22:25:59 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4H7gzp4Yh4z6g1x; Tue, 14 Sep 2021 00:25:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:date:date:message-id:from:from :references:subject:subject:received; s=bjowvop61wgh; t= 1631571956; x=1633386357; bh=fSIpmhlQVaicHV35xb6cja4j8b+XccfCDio Pz0I01TQ=; b=KovdLoPvSSyjNJs5zDElVKT5tRAQ9jukLOMpe3DgX76QU6d1reZ EPw7ZKgw/WFLWny8p0WrDvekoJfQR9nyOJ7fxYVsso2s037kVnxlwYU/IexyWYdr +98dubUzNMLQ8rz7c2lEcgrNQC+GWbAH/zHxpq49YWZX1d3RKoa9gbRRqhirIk5v PYOO0RSJREbhYmvdCTyOtPLOoCs/inWJpsz/hVimx1JqMlf59RVP11FA98we3T9j Z4MHPPJI1NJf2ORFvl/mO3atjCyxftnZJdB18h14x+QUD9vQNuEet8C43Z+8UEd+ BBa/htThCH2RZKbmNbicPypAgpn7o0c6Gxw== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id EzMYte65oTNI; Tue, 14 Sep 2021 00:25:56 +0200 (CEST) Subject: Re: recent head having significantly less "avail memory" To: Konstantin Belousov Cc: FreeBSD Current References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> <9e40483c-29e0-303a-eaa4-86d294403868@madpilot.net> Message-ID: Date: Tue, 14 Sep 2021 00:25:55 +0200 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H7gzq4KVwz4V7G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: mad@madpilot.net From: Guido Falsi via freebsd-current X-Original-From: Guido Falsi X-ThisMailContainsUnwantedMimeParts: N List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org On 14/09/21 00:12, Konstantin Belousov wrote: > On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote: >> On 13/09/21 19:08, Konstantin Belousov wrote: >>> On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: >>>> Hi, >>>> >>>> I updated head recently and today I noticed a difference which looks wrong. >>>> >>>> At boodt the new head shows signifcantly less avail memory than before, >>>> around 3 GiB less. >>>> >>>> I moved from commit 71fbc6faed6 [1] where I got: >>>> >>>> Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) >>>> Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) >>>> >>>> to commit 7955efd574b [2] where I get: >>>> >>>> Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) >>>> Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) >>>> >>>> I'm seeing this on multiple machines. >>>> >>>> Unluckily bisecting and trying an older loader.efi in sseparate tests did >>>> not give me any more insight. >>>> >>>> The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look >>>> like a possible trigger to this, but I have been unable to confirm it. >>>> >>>> Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could >>>> be? >>> >>> Is this UEFI or bios boot? >>> Provide verbose dmesg for old and new boots on the same machine. >>> For UEFI boot, show output of 'sysctl machdep.efi_map', again for old >>> and new boots. >>> >> >> I shared the data you request here: >> >> https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG > > Thanks. > > If you do on the loader prompt for the new (AKA bad) kernel > copy_staging enable > and then boot, does the report of avail memory becomes good? > Yes, it works as expected, that is reports the amount of memory I expect: Sep 14 00:24:50 marvin kernel: real memory = 17179869184 (16384 MB) Sep 14 00:24:50 marvin kernel: avail memory = 16590356480 (15821 MB) -- Guido Falsi From nobody Tue Sep 14 01:30:02 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C6EB17C605B for ; Tue, 14 Sep 2021 01:30:13 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7m4N4cy6z3wHH; Tue, 14 Sep 2021 01:30:12 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1631583003; bh=Fnr9tKP1lCtJXv+h9dMaV3fa5YdENYKj/ix5VKx W4hQ=; b=CcQvY0SBhbCY0gg8cxSFjFbk2ayWbh5DCgxnwpPYYYmw6q5r6uLE3jg Na9gx2BS2Mj5jfh9bRfF5jYTjM+fgHth09nhBxhqmHTaowlZ0xGSPnyyy1wDcihw sywErt0djongw4uyuc+C83eQs1V/FNJQFye+g78teAgH5uFToDuw= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 117D33104A; Tue, 14 Sep 2021 01:30:03 +0000 () To: freebsd-current Cc: trasz@freebsd.org Subject: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al Message-ID: <174267aa-00de-6e35-a75a-80be3617b6a1@protected-networks.net> Date: Mon, 13 Sep 2021 21:30:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-NZ Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4H7m4N4cy6z3wHH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=CcQvY0SB; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[protected-networks.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set. For example .. imb@vm01:/home/imb> date Tue Sep 14 01:25:57 2021 Every other daemon also thinks it's running in UTC+0 :-( When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf, the output is (for me) .. imb@vm01:/usr/src/lib/libc> date Mon Sep 13 21:28:29 EDT 2021 imb From nobody Tue Sep 14 09:02:46 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0989F17C254E for ; Tue, 14 Sep 2021 07:03:03 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4H7vSQ6SJ3z4sXs; Tue, 14 Sep 2021 07:03:02 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ej1-x62d.google.com with SMTP id hx25so3669028ejc.6; Tue, 14 Sep 2021 00:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=GylOln/FfAtp/4wcpHcPZqCW8cAwNWFQB41s3QPTPBk=; b=b6jU8XUfjZ7HWtxbyeEPpUQ9ikbugZ3ANw2KA8iaoVkE/+FkbUnh0+yx6Rcq0FlG3h jHGXMHf3wtlzAWWJa/uNELD9bYRZSom0wCKZFR4hkL1X2ZozIzIG5PSC7WHb6u0KouXf 32KAzUBFIESGBerNir944qGyZ8OLtqSJC9K5Winy7McgUOxPpwXkdJk/FJ1tcr7kMV9f nUVL1FeBVJ9ihmLjIujqi1CfCqCkGaCzAahQ0AQQ3MmV5AGEWGblL+fxfivbWkBy6HVG f8qdLcSQfISmtsfrLsNKJ4NoU+xIEpIQfS7N68uP2UEjyFRFfMzEifPRAmDmpw6STG83 gQaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=GylOln/FfAtp/4wcpHcPZqCW8cAwNWFQB41s3QPTPBk=; b=6fnQ3JQ8SGzI5i2dgAVdWye62KiBwcIqO8ADKsFf0Yi3Y57EU+hCpZffrbIhYURrgA dZVA+VcUJjRwwpLcXAkTTw0x6pN8ojLVwzEcGcGw5PM68PSmRiDmm+P/KxU+Ao9aaoZy ub44My5IqL+ah1DC6i2kFeXQaxgjr8IKCmmkjyss+BHat6S5dvj9Pah0BafrgmB3zmDm yiXmEB9zbFrRg4anhBKAV8aBz6kAnL5V8vfDlU2F5bAen5kQU/TkMLabUVPPrddxz7CC W/AnBIzf/5DhB5iMFyVW68oLF71feNvj2yQC7R64eWD4ruqD5fLlCu5aZ2LywxBoZApC ECDA== X-Gm-Message-State: AOAM533nQ4aOZXJ2jRO4Rw/cufZ83RAl+d8bB+IEEsdcnSui5qV+vVyL G66ZYvkX27aA9QvsOo6cOdLedOyhJqM= X-Google-Smtp-Source: ABdhPJz80dBQuJ4oHTUrlNP2T3SsHWE5wQx9zSZKGSglIUPkCx5IDZHWAQ3/7Dlym6e0lduPmRRDOg== X-Received: by 2002:a17:906:b59:: with SMTP id v25mr6598239ejg.547.1631602976146; Tue, 14 Sep 2021 00:02:56 -0700 (PDT) Received: from ernst.home (p5b023517.dip0.t-ipconnect.de. [91.2.53.23]) by smtp.gmail.com with ESMTPSA id bq4sm4459057ejb.43.2021.09.14.00.02.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 00:02:55 -0700 (PDT) Date: Tue, 14 Sep 2021 09:02:46 +0000 From: Gary Jennejohn To: Michael Butler via freebsd-current Cc: imb@protected-networks.net, trasz@freebsd.org Subject: Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al Message-ID: <20210914110246.724cf733@ernst.home> In-Reply-To: <174267aa-00de-6e35-a75a-80be3617b6a1@protected-networks.net> References: <174267aa-00de-6e35-a75a-80be3617b6a1@protected-networks.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H7vSQ6SJ3z4sXs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 13 Sep 2021 21:30:02 -0400 Michael Butler via freebsd-current wrote: > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set. > > For example .. > > imb@vm01:/home/imb> date > Tue Sep 14 01:25:57 2021 > > Every other daemon also thinks it's running in UTC+0 :-( > > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf, the output is (for me) .. > > imb@vm01:/usr/src/lib/libc> date > Mon Sep 13 21:28:29 EDT 2021 > Same here. After instaling the new world this morning I was suddenly in UTC instead of CEST (2 hours difference). Thanks for the fix :-) -- Gary Jennejohn From nobody Tue Sep 14 08:37:36 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C0E9717C5560 for ; Tue, 14 Sep 2021 08:37:40 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7xYc3LHQz3sx2 for ; Tue, 14 Sep 2021 08:37:40 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 7c71defb; Tue, 14 Sep 2021 08:37:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=date:from:to:cc :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=20180501; bh=sj7XdO9R bxDWj21231sdDs6rL1U=; b=inSDK9Hf7IZsmtMEcQeem8mucRnXVtPVXNc7Vv87 X/i/FQecRl64WMLy/+oE2fdsLZ86ejUBPmH15HnXMDsUIiQyWkkUWPpvyr/Qx63n /7LUJFqkUhPFqvxPzZ17tPS+8KeoeiVZE7m+QEzI7q6GaflBjHGBIppl+9CJYfYD 9ZXJvdITi9LBrz1geM/rPTlGFqN6BGP8HJ8TO+YJIEEoLDsBAlfwkd+nlPKwvpDZ XNbtYWPOKUYAzjvIVwydLWOxkUNUmPUTikMfED+tbU4U5yF83pOCZUPLI2XB3RhN c4++Imi+cMGZdugCj63mAUNHTNvHon3uNmt9o5c1TPrq3Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=date:from:to:cc :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=20180501; b=nA KKouWZavy8ppkVrpGADoZqldE+3mV4Grcu06t1dDXFBmPSNe8NXG4O5vRNqThuiS 5YSRRjBFRPVl0T4Zzt9eXnej6x9ksDKrJbXE5UEdIoo+ZrtKiFIAyoAtvUkRa/6L N6iiu3TUFjh2DKdLwTv/p/bcrzDOCLGjwuksc5pVzBBd/cbcFyZ+xuxV2dWkIJQY Q4gCtARemeFIMyucNUHm47bjnL0igQH0sDeoH9p3zbCPdqLaEqAiiyDCuuer+PA3 Rl9N7pFQwCT0QacH27SIkt4m2UOAtRHmMmtqkQySDuwVI/8vCTnyaXmSWrsloUHl 8iZQ+8FQclOYRY66pLAw== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 39cd0808 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Tue, 14 Sep 2021 08:37:37 +0000 (UTC) Date: Tue, 14 Sep 2021 10:37:36 +0200 From: Michael Gmelin To: freebsd-current@freebsd.org Cc: gljennjohn@gmail.com Subject: Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al Message-ID: <20210914103736.4dbe1252@bsd64.grem.de> In-Reply-To: <20210914110246.724cf733@ernst.home> References: <174267aa-00de-6e35-a75a-80be3617b6a1@protected-networks.net> <20210914110246.724cf733@ernst.home> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H7xYc3LHQz3sx2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 14 Sep 2021 09:02:46 +0000 Gary Jennejohn wrote: > On Mon, 13 Sep 2021 21:30:02 -0400 > Michael Butler via freebsd-current > wrote: > > > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to > > recognize any configured timezone when WITH_DETECT_TZ_CHANGES is > > not set. > > > > For example .. > > > > imb@vm01:/home/imb> date > > Tue Sep 14 01:25:57 2021 > > > > Every other daemon also thinks it's running in UTC+0 :-( > > > > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in > > /etc/src.conf, the output is (for me) .. > > imb@vm01:/usr/src/lib/libc> date > > Mon Sep 13 21:28:29 EDT 2021 > > > > Same here. After instaling the new world this morning I was suddenly > in UTC instead of CEST (2 hours difference). > > Thanks for the fix :-) Before reading your message, I (ironically) wanted to tell you about your email's date header containing the wrong timezone ^_^ -m -- Michael Gmelin From nobody Tue Sep 14 10:24:33 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0908717D34B1; Tue, 14 Sep 2021 10:24:47 +0000 (UTC) (envelope-from merv@soundabstractions.io) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7zx95pFZz4sSX; Tue, 14 Sep 2021 10:24:45 +0000 (UTC) (envelope-from merv@soundabstractions.io) Received: (Authenticated sender: merv@soundabstractions.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id B73481C0008; Tue, 14 Sep 2021 10:24:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Call for participation From: Merv Hammer In-Reply-To: Cc: FreeBSD Current , FreeBSD Hackers , FreeBSD Ports Date: Tue, 14 Sep 2021 11:24:33 +0100 Message-Id: References: To: Warner Losh X-Mailer: iPhone Mail (18G82) X-Rspamd-Queue-Id: 4H7zx95pFZz4sSX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of merv@soundabstractions.io designates 217.70.183.197 as permitted sender) smtp.mailfrom=merv@soundabstractions.io X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RWL_MAILSPIKE_POSSIBLE(0.00)[217.70.183.197:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[soundabstractions.io]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.197:from] X-ThisMailContainsUnwantedMimeParts: N Hi Warner, Please count me in too. -Merv From nobody Tue Sep 14 12:11:26 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AD9D417B9B83; Tue, 14 Sep 2021 12:11:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) by mx1.freebsd.org (Postfix) with ESMTP id 4H82JV5ltSz4Qm6; Tue, 14 Sep 2021 12:11:38 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6dae8.dip0.t-ipconnect.de [79.230.218.232]) (authenticated bits=128) by land.berklix.org (8.15.2/8.15.2) with ESMTPA id 18ECBWha028961; Tue, 14 Sep 2021 12:11:32 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 18ECBQXT036653; Tue, 14 Sep 2021 14:11:26 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.16.1/8.16.1) with ESMTP id 18ECBQBe071018; Tue, 14 Sep 2021 14:11:26 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202109141211.18ECBQBe071018@fire.js.berklix.net> To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org cc: "Dimitry Andric" , "Julian H. Stacey" Subject: Re: src/lib/libgcc_s needs mv /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Sun, 12 Sep 2021 14:53:58 +0200." <202109121253.18CCrw1O000484@fire.js.berklix.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71016.1631621486.1@fire.js.berklix.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Sep 2021 14:11:26 +0200 X-Rspamd-Queue-Id: 4H82JV5ltSz4Qm6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-1.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; URI_HIDDEN_PATH(1.00)[http://berklix.com/~jhs/bin/.csh/unsetenv.csh]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.218.232:received] X-ThisMailContainsUnwantedMimeParts: N Hi stable@ & current@, Apologies for a cross post, as = a fault reported May 2019 on current, is still breaking on stable Sept 202= 1. 2019 Refs: Subject: lib/libgcc_s fails on make all after make world succeeds https://lists.freebsd.org/pipermail/freebsd-current/2019-May/073440.html From: Julian H. Stacey jhs at berklix.com Sun May 19 21:30:10 UTC 2019 https://lists.freebsd.org/pipermail/freebsd-current/2019-May/073442.html From: Dimitry Andric dim at FreeBSD.org = Date: Sun, 19 May 2019 23:54:18 +0200 2021 Ref: Subject: src/lib/libgcc_s needs mv /usr/obj/usr/src/amd64.amd64/lib/libc/l= ibc.a https://lists.freebsd.org/archives/freebsd-stable/2021-September/000225.h= tml From: From: Julian H. Stacey = Dimitry suggested maybe a rare race condition, so I just started a make -B -j 1 world It will take a while, old machines here, (maybe that's what's exposing a race condition not seen on faster boxes ?) = A 2nd speculation was I may be missing symbolic links ? Last year & maybe earlier, I had problems from missing symbolic links, when I was fetching src/ with a (since fixed, Sept 2020) ctm; But my src= -12/ is new, not CTM supplied, but from cd ~/git/`hostname -s`/src-12 git clone -o freebsd -b stable/12 https://git.freebsd.org/src.git src cd ~/git/`hostname -s`/src-12/src = git pull --ff-only The only symbolic links I have are in src-cur/ contrib/bc/ contrib/tcpdump/ sys/contrib/openzfs/ src-12/ contrib/bc/ contrib/tcpdump/ So lack of symbolic links is not the problem, unless someone sees more lin= ks I dont have, if one of you could perhaps kindly check ? with eg cd /usr/src; find -s . -type l | sort | grep -v sys/amd64/compile \ grep -v contrib/bc | grep -v contrib/tcpdump | grep -v sys/contrib/open= zfs Anyone else seen problems making lib/libgcc_s ? Any other ideas what else to check ? I've already checked as in my last post appended. I'm now checking for any files only under root or only under a tree installed by setenv DESTDIR . Suggestions welcome please ? {=3D=3D=3D=3D=3D=3D To: FreeBSD-STABLE Mailing List Subject: src/lib/libgcc_s needs mv /usr/obj/usr/src/amd64.amd64/lib/libc/l= ibc.a Date: Sun, 12 Sep 2021 14:53:58 +0200 Hi all, Anyone else seen this ? After cd /usr/src ; make install this fails cd /usr/src/lib/libgcc_s ; make until a manual mv /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a \ /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a.MV when = cd /usr/src ; make all ; make install can run OK, but then again needs another 'mv'. Identical: md5 /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a* /usr/lib/libc= .a Maybe its changing where linking from ? ** I've had this on & off for months I think, on multiple hardware, but possi= bly just 12.2-STABLE, = it's still so with a stable src/ fetched a day or ago with git pull --ff-o= nly To help simplify debug, I have no /etc/src.conf /etc/make.conf I also stripped my env with http://berklix.com/~jhs/bin/.csh/unsetenv.csh source `which unsetenv.csh` Remaining: DESTDIR DISPLAY HOSTDISPLAY PATH TERM TERMCAP TERMPATH None of that helps. I am running a 12.2 self built system, uncustomised src/, no kernel module= s, uname -a FreeBSD fire.js.berklix.net 12.2-RELEASE FreeBSD 12.2-RELEASE #0: Sat May 22 20:41:18 CEST 2021 jhs@fire.js.berklix.net:/1s4/ftp/pri/FreeBSD/releases/12.2-RELEASE/generi= c/src/sys/amd64/compile/GENERIC amd64 with the exception of /boot/kernel which is 12.2-RELEASE as for some unkno= wn reason I cant boot a local compiled or cross compiled 12.2-STABLE kernel (I'm still investigating that presumed un-associated issue) ** Here's a script log : {------- =3D=3D=3D> etc (install) =3D=3D=3D> etc/sendmail (install) cd /usr1/src/share/man; make makedb makewhatis /usr/share/man makewhatis /usr/share/openssl/man .... cd /usr/src/lib/libgcc_s ; make cat /usr1/src/lib/libgcc_s/Symbol.map /usr1/src/lib/libgcc_s/SymbolDefault= .map | cpp - - | awk -v vfile=3D/usr1/src/lib/libgcc_s/Versions.def -f /u= sr/share/mk/version_gen.awk > Version.map building shared library libgcc_s.so.1 cc -nodefaultlibs -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl= ,--fatal-warnings -Wl,--warn-shared-textrel -o libgcc_s.so.1.full -Wl,-so= name,libgcc_s.so.1 `NM=3D'nm' NMFLAGS=3D'' lorder i386/fp_mode.pico absvd= i2.pico absvsi2.pico absvti2.pico addvdi3.pico addvsi3.pico addvti3.pico a= pple_versioning.pico ashldi3.pico ashlti3.pico ashrdi3.pico ashrti3.pico b= swapdi2.pico bswapsi2.pico clear_cache.pico clzdi2.pico clzsi2.pico clzti2= .pico cmpdi2.pico cmpti2.pico ctzdi2.pico ctzsi2.pico ctzti2.pico divdc3.p= ico divdi3.pico divmoddi4.pico divmodsi4.pico divsc3.pico divsi3.pico divt= c3.pico divti3.pico divxc3.pico enable_execute_stack.pico eprintf.pico ext= endhfsf2.pico ffsdi2.pico ffssi2.pico ffsti2.pico fixdfdi.pico fixdfti.pic= o fixsfdi.pico fixsfti.pico fixunsdfdi.pico fixunsdfsi.pico fixunsdfti.pic= o fixunssfdi.pico fixunssfsi.pico fixunssfti.pico fixunsxfdi.pico fixunsxf= si.pico fixunsxfti.pico fixxfdi.pico fixxfti.pico floatditf.pico floattidf= .pico floattisf.pico floattixf.pico floatunditf.pico floatunsidf.pico floa= tunsisf.pico floatuntidf.pico floatuntisf.pico floatuntixf.pico gcc_person= ality_v0.pico int_util.pico lshrdi3.pico lshrti3.pico moddi3.pico modsi3.p= ico modti3.pico muldc3.pico muldi3.pico mulodi4.pico mulosi4.pico muloti4.= pico mulsc3.pico multc3.pico multi3.pico mulvdi3.pico mulvsi3.pico mulvti3= .pico mulxc3.pico negdf2.pico negdi2.pico negsf2.pico negti2.pico negvdi2.= pico negvsi2.pico negvti2.pico paritydi2.pico paritysi2.pico parityti2.pic= o popcountdi2.pico popcountsi2.pico popcountti2.pico powidf2.pico powisf2.= pico powitf2.pico powixf2.pico subvdi3.pico subvsi3.pico subvti3.pico tram= poline_setup.pico truncdfhf2.pico truncsfhf2.pico ucmpdi2.pico ucmpti2.pic= o udivdi3.pico udivmoddi4.pico udivmodsi4.pico udivmodti4.pico udivsi3.pic= o udivti3.pico umoddi3.pico umodsi3.pico umodti3.pico floatdidf.pico float= disf.pico floatdixf.pico floatundidf.pico floatundisf.pico floatundixf.pic= o cpu_model.pico adddf3.pico addsf3.pico divdf3.pico divsf3.pico extendsfd= f2.pico fixdfsi.pico fixsfsi.pico floatsidf.pic! o floatsisf.pico muldf3.pico mulsf3.pico subdf3.pico subsf3.pico truncdfs= f2.pico comparedf2.pico comparesf2.pico gcc_personality_v0.pico int_util.p= ico Unwind-EHABI.pico Unwind-sjlj.pico UnwindLevel1-gcc-ext.pico UnwindLev= el1.pico UnwindRegistersRestore.pico UnwindRegistersSave.pico libunwind.pi= co s_fabs.pico s_fabsf.pico s_fabsl.pico s_fmax.pico s_fmaxf.pico s_logb.p= ico s_logbf.pico s_scalbn.pico s_scalbnf.pico s_fmaxl.pico s_logbl.pico s_= scalbnl.pico | tsort -q` -L/1s4/release/12.2-STABLE/usr/obj/usr/src/amd64= .amd64/lib/libc -lc ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32S aga= inst symbol: __je_sz_size2index_tab in readonly segment; recompile object = files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the = output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_sz.o) >>> referenced by sz.h:158 (/usr1/src/contrib/jemalloc/include/jemalloc/in= ternal/sz.h:158) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32S aga= inst symbol: __je_arenas in readonly segment; recompile object files with = -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by atomic.h:55 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/atomic.h:55) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32S aga= inst symbol: __je_sz_index2size_tab in readonly segment; recompile object = files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the = output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_sz.o) >>> referenced by sz.h:201 (/usr1/src/contrib/jemalloc/include/jemalloc/in= ternal/sz.h:201) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst local symbol in readonly segment; recompile object files with -fPIC or= pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:144 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/mutex.h:144) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst local symbol in readonly segment; recompile object files with -fPIC or= pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:203 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/mutex.h:203) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst local symbol in readonly segment; recompile object files with -fPIC or= pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:214 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/mutex.h:214) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_extent_hooks_default in readonly segment; recompile objec= t files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in th= e output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_extent.o) >>> referenced by jemalloc_internal_inlines_a.h:91 (/usr1/src/contrib/jema= lloc/include/jemalloc/internal/jemalloc_internal_inlines_a.h:91) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_extents_rtree in readonly segment; recompile object files= with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the outpu= t >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_extent.o) >>> referenced by rtree.h:381 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/rtree.h:381) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_extents_rtree in readonly segment; recompile object files= with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the outpu= t >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_extent.o) >>> referenced by rtree.h:381 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/rtree.h:381) >>> jemalloc_jemalloc.o:(a0ialloc) in archive /1s4/release/1= 2.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32S aga= inst symbol: __je_arenas in readonly segment; recompile object files with = -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by atomic.h:55 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/atomic.h:55) >>> jemalloc_jemalloc.o:(a0idalloc) in archive /1s4/release/= 12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32S aga= inst symbol: __je_sz_index2size_tab in readonly segment; recompile object = files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the = output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_sz.o) >>> referenced by sz.h:201 (/usr1/src/contrib/jemalloc/include/jemalloc/in= ternal/sz.h:201) >>> jemalloc_jemalloc.o:(a0idalloc) in archive /1s4/release/= 12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_extents_rtree in readonly segment; recompile object files= with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the outpu= t >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_extent.o) >>> referenced by rtree.h:381 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/rtree.h:381) >>> jemalloc_jemalloc.o:(a0idalloc) in archive /1s4/release/= 12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_extents_rtree in readonly segment; recompile object files= with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the outpu= t >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_extent.o) >>> referenced by rtree.h:381 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/rtree.h:381) >>> jemalloc_jemalloc.o:(a0idalloc) in archive /1s4/release/= 12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_extents_rtree in readonly segment; recompile object files= with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the outpu= t >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_extent.o) >>> referenced by rtree.h:381 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/rtree.h:381) >>> jemalloc_jemalloc.o:(a0idalloc) in archive /1s4/release/= 12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_extents_rtree in readonly segment; recompile object files= with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the outpu= t >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_extent.o) >>> referenced by rtree.h:381 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/rtree.h:381) >>> jemalloc_jemalloc.o:(a0idalloc) in archive /1s4/release/= 12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32S aga= inst symbol: __je_arenas in readonly segment; recompile object files with = -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by atomic.h:55 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/atomic.h:55) >>> jemalloc_jemalloc.o:(__je_arena_set) in archive /1s4/rel= ease/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_arenas_lock in readonly segment; recompile object files w= ith -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:144 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/mutex.h:144) >>> jemalloc_jemalloc.o:(__je_arena_init) in archive /1s4/re= lease/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_arenas_lock in readonly segment; recompile object files w= ith -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:203 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/mutex.h:203) >>> jemalloc_jemalloc.o:(__je_arena_init) in archive /1s4/re= lease/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32S aga= inst symbol: __je_arenas in readonly segment; recompile object files with = -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by atomic.h:55 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/atomic.h:55) >>> jemalloc_jemalloc.o:(__je_arena_init) in archive /1s4/re= lease/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mcan't create dynamic relocation R_X86_64_32 agai= nst symbol: __je_arenas_lock in readonly segment; recompile object files w= ith -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /1s4/release/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/li= bc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:214 (/usr1/src/contrib/jemalloc/include/jemalloc= /internal/mutex.h:214) >>> jemalloc_jemalloc.o:(__je_arena_init) in archive /1s4/re= lease/12.2-STABLE/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: =1B[0;31merror: =1B[0mtoo many errors emitted, stopping now (use -erro= r-limit=3D0 to see all errors) cc: =1B[0;1;31merror: =1B[0mlinker command failed with exit code 1 (use -v= to see invocation)=1B[0m *** Error code 1 Stop. make: stopped in /usr1/src/lib/libgcc_s 12.2-RELEASE /dev/pts/2 jhs 1 fire/usr1/src/lib/libgcc_s ls -l /usr/obj/u= sr/src/amd64.amd64/lib/libc/libc.a -rw-r--r-- 1 jhs staff 17050712 Sep 12 13:28 /usr/obj/usr/src/amd64.amd= 64/lib/libc/libc.a 12.2-RELEASE /dev/pts/2 jhs 2 fire/usr1/src/lib/libgcc_s mv /usr/obj/usr/s= rc/amd64.amd64/lib/libc/libc.a /usr/obj/usr/src/amd64.amd64/lib/libc/libc.= a.MV 12.2-RELEASE /dev/pts/2 jhs 3 fire/usr1/src/lib/libgcc_s make building shared library libgcc_s.so.1 cc -nodefaultlibs -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl= ,--fatal-warnings -Wl,--warn-shared-textrel -o libgcc_s.so.1.full -Wl,-so= name,libgcc_s.so.1 `NM=3D'nm' NMFLAGS=3D'' lorder i386/fp_mode.pico absvd= i2.pico absvsi2.pico absvti2.pico addvdi3.pico addvsi3.pico addvti3.pico a= pple_versioning.pico ashldi3.pico ashlti3.pico ashrdi3.pico ashrti3.pico b= swapdi2.pico bswapsi2.pico clear_cache.pico clzdi2.pico clzsi2.pico clzti2= .pico cmpdi2.pico cmpti2.pico ctzdi2.pico ctzsi2.pico ctzti2.pico divdc3.p= ico divdi3.pico divmoddi4.pico divmodsi4.pico divsc3.pico divsi3.pico divt= c3.pico divti3.pico divxc3.pico enable_execute_stack.pico eprintf.pico ext= endhfsf2.pico ffsdi2.pico ffssi2.pico ffsti2.pico fixdfdi.pico fixdfti.pic= o fixsfdi.pico fixsfti.pico fixunsdfdi.pico fixunsdfsi.pico fixunsdfti.pic= o fixunssfdi.pico fixunssfsi.pico fixunssfti.pico fixunsxfdi.pico fixunsxf= si.pico fixunsxfti.pico fixxfdi.pico fixxfti.pico floatditf.pico floattidf= .pico floattisf.pico floattixf.pico floatunditf.pico floatunsidf.pico floa= tunsisf.pico floatuntidf.pico floatuntisf.pico floatuntixf.pico gcc_person= ality_v0.pico int_util.pico lshrdi3.pico lshrti3.pico moddi3.pico modsi3.p= ico modti3.pico muldc3.pico muldi3.pico mulodi4.pico mulosi4.pico muloti4.= pico mulsc3.pico multc3.pico multi3.pico mulvdi3.pico mulvsi3.pico mulvti3= .pico mulxc3.pico negdf2.pico negdi2.pico negsf2.pico negti2.pico negvdi2.= pico negvsi2.pico negvti2.pico paritydi2.pico paritysi2.pico parityti2.pic= o popcountdi2.pico popcountsi2.pico popcountti2.pico powidf2.pico powisf2.= pico powitf2.pico powixf2.pico subvdi3.pico subvsi3.pico subvti3.pico tram= poline_setup.pico truncdfhf2.pico truncsfhf2.pico ucmpdi2.pico ucmpti2.pic= o udivdi3.pico udivmoddi4.pico udivmodsi4.pico udivmodti4.pico udivsi3.pic= o udivti3.pico umoddi3.pico umodsi3.pico umodti3.pico floatdidf.pico float= disf.pico floatdixf.pico floatundidf.pico floatundisf.pico floatundixf.pic= o cpu_model.pico adddf3.pico addsf3.pico divdf3.pico divsf3.pico extendsfd= f2.pico fixdfsi.pico fixsfsi.pico floatsidf.pic! o floatsisf.pico muldf3.pico mulsf3.pico subdf3.pico subsf3.pico truncdfs= f2.pico comparedf2.pico comparesf2.pico gcc_personality_v0.pico int_util.p= ico Unwind-EHABI.pico Unwind-sjlj.pico UnwindLevel1-gcc-ext.pico UnwindLev= el1.pico UnwindRegistersRestore.pico UnwindRegistersSave.pico libunwind.pi= co s_fabs.pico s_fabsf.pico s_fabsl.pico s_fmax.pico s_fmaxf.pico s_logb.p= ico s_logbf.pico s_scalbn.pico s_scalbnf.pico s_fmaxl.pico s_logbl.pico s_= scalbnl.pico | tsort -q` -L/1s4/release/12.2-STABLE/usr/obj/usr/src/amd64= .amd64/lib/libc -lc objcopy --only-keep-debug libgcc_s.so.1.full libgcc_s.so.1.debug objcopy --strip-debug --add-gnu-debuglink=3Dlibgcc_s.so.1.debug libgcc_s.= so.1.full libgcc_s.so.1 12.2-RELEASE /dev/pts/2 jhs 4 fire/usr1/src/lib/libgcc_s = -------} =3D=3D=3D=3D=3D=3D} Cheers, -- = Julian Stacey http://berklix.com/jhs/ http://stolenvotes.uk From nobody Tue Sep 14 12:36:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8467817C438F for ; Tue, 14 Sep 2021 12:37:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H82sr1vlZz4ZMl for ; Tue, 14 Sep 2021 12:37:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 18ECaowE051722 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Sep 2021 15:36:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 18ECaowE051722 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 18ECan4V051721; Tue, 14 Sep 2021 15:36:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 Sep 2021 15:36:49 +0300 From: Konstantin Belousov To: Guido Falsi Cc: FreeBSD Current Subject: Re: recent head having significantly less "avail memory" Message-ID: References: <4c990632-868a-2393-291b-fe7e2bc1974f@madpilot.net> <9e40483c-29e0-303a-eaa4-86d294403868@madpilot.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4H82sr1vlZz4ZMl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Sep 14, 2021 at 12:25:55AM +0200, Guido Falsi wrote: > On 14/09/21 00:12, Konstantin Belousov wrote: > > On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote: > > > On 13/09/21 19:08, Konstantin Belousov wrote: > > > > On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: > > > > > Hi, > > > > > > > > > > I updated head recently and today I noticed a difference which looks wrong. > > > > > > > > > > At boodt the new head shows signifcantly less avail memory than before, > > > > > around 3 GiB less. > > > > > > > > > > I moved from commit 71fbc6faed6 [1] where I got: > > > > > > > > > > Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) > > > > > Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) > > > > > > > > > > to commit 7955efd574b [2] where I get: > > > > > > > > > > Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) > > > > > Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) > > > > > > > > > > I'm seeing this on multiple machines. > > > > > > > > > > Unluckily bisecting and trying an older loader.efi in sseparate tests did > > > > > not give me any more insight. > > > > > > > > > > The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look > > > > > like a possible trigger to this, but I have been unable to confirm it. > > > > > > > > > > Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could > > > > > be? > > > > > > > > Is this UEFI or bios boot? > > > > Provide verbose dmesg for old and new boots on the same machine. > > > > For UEFI boot, show output of 'sysctl machdep.efi_map', again for old > > > > and new boots. > > > > > > > > > > I shared the data you request here: > > > > > > https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG > > > > Thanks. > > > > If you do on the loader prompt for the new (AKA bad) kernel > > copy_staging enable > > and then boot, does the report of avail memory becomes good? > > > > Yes, it works as expected, that is reports the amount of memory I expect: > > Sep 14 00:24:50 marvin kernel: real memory = 17179869184 (16384 MB) > Sep 14 00:24:50 marvin kernel: avail memory = 16590356480 (15821 MB) Please try https://reviews.freebsd.org/D31958 From nobody Tue Sep 14 15:33:58 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E45A617C9090 for ; Tue, 14 Sep 2021 15:34:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H86p94Ks3z4SQ3 for ; Tue, 14 Sep 2021 15:34:08 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 18EFXwRc026867 for ; Wed, 15 Sep 2021 00:33:58 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 15 Sep 2021 00:33:58 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al Message-Id: <20210915003358.e07554a69c01f6125850b26c@dec.sakura.ne.jp> In-Reply-To: <20210914103736.4dbe1252@bsd64.grem.de> References: <174267aa-00de-6e35-a75a-80be3617b6a1@protected-networks.net> <20210914110246.724cf733@ernst.home> <20210914103736.4dbe1252@bsd64.grem.de> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H86p94Ks3z4SQ3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.60 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[sakura.ne.jp]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, 14 Sep 2021 10:37:36 +0200 Michael Gmelin wrote: > > On Tue, 14 Sep 2021 09:02:46 +0000 > Gary Jennejohn wrote: > > > On Mon, 13 Sep 2021 21:30:02 -0400 > > Michael Butler via freebsd-current > > wrote: > > > > > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to > > > recognize any configured timezone when WITH_DETECT_TZ_CHANGES is > > > not set. > > > > > > For example .. > > > > > > imb@vm01:/home/imb> date > > > Tue Sep 14 01:25:57 2021 > > > > > > Every other daemon also thinks it's running in UTC+0 :-( > > > > > > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in > > > /etc/src.conf, the output is (for me) .. > > > imb@vm01:/usr/src/lib/libc> date > > > Mon Sep 13 21:28:29 EDT 2021 > > > > > > > Same here. After instaling the new world this morning I was suddenly > > in UTC instead of CEST (2 hours difference). > > > > Thanks for the fix :-) > > Before reading your message, I (ironically) wanted to tell you about > your email's date header containing the wrong timezone ^_^ > > -m > > -- > Michael Gmelin > Just a thought (not at all tested), but... #define change_in_tz(X) 0 in line 393 of localtime.c should be #define change_in_tz(X) 1 if I understand correctly. Or remove line 392 and 393 with guarding added line 470 though 485 with #ifdef DETECT_TZ_CHANGES. Old behaviour never returns there. I suspect current code without defining WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf make first tzload() call do nothing and forth fallback to UTC. -- Tomoaki AOKI From nobody Tue Sep 14 17:28:00 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EBDEA17CC3AF; Tue, 14 Sep 2021 17:28:07 +0000 (UTC) (envelope-from verm@darkbeer.org) Received: from mx.coeval.ca (mx.coeval.ca [184.75.211.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H89Kg0fTFz3K0l; Tue, 14 Sep 2021 17:28:06 +0000 (UTC) (envelope-from verm@darkbeer.org) Received: from mx.darkbeer.org (unknown [192.168.211.20]) by mx.coeval.ca (Postfix) with ESMTP id 8BD9643605D; Tue, 14 Sep 2021 17:28:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbeer.org; s=mail; t=1631640480; bh=KaCA46Au+FAfrWm6rduxNFbFEFQIaEeYjiXQ6bzabfY=; h=Date:From:To:Subject:References:In-Reply-To; b=PegaZPCvz1Fu1JkvPfWTVeBzuxB5dbucopcG/wVQEhLpbjYSTYucPzsEqfaJGAuUv n3sW3NGUfMyBtE5KUH3c+iNI8K8YBsoZXRJbW/8NNVBqnzQI4iMUp6BYv5UxBTLJu+ B+kCfUunohYchl5DxFTSkoRbESabH+6ADghis4nE= Received: by mx.darkbeer.org (Postfix, from userid 1001) id 84635470B3F; Tue, 14 Sep 2021 17:28:00 +0000 (UTC) Date: Tue, 14 Sep 2021 17:28:00 +0000 From: Amar Takhar To: freebsd-current@freebsd.org, FreeBSD Hackers , FreeBSD Ports Subject: Re: Call for participation Message-ID: <20210914172800.GA28969@darkbeer.org> Mail-Followup-To: freebsd-current@freebsd.org, FreeBSD Hackers , FreeBSD Ports References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4H89Kg0fTFz3K0l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=darkbeer.org header.s=mail header.b=PegaZPCv; dmarc=none; spf=pass (mx1.freebsd.org: domain of verm@darkbeer.org designates 184.75.211.21 as permitted sender) smtp.mailfrom=verm@darkbeer.org X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[darkbeer.org:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:184.75.211.21]; DMARC_NA(0.00)[darkbeer.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[darkbeer.org:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:32489, ipnet:184.75.211.0/24, country:CA]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Please count me in for this. Thank you. Amar. From nobody Wed Sep 15 12:08:05 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4C5B217D561D for ; Wed, 15 Sep 2021 12:08:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H8fB26HkMz4rxq for ; Wed, 15 Sep 2021 12:08:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 18FC86Sm089011; Wed, 15 Sep 2021 21:08:06 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 15 Sep 2021 21:08:05 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: Edward Tomasz =?ISO-2022-JP?B?TmFwaWVyYRskQiIuGyhCYQ==?= Subject: Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al Message-Id: <20210915210805.957f327d0ad38f59062f7025@dec.sakura.ne.jp> In-Reply-To: <491ECFA9-FF9C-4ACE-BEC0-262E94A404C6@gmail.com> References: <174267aa-00de-6e35-a75a-80be3617b6a1@protected-networks.net> <20210914110246.724cf733@ernst.home> <20210914103736.4dbe1252@bsd64.grem.de> <20210915003358.e07554a69c01f6125850b26c@dec.sakura.ne.jp> <491ECFA9-FF9C-4ACE-BEC0-262E94A404C6@gmail.com> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H8fB26HkMz4rxq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.60 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[gmail.com] X-ThisMailContainsUnwantedMimeParts: N On Tue, 14 Sep 2021 21:49:28 +0100 Edward Tomasz Napiera$B".(Ba wrote: > > > On 14 Sep 2021, at 16:33, Tomoaki AOKI wrote: > > > > On Tue, 14 Sep 2021 10:37:36 +0200 > > Michael Gmelin wrote: > > > >> > >> On Tue, 14 Sep 2021 09:02:46 +0000 > >> Gary Jennejohn wrote: > >> > >>> On Mon, 13 Sep 2021 21:30:02 -0400 > >>> Michael Butler via freebsd-current > >>> wrote: > >>> > >>>> After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to > >>>> recognize any configured timezone when WITH_DETECT_TZ_CHANGES is > >>>> not set. > >>>> > >>>> For example .. > >>>> > >>>> imb@vm01:/home/imb> date > >>>> Tue Sep 14 01:25:57 2021 > >>>> > >>>> Every other daemon also thinks it's running in UTC+0 :-( > >>>> > >>>> When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in > >>>> /etc/src.conf, the output is (for me) .. > >>>> imb@vm01:/usr/src/lib/libc> date > >>>> Mon Sep 13 21:28:29 EDT 2021 > >>>> > >>> > >>> Same here. After instaling the new world this morning I was suddenly > >>> in UTC instead of CEST (2 hours difference). > >>> > >>> Thanks for the fix :-) > >> > >> Before reading your message, I (ironically) wanted to tell you about > >> your email's date header containing the wrong timezone ^_^ > >> > >> -m > >> > >> -- > >> Michael Gmelin > >> > > > > Just a thought (not at all tested), but... > > > > #define change_in_tz(X) 0 > > > > in line 393 of localtime.c should be > > > > #define change_in_tz(X) 1 > > > > if I understand correctly. > > > > Or remove line 392 and 393 with guarding added line 470 though 485 with > > #ifdef DETECT_TZ_CHANGES. > > > > Old behaviour never returns there. > > I suspect current code without defining WITH_DETECT_TZ_CHANGES=yes > > in /etc/src.conf make first tzload() call do nothing and forth fallback > > to UTC. > > Hello. Sorry for breakage (and sorry for not noticing this thread > earlier; some day I$B!G(Bll figure out how to convince GMail to not put > mailing list emails into mailing list mailboxes when I$B!G(Bm Cc-ed). > That$B!G(Bs exactly the fix that got committed. Let me know if there > are any more issues. Confirmed fixed without defining WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf. Thanks! -- Tomoaki AOKI From nobody Thu Sep 16 20:01:16 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8355117DEE8F for ; Thu, 16 Sep 2021 20:01:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9Sdl2mq8z4bsr for ; Thu, 16 Sep 2021 20:01:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631822483; bh=TgkhA92BtdsIwBtir1QHN0G3ZOrcN3KVjvm7xs4ZRXg=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=VAmq9be0Fj3MxZeJgafKnVZMHvor8b2YIhADdn1xLpjrfQgNS4zNZ58a/2277mdELlPDcu8Q1TAjbXs1qIU7xmBvZbGmNzoOxJPdgwqRUHO7JE0RsaaSowVWc+x2cKEHU0jmxStXwThW4DVNJSIg/Sp0U49qFDivvJsC67OTSxxZG6GQM+KPBjeYwXqOafgbotte8dK7iQSRLZ/kixI3F7t1s4Uximkb3jdCYJWdAo0e5N5UCxWmvKEaPvfBVYgOZFMmoT2DSw6jct4wlBpo124YvKJ0P2OszVqoaNAI/lxnnz3sDdvbkEIUgsDygeYXMSZC/gpRF4VGfXdVPyKP0g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631822483; bh=hD/bAgrX3f0IF1NihUT62oFS3Qt84zhVuydElyckNym=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=iJ5nxQpaAaaKiTxEOIR3LEAbwPL30/0ELQl/Crirqm7sr6CLV/Nqtiazt13saHrEtCdCARZrtYaXFn1hmPRhFU9YbnChqcNV81BF1xmILumoSWBzW513qWz0z2P/wmCbIMzwa2n9QJUbdnhnD0Zya102N/mSrU+Sy6DsRE8O2FYCocZqFzgZirhOxU7py1pOLBqcoe5X36nHjl2kIARTrtSQA18iGiM/7RzTRwPhGkg0i401AAb3RrJos+Fgzfo2GGtBZgHM/PdaCCPOlfO/WRwesqgwfB0gViIpGNJSxtGyySG44g40Iynpry2Hs5IlLWd0MGqcUKUo1lUrvZ8AZA== X-YMail-OSG: WOXXoLQVM1nCl6DqhS4OGez257UEksVJIOOK6f1X4N.zoY4RF5XtvVIn_9cXHNf .xZgMWrpS2w.qyCu.C6azkD.Oj9.ql5uW.uH1KFMW3V5686ZaPtEeDYU1i9UUbUWhjVYmGHWIZA5 v0FsJMB3R8zK6x.mGTSUdkJRftVuBA0Zi.YGQjPnF.JG7cRAQYWHIpcYCElp7FG5VsQiTHLdmhzt ATgVnV0g1rEvAZrmEswvTnhvDea8bHUR5aWRq_9VAR7Q5dbsv.25Y98mGoYyrtBg.Wyeq4vBZ20n iEO02q7U_.CGQ8ktU7uq8pE6Chk6kWxRaItCTw33gQOGtJm80cP30.pOZLNmx.THeUlNn_DmfWiQ 38j9JhaVXZkMunihrVhFbYCKRZAUOXLsNcAyQAS51gA647P_9inzvWsfocuJGEsB6jHCYIJAFiZx aGgy8xBL_0pggEZINrtm.jyzjkb70VPEAIgfwG87up4MQOKv0bfIcLX2N.nkuw6ZPAFc.XTn5G8W _sAsn3UqV9Hp8RPr.WljtLip6Jyd82EniXy1_UaSRrT35henHNoDd2VDIbWoqQgzAIoXsCEyI.H2 Df3KsADlBpwcnZYKyZTbKbq1XY02JJm_tbcqqsiAB0RzW2iD.xhS6kw8VD5Z8o3b5MJO7yetBEgL 13DGD6e9MTNoBjbcqk2HKtnpEGLU8AWbyx4p0QSeB5D3GDnaTCGxJDKbo9qq5R_ouTGON5BmeO0C XJRNafeBB4LiPCbiPAXMXskMZEsG.wIXWvFSBetVj3PNvc6OS9ccpnxMsGWLyTufAZB84skFChGm t9cjQf0HVuaxccGGuwaWOHGrtR644DCKk1bLG5RIoku0PUpzMk_ehLqgfLR9.5DaIKfKqO7QEESD QXLfzuDvGedhGvOJvQ0t4xK3cYJRC2JbShgRDDDQxa9bNQ6sUWTxeIJK5tYdpcpfUQAK5QAtBa4c DZQvG2xKtHD18PPudvkjIIUF3E0LoV4DTTwfcH6s5sMryF77UeeGoho4nokHh7ZBKKPLvMQqKBJA e3T6_CyD5FShUgpYm3Y6vNyvdROxgNnkRn5Q8y8InRae48BVpw0R3wEIG.LTKvTWPaBT_YorRb0U mmv0zeRvDQz4w5pVQWT8.LjRApuKNx8QvFjFshLxp7q.kw5Lma.SLkkvFWM3w.ebXqTS5vDBvap3 9Z_imTYovqOx5z1ZUDNnDRu0mNOnt1WWQnL1A3nxxYhJSpGD68hCSFZfVWelsQwVnV7Lhd7pCLS_ 4zFwi_71WbWj5ELdCVU.hYIkl9GOPeBBhBwaBRWXCv02BWLboFNdXJ7waumyHsatqgcwlCr9ivsJ pHGjP.pZibql6KwRHUBpt9hn3tX2NVgAPXbckOUOww_YP_mXbjsAvI5O7mrVLcWmgNCIdeO0pGUP YgVEzpnN0i6ITr2hkmnI5bQazgZTcwsEDsAPuSK6mQGzeAVuwpueCNpzZW5stxPte_uvgLYxoo2. gpBVXO2kXBrlvTkc8GondHI.UJ5lQZy02rV9_5FTX.2DtFt1vlm0jCilSouDXGTK9Oxo3lBa2oh. B5SQPshDdwcQYyCFCjprjNEsrwwggat2jU6Y4Iv2S2fS9l1_bLPtKrnUMMNUFSbueUHSEGT2ejZn LAUZoe4QJgMi3NkeXZKJmw5wEsGZ75prUlzW5sbFDIW9aLfrdl0CiRr3QecAlzDeWydjwok7jyte WuoJP38mdxm3_56YibZXiepgwM2HG7AjBqUkbNZ8fMp6AIrPI6Mz5NvztFlBa3Fp7i4KPyPd_Ifj ZekoEH53r42.mRbNCogknMP9.R365AkhS61W4Glzenx3aWv49ItTFh1ZMQwNKHjdyrf1Mcwr70OK 62FLTFUMnREba5NBzLS5XIftbMO8D3hIIFtbshgaczfuKBIwsrq1J8YsRjivMOMBq._lo_XNbXih _Fcbk0jHJsE4BkfYkmAqgi6zl7TYm2MUDHDa9HKcdScvwknMhOQYCd3pfh2mG1hReTvQQ9pLNgEC .0NNbDTJjTatmt_dDVisl9o75ZOVlC2lodPqi3FeTBhehQoeSaI0nIA4RUV6b52qNqRtEGCNKkyM S1CRlmrGk_nCQrv3rXq6NBq9cSqhP3HFgWrLOVf8lEFq7EsNkhqNzr2U3L4hUWWT5Xe4T1mYTmie xFE6plcbuiWrJ6NqGLB8BjeUa08.H9qz1DHpZ4Xt0Mpx6TF2CjBGcFFRKVbhxplQMZ0syxjxeLYs sUWF4rDr9T1vN7JXnhdwrHaEvi7S4kHe1wF6qNUI.5cAo4.iIfsXXZ9VkOZ.S9pvBsYuYqjpa0og AZXAOGTCGbWFkzwRvf1UiAon9lKybiQ6YbgnzRgnGbC3RUXM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Sep 2021 20:01:23 +0000 Received: by kubenode518.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7f0c691e87d2c3f86b92e7cacaaa9419; Thu, 16 Sep 2021 20:01:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" Message-Id: Date: Thu, 16 Sep 2021 13:01:16 -0700 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4H9Sdl2mq8z4bsr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VAmq9be0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N What do I go about: QUOTE # zpool import pool: zopt0 id: 18166787938870325966 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E config: zopt0 FAULTED corrupted data nda0p2 UNAVAIL corrupted data # zpool status -x all pools are healthy # zpool destroy zopt0 cannot open 'zopt0': no such pool END QUOTE (I had attempted to clean out the old zfs context on the media and delete/replace the 2 freebsd swap partitions and 1 freebsd-zfs partition, leaving the efi partition in place. Clearly I did not do everything require [or something is very wrong]. zopt0 had been a root-on-ZFS context and would be again. I have a backup of the context to send/receive once the pool in the partition is established.) For reference, as things now are: # gpart show =3D> 40 937703008 nda0 GPT (447G) 40 532480 1 efi (260M) 532520 2008 - free - (1.0M) 534528 937166848 2 freebsd-zfs (447G) 937701376 1672 - free - (836K) . . . (That is not how it looked before I started.) # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 = releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 I have also tried under: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 after reaching this state. It behaves the same. The text presented by: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E does not deal with what is happening overall. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Sep 16 20:26:16 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 69A9317C55EE for ; Thu, 16 Sep 2021 20:27:20 +0000 (UTC) (envelope-from joe@via.net) Received: from smtp1.via.net (smtp1.via.net [157.22.3.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "via.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9TCX1QNZz4lpq for ; Thu, 16 Sep 2021 20:27:20 +0000 (UTC) (envelope-from joe@via.net) Received: from mail.via.net (mail.via.net [157.22.3.34]) by smtp1.via.net (8.15.2/8.14.1-VIANET) with ESMTPS id 18GKQQot028003 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Sep 2021 13:26:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at smtp1.via.net Received: from smtpclient.apple ([209.81.2.65]) by mail.via.net (8.15.2/8.14.1-VIANET) with ESMTP id 18GKQQHU013218; Thu, 16 Sep 2021 13:26:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at mail.via.net From: joe mcguckin Message-Id: <88799C4C-2371-42C1-A41C-392969A1C1E0@via.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_F8FAC72C-E5C8-4A65-BEDB-BB6BDC7D2E94" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" Date: Thu, 16 Sep 2021 13:26:16 -0700 In-Reply-To: Cc: freebsd-current To: marklmi@yahoo.com References: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (smtp1.via.net [157.22.3.5]); Thu, 16 Sep 2021 13:26:27 -0700 (PDT) X-Rspamd-Queue-Id: 4H9TCX1QNZz4lpq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_F8FAC72C-E5C8-4A65-BEDB-BB6BDC7D2E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I experienced the same yesterday. I grabbed an old disk that was = previously part of a pool. Stuck it in the chassis and did =E2=80=98zpool = import=E2=80=99 and got the same output you did. Since the other drives of the pool were missing, the pool could not be = imported. zpool status reports 'everything ok=E2=80=99 because all the existing = pools are ok. zpool destroy can=E2=80=99t destroy the pool becuase it = has not been imported. I simply created a new pool specifying the drive address of the disk - = zfs happily overwrote the old incomplete pool info. joe Joe McGuckin ViaNet Communications joe@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current = wrote: >=20 > What do I go about: >=20 > QUOTE > # zpool import > pool: zopt0 > id: 18166787938870325966 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > config: >=20 > zopt0 FAULTED corrupted data > nda0p2 UNAVAIL corrupted data >=20 > # zpool status -x > all pools are healthy >=20 > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE >=20 > (I had attempted to clean out the old zfs context on > the media and delete/replace the 2 freebsd swap > partitions and 1 freebsd-zfs partition, leaving the > efi partition in place. Clearly I did not do everything > require [or something is very wrong]. zopt0 had been > a root-on-ZFS context and would be again. I have a > backup of the context to send/receive once the pool > in the partition is established.) >=20 > For reference, as things now are: >=20 > # gpart show > =3D> 40 937703008 nda0 GPT (447G) > 40 532480 1 efi (260M) > 532520 2008 - free - (1.0M) > 534528 937166848 2 freebsd-zfs (447G) > 937701376 1672 - free - (836K) > . . . >=20 > (That is not how it looked before I started.) >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 = releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 >=20 > I have also tried under: >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 >=20 > after reaching this state. It behaves the same. >=20 > The text presented by: >=20 > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >=20 > does not deal with what is happening overall. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 >=20 --Apple-Mail=_F8FAC72C-E5C8-4A65-BEDB-BB6BDC7D2E94-- From nobody Thu Sep 16 20:39:08 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A3A9317CAD90 for ; Thu, 16 Sep 2021 20:39:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4H9TTV46bLz4qrK for ; Thu, 16 Sep 2021 20:39:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f45.google.com with SMTP id x10-20020a056830408a00b004f26cead745so9945197ott.10 for ; Thu, 16 Sep 2021 13:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iCcvONmgHU1B1z+j82umw8gqHQ/1mq4KSMPEpVGSkPY=; b=bd/J8tVL+sqfr/c0FlYARDi/y7lTiqS+6yh2bGKFC3H7/dESnMB0JDFrWHWMOmx1Xx QEAPLRz7h1r0aUD7EDWcdFPrWFmF3LdLS2Jb/tzg4nIYof6XsmJ/ftiYtFLR05S9daUH Icd4OCBnsgxmLH3ea3Wl6YkUUOj5U17FT2Ltw+dTh7UBkAoHXNoZ9OWnAUSga0RaWHrB 904REictiYmer9dB7MjEs1lGOHhzh7lQiTTWM+dkbxUeQh7UBc/fdAH2/lZ2y1xkO/tw DAEKmkMG7a+b68RPCoNa8Dr/I7j3In7YnaLZFEeccIM86/cIjdNXU3JrEQHvrdm1uXIG xpRw== X-Gm-Message-State: AOAM530OBr/0IRYwo1AJbfKaPaXsN2lDJJHLjXZPkZJfJUea7ZJkb1CE 6d7MvuMApSjz36DLgqz2XG+g/arrJu3r9otzeXA= X-Google-Smtp-Source: ABdhPJwx9mAFQHxlsnxZLpTt+PD57LS9+Q5swTDJSIIzfaHD1GoF7b1w9rWhgoBRtrcqL/o8RTSycA0Rtg8KZ2VudoI= X-Received: by 2002:a9d:411d:: with SMTP id o29mr6419091ote.111.1631824759970; Thu, 16 Sep 2021 13:39:19 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 16 Sep 2021 14:39:08 -0600 Message-ID: Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" To: Mark Millard Cc: freebsd-current Content-Type: multipart/alternative; boundary="000000000000275f3c05cc22cfa2" X-Rspamd-Queue-Id: 4H9TTV46bLz4qrK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000275f3c05cc22cfa2 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > What do I go about: > > QUOTE > # zpool import > pool: zopt0 > id: 18166787938870325966 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > config: > > zopt0 FAULTED corrupted data > nda0p2 UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (I had attempted to clean out the old zfs context on > the media and delete/replace the 2 freebsd swap > partitions and 1 freebsd-zfs partition, leaving the > efi partition in place. Clearly I did not do everything > require [or something is very wrong]. zopt0 had been > a root-on-ZFS context and would be again. I have a > backup of the context to send/receive once the pool > in the partition is established.) > > For reference, as things now are: > > # gpart show > => 40 937703008 nda0 GPT (447G) > 40 532480 1 efi (260M) > 532520 2008 - free - (1.0M) > 534528 937166848 2 freebsd-zfs (447G) > 937701376 1672 - free - (836K) > . . . > > (That is not how it looked before I started.) > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 > releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > I have also tried under: > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 > main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > So you just want to clean nda0p2 in order to reuse it? Do "zpool labelclear -f /dev/nda0p2" --000000000000275f3c05cc22cfa2-- From nobody Thu Sep 16 20:56:16 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3354317D513B for ; Thu, 16 Sep 2021 20:56:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9Ts73kVBz3FFy for ; Thu, 16 Sep 2021 20:56:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631825779; bh=KmrhPB2ARfz9NNKsHBeH8VO7/VSYkSxa7sjyNV31y2o=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=hsJu4OQe5EAol61GV+WhDjrOF1NGMhoO9T0sJ5gg3V8T0n0EOESyvZX91lJ1ewzBk5g7J6++E4p3nYwyORgFdFN5UCTGgF5ZKTtg8hZIG1DzNBx3BXx035S4N0Q7y3effI5YvJJbU7riSyy0zBUpqaGoqiZIYXm/fdvwUewyd2IJryKs16e5TjY6CRwFcTilhOLpjkmtZeIPo3W/3438GMm1aaKtl6IFDpkmZfOIYH5UqZ5xX9+iLdhqelRNsOvVTc0VrsrTBo/gHOUfMTgbpyq6TBKEXeGgeJsCQczMc1RYJlRhw21ARzHKcXll6CuzGjCM0L4NTLU6sc9uvzwVgQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631825779; bh=WHZkcpvtnI960cXBR7T3ievPUFUJ+tvq6RuDOh32czi=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jROxKSU0zHwpX02XnK+opYBibZlG88FYccklxUJAdcKLzeESG1Xhz+dsqMaddOg7rBKPhdbkvBBrZnaJpwlROZ2fR4u8Bjl2cj+IjUWiSJBELboa9J/9k6VYX1uUWGNCN8fbRPNuEO+2tQ41HgfNTiNY2RIyz1t82/8Ef4UAk4uY6rPM6Ul27NQLiasoGwkbcdwq7Skx5eKP9IjBHstJK4GWHFGUk0nfXKmD6FTLoOT7CDjwkCWwJbIP/+BospQFCdTin2Yz3+3fJOO20lOXfQTHFZElXC5zF7iqbSEJZ0RxVpvbr+fvipHSaF98EEfSgllnVB9iGywhrqPFrDyGRw== X-YMail-OSG: 9cRiqoIVM1n7oe2JIlYQ.fTAVrcIVDqUHitTsGyj_mwncxkqlTlodLohh2PEqm3 .oCEorymewF40aw_C1oGRGHXGDwnY5yt7jxNGtWIKVaC1BPboNyypjeglGyjsHCwBEqwlJQWCZuL j.YX9ov69Is7g7X5rPFZ0511f8guIaQTNS.T6qnfBhDEwBWsOZqFH4Bl7sRxVUQ7LeA3.c4iXqQr 8OfszoSY3qDI9WvIhN9txyevr.kEnp.8WuP6Tr6d9Cu0P2FG4hK2MIMb06U66g0MGNvnUhF2BNXw HfTUuzi_XJAW.c7uA2gPpmmS1AajO.kB4IajbANCp7ZAGHTWe2dUAoIam0_COmCqqXkUwvpTMs6A 483Y4XMSL.9H5odZNkZVWc9NQZ5bMURCfmqeEHN4F74qImGnz4fVguVD.H_MyxrBy1rwlbS9KK2Z H7eRaByqV3vTH7QN_ievkgpyEOmQ0pkcaB7JqzqhYT8694z8OkZYKQsOFwR2kRc5kNSHx2_hHIyO 0kkKDnbc0xFL7aWXtu.fwiYjIneE0shm6o5jhHDFS6YdeIajEEwZL8JjYUpzpFLPVFc5i395iC.2 bN6oPOHk80qQ98CYqx40pTHP0hY1c0v_M5JWu5jzF1HunyjvLAkkZldoa5wOuCOHWUihHEilcmPC vy.wZgRvIJxtSAwWzHJoO.rVcnMNAm5GzB4oFIPuh5h6OTL44dlxqO5zzMM2DU6Q12HizAohu56U adGX2TBWhbJs3UWZ5rLrPDSmmwUbum59sH.lfya57rourbKcM6d7SoONYPl7R30siXMh04Bm2hF0 mqt9qxqBzGsFChw4I2ymBWAY2wsTu1bNYNPsC2E55NufqdEPh1M5txWtFLudl2_Fo4CHiZge8bR7 SjG2DWxS2vfqUymVsEQoPX7W_QdBkJNRbsEWtAwhLo7uLe_jMbWwA1LvQ_ZACCZnhUG3.Oh6Ufk_ sU4UdPlJXjPkmCr5EXHE02Su5zY0b301Qr99KKYkXyEsbKCuqve2TesBKrE2L4Qm036dfuHMhPuA 5ZJbjHz3pIW9zZPCSumu46ZWQdzcWiOicocyH_414UOM6ZuvF8nPwHL_Kyp.ZtqnH9KMSHDSooGI 3snQJQVUXOZvNb_y3pXWngsWF5e6fwsTfAKDbaUnAe4t8zhLinwoRAWGej1FKtm6jgsuizonFlWx JfBVBpbQfvALxcNEWGcCd_UG1HZBwSwn.H.H_aR7u9z2dq86vObrANfdOMC29pSlWRQIAlYmNAZt bJzxE15FOkuK5_GZczDBM2JElvtYK2.jP97dK3kFUHdPjar9IqLEbR9ZuhyvR79O59K_43My.R5j jaOBTgdEBnqpSGKw5zioiwWzCQNC1dQ_jgmE1LkQbCubykVoJJ6vt_MWcWszTCvKzXMJBFFqDlE5 ZZ5wKAovSdTWhHSxr8VHZHSHE7Y4MIiOuvjVNitBlemt4fk3rnjK00.PkDIFOKsjxkK1OXBBR8kQ LrNzItcgnrWITshvaRZWKgPw2NKlpeBhjdIK9Eyx2dgYoKrOCWXNYVtRrPh6xsDc7RwieMBJbV.O ZExLf6veHp4UGsuThfk6diB_NJ3cz5kTOQWdjZUPnjnCY3srEebIz56k0rkdTujqbhSjawyNnvj6 RvwaefGCd6eTKVE6C4s_6nEfnIY3ORSMKuhFiRJ_U3QYD6lQj9xAJ8SCV7xX.yitxpbtt1lmI_TW m1y4NkYXG2elidjqGN256bjPXQn_88J5yhztcijEUQ0JzPjPK2zODPCy3Jm31YiltWthiSAkKCg3 beDO.jXQdQBh7.E_59nYvR_82VANb..6PxC3LrAioAldse1vekY9JaRycEQ5m9UaPDwrp2X3JqHd 5IQKQrksSNJU59qSQrlAIkA5HX5ibKhbRHFRX5nwEVShZxQxFMBztH04SxscRYXIMOS8EpXAspbt tM95iTUgXB8G9LZPqIO9zYrMdk00LUQ0j_.GKQQPxK73fDNRm2YFw.fRRxSg7Icmif9Pj3fUuOw5 xwY8zsRYU641_cH5KSl64mcyznA3Zv2s6AD9sICRqfxFd2NxBSrMdnZr.vqYFKtNFW8ZOlkMP9RU tdwTUrfOAbUJ1N81wmBjvM7swgQusCqqOsk4rUWApxkl0GBcY0FaVnyyhW28y_kbFULobhCumf6Y QCp4SDgtFhuBZlspTbnnDkESH0GQ55Hh4A_tyOOxJcZmmPrrKS7i1OhVoeI8kuPimu_ddlZX0YeA jyKZUDcwn8zVoxCjtNOyeXAOoT8UpG6N9cG55sRNzdcuIIz67vUFx3DgRZ.iWhymZfOYGdekJ4Is - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Sep 2021 20:56:19 +0000 Received: by kubenode516.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f4df509ef9df79259376d40ad5f5091a; Thu, 16 Sep 2021 20:56:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" Date: Thu, 16 Sep 2021 13:56:16 -0700 References: To: freebsd-current In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H9Ts73kVBz3FFy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hsJu4OQe; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-16, at 13:01, Mark Millard wrote: > What do I go about: >=20 > QUOTE > # zpool import > pool: zopt0 > id: 18166787938870325966 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > config: >=20 > zopt0 FAULTED corrupted data > nda0p2 UNAVAIL corrupted data >=20 > # zpool status -x > all pools are healthy >=20 > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE >=20 > (I had attempted to clean out the old zfs context on > the media and delete/replace the 2 freebsd swap > partitions and 1 freebsd-zfs partition, leaving the > efi partition in place. Clearly I did not do everything > require [or something is very wrong]. zopt0 had been > a root-on-ZFS context and would be again. I have a > backup of the context to send/receive once the pool > in the partition is established.) >=20 > For reference, as things now are: >=20 > # gpart show > =3D> 40 937703008 nda0 GPT (447G) > 40 532480 1 efi (260M) > 532520 2008 - free - (1.0M) > 534528 937166848 2 freebsd-zfs (447G) > 937701376 1672 - free - (836K) > . . . >=20 > (That is not how it looked before I started.) >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 = releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 >=20 > I have also tried under: >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 >=20 > after reaching this state. It behaves the same. >=20 > The text presented by: >=20 > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >=20 > does not deal with what is happening overall. >=20 I finally seem to have stomped on enough to have gotten past the issue (last actions): # gpart add -tfreebsd-swap -s440g /dev/nda0 nda0p2 added # gpart add -tfreebsd-swap /dev/nda0 nda0p3 added 7384907776 bytes transferred in 5.326024 secs (1386570546 bytes/sec) # dd if=3D/dev/zero of=3D/dev/nda0p3 bs=3D4k conv=3Dsync status=3Dprogress= dd: /dev/nda0p3: end of device972 MiB) transferred 55.001s, 133 MB/s 1802957+0 records in 1802956+0 records out 7384907776 bytes transferred in 55.559644 secs (132918559 bytes/sec) # gpart delete -i3 /dev/nda0 nda0p3 deleted # gpart delete -i2 /dev/nda0 nda0p2 deleted # gpart add -tfreebsd-zfs -a1m /dev/nda0 nda0p2 added # zpool import no pools available to import # gpart show . . . =3D> 40 937703008 nda0 GPT (447G) 40 532480 1 efi (260M) 532520 2008 - free - (1.0M) 534528 937166848 2 freebsd-zfs (447G) 937701376 1672 - free - (836K) # zpool create -O compress=3Dlz4 -O atime=3Doff -f -tzpopt0 zopt0 = /dev/nda0p2 # zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP = HEALTH ALTROOT zpopt0 444G 420K 444G - - 0% 0% 1.00x = ONLINE - zroot 824G 105G 719G - - 1% 12% 1.00x = ONLINE - I've no clue what made my original zpool labelclear -f attempt leave material behind before repartitioning. Still could have been operator error of some kind. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Sep 16 22:02:48 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 73F4317D2316 for ; Thu, 16 Sep 2021 22:02:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9WKq143Rz3pb7 for ; Thu, 16 Sep 2021 22:02:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631829773; bh=G5La6YLccKrDnBc/dgV2I5DLldkBiIHsNct+K3SGFdA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EJKKt/HfODnF2/sYhGETEJ48P5lY8dauKTlr38MeOLSSwQP8VtClDf3NvWjESwz4ybXxUz3aduk4kLNCnlVGMxlp7rCL8UmYsa3vPPWezGllyd5V7wmnOyzGX2WRl+oEjhOMW0i31aJhgl0htffAtbMLHw7Hix3YZcnIzQtxeOgqMO+cxTt+iMPso2MI+zEiKe7HwXOtCjxQ29GPF9S/yKcqCV+CKMyzuJMjBg7c3Oww9vjZyiAceumbkfDczCbg1LfTIQlv4CkgyNuG36Q+TZPaUuqRSgq0Q+iNXKzVq97WUXjY3HIwtLSheLCaSKRyvbi6LDXGOoU2Fym+0MueRA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631829773; bh=xdYPfyJ7r058uFdeX86LWkR6z0DEPA6XqVMjOTT2WhR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EM6zYKfumgfDvRPfGG5FXTy3FdwryajFWuMsV1uHSvDR7VNlGrJy858p1oqs/evc3qkkCnt/vtWgbA+rGNVoqkeGvknioN0xiJicA51DTTzwO0pLOTDbIDuEiYtvebebFNkk4HIiLidTlI2DybUgqEWrKpjqkpASNCASi9YSfM3gXdaRK13vqwAvJxWa9RR/vgXlsc7mPqI3sv7U/okikgUhkl9yR5jvyrPlTZLYBjksUinjuZwnrXNQNFFUygdrrX6+G8AIlD4NyZyTqVHSIO7gZBn1PdlWd5nGu/K3gox6lI/bwjcQl7E8OPeY6P2vK7Xt89yc5or9zYVqng1TiA== X-YMail-OSG: KnYmGgwVM1kc.RZhy4vGu9B.hNjC4iYyNSe7xB22XMHGC82IlNP7P.NOIvut4Yf 9SWpXRkPpN6lAeYC3dRTfKVYx1Ah2V1OPrpJBMbcYwUietQ0WugFg_7nIuib9OC6wDKRcPLamtzu 8dEMyjmBClw3G71NDY7wuTH6MG7hSSdV1zlGUHnIror4HyzaC5EAlCX9vyP_ZlBpQDCmqwDrjDSu JFSfhNz3hm2XtlyYZhdFzv_EgBvI2jXoOZLNvQXxXb7Y5P0aSxIGmeUqPnWMFgYFPqitx7cOtmOs XI.McCBrkvobZmHkiGqI2VZUXmZHZ8RIW1Sye9sKkw79u.6fWJMQugbgxls9H8R5BRYYwt3eSNi_ oYn_oQtV.0pv6nLbstBgi786E.9bBXxRE28.6V94mz28wZKfTxHuLodGwjZmgDr0BRu3fEv5e.dq R4PI91pmmzDBVDnyY7wP9NwW.JFFw7asnR.ETUpObxjdPvc2YuyqgKzFT4ut0mMP2FzasfyEKuc2 nZ99qa3SgSmZ1d7yKefGERolWA8437Ji_ExtwG8fMY4BiwYmj.dTk5UrKcDHOmrhIAPOVf2oYiMB Br1sSTUImoGvnsVZyy0kibVESOuzzwxYNCNTw0qTbuvNC.5MGOkm_45mJJ7.EFrSAkK.EUR9WOcT fswLuUFdlydC_HRQPks__jptE.8f_juXFQVYvieupqxlIWR_VmvdGyIuDBBRhxCAzSV9jLwn3NNn HqwkCcwIzrL15wypd4lrrMnItZI21Oz7BJ3Kro2ZWJRD76tRaJWTvfSoafm364olZzUUvq.jDD6f 5jsD37jJ0H6RrxN1n8xXpHd_7msp1uCJZ_NsgX_DtiyD2IR7r8IrY3Kmoa..RPlRXchyYlH4z5v4 XySZVysXnTvHR72swMflBSmg.o3H3zDcnfKt.RPcCN0RbNQQIvVn1AfJUv.cb_LhkT2MduRBR0aG PFC8hpAbqcWZZGsCb2FggoL_r7L5F3nhOZOZcq0kw7b_vUmk9Q3cOdaQamksxpCSAxIsvu9d6Y3M UrWXUGpCiV8tnanZ75hXpA5eOcIAlHwP_Wuc8O0xuaIL7g15zAdcktNpzuHQnx3VC48sSobw15GF Gn.PyoOM55MVKszAcWw_2dqcz07XhXeJf8WeHcCcNVXbMUe5Iut5rDvJmHr1TvmXGtMTbz8H_R1g LW5WzFvwH1lQIlYTksHPHkT1fX6KMsEL_971.6w_xPegkgD078vfY1XAcgVmkKRzt50NE1cQSH.E sk_1oy6jL7wCh2w5qGBbI.gkChT3zwlgl_N7A6VaYfokv19zmS4UvE1ZTNuj48aMG0dKFZ3JFfZT D5XMZw5Sr0_LM2rpyJl1Rxn8jTqvQKxHYQPhCjKbAhE44TdGVxBC1evZE_Aj9t9Fl_0Z3xksQ49l oqA6mFPHm7_LJDhgOiah8NW.EHT6GN1hzgdJIKcT5I.y53k2oVYVQp14DDkiVkwprroV.QqCqUyu rYoe0N_nBD84JqgJwBvB5gVOxkDCfD6BlOjyGUIfAqvLJqF4DOcjMAl5pVzaIUATz.VyuXL9pqjN kAab4BQc8.cmJTpYvMl4bR90K7623Hf65rBWjyOYBfgosNiSSWYzi3puvDu7VO2sXyFyy.GnvSVt 2cltWYae3SmV8.JxsjaKgRM7n_hBl.9sgeoQx4Vm58.nS8ml6BJx3z75vqT3hBffxmHo4oj6owWG gYDWsLkcw7BPFFztJh1LEIvCSfUzdGIuywYLK_fay5ZX7nkklELf9x9Iwqu9Letn9veQrtsX3iok J3kq5ndHTCG5wTTpJmaFhNmmNTmErFzteynJLvpOY32iWfafs_FMhVutgWuIK0bQzYuROrIzq1uw C4OXTVi9mHSoxuWi2oKJSrc._z_m3c344JseRegrO9Y7niGgnrFWsf9RjL.Zz8zjWK8UapRlydpJ OkJB89OTliBsGEbkiyUAKpCy5Okw1l_u1xngaCUb2kR2Iz_vYQS3VCJh2UVB.Wb9_OAXiKh1Jege 5qkTYunpsa4aLWRevbiJ56YeZZ1f5iwZU09kLxGRg3VpPFipapRr7pcyY.aPNZkXc5JTBrHdkFjs JH8n9jn9sH8coyJoeNhhsrqA_MGGM_VHM5WthWPI5YxZsCdg9Q3X3.jNEW6ecXmU6wJ1pdwRICys R_4kAtKMaH99JLhde8NN8FIOZBD_XZ.EqfyEtyHAexgd6NQcmMwIQfoznUmnNWI4eWBjbP3Am8l. 8avryazGZhxn2PqE0lFhEX3moVVN_32Z0AmMkOQNjAQ.4ir4ppEAbJ94GgLjY7qOsIx0B0kDNR5P Iz3BGHEBWle82 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Sep 2021 22:02:53 +0000 Received: by kubenode504.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c77f25ff480d00820c3aae5e498e4b13; Thu, 16 Sep 2021 22:02:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" In-Reply-To: Date: Thu, 16 Sep 2021 15:02:48 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H9WKq143Rz3pb7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-16, at 13:39, Alan Somers wrote: > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current = wrote: > What do I go about: >=20 > QUOTE > # zpool import > pool: zopt0 > id: 18166787938870325966 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > config: >=20 > zopt0 FAULTED corrupted data > nda0p2 UNAVAIL corrupted data >=20 > # zpool status -x > all pools are healthy >=20 > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE >=20 > (I had attempted to clean out the old zfs context on > the media and delete/replace the 2 freebsd swap > partitions and 1 freebsd-zfs partition, leaving the > efi partition in place. Clearly I did not do everything > require [or something is very wrong]. zopt0 had been > a root-on-ZFS context and would be again. I have a > backup of the context to send/receive once the pool > in the partition is established.) >=20 > For reference, as things now are: >=20 > # gpart show > =3D> 40 937703008 nda0 GPT (447G) > 40 532480 1 efi (260M) > 532520 2008 - free - (1.0M) > 534528 937166848 2 freebsd-zfs (447G) > 937701376 1672 - free - (836K) > . . . >=20 > (That is not how it looked before I started.) >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 = releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 >=20 > I have also tried under: >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 >=20 > after reaching this state. It behaves the same. >=20 > The text presented by: >=20 > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >=20 > does not deal with what is happening overall. >=20 > So you just want to clean nda0p2 in order to reuse it? Do "zpool = labelclear -f /dev/nda0p2" >=20 I did not extract and show everything that I'd tried but there were examples of: # zpool labelclear -f /dev/nda0p2 failed to clear label for /dev/nda0p2 from when I'd tried such. So far I've not identified anything with official commands to deal with the issue. Ultimately I zeroed out areas of the media that happened to span the zfs related labels. After that things returned to normal. I'd still like to know a supported way of dealing with the issue. The page at the URL it listed just says: QUOTE The pool must be destroyed and recreated from an appropriate backup = source END QUOTE But the official destroy commands did not work: same sort of issue of reporting that nothing appropriate was found to destroy and no way to import the problematical pool. Note: I use ZFS because of wanting to use bectl, not for redundancy or such. So the configuration is very simple. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Sep 16 22:16:25 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C1CAE17D98AB for ; Thu, 16 Sep 2021 22:16:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4H9Wdk4wtgz3vks for ; Thu, 16 Sep 2021 22:16:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id y63-20020a9d22c5000000b005453f95356cso3358752ota.11 for ; Thu, 16 Sep 2021 15:16:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uF7CW3LcGIjZqE0/Tmi91iYactTKpoWnniO9mU0KLwA=; b=XlUx9BIR3N41cOD5GBcI9xE+uBxiQ8y0MC1BHM0L9r37Ks+12sYYVaKljc4L96C6LT 472PQ9Jt8t5M8zmmhCAGpCxNi4HfqsnJVIF2TMBBf3WLi2V1/104ftw+c8qJ1/K+SV63 J2M9kYzkmxA7gF2b4FfShBD0lHLoMck4tODtTFiC8YqNBoJWPaXz/HEf3an1u9LFx0Dy Y/nTBuBmU50Bgx3SH8rBYh2rK9cdKDs90lEKVVsXiRcRuKaJxbfnqUkouGwc5fe8v9vF KhnlkwYqioSJYsgpImxauHisEfoByZJcwLLCtBkLcYfWHHbGBzSdRwkxKuApdu73Htc/ vKsA== X-Gm-Message-State: AOAM530gm5nDSm/zPOST9orbWYiPHADwT8R//8NsHypiGAjuFrevuScq 4Fo6aVTqJhf/dcS+06HgRy5T5aM9IJtYictdhSUn+6LD/2s= X-Google-Smtp-Source: ABdhPJzkOIPCyLA4dM2K8wXvNXiLW9vNxUgXMKj//ovrSKYktJZKumYy6h3m7uHP4Tc7x3F7TXTFRbtFIsk6yFLaXuI= X-Received: by 2002:a9d:411d:: with SMTP id o29mr6722369ote.111.1631830596292; Thu, 16 Sep 2021 15:16:36 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 16 Sep 2021 16:16:25 -0600 Message-ID: Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" To: Mark Millard Cc: freebsd-current Content-Type: multipart/alternative; boundary="0000000000000693bd05cc242b43" X-Rspamd-Queue-Id: 4H9Wdk4wtgz3vks X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000000693bd05cc242b43 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 16, 2021 at 4:02 PM Mark Millard wrote: > > > On 2021-Sep-16, at 13:39, Alan Somers wrote: > > > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current < > freebsd-current@freebsd.org> wrote: > > What do I go about: > > > > QUOTE > > # zpool import > > pool: zopt0 > > id: 18166787938870325966 > > state: FAULTED > > status: One or more devices contains corrupted data. > > action: The pool cannot be imported due to damaged devices or data. > > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > config: > > > > zopt0 FAULTED corrupted data > > nda0p2 UNAVAIL corrupted data > > > > # zpool status -x > > all pools are healthy > > > > # zpool destroy zopt0 > > cannot open 'zopt0': no such pool > > END QUOTE > > > > (I had attempted to clean out the old zfs context on > > the media and delete/replace the 2 freebsd swap > > partitions and 1 freebsd-zfs partition, leaving the > > efi partition in place. Clearly I did not do everything > > require [or something is very wrong]. zopt0 had been > > a root-on-ZFS context and would be again. I have a > > backup of the context to send/receive once the pool > > in the partition is established.) > > > > For reference, as things now are: > > > > # gpart show > > => 40 937703008 nda0 GPT (447G) > > 40 532480 1 efi (260M) > > 532520 2008 - free - (1.0M) > > 534528 937166848 2 freebsd-zfs (447G) > > 937701376 1672 - free - (836K) > > . . . > > > > (That is not how it looked before I started.) > > > > # uname -apKU > > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 > releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > > > I have also tried under: > > > > # uname -apKU > > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 > main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > > > after reaching this state. It behaves the same. > > > > The text presented by: > > > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > > > does not deal with what is happening overall. > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > labelclear -f /dev/nda0p2" > > > > I did not extract and show everything that I'd tried but > there were examples of: > > # zpool labelclear -f /dev/nda0p2 > failed to clear label for /dev/nda0p2 > > from when I'd tried such. So far I've not > identified anything with official commands > to deal with the issue. > That is the correct command to run. However, the OpenZFS import in FreeBSD 13.0 brought in a regression in that command. It wasn't a code bug really, more like a UI bug. OpenZFS just had a less useful labelclear command than FreeBSD did. The regression has now been fixed upstream. https://github.com/openzfs/zfs/pull/12511 > > Ultimately I zeroed out areas of the media that > happened to span the zfs related labels. After > that things returned to normal. I'd still like > to know a supported way of dealing with the > issue. > > The page at the URL it listed just says: > > QUOTE > The pool must be destroyed and recreated from an appropriate backup source > END QUOTE > It advised to to "destroy and recreate" the pool because you ran "zpool import", so ZFS thought that you actually wanted to import the pool. The error message is appropriate if that had been the case. > > But the official destroy commands did not work: > Because "zpool destroy" only works for imported pools. The error message meant "destroy" in a more generic sense. > same sort of issue of reporting that nothing > appropriate was found to destroy and no way to > import the problematical pool. > > > Note: I use ZFS because of wanting to use bectl, not > for redundancy or such. So the configuration is very > simple. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > --0000000000000693bd05cc242b43-- From nobody Thu Sep 16 22:19:40 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A1B2717DB6B8 for ; Thu, 16 Sep 2021 22:19:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9WjQ2S2sz4S7f for ; Thu, 16 Sep 2021 22:19:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631830787; bh=QLjQ3wo2Jv8PNHiFe4UzACOM9iebWtYmkXLoTf++2rM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TzS+Czm6JXDmXCkTdWw24UC7M2DhM6XuZncs1IEqN/mFrYnf6mIXJnoQYEy5EHmYv3RYnDL+QMKXNaR5xn0vgmRDHtGLbZtLzopZuLT3FdW1ceoCr7apaCXXQLAGdJUKKY0qTCWdcH0Fx6WpByS26OpIbfhmzu+SFSAMoq9MhdMXxeEigllpKL68jZACyLUJ7erfa7AhQUU23IgU3dSQTXQETuUVAfB9unO+uERJJozrpP5jiyQDK6xOxa/37kvOZZKMpemlzpjrwhOOlKgK/i3AdXA81jyNVeS3ZuaDdcbevTIXyZRTYkXqn0+RzSDQaQl7lqQA404+II37auU6Hg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631830787; bh=iWhw+TJ4U5QcupmTYF29r3QY82O4A5qtIbg5RI9bhQi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UP3gob6BzGxREk73G5da2iBOf5dEunXLAMU5jwjiX57hLPuHzD5nQOSWRBycB8yG/EPp/3fp5TcusKQIYQfM5BisMqtlCfqnDwcksf/EBL2GDKQAL5IAO17Mlm1p2xp5ky9HIuykzKM0rBbYPZehkYkqjX19Yep6Kpaz3+CdiLNfRTsLa/y4i/UfHnLKpXyPcjVOFSYG2eOfmgCweUhHpc1vn7EpfxQHa+XS9P758Q4ns0NNe7ljmJHTGxAQGUVO7XuQH4ICXRefQ/XO1tykRDG1BABoaHqhrFLtMT3l98ovPDnZdowHl4oQbG6F4LP8Zq0vQktKPCD5wJ8JBB7URg== X-YMail-OSG: NrfMS2kVM1nm5kpDEG0r9dgelLi2_z4IZ5RiIDGOdcxFvcMSRE8xHAvuRZPDhIe GMM9xPOgifR0QMCCdBRZDpRHOCRCFQ6iRxHi73rVvymNasb8nGpfjFYfd_sMP0px1NRrUZkQRaLn peH9zjV6OzjPVqui14iiXZueJ.8V2hT5p06h9VS8KkdrFHbFOecoyTI.Tq1S805_0vaelIHVAm38 3G1Wz.oHV4GnerD_b.KRhaOEHkRIOywgBnoHdNBycqaUH6xOV5Jikz0U0sWnsLf47TNy2EBL3W30 nCR9EES5B6b5ZzKifeK.Dzn7iaTMkKS_5B6C_42Wl4JXs.Pm7XER4c44hd3vzK_Vxv5LGPfJywT5 hXsB.I0CIyM_7hWHBzSAQlgNRfAI6dWb4mufF395Q8zggT9J1jwzFA54F9uFwG1gh1Lw88w9iaI2 TQVrQ0DVbZu8Aex2GLSrNhgSWpkr7bPo3RNn21wmb_RurQKiZYs.I403cA31FnDr241SgCqxAHx. Lu4NZSVxaJ3bxEAjKzi1rrrqAS0CW1TH7xalGhD2FJ1G9Yk8hoHYnXUFrbuake2kNT_HFU5BamC5 8FLkJbYUk2OYDeCERVK7bwADZaFnbaUbZksVlYi_8wtmMYzXMhp8LFo0M0WGYhkWYQMbVe1r3ekQ pBvSByen.oVFLzxv4yQvEd5hbLiq9D8EmheF1rZeQ4EBkdydRwaKnCH1Q737Sgx2x9GHR_eyyA3U h2g992phXota74rY_6Wx9CRfrr7pP3qSJu6R3pYJM6tmshG.XDuH4hlfjvYIGXlYS9iGx7aeqe5Z bntqU0zYBTF8VUaKO7qGoJoNbvbg_i649q2_Vo.VYq8GoOstmYLBOSmiIbc.wRcjMY5VPCPp4fK9 mrTy0RBXA9AK31JNBaqC3A5wd22aOngmPnByPT6XGucDSDhCFSJItyrpOgpa5zxip3saPB1owLar GHcJHeXquUGndhd.UUtW8.lRZs8iRlme_lwYgxE7EXdiBNaJsf2_lWKj3lhg9GXwHkim1D_m7zNB q_BJJe4TbdyWDBnayy1mogCskxUmg_sTOo3L0zfY2kQdDHaVnLRTFBREJGz_E53a6Lou7NxP4gVr ERDKQEwTqOPgQ1Mbmze9XkrgcdMDlVYxYXY3sWHgbO0tyG3EOGDczi21RpkOxO2kIbXpNY30DkyJ 1rcm.FMlAsOv0Jb.zoqE8au37lExPLCmv1fgsjdPgn_E715yQOct9KRq1tVeJQv9zMMlKxRMJ2jF IhITtDDyl8jg.hnzYmrB1oHBuPQNv12w7tOgx62.BJFIP.HWCzdzCSDOk2EioUe82O9wXD3SZ89e daGenQJ0WqeuHye65HhRuX.gy_abIPpjXsuKclZpKfwb2eJ_nmncgrGGjNFWOiDjAdHUeacBR1hg FaekzuPTnPeHC54bi7zjh7FgM706.U2PiKYaQLm9fezp4.Jq8p6a3z32j7_RlxbmYMMSJe3aAfo5 QGutW9ETvVO5_bBwVGo1ZPisOG8NGrK4wK8ZL0N4z2Wo6vZAwlzKTF5sGuTFTO.DXK9sS9hieqxV 0PP3syH6xAfWSR0gbjg0YtIoCQNP9gEI33ZFvKFbgy8RBsCGSDx.3Y_if_c_Eh0aLV39jMl5NswT EqwH5Zh7VQKpZqV1BHlt_oWz_OXyhw8qxq9uR6VLZ9lhY75bsgdfliufPGiHMEydMb3AnfyhVrAT MxjFPHMfddl2yuRaC0OxOIHk.D5Pij4l0QdR1ugIwylRpkJrsQgmhP0Jub9Nf83NcoGetw4h60Ky xal4yVC5M8SKTzvpRupEeMU9YVGpFne7S255kzxYhYqO3MM9kz3JCV.YAehfir.EuvD7hbPP2X4s zHSTE0wz7eVOT5495Yr6Vgv9Dl4IrhkVMo_zJ2Jcn2Me6qLhUkIgLlyAQC59DQtKrhq2haHXI2NK OylVJadcsEXhmJCzOiZ01PV88wWjlkXB8s1RII0aiC8Gpwfef0fbBIbnXLWs8cg5tO21hBJRQrpL duJk3lJVxOpn2KZD0NprTpULcA8GuDoBDXmo15mkPBGcUbGXuX9Zk5FaJQot_Z375FJg3H_4HfFR IWDMIIdpZTnY5vClIMoXrt_MkS8iB7kJHqZJWxJ6Z71et.a1DC3B2B5Srh6OIsDK7kMtp3Agpw.g kSfAqcvHr99wCiRBIUd8v5FikJKNsG_UPEMHPkcAsU9IvSdC3EpT1wGoU0mdavqEij9VVyxSgtQ6 5U8oahwiJQvszY5msrpxeXVZBB8AOTdlyUanDe7f.SbCd9ymCM2kX5qFgrrmBcfGZnm93_mwenti Vm8kXEEqk X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Sep 2021 22:19:47 +0000 Received: by kubenode517.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 576ca0b717829a889d66ee8a668801ea; Thu, 16 Sep 2021 22:19:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" In-Reply-To: <88799C4C-2371-42C1-A41C-392969A1C1E0@via.net> Date: Thu, 16 Sep 2021 15:19:40 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <6B748E71-0E70-4FFA-9AB5-639465E91275@yahoo.com> References: <88799C4C-2371-42C1-A41C-392969A1C1E0@via.net> To: joe mcguckin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H9WjQ2S2sz4S7f X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-16, at 13:26, joe mcguckin wrote: > I experienced the same yesterday. I grabbed an old disk that was = previously part of a pool. Stuck it in the chassis and did =E2=80=98zpool = import=E2=80=99 and got the same output you did. Mine was a single-disk pool. I use zfs just in order to use bectl, not for redundancy or other such. So my configuration is very simple. > Since the other drives of the pool were missing, the pool could not be = imported. >=20 > zpool status reports 'everything ok=E2=80=99 because all the existing = pools are ok. zpool destroy can=E2=80=99t destroy the pool becuase it = has not been imported. Yea, but the material at the URL it listed just says: QUOTE The pool must be destroyed and recreated from an appropriate backup = source END QUOTE so it says to do something that in my context could not be done via the normal zfs-related commands as far as I can tell. > I simply created a new pool specifying the drive address of the disk - = zfs happily overwrote the old incomplete pool info. Ultimately, I zeroed out an area of the media that had the zfs related labels and after that things operated normally and I could recreate the pool in the partition, send/recieve to it the backup, and use the restored state. I did not find a way to use the zpool/zfs related commands to deal with fixing the messed-up status. (I did not report everything that I'd tried.) > joe >=20 >=20 > Joe McGuckin > ViaNet Communications >=20 > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax >=20 >=20 >=20 >> On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current = wrote: >>=20 >> What do I go about: >>=20 >> QUOTE >> # zpool import >> pool: zopt0 >> id: 18166787938870325966 >> state: FAULTED >> status: One or more devices contains corrupted data. >> action: The pool cannot be imported due to damaged devices or data. >> see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >> config: >>=20 >> zopt0 FAULTED corrupted data >> nda0p2 UNAVAIL corrupted data >>=20 >> # zpool status -x >> all pools are healthy >>=20 >> # zpool destroy zopt0 >> cannot open 'zopt0': no such pool >> END QUOTE >>=20 >> (I had attempted to clean out the old zfs context on >> the media and delete/replace the 2 freebsd swap >> partitions and 1 freebsd-zfs partition, leaving the >> efi partition in place. Clearly I did not do everything >> require [or something is very wrong]. zopt0 had been >> a root-on-ZFS context and would be again. I have a >> backup of the context to send/receive once the pool >> in the partition is established.) >>=20 >> For reference, as things now are: >>=20 >> # gpart show >> =3D> 40 937703008 nda0 GPT (447G) >> 40 532480 1 efi (260M) >> 532520 2008 - free - (1.0M) >> 534528 937166848 2 freebsd-zfs (447G) >> 937701376 1672 - free - (836K) >> . . . >>=20 >> (That is not how it looked before I started.) >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 = releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 >>=20 >> I have also tried under: >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 >>=20 >> after reaching this state. It behaves the same. >>=20 >> The text presented by: >>=20 >> https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >>=20 >> does not deal with what is happening overall. >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Sep 16 22:42:09 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4EF6317BF2EB for ; Thu, 16 Sep 2021 22:42:20 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9XCH6bKwz4bjx for ; Thu, 16 Sep 2021 22:42:19 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 18GMg9I4064037; Fri, 17 Sep 2021 07:42:09 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 17 Sep 2021 07:42:09 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: marklmi@yahoo.com Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" Message-Id: <20210917074209.7b3b665188af8cdd22b98eef@dec.sakura.ne.jp> In-Reply-To: References: Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H9XCH6bKwz4bjx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Sep 2021 13:01:16 -0700 Mark Millard via freebsd-current wrote: > What do I go about: > > QUOTE > # zpool import > pool: zopt0 > id: 18166787938870325966 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > config: > > zopt0 FAULTED corrupted data > nda0p2 UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (I had attempted to clean out the old zfs context on > the media and delete/replace the 2 freebsd swap > partitions and 1 freebsd-zfs partition, leaving the > efi partition in place. Clearly I did not do everything > require [or something is very wrong]. zopt0 had been > a root-on-ZFS context and would be again. I have a > backup of the context to send/receive once the pool > in the partition is established.) > > For reference, as things now are: > > # gpart show > => 40 937703008 nda0 GPT (447G) > 40 532480 1 efi (260M) > 532520 2008 - free - (1.0M) > 534528 937166848 2 freebsd-zfs (447G) > 937701376 1672 - free - (836K) > . . . > > (That is not how it looked before I started.) > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 > > I have also tried under: > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) IIRC, zpool (except zpool import) only works with already-imported pool(s). So IIUC, `zpool status` and `zpool destroy` for faulted pool(s) would only works properly if the pool(s) fault after graceful import. *I have root pools only (in different physical drives), so non-root pools can behave differently. -- Tomoaki AOKI From nobody Thu Sep 16 22:50:17 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F33F417C53F8 for ; Thu, 16 Sep 2021 22:50:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9XNs4fXLz4gkh for ; Thu, 16 Sep 2021 22:50:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631832620; bh=AS5aRs8ns+3OkMyFckDVrrFmWPof0GiBu4JKN/Y/FbE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qBFU1t80ndAoO1oEEDDMjFzugOf+LYBWQJT9S6GUqome6mVfYrstpm/SaXAU8dCcD4d3z9bAdm4cfgMRIJJLaP7oNpdXWPfCPfRfOajd5u3nrcx/hRbo4oJ5cv2jasxNp/nlxi9V+UbQGuoz3ugirhIJNASzw+TDRA/Fba7wtTOx6sF4fpLdDYtkcfb5dgmYBR/byRs1Ey+8PVJl+asXoknAWplMDKLu2rWm2602qcN/CPXUaP6bAOtwy19MhBl8OkvHEx46zAEvL0H8OyfchW8ckTWiDBAbsRmUkYtTTMXrbagb+smnbNhQyb9PzJIb1KaeSvknAus11y7AmE7KxA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631832620; bh=zC11IJJMP4OrfV00tA4uXFHxiZRZNl8YF63eOUIivLf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tQo3PIPQWQTQeL5/5dv5QxtftFXX3kZgdcIW/xr5kYVKtBVDJrTEQZRjfcrlWef6umwRBmuWAnbd2Nuau8ETRjDStMaZa3wS6ksh2R+CFNnhQtw2kswLdEUn4r4nM98ClfxtWbwG6uG+TKAiV8AYmw8Vq+bV1rtmyxDH5FmUlnfE7Z8PNMeRNJ6pU3dHrLnLGdA3No7gw5BtoCdrhOzQwh2XJKg7iewozPQWj9ZX/nsNGporuREjWX3JuhVaiS56RR87K7Z2j9zeC+liqrMbPlN6bwaN1yWNTWLUwe4onUkSSqT/TPUZE6+wHG5+lNbD/CO517Ye5g0JIryLd6uoYg== X-YMail-OSG: RimUAesVM1mAXtHAH7bqgFD.DYaNgEBgqTwKAYcjwAGjjgAekA64UuLRSGcgtXL pzF_9STgh6o6aZxwutFx10XxgSiDE5UsrymqVEQQvRzmtXzQrnf.xUnIT6VnSAi.FOKi9rQGrKEj JnM1c39S9eve_mrTzukbsBDsXCikiiLBmbJx_2v3TgwS__dSGg3v0s_noB6vjfYA2eGGCPM.g_yD wOa1NizeynoKm6p6nfmyWAE_ERAthnVPOIRtezFiOMxtR0UGv40ZNi1F37JNBbq.ChQ3ivIsHuPN OfqFDsdLKJJl5vndhs9o3e5K9uLhrKmRO9bq_QXgzLvcx8lGZAROvP.CLM05ziImyuxKpQiDM9OS 02hB3cgoHR8rF2jHSuCjEaRyXxQTXgjyzw8MBWP.WO9Sd4vMuGCgTKFVlUtqUhtUXOinf0l6YeDu JfqY.JakCbwwIV91ZdR7otLsTjePsi6xoFThKWZdOiTYvc01NIoCx1LlPqgqQfCYUcEvCv.Ywfcw ZVUUiRLwNc1XuYpIHggnh8UakgK03tkrNjLtUcUFwdunFi3oAWjIZuen1c5njpdt9SxagttzV8Ll BGFmI38k_cAI1iqZwt4kx0k57oyApD0zU50Ss2oRresxkJnrtGYZskSOYSLzfLBZzqkSQjeRLiFV CfUL.fHOgALH9eQACV.hLtW_ybqQNFT.u4dkLjYaqpCxyMmmae8XRIv7BT5B2240yBXdhCpYHguu 2aunrNX1qcShfvwxxvq4HP.S0Cz6ISVsIylH0zuKee2_8m.BniSP7X1pPllQtqabPVVfm2EHgGbn C7QaoGkxMwOvRwWhOWB6085fWjkpTOSPpjCZ5HJKMOEeYPXi4gq6FNkq4fNq6ihZCnFh4zdivh6L zicALp4mCTHs3ZHGNi2kvNuXwAnuEax9eSU0NlyqSPOW0t5klDp3dW_D_QcBj9u497cE5.XqFukN VyP1p6B2beIK0rHm8l.0ZcWfuO8_i8w4X.Rbeq8YMucJTODVfNEr4Xi_CUaR6y7ICSWS94iSOq56 9QRPLrawm7jIAxJaiXHOn6NYdgJ8aoGE11WD1W1y0HTMBiQZaDobX.CTxzorGE4geKNs7WyPfeBv y3p4.IqRXb1ZiitnscodNGAAwcxScRjCs41iFGhwdkdOZ.L8T6vawbWLojjtlbq7HeiiW82r6y4p VKw0rEaxZALl0rvk7BQjHHJMeyprycqtTPAxkcZ4tPLCK2hT4lr3o8uVcxD7cm675Ph9SUeRRGw_ euFrSgLrtxFXy9GEwDtCXny0lEvThAa2y21lrccV1EQZM2AzRcciQprX0.R5Lq4PtQJs1musnbpC 8FVgiPz2PHlBx.GyInhE0EDciDCSWb97CAAjl3p2rud1DjZT_A5zkRFV7243s9F.dDScZFXbfZ.n XbQ12J4zXnORoABbHcBVOtxfH86WY5BngLdREVwHr61wud3qEEgMrn7AxMHcgZhX6FYeS_iod4YE s4HXB9r9ZCMKXuoUoJhDlisK1OqEM.mmXypT2kHzO.xOCj2E1ioSQA0QEMIMPel4_do.5Sbagoti G7bVSSjFbBDkWsDPDQ8CT1iNTrdYo5nLMppcHlTs9d6v6Mz0nA.uMgziiN2Q61LK6fXToudWBIFJ j5oHKY3OOF19ffN3t9w1FdlUzRs9k6kg4kF77H_XF.JOkjKyCnroEa1rNreoBWjGCAJQ.PUvALF7 _AzjVT_jcE96BRtfJhShCuWEy_6Czz53_fLk.7947MgpPjccEx7_xSYoXPZdlEC0dQlhHQlJRKN4 WNRXFZHTd1jL7p.3m1Rn41r0_2MYr69XEFjTyGCcZu9ezImlkWuKW4PNIeFi7WHgX_x1i_oW3t9M YnchIYELzlHZj1JS.Wo1oZ7r_XQhTH3mnUv6LwSSzhDJKpHOHJRP0Aay_B5DeAoznujRw_odtmG9 6_OE1VWX6ibCLg7XsKNzNO_MtH9ODPKuweq.4NJRSa_9OYyHHR0JZ_bAlGjOwoGKRFnia2uSX8uH e7gx3arGhG1KLhSPhrFJOpyC0huphmn9t4wRXSBQK.AA_qB71SMdTGADtEtGpZM_QV89NYV7gaXP CSxzUepY0R56N_wh0jN6GRsdblUg8VegmC0UzjxRvoR56taG7F0ul6Cb1PuaWZWf2dYr4V_p.kux HZGSHY3_cDpfb3_HoqSaCGSA0qO9wANljpLUkBKq.o4oL3X4iJI_UoLmdYPvQ.7T15rs25KUntlj QYpWnq7lzqWNqdpUk5gBA_XePA4lj0YnwWYfwiH_YrERQ.6oR6Ro3wDXlxYv5mRG7pyim5kYWwcp jocK7I2K7Ab5gDR93 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Sep 2021 22:50:20 +0000 Received: by kubenode526.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c6ff517a5daddbcb429d402e81f6c96c; Thu, 16 Sep 2021 22:50:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" In-Reply-To: Date: Thu, 16 Sep 2021 15:50:17 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <37A64EF6-C638-41A6-9304-3C11550B811E@yahoo.com> References: To: Alan Somers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H9XNs4fXLz4gkh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-16, at 15:16, Alan Somers wrote: > On Thu, Sep 16, 2021 at 4:02 PM Mark Millard = wrote: >=20 >=20 > On 2021-Sep-16, at 13:39, Alan Somers wrote: >=20 > > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current = wrote: > > What do I go about: > >=20 > > QUOTE > > # zpool import > > pool: zopt0 > > id: 18166787938870325966 > > state: FAULTED > > status: One or more devices contains corrupted data. > > action: The pool cannot be imported due to damaged devices or data. > > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > config: > >=20 > > zopt0 FAULTED corrupted data > > nda0p2 UNAVAIL corrupted data > >=20 > > # zpool status -x > > all pools are healthy > >=20 > > # zpool destroy zopt0 > > cannot open 'zopt0': no such pool > > END QUOTE > >=20 > > (I had attempted to clean out the old zfs context on > > the media and delete/replace the 2 freebsd swap > > partitions and 1 freebsd-zfs partition, leaving the > > efi partition in place. Clearly I did not do everything > > require [or something is very wrong]. zopt0 had been > > a root-on-ZFS context and would be again. I have a > > backup of the context to send/receive once the pool > > in the partition is established.) > >=20 > > For reference, as things now are: > >=20 > > # gpart show > > =3D> 40 937703008 nda0 GPT (447G) > > 40 532480 1 efi (260M) > > 532520 2008 - free - (1.0M) > > 534528 937166848 2 freebsd-zfs (447G) > > 937701376 1672 - free - (836K) > > . . . > >=20 > > (That is not how it looked before I started.) > >=20 > > # uname -apKU > > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 = releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 > >=20 > > I have also tried under: > >=20 > > # uname -apKU > > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 > >=20 > > after reaching this state. It behaves the same. > >=20 > > The text presented by: > >=20 > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > >=20 > > does not deal with what is happening overall. > >=20 > > So you just want to clean nda0p2 in order to reuse it? Do "zpool = labelclear -f /dev/nda0p2" > >=20 >>=20 >> I did not extract and show everything that I'd tried but >> there were examples of: >>=20 >> # zpool labelclear -f /dev/nda0p2 >> failed to clear label for /dev/nda0p2 >>=20 >> from when I'd tried such. So far I've not >> identified anything with official commands >> to deal with the issue. >>=20 > That is the correct command to run. However, the OpenZFS import in = FreeBSD 13.0 brought in a regression in that command. It wasn't a code = bug really, more like a UI bug. OpenZFS just had a less useful = labelclear command than FreeBSD did. The regression has now been fixed = upstream. > https://github.com/openzfs/zfs/pull/12511 Cool. >> Ultimately I zeroed out areas of the media that >> happened to span the zfs related labels. After >> that things returned to normal. I'd still like >> to know a supported way of dealing with the >> issue. >>=20 >> The page at the URL it listed just says: >>=20 >> QUOTE >> The pool must be destroyed and recreated from an appropriate backup = source >> END QUOTE >=20 > It advised to to "destroy and recreate" the pool because you ran = "zpool import", so ZFS thought that you actually wanted to import the = pool. The error message is appropriate if that had been the case. The start of the problem looked like (console context, so messages interlaced): # zpool create -O compress=3Dlz4 -O atime=3Doff -f -tzopt0 zpopt0 = /dev/nvd0 GEOM: nda0: the primary GPT table is corrupt or invalid. GEOM: nda0: using the secondary instead -- recovery strongly advised. cannot create 'zpopt0': no such pool or dataset # Sep 16 12:19:31 CA72_4c8G_ZFS ZFS[1111]: vdev problem, zpool=3Dzopt0 = path=3D/dev/nvd0 type=3Dereport.fs.zfs.vdev.open_failed The GPT table was okay just prior to the command. So I recovered it. The import was the only command that I tried that referenced what to do about what was being reported. (Not that it was useful for my context.) I discovered the zpool status via the import reporting what it did after doing the GPT recovery first. I've still no clue what was wrong with my labelclear before the repartitioning. But it appeared that the GPT tables and the zfs related labels were stomping on each other after the reparitioning. So, yes, I was trying to import when I first got the message in question. But I could not do as indated and it reported to do a type of activity that I could not do. That was confusing. >> But the official destroy commands did not work: >>=20 >> Because "zpool destroy" only works for imported pools. The error = message meant "destroy" in a more generic sense. >> =20 >> same sort of issue of reporting that nothing >> appropriate was found to destroy and no way to >> import the problematical pool. >>=20 >>=20 >> Note: I use ZFS because of wanting to use bectl, not >> for redundancy or such. So the configuration is very >> simple. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Sep 16 23:27:54 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A85E317D6204 for ; Thu, 16 Sep 2021 23:28:05 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4H9YD53hjgz4t6c; Thu, 16 Sep 2021 23:28:05 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-io1-xd2b.google.com with SMTP id f6so10060648iox.0; Thu, 16 Sep 2021 16:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJKRQ/Jg6Ka59oJZFoTDPSSqrHvPYr0f5DwC78ydBKw=; b=O2mFgANjA3GO7BAqEPb4FBFFawbrUJ/yec2s5xGBPOFvgP1YQAKIusgkrK1LUq97U5 KxZaAwW4qo90iY202ciu+LnTIuIBynBPs6+bH0VEiIxo+ns/N7biH4jF8QcUr8onZ7AO TL+2hBnIW5Gkv7LEqWIpTWmI/xskuhW96yC+d+kD9R3DTWjNoa3cDziNexqBjKfxdRfY QdYN1IZx6TwNIOk1w6x36srJUx0Ki8DUvdqL88M8orrzFdM/9K0BrelRpJIAiURfSKJd WYPB8xb0rixaKPhfRly8sIQmodULuK1QpMXoqdcfZsLwp6o/MLB10n9jclxAguxBPigc EdqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DJKRQ/Jg6Ka59oJZFoTDPSSqrHvPYr0f5DwC78ydBKw=; b=bM3qSO0DtCiVqg6qegJWCxGlFtiYDGiNLYozBJjNNORHQl6JKzKJ7U0osj7/yvO4lZ iN5Qjx6HugKEVTPo93RUIP2dOjFMzvP5B35+9wUXU3oEMMXlJKS+4hcZOz5pbwnJoPGv 6sBRWMVmPY5738h1/YdaO0nlpYCctWy2Lq/GuZMN5jX0alMKt9rv8MlqDMwtHWOHiba1 y5Fr9XQS1nIL1yuTLzT1TWQsK44mKOAd2sB5dGLEVNBrG9grnLjQTgJJAacQEFhtABfN kxBFop+6TP6z1Xhw1tdLQivqKFN9HRjI8BYuithZiCYwdKrszDjwd6Ub2ay5Biw5+Uy6 yzEg== X-Gm-Message-State: AOAM530moBw493J+GwTLENCqNrlDF9CqfZFeBIZS3O1IjkFG4dqTaGiu Dg18Fznvh57nE0ZmQVX1VGyz415D7XLqJZSsyhs= X-Google-Smtp-Source: ABdhPJzzjj8JQq3rS51J+XsscogLJ9I4WpF9AXRjykSBIcz2MnsDe9WlHQEcW8i7zUP1xkdIB/YDRFnOTvbf9ZtSwTA= X-Received: by 2002:a05:6602:2211:: with SMTP id n17mr6259749ion.142.1631834884859; Thu, 16 Sep 2021 16:28:04 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <37A64EF6-C638-41A6-9304-3C11550B811E@yahoo.com> In-Reply-To: <37A64EF6-C638-41A6-9304-3C11550B811E@yahoo.com> From: Freddie Cash Date: Thu, 16 Sep 2021 16:27:54 -0700 Message-ID: Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" To: marklmi@yahoo.com Cc: Alan Somers , freebsd-current Content-Type: multipart/alternative; boundary="000000000000a4ec8605cc252a1d" X-Rspamd-Queue-Id: 4H9YD53hjgz4t6c X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000a4ec8605cc252a1d Content-Type: text/plain; charset="UTF-8" [message chopped and butchered, don't follow the quotes, it's just to show some bits together from different messages] On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > > > For reference, as things now are: > > > > > > # gpart show > > > => 40 937703008 nda0 GPT (447G) > > > 40 532480 1 efi (260M) > > > 532520 2008 - free - (1.0M) > > > 534528 937166848 2 freebsd-zfs (447G) > > > 937701376 1672 - free - (836K) > > > . . . > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > labelclear -f /dev/nda0p2" > > > > >> > >> I did not extract and show everything that I'd tried but > >> there were examples of: > >> > >> # zpool labelclear -f /dev/nda0p2 > >> failed to clear label for /dev/nda0p2 > > The start of the problem looked like (console context, > so messages interlaced): > > # zpool create -O compress=lz4 -O atime=off -f -tzopt0 zpopt0 /dev/nvd0 > GEOM: nda0: the primary GPT table is corrupt or invalid. > GEOM: nda0: using the secondary instead -- recovery strongly advised. > cannot create 'zpopt0': no such pool or dataset > # Sep 16 12:19:31 CA72_4c8G_ZFS ZFS[1111]: vdev problem, zpool=zopt0 > path=/dev/nvd0 type=ereport.fs.zfs.vdev.open_failed > > The GPT table was okay just prior to the command. > So I recovered it. > It looks like you're trying to use a disk partition for a ZFS pool (nda0p2), but then you turn around and use the entire drive (nvd0) for the pool which clobbers the GPT. You need to be consistent in using partitions for all commands. You're also mixing up your disk device nodes for the different commands; while they are just different names for the same thing, it's best to be consistent. GEOM is built out of layers (or more precisely, "containers" as it specifies a new start and end point on the disk), which is very powerful. But it's also very easy to make a mess of things when you start accessing things outside of the layers. :) And ZFS labelclear option is the nuclear option that tends to remove everything ZFS-related, and everything GPT-related; although I've never seen it used on a partition before, usually just the disk. Best bet in this situation is to just zero out the entire disk (dd if=/dev/zero of=/dev/nda0 bs=1M), and start over from scratch. Create a new GPT. Create new partitions. Use the specific partition with the "zpool create" command. -- Freddie Cash fjwcash@gmail.com --000000000000a4ec8605cc252a1d-- From nobody Fri Sep 17 00:14:42 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 94F4917CC0A2 for ; Fri, 17 Sep 2021 00:14:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9ZG92GJMz3PNQ for ; Fri, 17 Sep 2021 00:14:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631837690; bh=fCjUbFn+TOudf+6xa9l9GOinMG11XobLkOJxC/0dNB0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RYczpoFaFxmjjqDillL7/ImtLlTnbRlSHW32s+ryrO1la5zm/bzjCmUxt/ihGH56xxTa1vWVDQhn9c1yx7432cDrd92wMMBg6TGXLAj6Ez6nd3v+oBR79lI9He5JErfW3zI/NdGB3oVipMs8RJpPBPuG4JKqJ8tKjYYy5eCAVWkP1k6XKnw+p+svJRtUW8W3XPJHEzSwWei5EFKA4SaozhyUwkxbxyXgNkzGpvkILDD9WWnutJyrERnC0bWFjQctJND85Ru/2La34nb0DXzf/ZnEheuZNXifLQO1P8EEOjT2X/RSfUIFX3Sfwx/tu/jIATVJ9uGYJlsLqEGLIkZv+w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631837690; bh=ijMOdPePFBu30ufXhHOUcW4Pi8HAqlbKENYFeYyRZjr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LQD7CWPbZsHls/34H7WfFYgK56xi3i0Jpaq13dOCHloDPptitV0dD7rY+gHezBhzpAFiKI+Xxn4k1z4XdTKrBcvzMaoAbpbJCCYYdpPBI4dZ7xvUC7ftosECHTSF8xx3F5DqfMgnEDLR4RCIdGh3JSxzlpj7XnffpSax1HLkzPKsK50dXp9wulXiY9CpcXcEeWdOunf9xLYjlswvyShM+XTgrlYFiOT9mFlq6iQZhcfPOWCRXiLoRG8wkTmzcjQaikbg/epbABNsLzqhHmp089QT1+hvqckS4zrXxh90pBbF5EUhdLcUV5qCPTBdF0o2ZCUUiwNj7jGH1WX1FGPQKA== X-YMail-OSG: yOpDEVcVM1k19JUHTDF2zbeug7KFxw4d6VAPV0E2YecEvueIjIf24UlHCYfh8UA 3sCouyM50.v7ScDJGAjZCww_iT8l4Mk0HuDoK8OX2xHvDNFN8pgEXq57lHWqzjD0b9BFo1bINXpQ 6Lwqqi_YyXI6bq3hsLF_YVZ.BNaumz7vBlspDm1seWc0amyI96zh6faEFACI1D7NlWDFA_Fbkjgm ffMXRYwUG4qmEyG5S_P9LItUQUkJGjcEXG6GWQhL17aZ.n5kT3FrBwRs5QGSu.j_YpgoK4Nc7rSY xa.y2rqkL3ZQQWTptlzRkM6t.KoV8rjJhhtXXjJ_4kSjAJUDlqAux_9Nsr2G6_XzvAYNxPpzJdoL B_4VEFGJXiBrj31D2eEen8jBTOWK0Vw.kyVBFUCI9pbku2kAVtDRPQvYeJFtGzqy7lDV7oIbtNji aHf9WdW38PLStc5BKSM711bM.pgeARW_0HT04fGwz2h1fXUaKY9C9xynzWXUY3lGmYALYbA7HIiN a9X_HdibODXO_BIqIKtl4RVV1t7v9KHZmdq3S7Hr8BRFvwGK0wEhBvbHpVXhKIFOVLlIlJfM4hvJ ZpSKL9nY4N2yiO.mlD8GPUVHK8CBo6Pf6EtfPy_eHknmdiqhAljed6KVIcsyUfYNNARTLz4Ry7Cx V8.w7vC5OJAC4ABUdsJWgOSHID3SUAyPtmxREkRh6M6UYZiKyzBuuNt47..9WLrS3MXphHt_HYnh 2e2nQc401IXlhSbbo0D65VUhbqBRN5t5RdHICAdKsTnBlPc1zk_KngCp5Dbojxd6Ov9EazhSEHZ8 GyjRWGaXQ80Ntpe3I4gFz4qVXNeAYBA8jrK7LcEYZ1.qqoVzeuPZSw1jumi64KCwzBE.SHyWmgnw Bza6QsFqwQotgnKJMKm4L54w6NZUPLolf4HCZNUh6T1ovNewb_HjPqbDAS1rPt34hVftRA.VRSFm bPKwXbDT9gO3TD06Wo_u3cHH0xmDxOjMIaS8awZCOGtfKF1Ocjy9TqseC_5513I6Yn.TARSHRW_x nv_zmHQeP52w3bQ_mfsoRza2hzTO.I2iaoAZUJXXUM.EDERYa_UpRXWX9kOgEl0zf9TcsATt.HRi rRFu_WHxdbJX.oxu7Bv9z.VHhHwMMhL97D_mq3sirvt4CEoDjIebxNMLfS23F5_9a155436EHPmm Dk7.iWWqV7AY1EiZ0vSqhg4AER3eTk6rbUrtahEbOuDTAXtoh4aKGDH.V3l_76UeglDkh7E7IIAU aeHyPC1OJ8z4lIgJY6gtUyuFur4mIdLQ1XXE5pU3I7HbBzU6f9HU8eTAGrt3x5lV.k_q6TccAe1x OJnk40j1Wl2ZhBAdNF3KXhe9JUUkE9Gtsj1rf..Lm6AtnHK1oXPoFD5YhdmFBm4g6w9jeMfZuOo_ rb6TwR.FedY0XvAUxXx6taKjYr3IcbfNnimJgDFdQXiIo_PuogZXD9lWva0M8QVRdxRZvZP4uJbH mQaTG7dLs3v2i4x.bK2X60Xurc9bei7zWP3IQYCT3KM3NJigtBD2GRmW3KvXH_69w6QVol7E8r_l 1NYbrH6IXeZf1RaSZjhLCYXkytos6sXUzFDZrMuohU0w70XGm_hO4ZeCWqUcAZ10P7k.ZQRwXtFM GGPTXuCsLS8Il7kjAM3VnFEmICdr6RZP6gQYiF2OvQTXyE5zn2RHQ4Y7yaw00.nAyui8cpk7Cd9P Q.1oBUgiP8WiFQoWDWw1vyQOFLHydPTV0LHd_st3pka_.2D4.xZk7dlLoBIrGTWcLcpnh8XjhfLx TBdSFXFrNs8266QNL5LLCUr4I_GCRRuE5qnJJj7tvtV6krqqQmCW4UkvWUvF1AYGj4msDj1B1Uyv oPGlQu.HWK444oucHVuCWZak.WCfqFL.kmk7I34HXFURWuU1sWaXB__usfjPK2_zBsjWabIVmC6Q ch2kIVT4UDo2pPQHNSV926LaAPK1GRPKunGr19mjdFuWtO8Rgbj2WdZHDG3h5MoCCIo2gihBbCzY istVgcnqUkOI7nLEfJaqED7YH8uLut2C0qyMBWrctW6yN6abmNVK3q53FjXHj0kLmcZL1H7GFNYP KqvzVZjNlTC0tpxKaLkGSxbDDVHUIfAWY8LlEeGF9fM7fqaJWMtBbSy7Lin6js7BoFtF2tVNB.nj RYmF8xlJ6iH0uWgDEfrs83nxPWACyFjzCuoLLGw7mRpzslZ5esHILQItaFSGlaHLy6hcIZ7OQYEp ALgH3nSalcPNP742oI7HlpsIrABGr34g9anbmRdXKs4mEiIhJhbPsreGdWk68UhZaa7d1lqfbJW1 2BizUVl39NefI X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Sep 2021 00:14:50 +0000 Received: by kubenode587.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 73cf60eca9e98b2d61c501cf59364bfe; Fri, 17 Sep 2021 00:14:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" In-Reply-To: Date: Thu, 16 Sep 2021 17:14:42 -0700 Cc: Alan Somers , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <18C84EC4-D7D6-4288-949B-0157F52C95D2@yahoo.com> References: <37A64EF6-C638-41A6-9304-3C11550B811E@yahoo.com> To: Freddie Cash X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H9ZG92GJMz3PNQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-16, at 16:27, Freddie Cash wrote: >=20 > [message chopped and butchered, don't follow the quotes, it's just to = show some bits together from different messages] >=20 > On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current = wrote: > > > For reference, as things now are: > > >=20 > > > # gpart show > > > =3D> 40 937703008 nda0 GPT (447G) > > > 40 532480 1 efi (260M) > > > 532520 2008 - free - (1.0M) > > > 534528 937166848 2 freebsd-zfs (447G) > > > 937701376 1672 - free - (836K) > > > . . . > =20 > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool = labelclear -f /dev/nda0p2" > > >=20 > >>=20 > >> I did not extract and show everything that I'd tried but > >> there were examples of: > >>=20 > >> # zpool labelclear -f /dev/nda0p2 > >> failed to clear label for /dev/nda0p2 >=20 > The start of the problem looked like (console context, > so messages interlaced): >=20 > # zpool create -O compress=3Dlz4 -O atime=3Doff -f -tzopt0 zpopt0 = /dev/nvd0 > GEOM: nda0: the primary GPT table is corrupt or invalid. > GEOM: nda0: using the secondary instead -- recovery strongly advised. > cannot create 'zpopt0': no such pool or dataset > # Sep 16 12:19:31 CA72_4c8G_ZFS ZFS[1111]: vdev problem, zpool=3Dzopt0 = path=3D/dev/nvd0 type=3Dereport.fs.zfs.vdev.open_failed >=20 > The GPT table was okay just prior to the command. > So I recovered it. >=20 > It looks like you're trying to use a disk partition for a ZFS pool = (nda0p2), but then you turn around and use the entire drive (nvd0) for = the pool which clobbers the GPT. I'd not noticed my lack of a "p2" suffix. Thanks. Explains how I got things messed up, with GPT and zfs conflicting. (Too many distractions at the time, I guess.) > You need to be consistent in using partitions for all commands. Yep: dumb typo that I'd not noticed. > You're also mixing up your disk device nodes for the different = commands; while they are just different names for the same thing, it's = best to be consistent. Once I had commands failing, I expectly tried alternatives that I thought should be equivalent in case they were not in some way. Not my normal procedure. > GEOM is built out of layers (or more precisely, "containers" as it = specifies a new start and end point on the disk), which is very = powerful. But it's also very easy to make a mess of things when you = start accessing things outside of the layers. :) And ZFS labelclear = option is the nuclear option that tends to remove everything = ZFS-related, and everything GPT-related; although I've never seen it = used on a partition before, usually just the disk. > Best bet in this situation is to just zero out the entire disk (dd = if=3D/dev/zero of=3D/dev/nda0 bs=3D1M), and start over from scratch. = Create a new GPT. Create new partitions. Use the specific partition = with the "zpool create" command. I ended up writing something less than a full 480 GiByte of writes. It preserved /dev/nda0p1 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Sep 17 00:18:33 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E8B5517CF2E2 for ; Fri, 17 Sep 2021 00:18:46 +0000 (UTC) (envelope-from ggm@algebras.org) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4H9ZLZ5rQlz3hds for ; Fri, 17 Sep 2021 00:18:46 +0000 (UTC) (envelope-from ggm@algebras.org) Received: by mail-lf1-x130.google.com with SMTP id y28so25439390lfb.0 for ; Thu, 16 Sep 2021 17:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bwX47m6w9/434sf/z1A/QOs162V2WVwxu+sM4D4kNu4=; b=0j4e8/aA+hdLy5obPxX7snXAX2vGgrwEetXgwulZ++bXRk6tInVZw6vedgo/4CfN0D lpoQzgB/sRyGqW8YGxaWshDUScj7fCvkatNp1PdmleBZqLiYcbLNQmlVZ/daVWENfwTI wlLEMPvrSrPCbfzeG07i/odp52Uj8wFf7Pdb7/4qHCjC7NO4XkkhwkEHb8lRJ/VqTg2q CzamoqJkyQXZic35W8G4zlLoT0RSErqoNdMjDxvQv5ux3vDlxdA+XEvN8PoOg06+gnEP /Z0cIpO6NvKh+XuxVDb/C6KHkCcAEZNYKVJB3jceyhrORrVe5gWB4vsqOgzbP6H3SuuM PvSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bwX47m6w9/434sf/z1A/QOs162V2WVwxu+sM4D4kNu4=; b=cktTN7oskJUNvglWAyrz6s8NJ68akWXnmCQJMBR9LJ04oyqJsP+ncSmmrE1JWLFIvV QNEtiuOBnrbhuwuVmFFIR8jwpr1EngaJ6O/t6drz1qYnZTysPzzEi3A1gGXKNsn1W1eG Nxf89UNH7F+FcaYQMpV7sNQWZ4QK/TuAZD7cL0WCAWJJB4K0mRYTcDKsTYfiFT93UH8P bYajzw1HRpnmDAJeE/0QCqwqU30Pm4lA9R5l4Ubz8pf/zeEjMgwhw0PveIIL4S/qYTfk 73HOJQmD6AEToG/7oBvJJN8jrzXkB4kl+9UaXlZpOjDJz5BbOjIar3qRFPMMgID4fAtq za1g== X-Gm-Message-State: AOAM5338MsMHUmyGq29+jGM+x39tRKZmqcm3z5d3mnLPKbNlYkw5RMqk 6oYpOv7iveiAwocn71kO58uK1nZ9G1h/0WmTuDOMjw== X-Google-Smtp-Source: ABdhPJzRoXw/3ruvlw0Ir80guN+rRpL5GZAkFHXndBl3Wm3LUIN9irwIhqrnSXN1S7c4bGK30EOBiJ/2RN05m7ojgYA= X-Received: by 2002:a05:6512:3a81:: with SMTP id q1mr4490974lfu.4.1631837925124; Thu, 16 Sep 2021 17:18:45 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <37A64EF6-C638-41A6-9304-3C11550B811E@yahoo.com> <18C84EC4-D7D6-4288-949B-0157F52C95D2@yahoo.com> In-Reply-To: <18C84EC4-D7D6-4288-949B-0157F52C95D2@yahoo.com> From: George Michaelson Date: Fri, 17 Sep 2021 10:18:33 +1000 Message-ID: Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" To: Mark Millard Cc: Freddie Cash , Alan Somers , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4H9ZLZ5rQlz3hds X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N GPT has a back-of-disk structure. Is the problem here that wiping GPT only at front, leaves emergency state at back which is detected, before the ZFS initialisation system can decide you don't want to use that? From nobody Fri Sep 17 13:30:19 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BE5FB17CE8E1 for ; Fri, 17 Sep 2021 13:30:57 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp3-1.goneo.de (smtp3.goneo.de [IPv6:2001:1640:5::8:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9vwc17d1z4V5Q; Fri, 17 Sep 2021 13:30:55 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-013-159-040.77.13.pool.telefonica.de [77.13.159.40]) by smtp3.goneo.de (Postfix) with ESMTPSA id EDE1E2040D96; Fri, 17 Sep 2021 15:30:46 +0200 (CEST) Date: Fri, 17 Sep 2021 15:30:19 +0200 From: FreeBSD User To: Ed Maste Cc: gljennjohn@gmail.com, FreeBSD CURRENT Subject: Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden Message-ID: <20210917153046.3be83f09@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20210909211530.5cf712d7@thor.intern.walstatt.dynvpn.de> <20210910082946.3f31c6e7@ernst.home> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H9vwc17d1z4V5Q X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:37) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[77.13.159.40:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.968]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Am Fri, 10 Sep 2021 09:04:30 -0400 Ed Maste schrieb: > On Fri, 10 Sept 2021 at 04:29, Gary Jennejohn wrote: > > > > Was the config.h in the patch the same as the one you committed? > > No it wasn't - USE_PAM was #defined in config.h after applying the > patch, while the committed version accidentally did not. > Hello out there, Just for clarification: after the last patches to the tree regarding openssh and recompilation of the base system, it seemed that everything turned to normal afterwards - in my case. Thanks. Kind regards, O. Hartmann -- O. Hartmann From nobody Fri Sep 17 15:07:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C10F217D8770 for ; Fri, 17 Sep 2021 15:07:40 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9y4D556sz3DZm for ; Fri, 17 Sep 2021 15:07:40 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 89D6DCE40 for ; Fri, 17 Sep 2021 15:07:40 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-148-130-214.range86-148.btcentralplus.com [86.148.130.214]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 900A32CC23 for ; Fri, 17 Sep 2021 16:07:39 +0100 (BST) Subject: Re: Building ZFS disk images To: freebsd-current@freebsd.org References: <16473d5f-1727-233a-7a95-a21c5b48b9ce@FreeBSD.org> From: David Chisnall Message-ID: <4e113e4a-a23b-dd85-03b0-f45b10895fab@FreeBSD.org> Date: Fri, 17 Sep 2021 16:07:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 05/08/2021 15:06, David Chisnall wrote: >> Would poudriere work for you? man poudriere-image > > Wow, there's a lot of stuff I didn't know poudriere could do!  It looks > as if it can produce a GPT partition table with all of the bootable > bits, or it can produce a ZFS disk image.  I guess it wouldn't be too > difficult to teach it to do both? FYI: I have raised a PR[1] that allows me to create a ZFS disk image. This allows me to create a ZFS root image that I can boot as a Gen1 or Gen2 Hyper-V VM. I have not yet tried it in Azure, but it should work. David [1] https://github.com/freebsd/poudriere/pull/921 From nobody Sun Sep 19 00:07:30 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C159817C2450 for ; Sun, 19 Sep 2021 00:08:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4HBp1s0Ctyz4SGF for ; Sun, 19 Sep 2021 00:08:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f49.google.com with SMTP id a15so17102138iot.2 for ; Sat, 18 Sep 2021 17:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WkScvObgQ50BTkPeRo7aVWa9DRk7kGUUFnAuBR4Ph+4=; b=XzfTJw0T361btf4j13VoCnCCVswlRVQjFgYJfNA1RcKuVE4NU8DfNf/x3ZeVm2kH0T CX5cTQjLd0lQhVKoR7E0x3jRmGsSEBUDn74yk4ydP/htVRZLqWZiPTVNibJcuveeCmTk Hzibcj9f94OaoIkP3PoxYCF/mmo8xhLSboZ63aWhwmjTf4/O9OSu91iy2xmf4WQYPscv KCQWY2oN6GlipTuFz4CgYW2F/ePuwkj8nUne6EOR6yljNoXIWbJO289I+wVKdLWHL2Om OwswaNNciBTF1UtBQZOKzBwYshW9LzCAG3xB7Kq5ktjl06Qhw8mFPhsV81A/UkcIigEp BCyg== X-Gm-Message-State: AOAM531OkhcaTu9gy/qOViur9SKWxTAhycGOqahAk56HSP/PO/4Z7mn4 FTCYkNdt8V8+FarYxBbYLPWYgt169jQC2uPWpgEeOUcR X-Google-Smtp-Source: ABdhPJwBgLTM+pqqZmffif26me9SLCo6oDOrJpfyvWc2/Cvxjz+0xi4m1m+X+sxpt/OkaMDOP5jTLB5AY1jbFaDw8I0= X-Received: by 2002:a02:95ee:: with SMTP id b101mr14125817jai.96.1632010112287; Sat, 18 Sep 2021 17:08:32 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20210909211530.5cf712d7@thor.intern.walstatt.dynvpn.de> <20210910082946.3f31c6e7@ernst.home> <20210917153046.3be83f09@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20210917153046.3be83f09@thor.intern.walstatt.dynvpn.de> From: Ed Maste Date: Sat, 18 Sep 2021 20:07:30 -0400 Message-ID: Subject: Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden To: FreeBSD User Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HBp1s0Ctyz4SGF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.49 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.58)[-0.583]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.49:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.49:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 17 Sept 2021 at 09:30, FreeBSD User wrote: > > Hello out there, > > Just for clarification: after the last patches to the tree regarding openssh and recompilation > of the base system, it seemed that everything turned to normal afterwards - in my case. Thank you for the update, and sorry for the trouble.