From owner-freebsd-stable@freebsd.org Sun May 14 08:17:20 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5968D6C757 for ; Sun, 14 May 2017 08:17:20 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BC4BF0E for ; Sun, 14 May 2017 08:17:20 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id e193so48616478pfh.0 for ; Sun, 14 May 2017 01:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=wNIx0dl5vwdlLG46zGM90zS6SbnUFLL/zQRYJlVHSSA=; b=ufV1EVJSZXdXU0WveDbnh4o3KY6TQ/yPiaVLq/OlM+svLC7UJBNjCNZOv0ZQ3VSPUO JGujmLMz44pRAJPzss+6X+TXIrPrqGoSnPfn3NvoapgG2EvFKRs937dAb1kfCOEj2CHz eii24ISL08fsCDiEXMM0XtdbFc1KirXNYKcjgeItip4I1bxAi9Cq9nXT+fGQ3/IQQ/dl CwFb5/B3Sn6cY5rQH1Hyezcwjn3Fw2S3UqwV+/pBt25kclO5+QxlJpkpN0LwR0zOuXOQ nE2t9OtoMzobjfiuuPbYa4b44855j5yu0l6xVudeox8/TS5ZJ9C4d6XTFKBRue8SRjF7 WkWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wNIx0dl5vwdlLG46zGM90zS6SbnUFLL/zQRYJlVHSSA=; b=c8rndAdMzuabDNWSxpP7bgh08YtXfLHGPqwrp8E4ACVSiDOdzG1MZ+mxb2KsbW3vl0 zQ5v6854yIUdMhawSjvdkjB6+qw3IZpzfebr62YjgyLuq6ezRzumEgYiTOuUORAftHKy BCE/hQ0p8QEZY+TMydqSyxVlpEtz/1Sub+URRLm/VOGk0ank/EMPyZbGQvMAgfFYvMGQ k6QG9UpRPwOTYn7zu8Qe05Nwt7GSV92DwrOovxI7rrUaKeRQ5oncMfrNBBodDB5p1+dT oma/ppTG+gu0J+pnIS9u3LD2nUj3Q2d45FTZI220JM8k4Y2ZNv5Q/Vt25bS+Xo5XmQiR WJ2Q== X-Gm-Message-State: AODbwcDsiOztjXjscZoveAz+qdBVN28ksqgIaidlahdcJ+h5B7VFZtG8 RWbWMruFs8tnl0DrcX8= X-Received: by 10.99.45.6 with SMTP id t6mr381689pgt.209.1494749839764; Sun, 14 May 2017 01:17:19 -0700 (PDT) Received: from [192.168.88.254] (ip70-173-249-54.lv.lv.cox.net. [70.173.249.54]) by smtp.gmail.com with ESMTPSA id s17sm14177380pfk.112.2017.05.14.01.17.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 May 2017 01:17:18 -0700 (PDT) Subject: Re: 11 stable vagrant images: page fault To: freebsd-stable@freebsd.org References: From: jungle boogie Message-ID: Date: Sun, 14 May 2017 01:17:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 08:17:20 -0000 On 05/06/2017 10:11 PM, jungle boogie wrote: > Hi All, > > I'm using 11-stable Vagrant image from here: > https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-STABLE > (tried 20th of April and 5th of April). > > Unfortunately, I can only get the VM to stay up for about 9 seconds, > because it's in a constant reboot loop. > This is still happening with the vagrant image from the 11th of May, 2017: https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-STABLE/versions/2017.05.11.2 From owner-freebsd-stable@freebsd.org Mon May 15 04:58:46 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 486E7D6D795 for ; Mon, 15 May 2017 04:58:46 +0000 (UTC) (envelope-from dpostolov@yandex.ru) Received: from forward23p.cmail.yandex.net (forward23p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F000C15CC for ; Mon, 15 May 2017 04:58:45 +0000 (UTC) (envelope-from dpostolov@yandex.ru) Received: from mxback2g.mail.yandex.net (mxback2g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:163]) by forward23p.cmail.yandex.net (Yandex) with ESMTP id 243A321569 for ; Mon, 15 May 2017 07:58:34 +0300 (MSK) Received: from web2o.yandex.ru (web2o.yandex.ru [95.108.205.102]) by mxback2g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Epm9Qm2gHO-wXROqkfL; Mon, 15 May 2017 07:58:33 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1494824313; bh=YOm7dTNySChaKzgUYGbLw8GFoNx2vHuLdfpEqmWGRo4=; h=From:To:Subject:Message-Id:Date; b=j6taa4IXJS2KnYKtSX54Fpw43JhSauwjmsoTPzLbWpc//FocKFNOnFRD2KeVOD5pD /48wQWJgiarp143OpB1ebK0ImuZ8M2HDJxjwAMyLu/oNv7ZbcGfqPgPgGmaxKWT9O2 k3kfCsctp96Qa3Q/vMMac+lPwt9XrafU0USuE/lk= Authentication-Results: mxback2g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web2o.yandex.ru with HTTP; Mon, 15 May 2017 07:58:33 +0300 From: Dmitry Postolov To: freebsd-stable@freebsd.org Subject: Conflict of Lenovo-fix option by default and Intel NUC5PPYH - Slow Bios starts MIME-Version: 1.0 Message-Id: <4814751494824313@web2o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 15 May 2017 09:58:33 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 04:58:46 -0000 Hi to all FreeBSD developers and users! Sorry for my bad English... I am install FreeBSD-11.0-STABLE with settings by default (Bios + Uefi) and run FreeBSD in Uefi mode. Intel NUC Braswell NUC5PPYH CPU N3700 with latest Biios and all previous versions. After install FreeBSD-11.0-STABLE-amd64 _and reboot_, Intel NUC5PPYH Bios slow starts from Logo to F2,F7,F10 message up to 18 seconds.If poweroff NUC and poweroff electric filter and power on electric filter again, and power on NUC, then all OK until next reboot of FreeBSD. This Problem was fixed in TrueOS 12.0-CURRENT (based on FreeBSD-12.0-CURRENT) with disable Lenovo-fix mode in Installer. Therefore problem in incompability Lenovo-fix mode and Intel NUC Bios/UEFI. https://github.com/trueos/trueos-core/issues/46 Kris Moore> Can you re-test this with later ISOs? We've disabled the "lenovofix" option by default that seemed to cause a few systems difficulty. Dmitry Postolov> Thanks! This problem is [SOLVED] in TrueOS 2016-12-15.USB Image. Video: https://yadi.sk/i/osvXqcw63J9Uou Previous versions of FreeBSD bugreport: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213638 It is possible to make the Lenovo-fix mode as Installer optional for Bios + Uefi Installer mode or to improve the Lenovo-fix mode for conflict prevention FreeBSD and Intel NUC ex-Atom series Bios? dmitry@freebsd5:~ % uname -a FreeBSD freebsd5.bsdnotes.me 11.0-STABLE FreeBSD 11.0-STABLE #0 r318134: Wed May 10 15:16:21 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 --- best regards, Dmitry Postolov dpostolov@yandex.ru From owner-freebsd-stable@freebsd.org Mon May 15 07:20:54 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B52FDD6DA53 for ; Mon, 15 May 2017 07:20:54 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9616A15B9 for ; Mon, 15 May 2017 07:20:54 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:65532] helo=localhost) by dnvrco-omsmta03 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id B3/44-25473-3D659195; Mon, 15 May 2017 07:20:52 +0000 Date: Mon, 15 May 2017 07:20:51 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org CC: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Problems with re(4) Ethernet driver in 11-STABLE and HEAD X-RR-Connecting-IP: 107.14.64.88:25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 07:20:54 -0000 I remember having problems with Realtek 8111E Ethernet on this Intel Ivy Bridge computer a couple years ago, and now the problem has resurfaced. I am fresh from updating FreeBSD to 11-STABLE and HEAD on two partitions, and in both cases can not connect with onboard Ethernet. >From NetBSD 7.99.1 /var/run/dmesg.boot : re0 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x06) re0: interrupting at ioapic0 pin 17 re0: Ethernet address d4:3d:7e:97:17:e2 re0: using 256 tx descriptors rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto NetBSD 7.99.1, an old build, and NetBSD going back to 5.x, worked well with this Ethernet, but the bug has come back in FreeBSD. Before giving up hope on FreeBSD 11-STABLE and HEAD on this computer, I have Hiro H50191 USB wi-fi adapter, driver rsu, haven't used it recently but see where I will try to bring it back. "dhclient re0" on HEAD (amd64) gave a couple lines of screen output before crashing into debugger (db>), whereupon I simply did "reboot". On 11-STABLE, also amd64, I got some lines before it gave up , "sleeping". On an old FreeBSD-current, svn r286653M, Aug 12, 2015, this Ethernet starts properly with dhclient. Now I am afraid to update except by installing onto a separate partition. I have plenty of space on 3 TB hard drive with GPT. I am not completely sure on which FreeBSD list is most appropriate for this issue. Tom From owner-freebsd-stable@freebsd.org Mon May 15 18:10:04 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DD3DD6EF97; Mon, 15 May 2017 18:10:04 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF49E10BC; Mon, 15 May 2017 18:10:03 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MY4Ls-1dWEzr2d3g-00UuOJ; Mon, 15 May 2017 20:09:55 +0200 Subject: Fwd: ZFS References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> From: Nikos Vassiliadis To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-Forwarded-Message-Id: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Message-ID: Date: Mon, 15 May 2017 20:09:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7VR/Pgmwc3gTksbhU74jS5SdNM6kPtbxWELlcBY0tBXE2z/hris rBDR3Zne7pzagP9MtRkwkIAPQWGek3AtuuKdM1VtV9SC5E1jT54on/JlDAWrQtN5hGgW0R8 eAKitMdVz8xgep3x/yhIJWU9zahwXIkk1WSGjCCUwfWBxH31lnhrDxT0DuK1PU1To/wBcoT wxTaYpkj44fGz764kOgOg== X-UI-Out-Filterresults: notjunk:1;V01:K0:vkMzPZ071pQ=:7gY66TLUldXwdAv6jrp3O+ bYJR4X9LkfWom7BFbrSDueQFNIgOP+F8nupAM7x0GCAAnMjENBeAcrXz4c8X+wyKVsWc3GZTa 8eLcfGjnbupOmOeFaWWiq5EoQsh8w2K0bvvSsbfajlW7Qe9MUcRWxMWlaD91ZoSft48CsozUZ 5owIcy2Um5bb0aiyZbdz72cu0VZCencRXM/PgJT7ERn+Qlr4szv+t+80f9erkC3vdQ6vk1aza C74eeUgwZQi7nqLnS8e6l5TB+6eqFGYJBahRe4KYNBMePjYRVm7e92SYr0ucGX8CEImU6KOHj fOtlE1KiM5yLjDd5eQgFM68lsvOCv8mKfjICXh7+iTnObFOcuuPyvEDgSlOwtz+ylhUeSOxVq SgXDx2LHBbMCoTyoPF6KACo1+GCrlOFS6WLZ4kssJRx6DuR1d2k4j01iFStpd6ccDfQzD3FSt Z3t/LkrhKeMAzd30LRwmiabWtgjmb1uJWIVyLujJb7PGA3jBi7fPDUNlU/BKZaFl5QvGT82h1 lJbZtIJ6sQzxUVn/iSISpkAeR5QMBBcnkngSaqVZV9y9+QEnPQ3J66vedzLtUe6BSrxkUqUg0 gko3DCG0hm7O9nQWhPpTK7oZbhCVjmRp4SznmjCTV1UGykIrUEUwHs6JvbYlyT9atL+LrFune IViCXNV6Iyi7kVRpnNImdeBtB/AAnTdAUdZ7tZxuo5h7WmBNc2E9lGLs9e/m7O4KULfWKDvkP N68fn2tYawD0TAhBq+4iXN9RRYb5DzNlxD5In/sbS3Vj6wWylOuYSyImkpzFbusEhmETq0ldd niFmif5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 18:10:04 -0000 Hi everybody, While trying to rename a zpool from zroot to vega, I ended up in this strange situation: nik@vega:~ % zfs list -t all NAME USED AVAIL REFER MOUNTPOINT vega 1.83G 34.7G 96K /zroot vega/ROOT 1.24G 34.7G 96K none vega/ROOT/default 1.24G 34.7G 1.24G / vega/tmp 120K 34.7G 120K /tmp vega/usr 608M 34.7G 96K /usr vega/usr/home 136K 34.7G 136K /usr/home vega/usr/ports 96K 34.7G 96K /usr/ports vega/usr/src 607M 34.7G 607M /usr/src vega/var 720K 34.7G 96K /var vega/var/audit 96K 34.7G 96K /var/audit vega/var/crash 96K 34.7G 96K /var/crash vega/var/log 236K 34.7G 236K /var/log vega/var/mail 100K 34.7G 100K /var/mail vega/var/tmp 96K 34.7G 96K /var/tmp zroot 1.83G 34.7G 96K /zroot zroot/ROOT 1.24G 34.7G 96K none zroot/ROOT/default 1.24G 34.7G 1.24G / zroot/tmp 120K 34.7G 120K /tmp zroot/usr 608M 34.7G 96K /usr zroot/usr/home 136K 34.7G 136K /usr/home zroot/usr/ports 96K 34.7G 96K /usr/ports zroot/usr/src 607M 34.7G 607M /usr/src zroot/var 724K 34.7G 96K /var zroot/var/audit 96K 34.7G 96K /var/audit zroot/var/crash 96K 34.7G 96K /var/crash zroot/var/log 240K 34.7G 240K /var/log zroot/var/mail 100K 34.7G 100K /var/mail zroot/var/tmp 96K 34.7G 96K /var/tmp nik@vega:~ % zpool status pool: vega state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 config: NAME STATE READ WRITE CKSUM vega ONLINE 0 0 0 vtbd0p3 ONLINE 0 0 0 errors: No known data errors pool: zroot state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 vtbd0p3 ONLINE 0 0 0 errors: No known data errors nik@vega:~ % ------------------------------------------- It seems like there are two pools, sharing the same vdev... After running a few commands in this state, like doing a scrub, the pool was (most probably) destroyed. It couldn't boot anymore and I didn't research further. Is this a known bug? Steps to reproduce: install FreeBSD-11.0 in a pool named zroot reboot into a live-CD zpool import -f zroot vega reboot again Thanks, Nikos PS: Sorry for the cross-posting, I am doing this to share to more people because it is a rather easy way to destroy a ZFS pool. From owner-freebsd-stable@freebsd.org Mon May 15 18:11:41 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A77FD6E25A; Mon, 15 May 2017 18:11:41 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B0AF1580; Mon, 15 May 2017 18:11:40 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx103 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MdK8t-1dS8AT3Ebj-00IV1p; Mon, 15 May 2017 20:11:38 +0200 Subject: zpool imported twice with different names (was Re: Fwd: ZFS) From: Nikos Vassiliadis To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Message-ID: Date: Mon, 15 May 2017 20:11:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uLu4BIUWtdJ0ahoKpW3EEJSRvJQccXKvHLT3RdCAMbuDayOh7uf iralYDcwSiyjy7/zpuydwSKHO4cQdC99VxY+hY8dRV8lMAF57REOfnwQMfRrkJe5WWfEl7h QFJCv+eDEKe2pgyNKnkCt2aaqjjz0fEAauQtfi4RP1Yt52h1i4ZdQM8H3Kq2zgr8c+hfsOq fmsfiptoRVHA9RXrkKQQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:8KRWvFFTzcE=:S0+rVJV1sfmAzdUvB6I2Ai p5MpV+or3wVdGdW7EjTO+5ieijzyHwpUhcfYKJRHrmRS3G4z43YyMKLsCIQYF7ha1eJbbjBkm 1M5x5qJXFlWSbeYYzchWJmERTVtMHTpnAxA+HJ/8TluXKVSuEb9ltjloK5iuBoadjICxJs+vT LGNRFBoAt3taga6Y7SZDCE7WIaxTwd04MKWJsPpCzNd4sazjZXkCA3u7U4fpdWhuSGR5ZqByd S2obvxs0gEiK5AbGxHMlKi8mO4P+wYkt4yDl5rChQO1WZaOPA1n8bUHhobmKacyHbyk0i52y/ wZ6rT785eY4y9et6LlktXXZKAVkDfMQgHh9gc4EEyaR6aShyVbWfzm6KftURKRkcOrLaxNEd1 dmQiFG1WMtxCbmrQwlK2rDyXBqsWbK/NmWaqLPcL4b8rHOw2ZmDpOORx8QH90BXEXy3eiykgP pdIRwhdkoIhQIFQFg7Q0b8HWbamWHkIYY0AVhvsehLHzGcvpjcIsPWOz6rAaB877lVpCVCp5S S2iKubvvzMd4x9+eorEOnLkuOKZTCm04bnjCTk83ouf6RNu2H0xUBhcfTc1kramSjkx+2GSzs sexiN7aJ1HGkkGIMjBY1WNSTTeQTPyFYUDqII0tiZDj7WkHEw8PKCq5ZHFG6hObdPkzgC3Kd4 fG8DC+iQ2NPhwm8u+E5zpH+6Tqzf0cQ4H5Y+UFDeT4AmsIZ+cHhg6+oaarTU/f5MERLjd1fTW OBeIVplx9A9RIsJofOGhq7xDWIbRgnXLDjL/ftX2g+6o9N6zFMr3ZIFd5ROV2tIE5IhqFmcFx ZO664zc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 18:11:41 -0000 Fix the e-mail subject On 05/15/2017 08:09 PM, Nikos Vassiliadis wrote: > Hi everybody, > > While trying to rename a zpool from zroot to vega, > I ended up in this strange situation: > nik@vega:~ % zfs list -t all > NAME USED AVAIL REFER MOUNTPOINT > vega 1.83G 34.7G 96K /zroot > vega/ROOT 1.24G 34.7G 96K none > vega/ROOT/default 1.24G 34.7G 1.24G / > vega/tmp 120K 34.7G 120K /tmp > vega/usr 608M 34.7G 96K /usr > vega/usr/home 136K 34.7G 136K /usr/home > vega/usr/ports 96K 34.7G 96K /usr/ports > vega/usr/src 607M 34.7G 607M /usr/src > vega/var 720K 34.7G 96K /var > vega/var/audit 96K 34.7G 96K /var/audit > vega/var/crash 96K 34.7G 96K /var/crash > vega/var/log 236K 34.7G 236K /var/log > vega/var/mail 100K 34.7G 100K /var/mail > vega/var/tmp 96K 34.7G 96K /var/tmp > zroot 1.83G 34.7G 96K /zroot > zroot/ROOT 1.24G 34.7G 96K none > zroot/ROOT/default 1.24G 34.7G 1.24G / > zroot/tmp 120K 34.7G 120K /tmp > zroot/usr 608M 34.7G 96K /usr > zroot/usr/home 136K 34.7G 136K /usr/home > zroot/usr/ports 96K 34.7G 96K /usr/ports > zroot/usr/src 607M 34.7G 607M /usr/src > zroot/var 724K 34.7G 96K /var > zroot/var/audit 96K 34.7G 96K /var/audit > zroot/var/crash 96K 34.7G 96K /var/crash > zroot/var/log 240K 34.7G 240K /var/log > zroot/var/mail 100K 34.7G 100K /var/mail > zroot/var/tmp 96K 34.7G 96K /var/tmp > nik@vega:~ % zpool status > pool: vega > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > config: > > NAME STATE READ WRITE CKSUM > vega ONLINE 0 0 0 > vtbd0p3 ONLINE 0 0 0 > > errors: No known data errors > > pool: zroot > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > vtbd0p3 ONLINE 0 0 0 > > errors: No known data errors > nik@vega:~ % > ------------------------------------------- > > It seems like there are two pools, sharing the same vdev... > > After running a few commands in this state, like doing a scrub, > the pool was (most probably) destroyed. It couldn't boot anymore > and I didn't research further. Is this a known bug? > > Steps to reproduce: > install FreeBSD-11.0 in a pool named zroot > reboot into a live-CD > zpool import -f zroot vega > reboot again > > Thanks, > Nikos > > PS: > Sorry for the cross-posting, I am doing this to share to more people > because it is a rather easy way to destroy a ZFS pool. > From owner-freebsd-stable@freebsd.org Mon May 15 20:29:14 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DC22D6E16B for ; Mon, 15 May 2017 20:29:14 +0000 (UTC) (envelope-from mil@milshop.ru) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A3A3E32 for ; Mon, 15 May 2017 20:29:14 +0000 (UTC) (envelope-from mil@milshop.ru) Received: by mail-wm0-x22c.google.com with SMTP id v15so61825504wmv.1 for ; Mon, 15 May 2017 13:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=milshop-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=FLjbDiUOu+Ih3zcRMRuoMwBK+zOq9Ry1uAXiRKbOg5o=; b=nnUSPQf1Hi6uovFoeotcWbgQbDxpnZ/7ddXaADa2V0e58jxLDBeiw8wsMZ6aZ5wSFa /4OQHz1e89DmWmie/9+m+xHHqpuS6SgAAiTYv+KcYucx4kUgguljsTjZiD3qddiBxU25 1k0h9X7690g1DrBHyj3daobCn0WCwRPCW/MvEsq2RBSvI/kVohmDdL2nDchg85V5ul96 eCpTW95gByo16o/hWooDVW8sQAShmJ2/to88J6emhL5xTUBWeV5wLugvQ7Xtsz60qB/h WMIQd7MHT9+OMr5Czx7bogumH89Yn9fq1UIOHAutf3xxrIp0bW4GYwdjvkF3MSNypMe+ rVWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=FLjbDiUOu+Ih3zcRMRuoMwBK+zOq9Ry1uAXiRKbOg5o=; b=p8x3/4HqezV4Lr2RV5qJz5mDFWyR8JXb7jOngI/LzZBWrsI8sb/7ARC+ZkTTpQGNUP VZz9DR6e5UEbGcRkcluuoXnFFP36WsAn+kNbdJ32y3xDF+o6geYQrr2d16ZjQBSbYkLi g6dfWPM/F9PJwBvfdATjhRX37GJ6R4IDqwB5mQdIzvriwCUk/Z41goKd0K4kNbfiOO7S /kGmXCbAZisiJY8jnET93XdoD/hWVifg8Xz4igtGv0Y+GJlhJ2EA5WTo2RNYCHNcedJG kOlTdv//fKCAGPc/iimxUzmNcZdeNfTf21wkGTZlyeNdwgAsht+M3k1o3hnTCST75oRs RRQg== X-Gm-Message-State: AODbwcC1LsXia2t90iTseQtLI6amevKsftZlKXWN4NMC24rBWY+AAai7 5oW+Io6QehB9q9nSADunWLxgOzC0fHpz X-Received: by 10.25.15.30 with SMTP id e30mr2352014lfi.10.1494880152357; Mon, 15 May 2017 13:29:12 -0700 (PDT) MIME-Version: 1.0 Sender: mil@milshop.ru Received: by 10.25.22.42 with HTTP; Mon, 15 May 2017 13:28:51 -0700 (PDT) From: Eugene Kazarinov Date: Mon, 15 May 2017 23:28:51 +0300 X-Google-Sender-Auth: so8iRptVnneaRyd_3fyg-jaVxZw Message-ID: Subject: something is not working: ipfw fwd VIA nat TO tun on FreeBSD-11 stable r318266 To: FreeBSD Stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 20:29:14 -0000 Hello. After upgrade from 10.3 stable something broke. I have tun0 tun0: flags=8151 metric 0 mtu 1500 options=80000 inet 10.10.0.6 --> 10.10.0.5 netmask 0xffffffff groups: tun Opened by PID 1111 in pf.conf I have rule nat on tun0 inet from 192.168.10.0/24 to any -> 10.10.0.6 ipfw forwarding rule: ipfw 1500 fwd 10.10.0.5 ip from 192.168.10.0/24 to any via em0 ipfw sh counts 01500 1609 102098 fwd 10.10.0.5 ip from 192.168.10.0/24 to any via em0 So packets from network 192.168.10.0/24 forward to tun0 and I see it there BUT Why I see they not mapped?!: # tcpdump -ni tun0 23:02:15.207682 IP 192.168.10.2 > 8.8.8.8: ICMP echo request, id 1, seq 2253, length 40 On another side of tun0 there is no packets. If I ping 10.10.0.1 then I see right packets on both sided of tun0 (so tun0 is up and working) 23:03:15.989577 IP 10.10.0.6 > 10.10.0.1: ICMP echo request, id 25095, seq 0, length 64 23:03:15.992260 IP 10.10.0.1 > 10.10.0.6: ICMP echo reply, id 25095, seq 0, length 64 Why pf doesnt map packets which are forwarded via ipfw? BTW I'd try ipnat.rules map tun0 from 192.168.10.0/24 to any -> 10.10.0.6/32 but ipnat doesnt map forwarded packets too. Why? How to fix it?! From owner-freebsd-stable@freebsd.org Tue May 16 00:22:33 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD618D6C999 for ; Tue, 16 May 2017 00:22:33 +0000 (UTC) (envelope-from mil@milshop.ru) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BAE71055 for ; Tue, 16 May 2017 00:22:33 +0000 (UTC) (envelope-from mil@milshop.ru) Received: by mail-wm0-x22f.google.com with SMTP id b84so108016465wmh.0 for ; Mon, 15 May 2017 17:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=milshop-ru.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=E+3u7BwIN7OI4zhn9EY3hLj+CBxKueAzOuFjA5/IES8=; b=sXMlmFDr63btJupB0f3FK9/2g5iOj/HwSPMdtH3UMA91pZxraaOFoYpEyMW9UtZIZa JGQu6cLsdD6gt7UYOt4lY/nAexyxI/Yy14Zv6bZplw4wO1nABXbCUSkzaQET1FQhd1st L3dPvcLo0DWudp5fT7ydcg8F051FcZFMD+kRr1q6jKLkAuNZnQF6bLGceWCncFBwX9ok sORRItcknIVwfQ2WvFEn/nsOeJ4+qtCVlTG/qUHdXcrikvMAyaANhxRSZ7+mJ2R2j/tw rzQiLgCRpcvAkoMcct65lb/HRLm2Y5PNo90roypPElM8efucUJlk3yL5zGa27Sz1RLCb 9Nkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=E+3u7BwIN7OI4zhn9EY3hLj+CBxKueAzOuFjA5/IES8=; b=PJgyTI9p9Mk01Y/0bFHuQuityMzWiMoxvVi5dbsbsgXVV4JPp7PwOSjWMp5qOZf/oF 3FnhvG819fYwxkqwLEOpZArYIVUwAFcheLALTODuryeKieqOuCpvOjVsGISb4DakzqUc 2GoEQctEe6qjztL1Q5UGIpShrckquBBy6CL/IJlbm9zQJ1f6UpVKlW/CiWmgPuQk2nJR p9ByZQijQrW90J8TJEQiR1fem/KpdXb91nJLFxw+PSs1fOtNPnpOKNIvDL/0YKwa3/L8 Z9WfHCTx5wU6zd421wErDCOsCNbyoMKnIoKvhJzTDj2SZam6vVljQvauK7NkW8X1l500 mNag== X-Gm-Message-State: AODbwcD2sZzWUPiBlgXjsJgnpRgvHNkwTRRv3MWowxUIHsKdJGZ74dJF jM/PSFd8kdSGMgbCTE0lnp/5YGdxohg3 X-Received: by 10.46.77.91 with SMTP id a88mr2674560ljb.1.1494894151312; Mon, 15 May 2017 17:22:31 -0700 (PDT) MIME-Version: 1.0 Sender: mil@milshop.ru Received: by 10.25.22.42 with HTTP; Mon, 15 May 2017 17:22:10 -0700 (PDT) In-Reply-To: References: From: Eugene Kazarinov Date: Tue, 16 May 2017 03:22:10 +0300 X-Google-Sender-Auth: WJ9acZLMaKvKjhX3w5yU9O_DR5o Message-ID: Subject: Re: something is not working: ipfw fwd VIA nat TO tun on FreeBSD-11 stable r318266 To: FreeBSD Stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 00:22:34 -0000 I downgraded via makeworld&etc from /usr/src to 10.3-STABLE r318297 And now ipnat.rules is working and mapping forwarded packets. Maybe I forgot that pf nat didnt map forwarded packets on 10 version. I install this system some time ago. And dont remember which config is apply (ipnat.rules or pf.conf) By now I see that ipnat.rules is mapping forwarded packets on 10.3-STABLE and doesnt map they on version FreeBSD-11 stable r318266. So. Something in ipnat mechanism is broken in FreeBSD-11 stable r318266. 2017-05-15 23:28 GMT+03:00 Eugene Kazarinov : > Hello. > After upgrade from 10.3 stable something broke. > > I have tun0 > tun0: flags=8151 metric 0 mtu 1500 > options=80000 > inet 10.10.0.6 --> 10.10.0.5 netmask 0xffffffff > groups: tun > Opened by PID 1111 > > in pf.conf I have rule > nat on tun0 inet from 192.168.10.0/24 to any -> 10.10.0.6 > > ipfw forwarding rule: > ipfw 1500 fwd 10.10.0.5 ip from 192.168.10.0/24 to any via em0 > > ipfw sh counts > 01500 1609 102098 fwd 10.10.0.5 ip from 192.168.10.0/24 to any > via em0 > > So packets from network 192.168.10.0/24 forward to tun0 and I see it > there BUT > Why I see they not mapped?!: > > # tcpdump -ni tun0 > 23:02:15.207682 IP 192.168.10.2 > 8.8.8.8: ICMP echo request, id 1, seq > 2253, length 40 > On another side of tun0 there is no packets. > > If I ping 10.10.0.1 then I see right packets on both sided of tun0 (so > tun0 is up and working) > 23:03:15.989577 IP 10.10.0.6 > 10.10.0.1: ICMP echo request, id 25095, > seq 0, length 64 > 23:03:15.992260 IP 10.10.0.1 > 10.10.0.6: ICMP echo reply, id 25095, seq > 0, length 64 > > Why pf doesnt map packets which are forwarded via ipfw? > > BTW > I'd try > ipnat.rules > map tun0 from 192.168.10.0/24 to any -> 10.10.0.6/32 > > but ipnat doesnt map forwarded packets too. Why? > > How to fix it?! > > From owner-freebsd-stable@freebsd.org Tue May 16 04:48:03 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB5BED6FFE9; Tue, 16 May 2017 04:48:03 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.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 2B4211FC4; Tue, 16 May 2017 04:48:02 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-507ff700000001c7-56-591a834c83a1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 16.A8.00455.C438A195; Tue, 16 May 2017 00:42:52 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v4G4goDV021949; Tue, 16 May 2017 00:42:50 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4G4gjbp022836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 May 2017 00:42:48 -0400 Date: Mon, 15 May 2017 23:42:45 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - First Quarter 2017 Message-ID: <20170516044244.GD39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqrevTLBVp8POpiMWua6fZLea8+cBk sX3zP0aLw81CDiweMz7NZwlgjOKySUnNySxLLdK3S+DK2NL+hKlgwXumirV35BsY18xj6mLk 5JAQMJE48v85YxcjF4eQwGImia4rB9khnI2MEuvWvWSBcK4ySfROXsIK0sIioCpxaOdMZhCb TUBNYv2Ka2C2iIC8xL6m9+wgNrOAtcS/B41gcWEBW4nPU2eD9fICrbt1pIUdwhaUODnzCQtE fZlEc+taIJsDyJaWWP6PAyQsKqAs8ffwPZYJjHyzkHTMQtIxC6EDIqwu8WfeJWYMYW2JZQtf M0PYtkCPvWdZwMi+ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyi82V1UdzDO +et1iFGAg1GJh3fFCslIIdbEsuLK3EOMkhxMSqK8adVSkUJ8SfkplRmJxRnxRaU5qcWHGFWA dj3asPoCoxRLXn5eqpIIb50JUB1vSmJlVWpRPkyZNAeLkjivuEZjhJBAemJJanZqakFqEUxW hoNDSYJ3QyNQo2BRanpqRVpmTglCmomD8xCjBAcP0PDiBpDhxQWJucWZ6RD5U4zGHO+WfnjP xNF15s97JiGwO6TEeWeCjBMAKc0ozYObBkpdEtn7a14xigM9Ksy7uAmoigeY9uDmvQJaxQS0 KuylOMiqkkSElFQDo/3BIM76SQf0Z86OCNl9ySjpaPXaR3ckz2g8OuSt1XzMaOeR+q9b+s9p vnoz5WXyvGN7vkuEnEu2W5Xovt5tr1IRZ1Rl+RHhVd4Bqgu0Hi9c6MURdOx/ZEtGjEfR04tT uDbGy00WLDLiXrCq/Oi8zbIpShn94VEPHjs+XnVaoL3g2Qqjl6kHEpRYijMSDbWYi4oTAVsv EUM4AwAA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 04:48:04 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - 1st Quarter 2017 While a few of these projects indicate they are a "plan B" or an "attempt III", many are still hewing to their original plans, and all have produced impressive results. Please enjoy this vibrant collection of reports, covering the first quarter of 2017. --Benjamin Kaduk __________________________________________________________________ The deadline for submissions covering the period from April to June 2017 is July 7, 2017. __________________________________________________________________ FreeBSD Team Reports * The FreeBSD Core Team * The FreeBSD Foundation * The FreeBSD Ports Collection * The FreeBSD Release Engineering Team Projects * Ceph on FreeBSD * OpenBSM * Porting Software to CloudABI: Sandboxed Bitcoin! * Support for eMMC Flash and Faster SD Card Modes * TrustedBSD Kernel * FreeBSD on Hyper-V and Azure * Intel 10G and 40G Network Driver Updates * Linuxulator * MMC Stack Using the CAM Framework * pNFS Server Plan B Architectures * 64-bit PowerPC Book-E Support * FreeBSD on Marvell Armada38x * FreeBSD/s390x Attempt III Ports * MySQL * Rust Documentation * The FreeBSD Dutch Documentation Project __________________________________________________________________ FreeBSD Team Reports The FreeBSD Core Team Contact: FreeBSD Core Team Core's primary function is to ensure the long-term viability of the FreeBSD project. A very large part of that is to ensure that the interactions between developers remain cordial, and consequently that the project appears welcoming to newcomers. Normally, most of Core's activities around this are done in private -- a quiet word in the right ear, some discrete peacemaking, occasional reading of the riot act. Most of the time, this is all that is necessary. Unfortunately, this quarter we had an instance where such private measures failed to achieve the desired result, and we ended up ejecting a developer. This developer is an extremely talented programmer and has made significant contributions to the Ports Collection. Despite this, portmgr found him to be sufficiently disruptive and abrasive that in their judgement, the project was better off overall to sever his connection to itself, and core backed them up in that. We are sorry that events came to this sad conclusion, but we remain convinced that this was a necessary step to safeguard the character of our community. In a more positive light, Core has been working on a proposal to recognise notable contributors to the FreeBSD project who are not (or perhaps not yet) suitable to be put forward as new committers. In addition to the usual routes of recognising people that write numbers of good bug reports or that supply patches or that volunteer to maintain ports, this will also allow recognition of people who contribute by such things as organising FreeBSD events or who promote FreeBSD through social media. A formal announcement of Core's proposal is imminent. During January, the core secretary held an exercise to contact all source committers who had been inactive for more than 18 months and persuade them to hand in their commit bits if they were not planning to resume working on FreeBSD in the near future. This is meant to be a routine function -- the "grim reaper" -- that aims to keep the list of people with the ability to commit pretty much in synchrony with the list of people that are actively committing. The regular process had fallen out of activity several years ago, and we needed to clear the decks before restarting. Ultimately, this resulted in some 20 developers-emeritus handing in their commit bits. No new commit bits were awarded during this quarter. Core is also taking soundings on producing a 10.4-RELEASE. This is not in the current plan, but a number of developers and important FreeBSD users would be keen to see it happen, given some of the work that has gone into the stable/10 branch since 10.3-RELEASE. On the other hand, this would represent an additional support burden for the Security Team, including maintaining versions of software that have been declared obsolete upstream, in particular OpenSSL. As an even-numbered release, 10.4-RELEASE would have a "normal" rather than an "extended" lifetime which means it should not result in extending the support lifetime of the stable/10 branch. In other news, Core arranged for the old and largely inactive marketing@FreeBSD.org mailing list to be wound up, and for any remaining activities to be transferred to the FreeBSD Foundation. Core also asked clusteradm to turn off Internet-wide access to the finger server on freefall.freebsd.org. Many developers have included details such as phone numbers into the GECOS field of their FreeBSD password database entries, and these would be revealed by the finger server -- details which are nowadays generally felt inadvisable to expose publicly. finger is still available internally within freefall.freebsd.org. Core recommends that GECOS data is limited to just your full name, and we have updated the standard "new committer" e-mail template to reflect that. Core is looking for new volunteers to help out with several of the teams that manage various aspects of the project. In particular, Postmaster and the Security Team are in need of new blood. Recruiting for a new member of the Security Team is well under way, but anyone interested in joining any of the teams is encouraged to make themselves known either to Core or directly to the teams concerned. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ Quarterly Newsletter URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/03/FreeB= SD-Foundation-Q1-2017-Update.pdf 2017 Storage Summit URL: https://wiki.FreeBSD.org/201702StorageSummit Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Our work is 100% funded by your donations. We kicked off the new year with some large contributions from Intel and NetApp, to help us raise over $400,000 last quarter! We engaged in discussions with new and old commercial users to help facilitate collaboration, explain how the Project works, and to ask for financial contributions to help us keep FreeBSD the innovative, secure, and reliable operating system they depend on. Please consider making a donation today! https://www.FreeBSDfoundation.org/donate/. The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. Our contributions also include funding separate project grants like the arm64 port, blacklistd access control daemon, and integration of VIMAGE support, to make sure FreeBSD remains a viable solution for research, education, computing, products and more. This quarter's project development highlights include: * 168 commits sponsored by the FreeBSD Foundation in the src tree (base system) development branch, across three staff members and four grant recipients/other developers. * Multiple funded grants, including the cfumass project, now committed to FreeBSD-HEAD, and improvements to the blacklistd daemon and FreeBSD/arm64 port. * Staff contributions including improvements to toolchain and build tool components, run time libraries, arm64, mips64 and 32- and 64-bit x86 architectures, release image build tooling, packaged base, and VM subsystem bug fixes. * Significant progress on the 64-bit inode project, which is nearly ready for commit. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting to use FreeBSD or contribute to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. Some of the highlights of our advocacy and education work over the last quarter: * Promoted FreeBSD at: FOSDEM, SCALE, AsiaBSDcon, and FOSSASIA * Promoted BSDCan, SCALE, USENIX LISA, vBSDcon and EuroBSDcon Calls for Participation * Promoted Google Summer of Code participation on social media and created a flyer for people to post at their universities * Published a New Faces of FreeBSD Story: Joseph Kong * Set up a Marketing Partnership with the USENIX Association and SNIA * Published and Promoted the Jan/Feb 2017 issue of the FreeBSD Journal: https://www.FreeBSDfoundation.org/journal/ * Published monthly Development Projects Updates on our blog * Secured a FreeBSD table at OSCON and promoted available discounts Conferences and Events The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users; this all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness about FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We also sponsored and/or attended the following events last quarter: * FOSDEM FreeBSD developer summit (sponsor) * AsiaBSDCon -- Tokyo, Japan (sponsor) * Organized and ran the FreeBSD Storage Summit in Santa Clara, CA * Board member Philip Paeps gave a FreeBSD presentation at FOSSASIA * Attended FOSSASIA, FOSDEM, and SCALE Release Engineering The Foundation provides a full-time staff member to lead the release engineering efforts. This has provided timely and reliable releases over the last few years. Some highlights from last quarter include: * Continued the production of weekly development snapshots for the 12-CURRENT, 11-STABLE, and 10-STABLE branches. * Published the initial FreeBSD 11.1-RELEASE schedule to the Project website. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We continued to review requests and grant permission to use the trademarks. Many more details about how we supported FreeBSD last quarter can be found in our Q1 newsletter! __________________________________________________________________ The FreeBSD Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.FreeBSD.org/index.html Ports Management Team URL: https://www.FreeBSD.org/portmgr/index.html FreeBSD portmgr on Twitter (@FreeBSD_portmgr) URL: https://twitter.com/FreeBSD_portmgr/ FreeBSD Ports Management Team on Facebook URL: https://www.facebook.com/portmgr FreeBSD Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: Ren=C3=A9 Ladan Contact: FreeBSD Ports Management Team The number of ports is currently just 500 short of 30,000. The current number of PRs is close to 2,400, of which 620 are unassigned. The last quarter saw 6656 commits from 167 comitters. Both the number of ports and the number of unassigned PRs have increased in the last quarter. In the last quarter, we welcomed 7 new committers: Eugene Grosbein (eugen), Johannes Dieterich (jmd), Larry Rosenman (ler), Mahdi Mokhtari (mmohki), Matthew Rezny (rezny), Tobias Kortkamp (tobik), and Vladimir Kondratyev (wulf). dumbbell@ was already a src committer and got an extension for the Ports Tree. We also welcomed back krion@ and miwi@. We took 6 bits in for safe-keeping: itetcu@, leeym@, mva@, olivierd@, pgollucci@, and sanpei@. There were no changes to the membership of portmgr. antoine@ worked on USES=3Dsamba to prepare for the removal of the long-outdated Samba 3.6 ports and replace them with modern versions. The new default versions are: FreePascal 3.0.2, Ruby 2.3, and Samba 4.4. A new variable USE_LOCALE was created to add the LANG and LC_ALL environment variables to all builds. Out-of-tree patches can now be added with the new EXTRA_PATCH_TREE variable. The error messages for invalid OPTIONS_SINGLE options were improved. Some of the major port updates last quarter were: pkg 1.10.1, linux c6_64, Firefox 52.0.2, Chromium 57.0.2987.110, GCC 4.9.4, Gnome 3.18.0, Xorg 1.18.4, Qt 4.8.7 and 5.7.1, and PHP 7.1. antoine@ ran 31 exp-runs to test version updates and under-the-hood changes. Open tasks: 1. The number of unassigned and open PRs is still growing, so if you have some spare time, please close some of those. __________________________________________________________________ The FreeBSD Release Engineering Team Links FreeBSD 11.1-RELEASE Schedule URL: https://www.freebsd.org/releases/11.1R/schedule.html FreeBSD development Snapshots URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team continued producing weekly development snapshots for the 12-CURRENT, 11-STABLE, and 10-STABLE branches. In addition, the FreeBSD 11.1-RELEASE schedule was added to the Project website. Please note, however, the schedule on the website is still subject to change. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Projects Ceph on FreeBSD Links Ceph Main Site URL: http://ceph.com Main Repository URL: https://github.com/ceph/ceph My FreeBSD Fork URL: https://github.com/wjwithagen/ceph Contact: Willem Jan Withagen Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability. * Object Storage Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface that is compatible with applications written for S3 and Swift. * Block Storage Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. * File System Ceph provides a POSIX-compliant network file system that aims for high performance, large data storage, and maximum compatibility with legacy applications. I started looking into Ceph because the HAST solution with CARP and ggate did not really do what I was looking for. But I aim to run a Ceph storage cluster of storage nodes that are running ZFS. User stations would be running bhyve on RBD disks that are stored in Ceph. Compiling for FreeBSD will now build most of the tools available in Ceph. Notable progress since the last report: * The most important change is that a port has been submitted: net/ceph-devel. However, it does not yet contain ceph-fuse. * Regular updates to the ceph-devel port are expected, with the next one coming in April. * ceph-fuse works, allowing one to mount a CephFS filesystem on a FreeBSD system and perform normal operations. * ceph-disk prepare and activate work for FileStore on ZFS, allowing for easy creation of OSDs. * RBD is actually buildable and can be used to manage RADOS BLOCK DEVICEs. * Most of the awkward dependencies on Linux-isms are deleted -- only /bin/bash is here to stay. To get things running on a FreeBSD system, run pkg install net/ceph-devel or clone https://github.com/wjwithagen/ceph and build manually by running ./do_freebsd.sh in the checkout root. Parts not (yet) included: * KRBD: Kernel Rados Block Devices are implemented in the Linux kernel, but not yet in the FreeBSD kernel. It is possible that ggated could be used as a template, since it does similar things, just between two disks. It also has a userspace counterpart, which could ease development. * BlueStore: FreeBSD and Linux have different AIO APIs, and that incompatibility needs to resolved somehow. Additionally, there is discussion in FreeBSD about aio_cancel not working for all devicetypes. * CephFS as native filesystem: though ceph-fuse works, it can be advantageous to have an in-kernel implementation for heavy workloads. Cython tries to access an internal field in struct dirent, which does not compile. Open tasks: 1. Run integration tests to see if the FreeBSD daemons will work with a Linux Ceph platform. 2. Compile and test the userspace RBD (Rados Block Device). This currently works but testing has been limitted. 3. Investigate and see if an in-kernel RBD device could be developed akin to ggate. 4. Investigate the keystore, which can be embedded in the kernel on Linux and currently prevents building Cephfs and some other parts. The first question is whether it is really required, or only KRBD requires it. 5. Scheduler information is not used at the moment, because the schedulers work rather differently between Linux and FreeBSD. But at a certain point in time, this will need some attention (in src/common/Thread.cc). 6. Improve the FreeBSD init scripts in the Ceph stack, both for testing purposes and for running Ceph on production machines. Work on ceph-disk and ceph-deploy to make it more FreeBSD- and ZFS-compatible. 7. Build a test cluster and start running some of the teuthology integration tests on it. Teuthology wants to build its own libvirt and that does not quite work with all the packages FreeBSD already has in place. There are many details to work out here. 8. Design a vitual disk implementation that can be used with bhyve and attached to an RBD image. __________________________________________________________________ OpenBSM Links OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation URL: http://www.openbsm.org OpenBSM on GitHub URL: https://github.com/openbsm/openbsm FreeBSD Audit Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/audit.h= tml DTrace Audit Provider URL: https://reviews.FreeBSD.org/D10149 DARPA CADETS project URL: https://www.cl.cam.ac.uk/research/security/cadets/ TODO List on GitHub URL: https://github.com/openbsm/openbsm/blob/master/TODO Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD audit mailing list OpenBSM is a BSD-licensed implementation of Sun's Basic Security Module (BSM) API and file format. It is the userspace side of the CAPP Audit implementations in FreeBSD and Mac OS X. Additionally, the audit trail processing tools are expected to work on Linux. During this quarter, experimental support for UUIDs in BSM trails was added to OpenBSM. A DTrace audit provider using this functionality has been developed as part of the DARPA CADETS project and is in review (https://reviews.FreeBSD.org/D10149). In the OpenBSM GitHub repository, support for Coverity static analysis was added via TravisCI. Additionally, the OpenBSM 1.2-alpha5 release has been merged into the FreeBSD HEAD branch. This project was sponsored by DARPA/AFRL (in part). Open tasks: 1. Test the latest release on different versions of FreeBSD, Mac OS X and Linux. Testing on the latest versions of Mac OS X would be particularly appreciated. 2. Fix problems that have been reported via GitHub and the FreeBSD bug tracker. 3. Implement the features mentioned in the TODO list on GitHub. __________________________________________________________________ Porting Software to CloudABI: Sandboxed Bitcoin! Links How to Use CloudABI on FreeBSD URL: https://nuxi.nl/cloudabi/freebsd/ LevelDB for CloudABI URL: https://nuxi.nl/blog/2017/02/18/porting-leveldb-to-cloudabi.html Memcached for CloudABI URL: https://nuxi.nl/blog/2017/03/15/sandboxed-memcached.html Bitcoin for CloudABI URL: https://laanwj.github.io/2017/03/02/porting-bitcoin-core-to-clouda= bi.html Contact: Ed Schouten CloudABI is a framework that allows you to develop strongly sandboxed applications a lot more easily. It is a programming environment that exclusively uses FreeBSD's Capsicum facilities. Any features incompatible with Capsicum have been removed entirely, which means that it is easier to determine how code needs to be adjusted to behave correctly while sandboxed. In essence, you only need to patch up the code until it builds. Last year we have managed to port a lot of exciting libraries over to CloudABI. Highlights include sandboxing aware versions of Boost and LevelDB. Now that these libraries are readily available, we are at the point where we can shift our focus towards porting full applications. In late February one of the lead developers of the Bitcoin reference implementation got in touch, as he is very interested in creating a copy of Bitcoin that is better protected against security bugs. You do not want a security bug in the networking/consensus code to allow an attacker to steal coins from your local wallet! As I think that this is a use case that demonstrates the strength of CloudABI well, I've made addressing any issues reported by the Bitcoin developers a top priority. Once the Bitcoin port is complete, we want to provide binary packages of it as well. This project was sponsored by Nuxi, the Netherlands. Open tasks: 1. Though getting Bitcoin to work is pretty awesome, don't let that distract us from porting other pieces of software over as well! Are you the maintainer of a piece of software that could benefit from sandboxing? Be sure to try building it using the CloudABI toolchain! 2. One of the pieces of software that got ported over to CloudABI some time ago is Memcached. Are you a user of Memcached? If so, feel free to give the sandboxed version of Memcached for CloudABI a try! 3. So far, CloudABI can be used to run software written in C, C++ and Python. Would you like to see any other programming language work on CloudABI as well? Be sure to help out! __________________________________________________________________ Support for eMMC Flash and Faster SD Card Modes Contact: Marius Strobl In r315430, support for eMMC partitions has been added to mmc(4) and mmcsd(4) in FreeBSD 12. Besides the user data area, i.e., the default partition, eMMC v4.41 and later devices can additionally provide up to: * 1 enhanced user data area partition * 2 boot partitions * 1 RPMB (Replay Protected Memory Block) partition * 4 general purpose partitions (optionally with an enhanced or extended attribute) Apart from simply subdividing eMMC flash devices or having UEFI code in the boot partition, as is done on some Intel NUCs, another use case for partition support is the activation of pseudo-SLC mode, which manufacturers of eMMC chips typically associate with the enhanced user data area and/or the "enhanced" attribute of general purpose partitions. In order to be able to partition eMMC devices, r315430 also added a Linux-compatible ioctl(2) interface to mmcsd(4). This allows the use of the GNU mmc-utils (found in ports as sysutils/mmc-utils) on FreeBSD. Besides partitioning eMMC devices, the mmc tool can also be used to query for lifetime estimates and pre-EOL information of eMMC flash, as well as to query some basic information from SD cards. CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation. Additionally, in order to make eMMC flash devices more usable, support for DDR (Dual Data Rate) bus speed mode at a maximum of 52 MHz (DDR52) has been added to mmc(4) and sdhci(4) in r315598, which will appear in FreeBSD 12. Compared to high speed mode (the previous maximum) at 52 MHz, DDR52 mode increases the performance of the tested eMMC chips from ~45 MB/s to ~80 MB/s. So far, support for DDR52 mode has been enabled for the eMMC controllers found in the Intel Apollo Lake, Bay Trail and Braswell chipsets. Note, however, that the eMMC and SDHCI controllers of the Apollo Lake variant occasionally lock up due to a silicon bug (which is independent of running in DDR52 mode). The only viable workaround for that problem appears to be the implementation of support for ADMA2 mode in sdhci(4) (currently, sdhci(4) supports only the encumbered SDMA mode or no DMA at all). However, r315598 also brought in infrastructure and a fair amount of code for using even faster transfer modes with eMMC devices and SD cards respectively, i.e., up to HS400ES with eMMC and the UHS-I modes up to SDR104 with SD cards. The intent is to merge these changes back to FreeBSD 10 and 11. Open tasks: 1. Add support for eMMC HS200, HS400, and HS400ES transfer modes. 2. Add support for SD card UHS-I transfer modes (SDR12 to SDR104). 3. Make mmcsd(4) more robust and correctly follow the relevant specifications for existing features, e.g., calculate and handle erase timeouts, do a SEND_STATUS when CMD6 is invoked with an R1B response to the extent not already fixed as part of r315430, get the remainder of the existing code to properly check and handle return codes, etc. __________________________________________________________________ TrustedBSD Links TrustedBSD Website URL: http://www.trustedbsd.org TrustedBSD on GitHub URL: https://github.com/trustedbsd Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD announce mailing list The TrustedBSD Project is an open-source community developing advanced security features for the open-source FreeBSD operating system. Started in April 2000, the project developed support for extended attributes, access control lists (ACLs), UFS2, OpenPAM, security event auditing, OpenBSM, a flexible kernel access control framework, mandatory access control, and the GEOM storage layer. The results of this work may be found not just in FreeBSD, but also NetBSD, OpenBSD, Linux, and Apple's Mac OS X and iOS operating systems. Today, the project continues to maintain and enhance these mature features in FreeBSD. During this quarter, the TrustedBSD project transitioned from the FreeBSD Perforce server to GitHub. This was made possible by Alexis Sarghel, who owned the user "trustedbsd" on GitHub and graciously transferred this account to the TrustedBSD project. To date, the repositories hosting the TrustedBSD website and the SEBSD repository have been moved. __________________________________________________________________ Kernel FreeBSD on Hyper-V and Azure Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Supported Linux and FreeBSD Virtual Machines for Hyper-V on Windows URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Sepherosa Ziehau Contact: Hongjiang Zhang Contact: Dexuan Cui Contact: Kylie Liang SR-IOV support for NICs is implemented. So far, we have only tested with the Mellanox ConnectX-3 VF card, which works despite some issues (Bug 216493: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D216493). Updates for UEFI VMs (i.e., Hyper-V Generation 2 VMs): 1. After the loader issue (Bug 211746) is fixed, UEFI VMs can now boot with Secure Boot disabled; 2. A synthetic keyboard driver has been added. Currently it is only in HEAD, but MFCs to stable/10 and stable/11 are planned to occur soon; 3. A SCSI DVD detection issue (Bug 218248) was fixed. Without the fix, the VM would fail to boot. This project was sponsored by Microsoft. __________________________________________________________________ Intel 10G and 40G Network Driver Updates Links Commit adding X553 ix/ixv Support for iflib URL: https://reviews.FreeBSD.org/D9851 Commit converting ixgbe to iflib URL: https://reviews.FreeBSD.org/D5213 Contact: Jeb Cramer Contact: Eric Joyner Contact: Krzysztof Galazka This driver update is for the Intel ix/ixv and ixl/ixlv network drivers, and includes support for several new hardware releases. ix/ixv: * Added support for X553 SoC devices based on the Denverton platform ixl/ixlv: * Added support for X722 10G SoC devices based on the Lewisburg chipset * Added an interface for the upcoming iWarp driver for X722 devices * Added support for XXV710 25G devices Open tasks: 1. ix/ixv iflib support is currently under review in Phabricator. It will be refactored to include D5213. 2. Initial work for ixl/ixlv iflib support is in progress. __________________________________________________________________ Linuxulator Contact: Dimitry Chagin Contact: Edward Tomasz Napiera=C5=82a Contact: Mahdi Mokhtari In this quarter, we are pleased to announce two (of many) works achieved in the Linuxulator. We added a new placeholder marker UNIMPLEMENTED to accompany the previously existing DUMMY, for distinguishing syscalls that the Linux kernel itself does not implement from those that we currently do not implement. Now our linux_dummy.c is clearer for newcomers to follow, and they will quickly know which areas they can start working on. Support for two new syscalls, preadv and pwritev, was added to the Linuxulator. Open tasks: 1. We plan to implement the execveat syscall for the native FreeBSD syscall table and then port/wrap it for use in the Linuxulator. __________________________________________________________________ MMC Stack Using the CAM Framework Links Project Information URL: https://bakulin.de/freebsd/mmccam.html Source Code URL: https://github.com/kibab/FreeBSD/tree/mmccam-collapsed-commits Contact: Ilya Bakulin The goal of this project is to reimplement the existing MMC/SD stack using the CAM framework. This will permit utilizing the well-tested CAM locking model and debugging features. It will also be possible to process interrupts generated by the inserted card, which is a prerequisite for implementing the SDIO interface. SDIO support is necessary for communicating with the WiFi/BT modules found on many development boards, such as the Raspberry Pi 3. Another feature that the new stack will have is support for sending SD commands from userland applications using cam(3). This will allow for building device drivers in userland and make debugging much easier. The new stack is able to attach to an SD card and bring it to an operational state so that it is possible to read and write to the card. The stack has been tested to work on the Beaglebone Black and Wandboard Quad platforms. Currently the code is being prepared for inclusion in the FreeBSD source tree. cam(3) is being extended to support SDIO-specific functions (reading registers, managing interrupts, etc.). Open tasks: 1. Integrate the code into FreeBSD HEAD to facilitate testing. 2. Begin writing a driver for Broadcom-based WLAN chips (found on the Raspberry Pi 3 and Wandboard). 3. Begin writing a driver for Marvell-based WLAN chips (found on the GlobalScale Dreamplug and some Chromebooks). __________________________________________________________________ pNFS Server Plan B Contact: Rick Macklem Parallel NFS (pNFS) is an extension to the NFSv4 protocol that allows for file accesses within a single logical mount to be performed against multiple file servers, with the potential for data access to occur in parallel. The pNFS "layout" in use specifies how the division occurs, with metadata operations occurring against the main server, and bulk data operations (read/write/setattr/etc.) occurring via a layout-specific scheme between the client and data servers. My first attempt at a pNFS server using GlusterFS was a dud. It worked, but performance was so poor that it was not usable. This attempt that I call "Plan B", only uses FreeBSD, with one FreeBSD server handling the metadata operations and multiple FreeBSD servers configured to serve data. An NFSv4.1 client that supports the pNFS File Layout will be able to read and write to the data servers directly, spreading out the RPC load and allowing growth beyond that of what a single FreeBSD NFS server could achieve. There is no support for the Flex Files Layout or mirroring at this time. I hope to use the Flex Files Layout to add mirroring support over the next year or so. Striping is also not supported, but I have no plans for implementing it at the moment. Plan B is working quite well now and should be available for testing by the end of April. I will announce how to do this on the freebsd-fs@FreeBSD.org mailing list when it is available. Open tasks: 1. Testing by others will be needed, once it is available. __________________________________________________________________ Architectures 64-bit PowerPC Book-E Support Contact: Justin Hibbits The Book-E platform target now supports 64-bit mode ("powerpc64"). It includes a 63-bit address space split, but the page table directory list uses holes to expand to the full address space, leaving gaps in the address space where page mappings are repeated. This may change in the future. As with the AIM powerpc64 port, Book-E supports running powerpc (32-bit) binaries as well, and has even been tested with a 32-bit init and 64-bit shell. Several of the SoC drivers are supported, however, the dTSEC ethernet controller is not yet supported. Work is ongoing to support it. A QORIQ64 config is included, targeting the P5 and T* series SoCs from Freescale. Thanks to Juniper Networks for providing patches against an older internally maintained FreeBSD version, which enabled this porting effort, and for providing historical context for quirks of the pmap changes. Open tasks: 1. Port the dTSEC driver to 64-bit. There are assumptions in the reference driver of operating in a 32-bit environment. It may be easier to port the Linux driver instead, which would also give ARM support for this ethernet controller. 2. Take advantage of pointer alignment to squeeze more bits out of the page tables; it should be possible to squeeze at least 3 more bits out, one at each level. __________________________________________________________________ FreeBSD on Marvell Armada38x Contact: Marcin Wojtas Contact: Zbigniew Bodek Final testing and productionization of support for the Marvell Armada38x platform is under way. The rebase and cleanup is going well, with patches functioning on top of HEAD and ready for upstreaming. Specific tasks completed include: * Platform benchmarking and low-level optimizations (internal bus, L1/L2 cache prefetch) -- already submitted) * Enable the PL310 L2 cache controller -- currently under review * NETA tests, optimizations and PHY-handling rework * e6000sw PHY handling rework and fixes * Fix and enable performance counter support * Fix timers and extract watchdog support to a separate driver * Crypto driver fixes -- merged * AHCI controller support -- merged * Thermal driver -- merged * Merge additional support for new boards (SolidRun ClearFog and DB-88F6285-AP) This project was sponsored by Stormshield, and Semihalf. Open tasks: 1. Submit the remaining fixes and drivers. __________________________________________________________________ FreeBSD/s390x Attempt III Contact: Bjoern A. Zeeb A long time ago, in the FreeBSD 5 times, there was an initial port of FreeBSD to s390 (32bit) and s390x (64bit) which booted past init on good days in an emulator. As an attempt to revive the s390x/systemz efforts I started to get FreeBSD s390x to build with clang/llvm 3.9. At this time, it is possible to build world and a GENERIC kernel skeleton (not doing anything yet) using external binutils. The primary idea of this initial work was to allow for incremental addition of the necessary architecture-specific code. Having the build framework in place will allow third-party developers to simply type make, as they are willing to contribute to the port without having to know FreeBSD build specifics. After some cleanup and further updates to a more recent HEAD I am planning to push the current work to a public repo to facilitate collaboration. Open tasks: 1. Write a wiki page with per-architecture specific tasks that need to be done, based on the current work and the experience from arm64 and riscv. 2. Implement both the userspace and kernel per-architecture gaps. 3. Figure out a way to get access to IBM's zPDT or better emulators to ease implementation, testing, and debugging. __________________________________________________________________ Ports MySQL Links MySQL80 Overview URL: https://www.mysql.com/why-mysql/presentations/mysql-80-overview/ MySQL80 InnoDB New Features URL: https://www.mysql.com/why-mysql/presentations/innodb-whats-new-mys= ql-80/ Contact: Mahdi Mokhtari Contact: Mark Felder This quarter a new -dev version of MySQL landed in the Ports Collection, MySQL 8.0. It introduces many new features, though we had to (re)-patch parts of it which were merged by MySQL from MySQL5.7. We also updated MySQL 5.6 to its latest version and closed many PRs related to it, mostly relating to using FreeBSD-provided ports for libraries instead of the bundled copies. And of course there were plenty of security updates. We can also report that the problem of having to specify ${mysql_optfile}, which some people encountered while using MySQL, is now considered to be solved in all MySQL versions: 5.6, 5.7, and 8.0. Now the init script will search all default locations, for backwards compatibility with the variety of locations used for configuration files, before it gives up and reports an error. Open tasks: 1. Test the new version and report problems. __________________________________________________________________ Rust Links Wiki Portal URL: https://wiki.FreeBSD.org/Rust Guide to Bootstraping Rust on FreeBSD URL: https://gist.github.com/dumbbell/b587da50ef014078da9e732a4331ebad Bug Report to Track Progress on Bootstrapping URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D216143 Contact: Jean-S=C3=A9bastien P=C3=A9dron Contact: Thomas Zander In the Ports Collection, Rust was updated to 1.16.0 and Cargo to 0.17.0, the latest versions at the time of this writing. lang/rust-nightly was also updated to a snapshot from February and it is now enabled on i386. It is lagging a bit behind upstream, but Rustup works nicely on FreeBSD if you need to try any versions/channels of Rust. Work has started to bootstrap Rust on non-x86 architectures. Patches to add FreeBSD/aarch64 support were submitted and accepted upstream. FreeBSD/sparc64 is in progress. The lang/rust-nightly port is also being adapted to compile natively on FreeBSD/aarch64. This work is critical, in particular because Firefox will shortly require Rust. If you want to help, please refer to the guide linked above. The compiler, rustc, is crashing sometimes when there is a compilation error. Therefore, there is a bit of work to do to improve stability. There is some code duplication between lang/rust* and devel/cargo. Those Makefiles deserve a bit of cleanup. It might be useful to create a USES=3Drust Makefile helper. Open tasks: 1. Bootstrap Rust on more platforms. 2. Investigate compiler crashes. 3. Create a USES=3Drust Makefile helper and simplify the Rust and Cargo ports. 4. Investigate how to speed up lang/rust* compilation time. __________________________________________________________________ Documentation The FreeBSD Dutch Documentation Project Links The Dutch Translation Project URL: https://www.FreeBSD.org/docproj/translations.html#dutch Contact: Ren=C3=A9 Ladan Contact: Remko Lodder Work has started on an initial translation of the FreeBSD Handbook to the Dutch language via the "po" system. While we have an (outdated) version of the Handbook available via the older XML files, we are now trying to get back into shape with the PO file. Rene started working on two articles already and did some translation of strings for the FDP-Primer, while Remko has started working on the Handbook. If you think you can assist with either, please send Rene and Remko an email so that we can start coordinating work. In addition, since we have a translation set already from the XML files, it would be interesting to see whether we can merge them easily into the PO structure. If you have ideas on that, contact us a.s.a.p. This project was sponsored by Snow B.V. (in part). Open tasks: 1. Identify a way to merge the current XML translations into the nl_NL.po files. 2. Merge the translations into the .po files. 3. Update the remaining open items into the po files. 4. Remove the old/outdated translation files from the main repo and use the po and book.xml files to generate the Dutch handbook and other files. 5. Identify whether we can also translate the htdocs pages via the PO system. __________________________________________________________________ --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAABCgAGBQJZGoM+AAoJECjZpvNk63UShiEMHiNj+z/V8LxFhIyFRTsKOJNQ KgEiR6NuUgGSYoanKkzSf2BO5MnhfbN3tSnxMx+WphyoV1WFdSiYBpgZEHOGWmta Z3pG6ov4n8IrHwhX71CoWcwawumDcA6aUrPoHlkJcG0HfLiyfp47BjHS85RmneR0 6BxcrvaCBkguL1fyiQUBlHqyhpFK0GqUBdihvkAUKFBjfXmPFLvmlJczrrDghbn6 ALD948qxIrGvvjAidp19gwft+9BMi6uxxLr+WAHQD5MejF3y8w7D1KPv3cJiaUV8 NULjQr+bGqkfvtRGKs94MyQdsvM+71QLsrpaVTdckMFlxTsRbRSkzzNGKWoi6vNR HF34QWqEE3upiqIEncSpDQY1wHi0yaL8VqAANavfUQT/xY1ZVwxdGaqx8mtUts4r T2solV102RYjVtXeS97/8u+1nqq8h9IVmttmQPLI8hj6MKCkurE0uOr169gXBmoy IV0A+cxjC6D2cKVRS5UwOjapt32l6bQQbgwADf+D8gwNHMk= =D2eA -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-stable@freebsd.org Tue May 16 06:31:50 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 284E8D6FA5B; Tue, 16 May 2017 06:31:50 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8D8F1954; Tue, 16 May 2017 06:31:49 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id v4G6VMSk076391 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 May 2017 08:31:22 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id v4G6VLvX076388; Tue, 16 May 2017 08:31:21 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 16 May 2017 08:31:21 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Nikos Vassiliadis cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) In-Reply-To: Message-ID: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:31:50 -0000 On Mon, 15 May 2017 20:11+0200, Nikos Vassiliadis wrote: > Fix the e-mail subject > > On 05/15/2017 08:09 PM, Nikos Vassiliadis wrote: > > Hi everybody, > > > > While trying to rename a zpool from zroot to vega, > > I ended up in this strange situation: > > nik@vega:~ % zfs list -t all > > NAME USED AVAIL REFER MOUNTPOINT > > vega 1.83G 34.7G 96K /zroot > > vega/ROOT 1.24G 34.7G 96K none > > vega/ROOT/default 1.24G 34.7G 1.24G / > > vega/tmp 120K 34.7G 120K /tmp > > vega/usr 608M 34.7G 96K /usr > > vega/usr/home 136K 34.7G 136K /usr/home > > vega/usr/ports 96K 34.7G 96K /usr/ports > > vega/usr/src 607M 34.7G 607M /usr/src > > vega/var 720K 34.7G 96K /var > > vega/var/audit 96K 34.7G 96K /var/audit > > vega/var/crash 96K 34.7G 96K /var/crash > > vega/var/log 236K 34.7G 236K /var/log > > vega/var/mail 100K 34.7G 100K /var/mail > > vega/var/tmp 96K 34.7G 96K /var/tmp > > zroot 1.83G 34.7G 96K /zroot > > zroot/ROOT 1.24G 34.7G 96K none > > zroot/ROOT/default 1.24G 34.7G 1.24G / > > zroot/tmp 120K 34.7G 120K /tmp > > zroot/usr 608M 34.7G 96K /usr > > zroot/usr/home 136K 34.7G 136K /usr/home > > zroot/usr/ports 96K 34.7G 96K /usr/ports > > zroot/usr/src 607M 34.7G 607M /usr/src > > zroot/var 724K 34.7G 96K /var > > zroot/var/audit 96K 34.7G 96K /var/audit > > zroot/var/crash 96K 34.7G 96K /var/crash > > zroot/var/log 240K 34.7G 240K /var/log > > zroot/var/mail 100K 34.7G 100K /var/mail > > zroot/var/tmp 96K 34.7G 96K /var/tmp > > nik@vega:~ % zpool status > > pool: vega > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > > config: > > > > NAME STATE READ WRITE CKSUM > > vega ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > > > > errors: No known data errors > > > > pool: zroot > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 2017 > > config: > > > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > > > > errors: No known data errors > > nik@vega:~ % > > ------------------------------------------- > > > > It seems like there are two pools, sharing the same vdev... > > > > After running a few commands in this state, like doing a scrub, > > the pool was (most probably) destroyed. It couldn't boot anymore > > and I didn't research further. Is this a known bug? > > I guess you had a /boot/zfs/zpool.cache file referring to the original zroot pool. Next, the kernel found the vega pool and didn't realise these two pools are the very same. > > Steps to reproduce: > > install FreeBSD-11.0 in a pool named zroot > > reboot into a live-CD Redo the above steps. > > zpool import -f zroot vega Do these four commands instead of a regular import: mkdir /tmp/vega zpool import -N -f -o cachefile=/tmp/zpool.cache vega mount -t zfs vega/ROOT/default /tmp/vega cp -p /tmp/zpool.cache /tmp/vega/boot/zfs/zpool.cache > > reboot again Reboot again. > > > > Thanks, > > Nikos > > > > PS: > > Sorry for the cross-posting, I am doing this to share to more people > > because it is a rather easy way to destroy a ZFS pool. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-stable@freebsd.org Tue May 16 14:26:47 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E31B9D6ED06; Tue, 16 May 2017 14:26:47 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2A15E3C; Tue, 16 May 2017 14:26:47 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x232.google.com with SMTP id u187so77188828pgb.0; Tue, 16 May 2017 07:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uAUpgAqnd1stsFvHEgHFbGeINeqKRDeEgnKaZRwCuME=; b=GOrTZvNP9MMjvWeDgKa44gRXxxNWRtWn8uvZnSlMcRXWkHasjHzAHHC7Aus9bqcUvs toNNxtG295qxEetlSLAYn9UZfI9sn35rZrg7ba+0CpSBMJSGwGhafuV8SzA+gulgcf0M EM5iAZfv8n6uvVQ+ix8MbOoupXj6xCxR8erQR5eWAnriZJgBk7BjKx4h59DipQBn4rsY HJaKw0eq0HfcJivbib/x5/8qodH2sRwhq8jUJiaUphONomuLKX+Ucd7nDJPzOgp0Si8f XYii9lU9jL1XAUugRZiPjeanHYL4gH+k7M7caM+Q1YwiuqLtFSCBvIUed1akfoI7kDYR tMEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uAUpgAqnd1stsFvHEgHFbGeINeqKRDeEgnKaZRwCuME=; b=EzwQbg3iKeqTV+GAMoXzpE6gbT2ViRpTlA48jxx+Y5Swx2D/ZghjBr/jqUF1LY+bGa 8MYrXaJHhPKTsXdcW9q9UQzsAWmhfSC8C+5YTsH7vp2CN7O6q6lN0gMgtU+akSZQxJsy a0C2HIFZk8agCzqIjmqBweWnHYi8GzzOKHPp/X0Tn9/SrM7ZRL5+Dcnnq/fbjszrlz8k Q2V5/jR8/D12UznuErun8AENgymJDAzKcnsEkI8WYBsKXAc/lcTRXFljZKSE2A+GppaL N22uawb0rA5e3lNfO+YFFvz7ekj7aOTdve5WrZTdr2L6C9v9fnx5oRx4t7uzQYY9Fvrt KWSg== X-Gm-Message-State: AODbwcAvBXOL0HekyoT13KndLd4mdSKUwtnhfkxFFGfR3br4pR1WYRLp HJYA10TZh0ukMFliFIZp5PTIQPwmvQ== X-Received: by 10.84.193.129 with SMTP id f1mr16469574pld.129.1494944807258; Tue, 16 May 2017 07:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Tue, 16 May 2017 07:26:46 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> From: "Eric A. Borisch" Date: Tue, 16 May 2017 09:26:46 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: Nikos Vassiliadis , "freebsd-fs@freebsd.org" , FreeBSD Stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:26:48 -0000 On Tue, May 16, 2017 at 1:31 AM, Trond Endrest=C3=B8l < Trond.Endrestol@fagskolen.gjovik.no> wrote: > I guess you had a /boot/zfs/zpool.cache file referring to the original > zroot pool. Next, the kernel found the vega pool and didn't realise > these two pools are the very same. > Assuming this is the case, shouldn't it be fixed? A check while importing that the guid of the pool targeted for import is not in the set of currently active guids would be worthwhile, but it -- apparently, if this is reproducible -- doesn't exist? Again, assuming this is reproducible. - Eric From owner-freebsd-stable@freebsd.org Tue May 16 14:55:07 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BC46D6E952 for ; Tue, 16 May 2017 14:55:07 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 981CF126; Tue, 16 May 2017 14:55:06 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4GEt3vT082045; Tue, 16 May 2017 16:55:03 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 1645B950; Tue, 16 May 2017 16:55:03 +0200 (CEST) Message-ID: <591B12C6.4040301@omnilan.de> Date: Tue, 16 May 2017 16:55:02 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org CC: tsoome@freebsd.org Subject: EFI loader doesn't handle md_preload (md_image) correct? Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 16 May 2017 16:55:03 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:55:07 -0000 Hello, unfortunately I had some trouble with my preferred MFS-root setups. It seems EFI loader doesn't handle type md_image correctly. If I load any md_image with loader invoked by gptboot or gptzfsboot, 'lsmod' shows "elf kernel", "elf obj module(s)" and "md_image". Using the same loader.conf, but EFI loader, the md_image-file is prompted and sems to be loaded, but not registered. There's no md_image with 'lsmod', hence it's not astonsihing that kernel doesn't attach md0 so booting fails since there's no rootfs. Any help highly appreciated, hope Toomas doesn't mind beeing initially CC'd. Thanks, -harry From owner-freebsd-stable@freebsd.org Tue May 16 14:58:10 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABE38D6EB4B for ; Tue, 16 May 2017 14:58:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 86320392; Tue, 16 May 2017 14:58:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQ100200VLTGI00@st13p35im-asmtp002.me.com>; Tue, 16 May 2017 14:57:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1494946677; bh=1rzcfrLRdbobufrsPm0yXKM2GNXPYD+U93GL5cQ4+cw=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=DCe2oht2M36GwGTUBspfvmPmah3rUB5FAEjSVjC0hTzGZsQ3Iij545qv5mumMPAYv mGb/KfVtTOECP0GdHzyeBfZG7xArKnNdSzD034v/JngnhXwiMialEQAApj002m5Kva nBNJclpvoRVO4ZmLSoMtDF/1KIgiuQBQwDSSZB+WvdOFXp937QtmUeLTtjQ8UcrIFc YqexGhr5hYj9LezopdUsRykJaNvyS4A07+Pn45Oxk5u6dsZCI88rPL4twqWrMliqoY rcK1Eyg6+ZebPUskzDIRRSqwOiXlo4fIwpduw5pOJKKx43gP46z461LhAFo+bb0ZmP bymKz4W8KoNbg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQ10055MW8HN650@st13p35im-asmtp002.me.com>; Tue, 16 May 2017 14:57:56 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-16_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705160120 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? From: Toomas Soome In-reply-to: <591B12C6.4040301@omnilan.de> Date: Tue, 16 May 2017 17:57:53 +0300 Cc: freebsd-stable@freebsd.org, tsoome@freebsd.org Content-transfer-encoding: quoted-printable Message-id: References: <591B12C6.4040301@omnilan.de> To: Harry Schmalzbauer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:58:10 -0000 > On 16. mai 2017, at 17:55, Harry Schmalzbauer = wrote: >=20 > Hello, >=20 > unfortunately I had some trouble with my preferred MFS-root setups. > It seems EFI loader doesn't handle type md_image correctly. >=20 > If I load any md_image with loader invoked by gptboot or gptzfsboot, > 'lsmod' > shows "elf kernel", "elf obj module(s)" and "md_image". >=20 > Using the same loader.conf, but EFI loader, the md_image-file is > prompted and sems to be loaded, but not registered. There's no = md_image > with 'lsmod', hence it's not astonsihing that kernel doesn't attach = md0 > so booting fails since there's no rootfs. >=20 > Any help highly appreciated, hope Toomas doesn't mind beeing initially = CC'd. >=20 > Thanks, >=20 > -harry The first question is, how large is the md_image and what other modules = are loaded? rgds, toomas= From owner-freebsd-stable@freebsd.org Tue May 16 15:03:54 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E361D6EF1F for ; Tue, 16 May 2017 15:03:54 +0000 (UTC) (envelope-from rose@audienceprospecting.com) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-bo1ind01on0090.outbound.protection.outlook.com [104.47.101.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AD22AB8 for ; Tue, 16 May 2017 15:03:52 +0000 (UTC) (envelope-from rose@audienceprospecting.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2447405.onmicrosoft.com; s=selector1-audienceprospecting-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wcqZ62JfuODsYn5PvGxCfrcbMn33CCjbXmNZToa1zn4=; b=nLly51OcYukCxotsL1bcVvUSgiGc/Nzen8rDdJMvYr4o9Gv1j/gJmRamBbTwWV4iNCrsTaSua18LTCcHWPHJVdYQxwyWGCiT70oC67j4GnkaB6OUPaRw4qNGxQw05raiY7fCSB7WK540tAktXm19p9ojDdyZplu8zmlzZFTvpnc= Received: from BMXPR01MB1093.INDPRD01.PROD.OUTLOOK.COM (10.174.218.138) by BMXPR01MB1094.INDPRD01.PROD.OUTLOOK.COM (10.174.218.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Tue, 16 May 2017 15:03:49 +0000 Received: from BMXPR01MB1093.INDPRD01.PROD.OUTLOOK.COM ([10.174.218.138]) by BMXPR01MB1093.INDPRD01.PROD.OUTLOOK.COM ([10.174.218.138]) with mapi id 15.01.1084.029; Tue, 16 May 2017 15:03:49 +0000 From: Rose Kate To: "freebsd-stable@freebsd.org" Subject: Office 365 Thread-Topic: Office 365 Thread-Index: AdLF5KqilyewpxCvT5Wnk6HpSBOQKg== Date: Tue, 16 May 2017 15:03:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=audienceprospecting.com; x-originating-ip: [183.82.18.206] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BMXPR01MB1094; 7:++dgl6oZruL7AKwIC1/jttf4rNRxh2024SFVN8de1dcLKQ0vQ1OgKMobk+FTBfXGXm9jfIAYC+wj4DZl2aR7L6W3xEKgKGaqpmtgn8BQcOZfUo0b9i6amk3BnwNeNxYQQfMYv/BsRwhKjFYm4NNNwcFd9VOYmoaYfXmeihD40mPb3B8wTNseg0qmYjDUbaQGjjdkSMqZvFHsZcZ8iwnAMOXMZ0mVO1utH9WZyjiDSeGLr3FD2G14PTXUKXIpKWds7RITVX0Appy4uEa34vhPFPrw1m0gk2tHwFoeHQrpxK+OTjNwogXyZCKd8uLaX3UqAn4HlPoSGWeLiY2go/QO6Q== x-ms-office365-filtering-correlation-id: 6408423c-2a4e-4835-6897-08d49c6cc234 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201702281549075)(201702085551020); SRVR:BMXPR01MB1094; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(20161123560025)(2016111802025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(6043046); SRVR:BMXPR01MB1094; BCL:0; PCL:0; RULEID:; SRVR:BMXPR01MB1094; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39400400002)(39410400002)(39850400002)(44134004)(152014003)(478600001)(7696004)(53936002)(2501003)(6116002)(3660700001)(5640700003)(45080400002)(102836003)(3846002)(8676002)(6916009)(7116003)(81166006)(5660300001)(6306002)(2906002)(8936002)(9686003)(25786009)(38730400002)(55016002)(86362001)(66066001)(54896002)(3280700002)(6436002)(110136004)(2900100001)(2351001)(122556002)(6506006)(7736002)(33656002)(77096006)(50986999)(9476002)(9326002)(189998001)(54356999)(74316002)(62570200001); DIR:OUT; SFP:1102; SCL:1; SRVR:BMXPR01MB1094; H:BMXPR01MB1093.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: audienceprospecting.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2017 15:03:49.3358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f39c1920-563c-460c-b898-276a580654bb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BMXPR01MB1094 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 15:03:54 -0000 Hi, Would you like to acquire an email lead list of Office 365 Customers, which= contains business information along with contact details of key profiles a= nd decision makers? Job Titles: ? CIO/ CTO ? SVP/ VP of IT ? Director of IT ? IT Manager The list comes with complete contact information like Contact name, Email a= ddress, Title, Company name, Phone number, Mailing address, etc. I'd be happy to send over few sample records on your request, and set up a = time to discuss in detail. If there is someone else in your organization that I need to speak with, I'= d be grateful if you would forward this email to the appropriate contact an= d help me with the introduction. Have a great day! Regards, Rose Kate | Info Solutions If you don't wish to receive emails from us reply back with "Unsubscribe". From owner-freebsd-stable@freebsd.org Tue May 16 15:28:14 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E66DD7060C for ; Tue, 16 May 2017 15:28:14 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1A641818 for ; Tue, 16 May 2017 15:28:13 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4GFSBwH082360; Tue, 16 May 2017 17:28:11 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 8EFB195F; Tue, 16 May 2017 17:28:11 +0200 (CEST) Message-ID: <591B1A8B.6070803@omnilan.de> Date: Tue, 16 May 2017 17:28:11 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Toomas Soome CC: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? References: <591B12C6.4040301@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 16 May 2017 17:28:11 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 15:28:14 -0000 Bezüglich Toomas Soome's Nachricht vom 16.05.2017 16:57 (localtime): > >> On 16. mai 2017, at 17:55, Harry Schmalzbauer wrote: >> >> Hello, >> >> unfortunately I had some trouble with my preferred MFS-root setups. >> It seems EFI loader doesn't handle type md_image correctly. >> >> If I load any md_image with loader invoked by gptboot or gptzfsboot, >> 'lsmod' >> shows "elf kernel", "elf obj module(s)" and "md_image". >> >> Using the same loader.conf, but EFI loader, the md_image-file is >> prompted and sems to be loaded, but not registered. There's no md_image >> with 'lsmod', hence it's not astonsihing that kernel doesn't attach md0 >> so booting fails since there's no rootfs. >> >> Any help highly appreciated, hope Toomas doesn't mind beeing initially CC'd. >> >> Thanks, >> >> -harry > > > The first question is, how large is the md_image and what other modules are loaded? Thanks for your quick response. The images are 50-500MB uncompressed (provided by gzip compressed file). Small ammount of elf modules, 5, each ~50kB. I haven't checked if the size does have any influence yet. I just wondered why I can't see any md_image with 'lsmod' and EFI loader. Btw, I forogt to mention I'm running 11-stable from this week, tested on real HW and ESXi guest. Thanks, -harry From owner-freebsd-stable@freebsd.org Tue May 16 15:41:16 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E0EED70A7A; Tue, 16 May 2017 15:41:16 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (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 35A4924B; Tue, 16 May 2017 15:41:15 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.158.117] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1dAeC5-0007rb-OD; Tue, 16 May 2017 17:15:25 +0200 Date: Tue, 16 May 2017 17:08:02 +0200 From: Fabian Keil Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Message-ID: <20170516170802.71c2a470@fabiankeil.de> In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> Reply-To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Ux+_Pdaq.tM_nalOv235In9"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 15:41:16 -0000 --Sig_/Ux+_Pdaq.tM_nalOv235In9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Nikos Vassiliadis wrote: > On 05/15/2017 08:09 PM, Nikos Vassiliadis wrote: > > Hi everybody, > >=20 > > While trying to rename a zpool from zroot to vega, > > I ended up in this strange situation: > > nik@vega:~ % zfs list -t all > > NAME USED AVAIL REFER MOUNTPOINT > > vega 1.83G 34.7G 96K /zroot > > vega/ROOT 1.24G 34.7G 96K none > > vega/ROOT/default 1.24G 34.7G 1.24G / > > vega/tmp 120K 34.7G 120K /tmp > > vega/usr 608M 34.7G 96K /usr > > vega/usr/home 136K 34.7G 136K /usr/home > > vega/usr/ports 96K 34.7G 96K /usr/ports > > vega/usr/src 607M 34.7G 607M /usr/src > > vega/var 720K 34.7G 96K /var > > vega/var/audit 96K 34.7G 96K /var/audit > > vega/var/crash 96K 34.7G 96K /var/crash > > vega/var/log 236K 34.7G 236K /var/log > > vega/var/mail 100K 34.7G 100K /var/mail > > vega/var/tmp 96K 34.7G 96K /var/tmp > > zroot 1.83G 34.7G 96K /zroot > > zroot/ROOT 1.24G 34.7G 96K none > > zroot/ROOT/default 1.24G 34.7G 1.24G / > > zroot/tmp 120K 34.7G 120K /tmp > > zroot/usr 608M 34.7G 96K /usr > > zroot/usr/home 136K 34.7G 136K /usr/home > > zroot/usr/ports 96K 34.7G 96K /usr/ports > > zroot/usr/src 607M 34.7G 607M /usr/src > > zroot/var 724K 34.7G 96K /var > > zroot/var/audit 96K 34.7G 96K /var/audit > > zroot/var/crash 96K 34.7G 96K /var/crash > > zroot/var/log 240K 34.7G 240K /var/log > > zroot/var/mail 100K 34.7G 100K /var/mail > > zroot/var/tmp 96K 34.7G 96K /var/tmp > > nik@vega:~ % zpool status > > pool: vega > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 > > 2017 config: > >=20 > > NAME STATE READ WRITE CKSUM > > vega ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > >=20 > > errors: No known data errors > >=20 > > pool: zroot > > state: ONLINE > > scan: scrub repaired 0 in 0h0m with 0 errors on Mon May 15 01:28:48 > > 2017 config: > >=20 > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > vtbd0p3 ONLINE 0 0 0 > >=20 > > errors: No known data errors > > nik@vega:~ % > > ------------------------------------------- > >=20 > > It seems like there are two pools, sharing the same vdev... > >=20 > > After running a few commands in this state, like doing a scrub, > > the pool was (most probably) destroyed. It couldn't boot anymore > > and I didn't research further. Is this a known bug? > >=20 > > Steps to reproduce: > > install FreeBSD-11.0 in a pool named zroot > > reboot into a live-CD > > zpool import -f zroot vega Why did you use the -f flag? Unless you can reproduce the problem without it, it's not obvious to me that this is a bug. Fabian --Sig_/Ux+_Pdaq.tM_nalOv235In9 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCWRsV0wAKCRAFiohV/3dU nU8JAKC5MOZFsHNKd0Ry4lkGNtpmLqimEwCgu28OsdQ1UNF+ft4TJZFd0VFneLc= =Qj7V -----END PGP SIGNATURE----- --Sig_/Ux+_Pdaq.tM_nalOv235In9-- From owner-freebsd-stable@freebsd.org Tue May 16 15:45:43 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83F43D70DF3 for ; Tue, 16 May 2017 15:45:43 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A47AA54 for ; Tue, 16 May 2017 15:45:42 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4GFjfmv082519; Tue, 16 May 2017 17:45:41 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id C3F3A966; Tue, 16 May 2017 17:45:40 +0200 (CEST) Message-ID: <591B1EA4.600@omnilan.de> Date: Tue, 16 May 2017 17:45:40 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Toomas Soome CC: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> In-Reply-To: <591B1A8B.6070803@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 16 May 2017 17:45:41 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 15:45:43 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 (localtime): > Bezüglich Toomas Soome's Nachricht vom 16.05.2017 16:57 (localtime): >>> On 16. mai 2017, at 17:55, Harry Schmalzbauer wrote: >>> >>> Hello, >>> >>> unfortunately I had some trouble with my preferred MFS-root setups. >>> It seems EFI loader doesn't handle type md_image correctly. >>> >>> If I load any md_image with loader invoked by gptboot or gptzfsboot, >>> 'lsmod' >>> shows "elf kernel", "elf obj module(s)" and "md_image". >>> >>> Using the same loader.conf, but EFI loader, the md_image-file is >>> prompted and sems to be loaded, but not registered. There's no md_image >>> with 'lsmod', hence it's not astonsihing that kernel doesn't attach md0 >>> so booting fails since there's no rootfs. >>> >>> Any help highly appreciated, hope Toomas doesn't mind beeing initially CC'd. >>> >>> Thanks, >>> >>> -harry >> >> The first question is, how large is the md_image and what other modules are loaded? > Thanks for your quick response. > > The images are 50-500MB uncompressed (provided by gzip compressed file). > Small ammount of elf modules, 5, each ~50kB. On the real HW, there's vmm and some more: Id Refs Address Size Name 1 46 0xffffffff80200000 16M kernel 2 1 0xffffffff8121d000 86K unionfs.ko 3 1 0xffffffff81233000 3.1M zfs.ko 4 2 0xffffffff81545000 51K opensolaris.ko 5 7 0xffffffff81552000 279K usb.ko 6 1 0xffffffff81598000 67K ukbd.ko 7 1 0xffffffff815a9000 51K umass.ko 8 1 0xffffffff815b6000 46K aesni.ko 9 1 0xffffffff815c3000 54K uhci.ko 10 1 0xffffffff815d1000 65K ehci.ko 11 1 0xffffffff815e2000 15K cc_htcp.ko 12 1 0xffffffff815e6000 3.4M vmm.ko 13 1 0xffffffffa3a21000 12K ums.ko 14 1 0xffffffffa3a24000 9.1K uhid.ko Providing md_image uncompressed doesn't change anything. Will deploy a /usr separated rootfs, which is only ~100MB uncompressed and see if that changes anything. That's all I can provide, code is far beyond my knowledge... -harry From owner-freebsd-stable@freebsd.org Tue May 16 16:00:36 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8ADA0D70208 for ; Tue, 16 May 2017 16:00:36 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 596231089 for ; Tue, 16 May 2017 16:00:36 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQ100600YX5QX00@st13p35im-asmtp002.me.com> for freebsd-stable@freebsd.org; Tue, 16 May 2017 16:00:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1494950422; bh=hHtUxDZFC0kKYbnnS1jayj33CqkR8J/Cp8wHNEYCjao=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=iqvvAvpZIAqRVZfnfC3ZcJqsPN9OIOt1kFV9aDFwso92mpx/JJZQ/bqsDBN/yJpNI QyusyEQ/utm5p6QIBJNwD9EmeOu1Ms7hFtVOIdU64z/DGvIgYVn9Qj2BUbO/q/V6Ha SstPEjfvgFhzzWqSVBw2Eeeztf2NmtQfUYiFGfMGZ30aN3k0xZpZ9F9hNeVtSvGky4 ywRU9oRkZK2aPkYKjKZNglpejCpUmDs2MJT6+g58sloqpY/EhB7CW0tEHhkIY/GoSu dn+zSrhmiG4jRivdyuiMFfmWDw4S3ALVsH+auPhWm1p8k57pchh9nhr9UeEi+2nvVk fme8ok2ldhAYQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQ100I7CZ4G7310@st13p35im-asmtp002.me.com>; Tue, 16 May 2017 16:00:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-16_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705160127 From: Toomas Soome Message-id: MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? Date: Tue, 16 May 2017 19:00:15 +0300 In-reply-to: <591B1EA4.600@omnilan.de> Cc: freebsd-stable@freebsd.org To: Harry Schmalzbauer References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:00:36 -0000 > On 16. mai 2017, at 18:45, Harry Schmalzbauer = wrote: >=20 > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 = (localtime): >> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 16:57 = (localtime): >>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer = wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> unfortunately I had some trouble with my preferred MFS-root setups. >>>> It seems EFI loader doesn't handle type md_image correctly. >>>>=20 >>>> If I load any md_image with loader invoked by gptboot or = gptzfsboot, >>>> 'lsmod' >>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>=20 >>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>> prompted and sems to be loaded, but not registered. There's no = md_image >>>> with 'lsmod', hence it's not astonsihing that kernel doesn't attach = md0 >>>> so booting fails since there's no rootfs. >>>>=20 >>>> Any help highly appreciated, hope Toomas doesn't mind beeing = initially CC'd. >>>>=20 >>>> Thanks, >>>>=20 >>>> -harry >>>=20 >>> The first question is, how large is the md_image and what other = modules are loaded? >> Thanks for your quick response. >>=20 >> The images are 50-500MB uncompressed (provided by gzip compressed = file). >> Small ammount of elf modules, 5, each ~50kB. >=20 > On the real HW, there's vmm and some more: > Id Refs Address Size Name > 1 46 0xffffffff80200000 16M kernel > 2 1 0xffffffff8121d000 86K unionfs.ko > 3 1 0xffffffff81233000 3.1M zfs.ko > 4 2 0xffffffff81545000 51K opensolaris.ko > 5 7 0xffffffff81552000 279K usb.ko > 6 1 0xffffffff81598000 67K ukbd.ko > 7 1 0xffffffff815a9000 51K umass.ko > 8 1 0xffffffff815b6000 46K aesni.ko > 9 1 0xffffffff815c3000 54K uhci.ko > 10 1 0xffffffff815d1000 65K ehci.ko > 11 1 0xffffffff815e2000 15K cc_htcp.ko > 12 1 0xffffffff815e6000 3.4M vmm.ko > 13 1 0xffffffffa3a21000 12K ums.ko > 14 1 0xffffffffa3a24000 9.1K uhid.ko >=20 > Providing md_image uncompressed doesn't change anything. >=20 > Will deploy a /usr separated rootfs, which is only ~100MB uncompressed > and see if that changes anything. > That's all I can provide, code is far beyond my knowledge... >=20 > -harry The issue is, that current UEFI implementation is using 64MB staging = memory for loading the kernel and modules and files. When the boot is = called, the relocation code will put the bits from staging area into the = final places. The BIOS version does not need such staging area, and that = will explain the difference. I actually have different implementation to address the same problem, = but thats for illumos case, and will need some work to make it usable = for freebsd; the idea is actually simple - allocate staging area per = loaded file and relocate the bits into the place by component, not as = continuous large chunk (this would also allow to avoid the mines like = planted by hyperv;), but right now there is no very quick real solution = other than just build efi loader with larger staging size. rgds, toomas From owner-freebsd-stable@freebsd.org Tue May 16 16:13:26 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A319DD705CF for ; Tue, 16 May 2017 16:13:26 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 400321C88 for ; Tue, 16 May 2017 16:13:26 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4GGDOai082789; Tue, 16 May 2017 18:13:24 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 00D99970; Tue, 16 May 2017 18:13:23 +0200 (CEST) Message-ID: <591B2523.6040101@omnilan.de> Date: Tue, 16 May 2017 18:13:23 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Toomas Soome CC: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 16 May 2017 18:13:24 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:13:26 -0000 Bezüglich Toomas Soome's Nachricht vom 16.05.2017 18:00 (localtime): > >> On 16. mai 2017, at 18:45, Harry Schmalzbauer > > wrote: >> >> Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 (localtime): >>> Bezüglich Toomas Soome's Nachricht vom 16.05.2017 16:57 (localtime): >>>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer >>>> > wrote: >>>>> >>>>> Hello, >>>>> >>>>> unfortunately I had some trouble with my preferred MFS-root setups. >>>>> It seems EFI loader doesn't handle type md_image correctly. >>>>> >>>>> If I load any md_image with loader invoked by gptboot or gptzfsboot, >>>>> 'lsmod' >>>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>> >>>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>>> prompted and sems to be loaded, but not registered. There's no >>>>> md_image >>>>> with 'lsmod', hence it's not astonsihing that kernel doesn't attach md0 >>>>> so booting fails since there's no rootfs. >>>>> >>>>> Any help highly appreciated, hope Toomas doesn't mind beeing >>>>> initially CC'd. >>>>> >>>>> Thanks, >>>>> >>>>> -harry >>>> >>>> The first question is, how large is the md_image and what other >>>> modules are loaded? >>> Thanks for your quick response. >>> >>> The images are 50-500MB uncompressed (provided by gzip compressed file). >>> Small ammount of elf modules, 5, each ~50kB. >> >> On the real HW, there's vmm and some more: >> Id Refs Address Size Name >> 1 46 0xffffffff80200000 16M kernel >> 2 1 0xffffffff8121d000 86K unionfs.ko >> 3 1 0xffffffff81233000 3.1M zfs.ko >> 4 2 0xffffffff81545000 51K opensolaris.ko >> 5 7 0xffffffff81552000 279K usb.ko >> 6 1 0xffffffff81598000 67K ukbd.ko >> 7 1 0xffffffff815a9000 51K umass.ko >> 8 1 0xffffffff815b6000 46K aesni.ko >> 9 1 0xffffffff815c3000 54K uhci.ko >> 10 1 0xffffffff815d1000 65K ehci.ko >> 11 1 0xffffffff815e2000 15K cc_htcp.ko >> 12 1 0xffffffff815e6000 3.4M vmm.ko >> 13 1 0xffffffffa3a21000 12K ums.ko >> 14 1 0xffffffffa3a24000 9.1K uhid.ko >> >> Providing md_image uncompressed doesn't change anything. >> >> Will deploy a /usr separated rootfs, which is only ~100MB uncompressed >> and see if that changes anything. >> That's all I can provide, code is far beyond my knowledge... >> >> -harry > > > The issue is, that current UEFI implementation is using 64MB staging > memory for loading the kernel and modules and files. When the boot is > called, the relocation code will put the bits from staging area into the > final places. The BIOS version does not need such staging area, and that > will explain the difference. > > I actually have different implementation to address the same problem, > but thats for illumos case, and will need some work to make it usable > for freebsd; the idea is actually simple - allocate staging area per > loaded file and relocate the bits into the place by component, not as > continuous large chunk (this would also allow to avoid the mines like > planted by hyperv;), but right now there is no very quick real solution > other than just build efi loader with larger staging size. Ic, thanks for the explanation. While not aware about the purpose of the staging area nor the consequences of enlarging it, do you think it's feasable increasing it to 768Mib? At least now I have an idea baout the issue and an explanation why reducing md_imgae to 100MB hasn't helped – still more than 64... Any quick hint where to define the staging area size highly appreciated, fi there are no hard objections against a 768MB size. -harry From owner-freebsd-stable@freebsd.org Tue May 16 16:20:39 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2978DD7074E for ; Tue, 16 May 2017 16:20:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 01031124 for ; Tue, 16 May 2017 16:20:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQ100J00ZREF400@st13p35im-asmtp002.me.com> for freebsd-stable@freebsd.org; Tue, 16 May 2017 16:20:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1494951638; bh=gbsrBr0DXK9RqRmnw9z+OVUPdR5oqfCWcHDHN3r1wrw=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=GLp7LIV9oCbh3ioeXOAJFWEhpT4psY4034iMjah78MYH6xAF98XW8Y+rRfvuzhvXs xz5rasGuCqTtQ97yIxfMBCnmruype6Ik5JYC6Z9R5B/lKJgWuuUdAw4VZtPX8YF3Ee 4HQc0FD6QJrUNXpiXdog6oRqFpRPSsxErv4N6eZOfg2djC2ZTCDyaJBBjLFZEwHDPD qt4lCHs6VEmk6fXoY9dVyUVoz2tpyRSqk0EmDrfay7L3mwuLOTEFoGVEoZIyQWZB0p yKbRgeJXjhVAV2L1B1QsRJFBykEzF9oxbuCC3axINc8yvL/6ln95PGyv4/4K8RKeh/ 7hZmR/JvC0tTg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQ200ATN02ATB00@st13p35im-asmtp002.me.com>; Tue, 16 May 2017 16:20:37 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-16_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705160130 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? From: Toomas Soome In-reply-to: <591B2523.6040101@omnilan.de> Date: Tue, 16 May 2017 19:20:34 +0300 Cc: freebsd-stable@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <591B2523.6040101@omnilan.de> To: Harry Schmalzbauer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:20:39 -0000 > On 16. mai 2017, at 19:13, Harry Schmalzbauer = wrote: >=20 > Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 18:00 = (localtime): >>=20 >>> On 16. mai 2017, at 18:45, Harry Schmalzbauer >> > wrote: >>>=20 >>> Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 = (localtime): >>>> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 16:57 = (localtime): >>>>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer >>>>> > wrote: >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> unfortunately I had some trouble with my preferred MFS-root = setups. >>>>>> It seems EFI loader doesn't handle type md_image correctly. >>>>>>=20 >>>>>> If I load any md_image with loader invoked by gptboot or = gptzfsboot, >>>>>> 'lsmod' >>>>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>>>=20 >>>>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>>>> prompted and sems to be loaded, but not registered. There's no >>>>>> md_image >>>>>> with 'lsmod', hence it's not astonsihing that kernel doesn't = attach md0 >>>>>> so booting fails since there's no rootfs. >>>>>>=20 >>>>>> Any help highly appreciated, hope Toomas doesn't mind beeing >>>>>> initially CC'd. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> -harry >>>>>=20 >>>>> The first question is, how large is the md_image and what other >>>>> modules are loaded? >>>> Thanks for your quick response. >>>>=20 >>>> The images are 50-500MB uncompressed (provided by gzip compressed = file). >>>> Small ammount of elf modules, 5, each ~50kB. >>>=20 >>> On the real HW, there's vmm and some more: >>> Id Refs Address Size Name >>> 1 46 0xffffffff80200000 16M kernel >>> 2 1 0xffffffff8121d000 86K unionfs.ko >>> 3 1 0xffffffff81233000 3.1M zfs.ko >>> 4 2 0xffffffff81545000 51K opensolaris.ko >>> 5 7 0xffffffff81552000 279K usb.ko >>> 6 1 0xffffffff81598000 67K ukbd.ko >>> 7 1 0xffffffff815a9000 51K umass.ko >>> 8 1 0xffffffff815b6000 46K aesni.ko >>> 9 1 0xffffffff815c3000 54K uhci.ko >>> 10 1 0xffffffff815d1000 65K ehci.ko >>> 11 1 0xffffffff815e2000 15K cc_htcp.ko >>> 12 1 0xffffffff815e6000 3.4M vmm.ko >>> 13 1 0xffffffffa3a21000 12K ums.ko >>> 14 1 0xffffffffa3a24000 9.1K uhid.ko >>>=20 >>> Providing md_image uncompressed doesn't change anything. >>>=20 >>> Will deploy a /usr separated rootfs, which is only ~100MB = uncompressed >>> and see if that changes anything. >>> That's all I can provide, code is far beyond my knowledge... >>>=20 >>> -harry >>=20 >>=20 >> The issue is, that current UEFI implementation is using 64MB staging >> memory for loading the kernel and modules and files. When the boot is >> called, the relocation code will put the bits from staging area into = the >> final places. The BIOS version does not need such staging area, and = that >> will explain the difference. >>=20 >> I actually have different implementation to address the same problem, >> but thats for illumos case, and will need some work to make it usable >> for freebsd; the idea is actually simple - allocate staging area per >> loaded file and relocate the bits into the place by component, not as >> continuous large chunk (this would also allow to avoid the mines like >> planted by hyperv;), but right now there is no very quick real = solution >> other than just build efi loader with larger staging size. >=20 > Ic, thanks for the explanation. > While not aware about the purpose of the staging area nor the > consequences of enlarging it, do you think it's feasable increasing it > to 768Mib? >=20 > At least now I have an idea baout the issue and an explanation why > reducing md_imgae to 100MB hasn't helped =E2=80=93 still more than = 64... >=20 > Any quick hint where to define the staging area size highly = appreciated, > fi there are no hard objections against a 768MB size. >=20 > -harry The problem is that before UEFI Boot Services are not switched off, the = memory is managed (and owned) by the firmware, and you can not write = into the random places. So you need to allocate the staging area, read = data there, switch BS off, move data into final location and start the = kernel. Alternatively, you move only the kernel into place, and let the kernel = to relocate and manage the modules and MD image. rgds, toomas From owner-freebsd-stable@freebsd.org Tue May 16 16:26:54 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA5BED70A31 for ; Tue, 16 May 2017 16:26:54 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 894508FD for ; Tue, 16 May 2017 16:26:54 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4GGQq7D082924; Tue, 16 May 2017 18:26:52 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 51953976; Tue, 16 May 2017 18:26:52 +0200 (CEST) Message-ID: <591B284B.6070204@omnilan.de> Date: Tue, 16 May 2017 18:26:51 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Toomas Soome CC: freebsd-stable@freebsd.org Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> <591B2523.6040101@omnilan.de> <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> In-Reply-To: <7CF3AC8F-A778-40AE-B457-9B96AE5B4719@me.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 16 May 2017 18:26:52 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:26:55 -0000 Bezüglich Toomas Soome's Nachricht vom 16.05.2017 18:20 (localtime): > >> On 16. mai 2017, at 19:13, Harry Schmalzbauer wrote: >> >> Bezüglich Toomas Soome's Nachricht vom 16.05.2017 18:00 (localtime): >>> >>>> On 16. mai 2017, at 18:45, Harry Schmalzbauer >>> > wrote: >>>> >>>> Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 (localtime): >>>>> Bezüglich Toomas Soome's Nachricht vom 16.05.2017 16:57 (localtime): >>>>>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer >>>>>> > wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> unfortunately I had some trouble with my preferred MFS-root setups. >>>>>>> It seems EFI loader doesn't handle type md_image correctly. >>>>>>> >>>>>>> If I load any md_image with loader invoked by gptboot or gptzfsboot, >>>>>>> 'lsmod' >>>>>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>>>> >>>>>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>>>>> prompted and sems to be loaded, but not registered. There's no >>>>>>> md_image >>>>>>> with 'lsmod', hence it's not astonsihing that kernel doesn't attach md0 >>>>>>> so booting fails since there's no rootfs. >>>>>>> >>>>>>> Any help highly appreciated, hope Toomas doesn't mind beeing >>>>>>> initially CC'd. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -harry >>>>>> >>>>>> The first question is, how large is the md_image and what other >>>>>> modules are loaded? >>>>> Thanks for your quick response. >>>>> >>>>> The images are 50-500MB uncompressed (provided by gzip compressed file). >>>>> Small ammount of elf modules, 5, each ~50kB. >>>> >>>> On the real HW, there's vmm and some more: >>>> Id Refs Address Size Name >>>> 1 46 0xffffffff80200000 16M kernel >>>> 2 1 0xffffffff8121d000 86K unionfs.ko >>>> 3 1 0xffffffff81233000 3.1M zfs.ko >>>> 4 2 0xffffffff81545000 51K opensolaris.ko >>>> 5 7 0xffffffff81552000 279K usb.ko >>>> 6 1 0xffffffff81598000 67K ukbd.ko >>>> 7 1 0xffffffff815a9000 51K umass.ko >>>> 8 1 0xffffffff815b6000 46K aesni.ko >>>> 9 1 0xffffffff815c3000 54K uhci.ko >>>> 10 1 0xffffffff815d1000 65K ehci.ko >>>> 11 1 0xffffffff815e2000 15K cc_htcp.ko >>>> 12 1 0xffffffff815e6000 3.4M vmm.ko >>>> 13 1 0xffffffffa3a21000 12K ums.ko >>>> 14 1 0xffffffffa3a24000 9.1K uhid.ko >>>> >>>> Providing md_image uncompressed doesn't change anything. >>>> >>>> Will deploy a /usr separated rootfs, which is only ~100MB uncompressed >>>> and see if that changes anything. >>>> That's all I can provide, code is far beyond my knowledge... >>>> >>>> -harry >>> >>> >>> The issue is, that current UEFI implementation is using 64MB staging >>> memory for loading the kernel and modules and files. When the boot is >>> called, the relocation code will put the bits from staging area into the >>> final places. The BIOS version does not need such staging area, and that >>> will explain the difference. >>> >>> I actually have different implementation to address the same problem, >>> but thats for illumos case, and will need some work to make it usable >>> for freebsd; the idea is actually simple - allocate staging area per >>> loaded file and relocate the bits into the place by component, not as >>> continuous large chunk (this would also allow to avoid the mines like >>> planted by hyperv;), but right now there is no very quick real solution >>> other than just build efi loader with larger staging size. >> >> Ic, thanks for the explanation. >> While not aware about the purpose of the staging area nor the >> consequences of enlarging it, do you think it's feasable increasing it >> to 768Mib? >> >> At least now I have an idea baout the issue and an explanation why >> reducing md_imgae to 100MB hasn't helped – still more than 64... >> >> Any quick hint where to define the staging area size highly appreciated, >> fi there are no hard objections against a 768MB size. >> >> -harry > > The problem is that before UEFI Boot Services are not switched off, the memory is managed (and owned) by the firmware, Hmm, I've been expecting something like that (owend by firmware) ;-) So I'll stay with CSM for now, and will happily be an early adopter if you need someone to try anything (-stable mergable). Thanks, -harry From owner-freebsd-stable@freebsd.org Tue May 16 17:32:21 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0A5ED702B4 for ; Tue, 16 May 2017 17:32:21 +0000 (UTC) (envelope-from registro@braslink.com.br) Received: from aracaju.braslink.com (smtp.mailbraslink.com [204.16.2.248]) by mx1.freebsd.org (Postfix) with ESMTP id 397DD1614 for ; Tue, 16 May 2017 17:32:21 +0000 (UTC) (envelope-from registro@braslink.com.br) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); Received: from WIN-6SPUI25VSBR (unverified [198.50.176.144]) by smtp-out1.braslink.com (SurgeMail 6.5a2) with ESMTP id 52727607-1862518 for ; Tue, 16 May 2017 13:16:10 -0400 From: Prezado =?UTF-8?B?Q2lkYWTDo28=?= Subject: Seu saldo FGTS =?UTF-8?B?asOh?= se encontra disponivel. - #48845 To: freebsd-stable@freebsd.org MIME-Version: 1.0 Reply-To: registro@braslink.com.br Date: Tue, 16 May 2017 14:35:00 -0300 Message-ID: <1494954970_371474@smtp-out2> X-Authenticated-User: registro@braslink.com.br X-ORBS-Stamp: Seu ip 198.50.176.144 esta listado em http://www.spamhaus.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 17:32:21 -0000 Caixa Economica Federal Prezado Cidad?o O pagamento j? come?ou! Seu saldo FGTS j? se encontra disponivel. Agora voc? tem acesso a mais um servi?o Caixa que facilitar a sua vida! Com o Servi?os Online de Contas Inativas, voc? consegue saber: 1. Quantas contas inativas de FGTS possui de acordo com a MP 763/16. 2. Qual o valor do seu saldo. 3. Se voc? ? nosso cliente, como escolher a op??o de cr?dito em sua conta Caixa. 4. O calend?rio de pagamento. 5. O local mais conveniente para atendimento. Realize o procedimento e evite a perca do seu beneficiocio. 1. Supens?o de recebimento do FGTS. 2. Quem perder o prazo n?o podera sacar contas inativas do FGTS. 3. Ter? que esperar um novo prazo para sacar o beneficio. N?o perca tempo! CONSULTAR FGTS Autentica??o: ASF8H46F.34NXF354.SKF95JAO.LK3R2ANJ Caixa Economica Federal A vida pede mais que um banco. From owner-freebsd-stable@freebsd.org Tue May 16 22:47:01 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD5AAD6E8FF for ; Tue, 16 May 2017 22:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A6FEF999 for ; Tue, 16 May 2017 22:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A6590D6E8FE; Tue, 16 May 2017 22:47:01 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6055D6E8FD for ; Tue, 16 May 2017 22:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 95D56998 for ; Tue, 16 May 2017 22:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4GMl1KJ084192 for ; Tue, 16 May 2017 22:47:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193363] [panic] panic at reboot Date: Tue, 16 May 2017 22:47:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jpaetzel@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 22:47:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193363 Josh Paetzel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jpaetzel@FreeBSD.org Resolution|--- |Overcome By Events Status|New |Closed --- Comment #6 from Josh Paetzel --- Let us know if this is a problem with newer FreeBSD versions. Clearly this panic on this FreeBSD version isn't going to get fixed. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Wed May 17 01:53:20 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B39AD70E82 for ; Wed, 17 May 2017 01:53:20 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 119EA71 for ; Wed, 17 May 2017 01:53:20 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qk0-x231.google.com with SMTP id y201so145506430qka.0 for ; Tue, 16 May 2017 18:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GlC4JnHfrxhB3lQjx8DxInRgZvb1VWgaojDPo2L7yZc=; b=Yr/UBJPUb5yEGRXvCoYntmsPmRwoTYjVnL6lvaBzbi6cArynQSb+z3PqUTX7xK0ko6 Qs+JAR8cytpqlV45au2V2IV4WoPBuPnvDx7dCOtk7tHFPxptqhlh+6pD3A8sjC2Naa0a Z+Fv5YR23VYyB4tLahL8NmbYyW/mhNeoqE6LvtUEXmEDuqoWqcD68lIdNYpZftnmbtPy vbVmTIq+rPvGP3QU+45ccCn1b4x4wRkQBlBn11M+cyswfanYR5cRs6IiaXXXeiXpKnhx ZJivw8uhaZuJ2sKKB/HukkUKvq4kmSeE7O5TQNCsUFtN5lvSd3ozA77dFcyTeiNKAJYr JmeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GlC4JnHfrxhB3lQjx8DxInRgZvb1VWgaojDPo2L7yZc=; b=No2fvUOpzVDjJKQLuVk8o3rvple4jw0PkTZ1jmrF04mvCRFne80kIxN1vWGBjiiywy b7OB6ysY76pHTHIDsH93GM8vPlurS/y1uhRMUbtGgTM5sEVvhYm5M26y3PDinpUUV6Ae EcXB8nq1clFuPlibSoTCIhzxtlZXE92K0l8L2Hwq6OatDH2eSaNSe4gT5Ahtu1rhwoxC xkQLLWaVpIhDmVN0wKUNeLhtc+aqsJlFSrv7u+Qb9bNGs6v+ekgVLhpI/JPTz9r1hm+e jWjMsvLhWwxE+iAVbyFd6UKwivDKu+a/bKVJZui19E7eObSc7WNu6jtthlql9O48C9oO x7ew== X-Gm-Message-State: AODbwcCUw9I161hKQuaNfi2zE4RQPPyXYu3BTv04/mtT1xcUC2T5ryzG +5fAbqLGUZQFW/T3 X-Received: by 10.55.215.219 with SMTP id t88mr834946qkt.45.1494985998916; Tue, 16 May 2017 18:53:18 -0700 (PDT) Received: from [192.168.2.65] (pool-74-109-188-83.albyny.fios.verizon.net. [74.109.188.83]) by smtp.gmail.com with ESMTPSA id j4sm429128qkd.19.2017.05.16.18.53.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 May 2017 18:53:18 -0700 (PDT) Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Paul Kraus In-Reply-To: Date: Tue, 16 May 2017 21:53:17 -0400 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> To: "Eric A. Borisch" , "freebsd-fs@freebsd.org" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 01:53:20 -0000 > On May 16, 2017, at 10:26 AM, Eric A. Borisch = wrote: >=20 > On Tue, May 16, 2017 at 1:31 AM, Trond Endrest=C3=B8l < > Trond.Endrestol@fagskolen.gjovik.no> wrote: >=20 >> I guess you had a /boot/zfs/zpool.cache file referring to the = original >> zroot pool. Next, the kernel found the vega pool and didn't realise >> these two pools are the very same. >>=20 >=20 > Assuming this is the case, shouldn't it be fixed? A check while = importing > that the guid of the pool targeted for import is not in the set of > currently active guids would be worthwhile, but it -- apparently, if = this > is reproducible -- doesn't exist? When you use the -f (force) flag all bets are off. The assumption is = that you _know_ it is safe to import the zpool as commanded. In this = case, it was not. Many sysadmins I know have gotten into the sloppy (in my opinion) habit = of using the force option (for various things) all the time. The force = flag, whether it be on a zpool import or a kill -9 should be the last = resort when the non-forced command fails.= From owner-freebsd-stable@freebsd.org Wed May 17 18:04:51 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99C74D7123F; Wed, 17 May 2017 18:04:51 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00ABF1152; Wed, 17 May 2017 18:04:50 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MSdz2-1daSTu2pRU-00RZGI; Wed, 17 May 2017 20:04:42 +0200 Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: freebsd-fs@freebsd.org Cc: freebsd-stable@freebsd.org References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <20170516170802.71c2a470@fabiankeil.de> From: Nikos Vassiliadis Message-ID: Date: Wed, 17 May 2017 20:04:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170516170802.71c2a470@fabiankeil.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6Rd0kPg9czQyeXeXZ2jF/uGJOkXUj70mrDlNMedt8G+8LCwuQs1 vVveoV5bQh+1X1rpRPLBKKGDbRx1icgJe44jOBqstKNmR5Wz3r2mJ4XGMC+saoS4TU2n0YK lPg3N3uac4qYTJ/7AHAxwmNwheq/q8zcxdr6dXCqZ/bgrA1jqBrkP5mnLNoeupKPNX8PU1J CP2b3VAJypzIJfE8euPXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:BdwiEojxuvU=:lmUH/4TrjS6leaks0TnLnX Am3V5MGGsvXoj2BbnlG4oFmQqr7XGFaeJ17iki/iRi1DbsrdLDEYhZwpytEihzDmoOFvhRauG j6SfUCK+ncO8ojmfyVZjzBXS9gleTbvo3lxtk+IN+mazTeU2vxet+rd+h/NcuBW/2vOBiLxXT HSPz9Yda0oPbmyb86ks1hz0cdCVkmnR01yn7k5yDKn9Ck5d1KawJ0c63ws0K3HFp1cL5GZ0Yr kumPV7iMAiHNCTPVu785/N8FMVN2CUjSw+YTroMZshruEP+DfODMic8JG2Gk2PSCHUUaX+RgA ATdzw77Fe1/eVkH7oIJF0atLGFZ2JDDjgCgS0ihZU3YOZ3WcHWUS8w/Gr9BAjVOcslk9N/z8q Dd910kF8CRgE+AbWIODfZgH1tKI1CqUqKg1/R+jJI8HMjjWVfO2csl3z/5rEWvcC/znScqmVp JMO2eX6usBVptJI/Z8//sEPdERz4esFg8/EdCziQ265kyumKBMg0kV2PjtPQtj+2gBicfgzex pS5m6iUnwe1MprFm4uSxsRVtbht7aNFKPdqQnaAfBA5/T6WduN3sRv3416Z47Cud6a3l/NbPW 90rSMqEsmMhR9rdohocet34m937D879kLkSLC+O5G7KG9RX4MGd3IdLD/kqvQYcPPeWowUWI9 99c/+QvdsQMNYveKXY56ML7YJ7HfOIzA3LkwHA48ErKzp0u3ajLwREEU+Dr0NHg5SJ591fjDe Op55DTIILt2Gj7dzw5iAPRH5vjnjFdrDMhIAaXpVLjMh6HeIM02667DdlpLgdkmI3acjVyEBi t7mfHy9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 18:04:51 -0000 On 05/16/2017 05:08 PM, Fabian Keil wrote: > Why did you use the -f flag? Unless you can reproduce the > problem without it, it's not obvious to me that this is a > bug. If you boot from another system, there is no other way to import a pool than using "import -f". So, I guess it is part of normal administrative tasks. You can read more here: > http://docs.oracle.com/cd/E19253-01/819-5461/gazuf/index.html This works and always have worked as documented. Renaming a pool also works as documented, that is, doing "zpool import oldnamepool newnamepool". Except for this corner-case. IMHO this is a very serious bug. Best, Nikos From owner-freebsd-stable@freebsd.org Wed May 17 18:13:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4571FD7150D; Wed, 17 May 2017 18:13:13 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1D781965; Wed, 17 May 2017 18:13:12 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-vk0-x22b.google.com with SMTP id x71so11328761vkd.0; Wed, 17 May 2017 11:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hYUUuMPJBB2gudUqoGc2lMp+p9y8838zDdhxLOvEDfs=; b=nSzD+EWdCvGB4MsVCiFsp5k9rDq8qNlDijNLqkC7E0looUs0APwj80K0YEHGN3rAuM JeryQRhU40aayalIDRUQ+facUoXiEdKPZ3CSMr+e/1DGbYYCTKQtk3DCLcbp14GcKrf/ xdqP4EBlpToSxreQNbWS26qrcfhSKGWfM7HAYXuP9Z/AT5d6ssYXdI0flTS+RqNWCUOr 5A693BelBA1NJcI2AgncIZSjqvYTX7tAXwtI7lhI+LRoYZqRaF0mHr2umo7UyJb+ZU1W 0m4xQUF5SEX01A3Ve5Sg0XR+uHORRxYE9dtlsPql3FkXKqHOWP6hu/k2JQ5xj9FGH5y5 zUfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hYUUuMPJBB2gudUqoGc2lMp+p9y8838zDdhxLOvEDfs=; b=qPvDhgOwWWr7hbwJVUFcokqjqKCMF5xfhwZA9LEMJ2gZV1EWbiFlVF1FofCPgVvew6 jqbqpWbdbHVMmX1gMnu+IdIzXfBfv1A4c6jNPthVpUJTHj63Gq2aX/nHliOmdEEOUA5+ Gw96A+HQdviijEjChNNONtUJw8jj4dz7oIr6mLzEXfkZHZFn+1KYbcodzSTWqpOreIOj 6AWf5+cvAgZJYsCTYjA/cqXKj2WrH5VQm15irFUNnFW1jpkxakndScn9HFicLY6T/Qo0 Xs6UWyZ9zfxaaU1zk4yPLBHsrSnCOxZzfcUdTbgwkF8PuiENInZwFb1v+nOAafLd7tL3 AgwQ== X-Gm-Message-State: AODbwcCSpHcRpeWTuG5XRGxR/bHi/+ck4EoQk++yrIGayGihdB2glosZ ZoUs2Mj1LoesEkQ6gi6muRBxHsmWsg== X-Received: by 10.31.197.5 with SMTP id v5mr28020vkf.119.1495044791867; Wed, 17 May 2017 11:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.169.135 with HTTP; Wed, 17 May 2017 11:13:11 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <20170516170802.71c2a470@fabiankeil.de> From: Brandon Allbery Date: Wed, 17 May 2017 14:13:11 -0400 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Nikos Vassiliadis Cc: freebsd-fs@freebsd.org, freebsd-stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 18:13:13 -0000 On Wed, May 17, 2017 at 2:04 PM, Nikos Vassiliadis wrote: > If you boot from another system, there is no other way to > import a pool than using "import -f". So, I guess it is > part of normal administrative tasks. You can read more here: > > http://docs.oracle.com/cd/E19253-01/819-5461/gazuf/index.html >> > > This works and always have worked as documented. > Renaming a pool also works as documented, that is, > doing "zpool import oldnamepool newnamepool". Except > for this corner-case. IMHO this is a very serious bug. > Sorry, no, that's not a bug. The bug is that, if importing on another system is a common administrative operation, it should not require you to disable *all* checking. I'd rather prefer specific support for that, e.g. "import -F expectedhostname" to import a zpool on a different host from expectedhostname --- now you have sanity checking for a potentially dangerous operation as well as not turning off *all* error/sanity checking. Sadly, this seems to not have occurred to either Sun or Oracle, despite having documented it. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@freebsd.org Wed May 17 18:17:38 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAE01D71655; Wed, 17 May 2017 18:17:38 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1906B1B9C; Wed, 17 May 2017 18:17:37 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from iris.berlin.strato.de ([192.166.200.216]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MRSeC-1dZMhJ1L4a-00SiiA; Wed, 17 May 2017 20:16:05 +0200 Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: "Eric A. Borisch" , =?UTF-8?Q?Trond_Endrest=c3=b8l?= Cc: "freebsd-fs@freebsd.org" , FreeBSD Stable References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> From: Nikos Vassiliadis Message-ID: <2bab15ae-9683-d9f3-9d5e-d8f66bc14cac@gmx.com> Date: Wed, 17 May 2017 20:15:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:G/hBLmD7MgVNB+aIa2NU9Xa494eigFoI3QCYrdY0VtYuO7dgP30 9nZ+fiqvQv4Z2cXA874fv0M/GF10GPoKKDvPPQ7CpIvhUyNlM3ZH5qlqlFDp5qxuMfEZcKn Oe65odg6RO+JB65mE/1waARtCNVnLlcABWhtrOfUF/W8LILkBaUMb2EqPglZCgywb82nv1A YrEBFyILMQRZFtlHsbZxg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Y5ymDjdWGY4=:t90FUQQ28kydicGzgKNw83 l0GxYaXYLBDhFCrdsdwDfEabwvGkiWFO+/6sRkYRTaYW8aPbxU9fM/xmqUuH3aVSt7HHBRt6Q 6cTcX+BY2Hxv6OeZiocdkzn6Myf4Ea0uEdLxm5GeRHOdzc9AIyg+rDl+HdZaGWK5mpvirYhZ9 HWB4xnOqJZVgNWu/zagMD1X38HVTVOkMmAT5crpjelRiaRgVXWVp01kvakrwEstHkVmojsgo4 WJ5h5hXBsWEDoLUYcaFSV/KFOKXzuNIiKaIVsBNEj/Nd9YI2IDUh3WJsZwlOLdU3HzdEpC4to cjX79c00A2fb9iS0vO4rw8b8sTRpShmsAI80gVSofml/XJXj33Htue9SQpM/m8HpLuL6xgwZW xlTShB8VilYRFQA0IvjccRVqeIoMtwWJb/Zf1jhF4tIGBGRaKfkcWFRUDQdcVCs5Z8Xs5bZ0p RisnaBHu6rU1Xc+xg2UHKXcMxtfaoVOGc6PVygoEfd9BO0E1KUxyxj3r6gXe3Gjwu4N+OSt9K 9u8k3WQHB2ltgqrS5tdtcfqcSFC2W9HWVNeJB2NT4gX/9h6pv91gFArjxHIMUWBWJX7X50J1J rIV9LDPJ/mU/BcmhcQMFycI26WH2OyMOb3+5yKLLpPnKMKI8yhxoUTspXB/E8zDnt17GdYoUK oYfFhe5L8AXWmsfCZ4SVKTr9N8Tho61U5/qZqjDznGdkNWlnsm22+PEnr9jo/g3icgcV/Amjp 950vzeNayhz/YKTy5bBfEgjfqwXInKigN/9RljqWByWGMybIAnmr/a+iPgvdg9/WHqVVUT9r5 m2rewvp X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 18:17:38 -0000 On 05/16/2017 04:26 PM, Eric A. Borisch wrote: > On Tue, May 16, 2017 at 1:31 AM, Trond Endrestøl < > Trond.Endrestol@fagskolen.gjovik.no> wrote: > >> I guess you had a /boot/zfs/zpool.cache file referring to the original >> zroot pool. Next, the kernel found the vega pool and didn't realise >> these two pools are the very same. >> > > Assuming this is the case, shouldn't it be fixed? A check while importing > that the guid of the pool targeted for import is not in the set of > currently active guids would be worthwhile, but it -- apparently, if this > is reproducible -- doesn't exist? > > Again, assuming this is reproducible. > It is reproducible. Except for a check in ZFS, I would also expect that the device cannot be opened twice for writing, that is, protected by GEOM. Nikos From owner-freebsd-stable@freebsd.org Wed May 17 21:12:16 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6508BD7138B; Wed, 17 May 2017 21:12:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E915650; Wed, 17 May 2017 21:12:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x22e.google.com with SMTP id q125so12600787pgq.2; Wed, 17 May 2017 14:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OWTKa7DOCMNQJXoDaOTRCgp716stR6ne//pxm3BAUiA=; b=G7S/54A309lIuMENoOMrz0KsHgt8SqGTDN3M1VDj1c4Ywq2QekJ1pOiGa+qdigrckV qw6QQt1NSpGPnVmW/RHqr1Qrf8xCJJpWXe9XPhc2HRiLzCrV5OdHKmdE/cPabW9NQnUB 9uAWgw6ba5NWc7G4VKHG+et7udGfrJu2FZbqD6x9Gvnu9siLx8FveBUbd24dk4FevNXe uSbGg2YSs5EN9Eb/fj08CEDEPHo2bQMk3g8oUNAhghr2cxp0OxmfNp0lXPHMwTSMNJ92 ToSKka6NLtr1I2/no8F1MvtngzV/t3JJ3DRuaftl+OGrKHZxBYQ57QHENPYAO6LgveKG CHnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OWTKa7DOCMNQJXoDaOTRCgp716stR6ne//pxm3BAUiA=; b=AzoSwkG9GW8bzqQ6g/TmwUGA3u9APPK7mwtoHAXgq+uCQ54crMDpVut8hlZH9IZBVZ q+SjlZVaUPDgYgP8XSDgvwzRj4z+V9mDeMs0QIcVxHvTQKBovrJdCcqaBJWcBhlAOAtn Dph42AUMfvi7TmPFKgcxXg+GiXcCC1OE621t5gZERuVISamjFm0Y3LBoP81Yd6fOM2PS zMe0bbsqt+BaQXKhzvVr777RtrSEaqhvLtrrfERCR0vE5RXMn7D+ugYdIXRGznar3G3v rElFnZfbBGBx7IhOfZkNDyO41l5NH6lCsBtLMCssOZ3uyKLA7rxz0kdUlPGLlCk+4FKA 5PKw== X-Gm-Message-State: AODbwcDR/0GsB70j993C19Z5EtgV/lVq/4kmP/0Yf5pDCBBA2cwVDiEJ Xz170B7Jc+PwftO6zqEvgm5VNDHGWA== X-Received: by 10.98.21.17 with SMTP id 17mr776347pfv.71.1495055535672; Wed, 17 May 2017 14:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Wed, 17 May 2017 14:12:15 -0700 (PDT) In-Reply-To: <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> From: "Eric A. Borisch" Date: Wed, 17 May 2017 16:12:15 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: "freebsd-fs@freebsd.org" , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 21:12:16 -0000 On Tue, May 16, 2017 at 8:53 PM, Paul Kraus wrote: > > > > On May 16, 2017, at 10:26 AM, Eric A. Borisch wrote: > > > > On Tue, May 16, 2017 at 1:31 AM, Trond Endrest=C3=B8l < > > Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > >> I guess you had a /boot/zfs/zpool.cache file referring to the original > >> zroot pool. Next, the kernel found the vega pool and didn't realise > >> these two pools are the very same. > >> > > > > Assuming this is the case, shouldn't it be fixed? A check while importing > > that the guid of the pool targeted for import is not in the set of > > currently active guids would be worthwhile, but it -- apparently, if this > > is reproducible -- doesn't exist? > > When you use the -f (force) flag all bets are off. The assumption is that you _know_ it is safe to import the zpool as commanded. In this case, it was not. > > Many sysadmins I know have gotten into the sloppy (in my opinion) habit of using the force option (for various things) all the time. The force flag, whether it be on a zpool import or a kill -9 should be the last resort when the non-forced command fails. Short version: It's not the -f causing the problem, it's the parsing and (double) importing via /boot/zfs/zpool.cache that is. Longer story: I've been able to reproduce the issue, and if I delete the /boot/zpool.cache file from the (alt rooted during live CD session) renamed pool before rebooting into it, everything is fine. So it is not the import with -f that is causing the problem here, it is the following reboot when the zpool.cache file is parsed and ensuing double-import. (As an aside, using the -f is required to import a pool last used and not exported by another system, and is a common and documented use case. If you look at the code, it turns on a the ZFS_IMPORT_ANY_HOST flag, not an 'ignore all errors' state. There is a separate -F which is more 'force'-ish (turns on rewinding).) This points to error checking while importing pools via the cache as one immediate place to look, specifically to exclude processing of any GUIDs already active on the system. A more general change to prevent importing two pools with the same GUID is also worthwhile (IMHO) and would prevent it the problem, too. - Eric From owner-freebsd-stable@freebsd.org Thu May 18 01:27:54 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBEAED71E4F for ; Thu, 18 May 2017 01:27:54 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA1A8192D for ; Thu, 18 May 2017 01:27:54 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qt0-x229.google.com with SMTP id v27so23697120qtg.2 for ; Wed, 17 May 2017 18:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NgvmcpnkSUZQzeEjpwZPTn7fjfwhuF2cS04IbRKQ5EE=; b=XsZi1o76VVz6p2yyrwuH4G90gqtOKtD7CyXRZT/yMRkGFZ68ub933e7LhcbLwZutrP cartnpU5qb3QIusB5BuNWd7y6lnb1PkVgp1WcOcQCaPRJSP3/PvEpFg1TupFdn0Q0Usd NZshKouVf1GWUlNci6X7c+zo1RpgfdcsTrsW76aBfZ1K1q+Fs4u5TjfetM83SZpHcR+h w4HIuEj65D/lOqDHqtFlG8ARCPT6KIC2oMr5bLloKqG7b2YxwvZROgMib6+cAShkAf50 egoQP49x7MnbcuyC7A4OxigBLEEF+ARvOOqRUXe2jmlIY44ukWaSzT7vwdJG15FsLRJu 7Jeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NgvmcpnkSUZQzeEjpwZPTn7fjfwhuF2cS04IbRKQ5EE=; b=QPVl1x/MUV5ZtrpXRQyiUHqCyQ22a98pkiU0IKSx0USUezSSQ2/aY94p4bbuYCf5+s dxIQObRoukzUXv4uPqWLAWZXFjaX3aApch7LxZCqAFSCg26hmFG8C1FzdI7ziXEDq0Lo uMVLc37FDUbdklJCeMoysSqQqgHOvnC7TBpYlLsugjlw8QeQOmI+R6nwBkvSJ8cOptik 1jKtrV1VmUJ39G5OoQZQqieif+0/0Fc014RAFO0tPZwtnTE9pdY75yQfeh9RRVpv8X+G HdYI67rFXFzZqTidiHTi8o9S3jVCmkIv0hJl44qXMvbDuk2IhCwHBBAeQjB2pKwMEKMz Rumw== X-Gm-Message-State: AODbwcDgrSOjrwnB/1lXXmP5sKdmHIrq+SrdJcvahbt9L6tHz9kCzxHy 1uZXrQAfG1sfOC8Ti+z9Eg== X-Received: by 10.200.55.124 with SMTP id p57mr1559084qtb.258.1495070873603; Wed, 17 May 2017 18:27:53 -0700 (PDT) Received: from [192.168.2.65] (pool-74-109-188-83.albyny.fios.verizon.net. [74.109.188.83]) by smtp.gmail.com with ESMTPSA id b23sm2740056qkb.31.2017.05.17.18.27.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 May 2017 18:27:53 -0700 (PDT) Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Paul Kraus In-Reply-To: Date: Wed, 17 May 2017 21:27:56 -0400 Cc: "freebsd-fs@freebsd.org" , FreeBSD Stable , =?utf-8?Q?Trond_Endrest=C3=B8l?= Content-Transfer-Encoding: quoted-printable Message-Id: <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> To: "Eric A. Borisch" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 01:27:55 -0000 > On May 17, 2017, at 5:12 PM, Eric A. Borisch = wrote: >=20 > Short version: >=20 > It's not the -f causing the problem, it's the parsing and (double) > importing via /boot/zfs/zpool.cache that is. I was unclear=E2=80=A6 _how_ do you get the double entry in zpool.cache = _except_ by using the -f option with a zpool that is already imported ? > Longer story: > So it is not the import with -f that is causing the problem here, it = is the > following reboot when the zpool.cache file is parsed and ensuing > double-import. I would maintain that it is the combination of the import of an already = imported zpool which causes the double entry in the zpool.cache in = combination with a recent rename of the zpool. Would (did) the import without the force fail ? The last host this zpool = was imported on was _this_ host, so the =E2=80=9Cis this zpool used by = another host=E2=80=9D check would not stop such an import. Or, is the zpool rename not updating the name in the zpool.cache file ? I don=E2=80=99t currently have a test system available or I would = experiment...=20 > (As an aside, using the -f is required to import a pool last > used and not exported by another system, and is a common and = documented use > case. If you look at the code, it turns on a the ZFS_IMPORT_ANY_HOST = flag, > not an 'ignore all errors' state. There is a separate -F which is more > 'force'-ish (turns on rewinding).) There are times when it is necessary to force an operation. One of the = underlying assumptions is that the person using the force option _knows_ = with a very high degree of certainty that the zpool is not in use, = either by another system or the same system. From owner-freebsd-stable@freebsd.org Thu May 18 02:38:39 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24EDDD723D2; Thu, 18 May 2017 02:38:39 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5F961D7E; Thu, 18 May 2017 02:38:38 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x231.google.com with SMTP id u28so15660524pgn.1; Wed, 17 May 2017 19:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fb817rkaPmR7yPis4e72q48e7yP4C00HB6jBQE5/w60=; b=hoVz6ChGvAM9FEDJU+0tpHWtV8cZ51wyPX434Imyp+Be9EU+wMJoO/BgiqTHlhgyHV ZgtU8p8fdBpWxWJpzNNtExoKrH+L24SiYxPDthcuo1DdT5padZNey9n6wD/jpI+DGaxK G9OW6CN8xYo8S0AarmuSp1TiOHX4r94yaXy89XLZhRR1WdIUDyq6kDOqhzUr5qsaD64D qDyE4+SiyYiVIj23gj52L3+xRp8rjPN2l6IfklQlC2f55nR+ZaGXBNvY77bsPMW4khAu Jy3ZnaxAM4op3qpjkbBtI1gR/ZKODexRY6RN+6tBS4qMnnr40KzH/bHok2ehSasyMCUW vzcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fb817rkaPmR7yPis4e72q48e7yP4C00HB6jBQE5/w60=; b=jkCQ6X0MMock6S9ey5liK0bYGjxNf7LBVXe9oqq5ENFzHXFgLkxNaHxujqAFoxQD1L BT/tNqhTCDd+Xb9tNMXdth6QueZ5UTqltPVMn2NlP/RHx3Ik2D4OpjRvcYnTPdoVlflt NKE1ScbJmHiNg9vuiTRWQJIgQrUpx7M9kHa/TncEmzCGQBbFeloK3NNONcAgU49lc31/ GhurwUGQHbh7xo7EM4Es6KT6/O5CHNIsVXdqMlij0NFQQ15/rQznZFZ5ARP6qkFejy6z erQ1d4L9PopEVdpwbanY4gZLeNyY0m9CGS8VjC7k/d0+vmV2h1c4a6JaDR+x1ziA1cPb RlTw== X-Gm-Message-State: AODbwcAEJW5lfBdSJy0VNMnUSK0idKhhJQONiIOD1CmPa4LRr1a/dHXH pe8tnzp8U2n0rhC0qc1Lfx4PffCANSttDo0= X-Received: by 10.84.193.129 with SMTP id f1mr2043238pld.129.1495075118396; Wed, 17 May 2017 19:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Wed, 17 May 2017 19:38:37 -0700 (PDT) In-Reply-To: <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> From: "Eric A. Borisch" Date: Wed, 17 May 2017 21:38:37 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: FreeBSD Stable , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 02:38:39 -0000 On Wed, May 17, 2017 at 8:27 PM Paul Kraus wrote: > > > On May 17, 2017, at 5:12 PM, Eric A. Borisch wrote= : > > > > Short version: > > > > It's not the -f causing the problem, it's the parsing and (double) > > importing via /boot/zfs/zpool.cache that is. > > I was unclear=E2=80=A6 _how_ do you get the double entry in zpool.cache _= except_ > by using the -f option with a zpool that is already imported ? > To be clear, I'm using "already imported" to me =3D=3D shows up in 'zpool l= ist' of some running OS, not described in a config file somewhere. The Oracle description [1] that goes along with 'import -f' is: "Do not attempt to import a pool that is active on one system to another system. ZFS is not a native cluster, distributed, or parallel file system and cannot provide concurrent access from multiple, different hosts." This sounds much more like like my description (shows in a running zpool list) than described by a config/cache file. Steps to recreate: (I did it in < 5 minutes in a VM.) Arabic numerals are user actions, Roman numerals are zpool state. 1) Install FreeBSD root-on-zfs onto 'Alpha' I. Alpha exists on disk, and is active whenever your computer is running 1a) Decide at some point later you would like to rename your root pool... so you 2) Boot off live CD II. Alpha exists on disk, but is not active (imported) 3) zpool import alpha beta (because that's how you rename pools) 3a) zpool helpfully points out that it *may be in use* on another system, and use -f to import it anyway. Realize you are at the system that was using it, but in a completely different environment, and decide that it is safe to import. III. Alpha still exists on disk, and is still not active 4) zpool import -f alpha beta succeeds without any complaints. IV. Alpha no longer exists, Beta exists (with the same GUID as Alpha) AND is active. This is an 'atomic' operation from user's point of view, and at no point does zpool list show more than one pool 5) zpool list shows only beta; scrubs fine, life is good.. V. Beta exists on disk and is active and healthy. Alpha is no more. (Except as a ghost in a cache file) 6) Reboot into OS. Kernel messages mention booting off of beta/. Good, good... VI. Beta exists at this point certainly, as boot progresses. The ghost of Alpha is still lurking, however. Before we drop to a prompt, the zpool.cache is parsed, and Alpha springs back into existence beside Beta. NOTE: This is where I'm suggesting a cache file shouldn't trump the on-disk metadata (name mismatch) and running state (GUID collision) and lead to corruption. VII. Alpha and Beta exist together violating the Pauli exclusion principle as it applies to zpools. 7) Despair. Try to export one or the other. No good. Errors start to show up in zpool status. Rebooting fails in various colorful ways. Trying to import the pool again via Live CD is equally fruitless. VIII. Your zpool is cooked. By a config file. Hope you weren't using ZFS for integrity. I would maintain that it is the combination of the import of an already > imported zpool which causes the double entry in the zpool.cache in > combination with a recent rename of the zpool. > > Would (did) the import without the force fail ? The last host this zpool > was imported on was _this_ host, so the =E2=80=9Cis this zpool used by an= other > host=E2=80=9D check would not stop such an import. Yes, it fails without the -f, and helpfully suggests using the -f to import it. I don't think it's already imported in a way that most people (including Oracle) describe it. Or, is the zpool rename not updating the name in the zpool.cache file ? As the zpool rename is occurring in the live cd system; the cache file (living on the filesystems of the pool to be renamed) isn't accessible during the import/rename step, and isn't known about by the active OS. I suspect using a temporary and updating the cache file post-rename pre-reboot would work, just like deleting the cache file before reboot worked. I still, however, maintain an errant cache file shouldn't trump both on-disk state (my name... is Beta) and in-memory state (but I already have that GUID) and bring down a pool. - Eric [1] http://docs.oracle.com/cd/E19253-01/819-5461/gazuf/index.html > From owner-freebsd-stable@freebsd.org Thu May 18 03:42:55 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35938D716E3 for ; Thu, 18 May 2017 03:42:55 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2C431FFE for ; Thu, 18 May 2017 03:42:54 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qk0-x231.google.com with SMTP id a72so26239359qkj.2 for ; Wed, 17 May 2017 20:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rRuiv0UMmsKXc6sLWxRBps3uE0ATm9YCKhbN2tZaT18=; b=ig7hl1yw+beA31TLcXiZQWzvMQTg1W8ojgFBJsYjKIs7GxlKa26DmOOAgNu/UkuXi/ tqvsohreC5RHpWjDGpZwusaIEaKcuwbUzstaYYI1QAge+a2p/KUUjp9JB2XpTbKfPXjC UkVi7WsOIS6JyhqfJpi1gAn+O8qNjfE8QtMcutmrywA9mUCPsG7FrzknQ7f0TqKZIufx h3FkHxUSOSLJY6NPDoLmlduCtMWuv8x/B/AiTKbO4tB0/aM2Iugqdo6VzNKpujHiDgAo 3+nagrBVhzFEjFqMO8gHVqlu47SWzOiaLfZvBhmui8/AypcGSYC4uz6uDSYIjIy83LjE /5LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rRuiv0UMmsKXc6sLWxRBps3uE0ATm9YCKhbN2tZaT18=; b=EpaObCRlU3FjUdYytbrG07zhEvi4ivkOB3L0q9ur32DUkbmB1w9u5zgEfrf/cnvtgf WnaiEJYGLY3DcBKsX+rWJ71ZwdMERn2uIE4V7rrIyGI2vCQVFzen1dTlQKh85s8GID21 3TFVajOaGebI5GOYesKZAsk7ZlEtTims7pJLD/lkxaDhMUDlXn7tpWYv/ECy5DK7UHFd 1MQEymp6dXmB8//RVIDesLCHS5X0eDnBTIrunWINw8lrbN+H+Mm1mmqtDFK9wW9mII2w GsbZAIm5ki0U7ONfrC5OnFOJaDmD9TGoUIXeKH5O2LeUlCqpy/fcwKrg2qXv3Adocaga MGOg== X-Gm-Message-State: AODbwcCfYcUJsD01CEl6lS0DGrK4Jg+HxfYFFIEuPwkrCU1mzWEKr1tU 3MH0MMXKYPL1c0dh X-Received: by 10.55.129.65 with SMTP id c62mr1894367qkd.229.1495078973857; Wed, 17 May 2017 20:42:53 -0700 (PDT) Received: from [192.168.2.65] (pool-74-109-188-83.albyny.fios.verizon.net. [74.109.188.83]) by smtp.gmail.com with ESMTPSA id l10sm2690871qte.15.2017.05.17.20.42.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 May 2017 20:42:53 -0700 (PDT) Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Paul Kraus In-Reply-To: Date: Wed, 17 May 2017 23:42:52 -0400 Cc: Nikos Vassiliadis , FreeBSD FS , freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <20170516170802.71c2a470@fabiankeil.de> To: Brandon Allbery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 03:42:55 -0000 > On May 17, 2017, at 2:13 PM, Brandon Allbery = wrote: >=20 > Sorry, no, that's not a bug. The bug is that, if importing on another > system is a common administrative operation, it should not require you = to > disable *all* checking. I'd rather prefer specific support for that, = e.g. > "import -F expectedhostname" to import a zpool on a different host = from > expectedhostname --- now you have sanity checking for a potentially > dangerous operation as well as not turning off *all* error/sanity = checking. The assumption at work here is that you have exported the zpool from the = system that was using it. At that point, zpool import with no = -f will work fine. It is only the special case of a zpool that was NOT = exported that requires the use of the -f option. I don=E2=80=99t see this as an unreasonable expectation. You unmount = non-ZFS (and under the covers ZFS) filesystems before moving them to = other systems. Why should we not be expected to export a zpool before = moving it ? Note that in the case of a crashed or failed or otherwise _unexpected_ = move of a zpool from one system to another you still need to force the = import. Just as you are forced to either fsck or replay journals on = non-ZFS filesystems before you can mount them.= From owner-freebsd-stable@freebsd.org Thu May 18 07:06:00 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57465D6C923 for ; Thu, 18 May 2017 07:06:00 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D3421C88 for ; Thu, 18 May 2017 07:05:59 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:62875] helo=localhost) by dnvrco-omsmta01 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id 63/BF-09002-3974D195; Thu, 18 May 2017 07:04:52 +0000 Date: Thu, 18 May 2017 07:04:51 +0000 Message-ID: <63.BF.09002.3974D195@dnvrco-omsmta01> From: "Thomas Mueller" To: freebsd-stable@freebsd.org CC: freebsd-current@freebsd.org Subject: Problem with re(4) Ethernet driver has resurfaced in 11-STABLE and HEAD X-RR-Connecting-IP: 107.14.64.6:25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 07:06:00 -0000 I recently updated my 10.1-STABLE to 11.0-STABLE and find I can no longer connect with the Ethernet. dhclient re0 produces DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 19 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 No DHCPOFFERS received. No working leases in persistent database - sleeping. uname -a shows FreeBSD amelia2 11.0-STABLE FreeBSD 11.0-STABLE #1 r317932: Mon May 8 23:23:37 UTC 2017 root@amelia2:/usr/obj/usr/src11/sys/SANDY11NC amd64 Relevant lines from /var/run/dmesg.boot are re0: port 0xe000-0xe0ff mem 0xf7d04000-0xf7d04fff,0xf7d00000-0xf7d03fff irq 17 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: d4:3d:7e:97:17:e2 re0: netmap queues/slots: TX 1/256, RX 1/256 Problem shows much quicker in my recent build of HEAD (12-current), where dhclient re0 gives just a couple lines screen output before crashing into debugger db> prompt Build host for 12-current installation was the recent build of 11.0-STABLE amd64. Kernel strings there show __page_fault.read __page_fault.write amd64 @(#)FreeBSD 12.0-CURRENT #1 r318262: Sun May 14 09:37:30 UTC 2017 FreeBSD 12.0-CURRENT #1 r318262: Sun May 14 09:37:30 UTC 2017 root@amelia4:/BETA1/usr/obj/BETA1/usr/src/sys/SANDY12NC FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) FreeBSD 12.0-CURRENT SANDY11NC It looks like I can connect to Internet with Hiro H50191 USB wireless adapter, driver rsu, but I am not sure of its stability on 11.0-STABLE and 12.0-current.. Tom From owner-freebsd-stable@freebsd.org Thu May 18 14:18:04 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11204D73EDB; Thu, 18 May 2017 14:18:04 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C682E13E6; Thu, 18 May 2017 14:18:03 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pf0-x236.google.com with SMTP id 9so24591390pfj.1; Thu, 18 May 2017 07:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uyiJiCu4ojy7hTBs2BmORXpW3VGO/WrzmJwDIv3Rd4A=; b=PGubdnf1QNCJxrmbXdrdx944WQLfaem2/gOm+IN+ubD6Ke9F+Evc7PoS51TlsqVol1 6+2dcWz9v0eJy8tNOFCllgfjdzTtz13f3q2kOHzKsAIZufqac+BQcPgzMPw3fQszzgDB Yw31KWKndq1WdT0xCBr0wJYRGT+OhJ/39wLyVkD9Q91vblr5uhutJepwAh4vguVbqnyg OtdZRNNUT3gSf9b5DvEdq0wsqEw8GyK9JzNfRWVw50A72hxF6NJh1HuKjeJKTFDypXtJ SQFx6lbPzCAiSRXE7KIwWiP9fuwKQMJr+9RBvCpPS2pYWm4Lu0Upp+8HzbdF2lVLSZGP HZew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uyiJiCu4ojy7hTBs2BmORXpW3VGO/WrzmJwDIv3Rd4A=; b=AmPOgwVJmy8mEMf3geZIe3VF4+XUHuukYTqK6/xX6N07JFWoFCm5NTOedmAND4BaJm p5TeN7DRm1oMr3o1VTtsOk5zd6WVpkT3qOFqWZv/0vvObFJXp6UkLH4X+2lGz0njUQwH HTNPXALr47wRyaVREeaE/4dDfreGFNdXyQQabfQn6GZ11kyP4fZFErLD30OGQKQ1c1iS VNtGCz7OBFPUbvt973eHhUsRCMRHhrNeeSahH3tZHCaGPKTMtgFQwpWiatQOPVK046wQ X+hWqE5pgJyhDH3stm8cku7bMTfvY3zTMtahQaqgZM4jbou7Q3oDpPRRsNUgS3ybN8ZN U4qA== X-Gm-Message-State: AODbwcDVy+4SbWUCMr4qb4L4e7H9ad8m6c16hxLvcr/eVQWH5supYLch lfWHz3TLwKFOY0UDRbOg86aVrAQN0pjy X-Received: by 10.99.186.78 with SMTP id l14mr4775984pgu.182.1495117083279; Thu, 18 May 2017 07:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Thu, 18 May 2017 07:18:02 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> From: "Eric A. Borisch" Date: Thu, 18 May 2017 09:18:02 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: FreeBSD Stable , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 14:18:04 -0000 On Wed, May 17, 2017 at 9:38 PM, Eric A. Borisch wrote: > 4) zpool import -f alpha beta succeeds without any complaints. > > IV. Alpha no longer exists, Beta exists (with the same GUID as Alpha) AND > is active. This is an 'atomic' operation from user's point of view, and at > no point does zpool list show more than one pool > > 5) zpool list shows only beta; scrubs fine, life is good.. > > V. Beta exists on disk and is active and healthy. Alpha is no more. > (Except as a ghost in a cache file) > A quick test revealed one other tidbit this morning; if I 'zpool export beta' at this point in the process (still in live CD OS), everything is OK on reboot into the installed OS. For whoever wants to investigate handling/hand-off between bootloader/kernel/fully booted, the problem appears when a: 1) root pool is renamed, but not 'zpool export'-ed after rename via an 'external' OS (live CD) ** and ** 2) A stale zpool.cache file exists on the pool referring to the original name. - Eric From owner-freebsd-stable@freebsd.org Thu May 18 14:55:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B013D729CC for ; Thu, 18 May 2017 14:55:13 +0000 (UTC) (envelope-from rose.merline@infodigitaldata.com) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-ma1ind01on0110.outbound.protection.outlook.com [104.47.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 230D6D20 for ; Thu, 18 May 2017 14:55:11 +0000 (UTC) (envelope-from rose.merline@infodigitaldata.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2126287.onmicrosoft.com; s=selector1-infodigitaldata-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ipOlcQcaVJOPj4F0YLgTTkn4y5DgQKdqmEcs78HMa+w=; b=VqA6JY7iDU9iKiJ/b9+WF+OusK02OokNCOO9aDiXGwZGeQvxugk7PIg/b8H4ijlzIp5vB82morvAC8pO06en33+LWJVSSBK0sRTrm0oQFhLHNfEpOhdK7oFq4KYjHY7e3qey++9yc21V9ZXufWOPN5oDxJFi9RIUd+0q3A0dOAo= Received: from BM1PR01MB0596.INDPRD01.PROD.OUTLOOK.COM (10.164.132.23) by BM1PR01MB0596.INDPRD01.PROD.OUTLOOK.COM (10.164.132.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Thu, 18 May 2017 14:55:07 +0000 Received: from BM1PR01MB0596.INDPRD01.PROD.OUTLOOK.COM ([10.164.132.23]) by BM1PR01MB0596.INDPRD01.PROD.OUTLOOK.COM ([10.164.132.23]) with mapi id 15.01.1101.017; Thu, 18 May 2017 14:55:07 +0000 From: Rose Merline To: "freebsd-stable@freebsd.org" Subject: COMPUTEX TAIPEI 2017 Thread-Topic: COMPUTEX TAIPEI 2017 Thread-Index: AdLP5m0KfCAUDzQoS2GGwU1fyr34Bg== Date: Thu, 18 May 2017 14:52:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=infodigitaldata.com; x-originating-ip: [49.207.53.190] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BM1PR01MB0596; 7:UDksBzfGPU/oK53zXYBW1Us+h5lbjT93F+4fvgjf/UEwZZrePg1FqXVvCbuOPnbWmihu/wO3tFsINVIEy7SvpGT6sWaWeHu3cdRM/ArAMLec+/5yPldeV1BQwHPXuhpZF3rK8qcBlqvWlIKB5q4LhJj3L7flEQbmludx/3Mozbralx0c105ons7q9wdOxOgn+d7WyG32CWSX9JwfSBODbBjtNbjHZ2b389+5/rM3alXn/iN5zIqR8M5TpJG/YAIdhTbAeadH+fujJhLLha17j3v1Rkh/r0iZVM/B6EyvOPWHULSX4smP4CRkseKUvoTkPZF6zMOHp+rNx9EprKRw3A== x-ms-traffictypediagnostic: BM1PR01MB0596: x-ms-office365-filtering-correlation-id: a2f8f7d6-9e63-44d6-e518-08d49dfde02a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201702085553020)(201702085551020); SRVR:BM1PR01MB0596; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6043046)(6072148); SRVR:BM1PR01MB0596; BCL:0; PCL:0; RULEID:; SRVR:BM1PR01MB0596; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(9326002)(53936002)(66066001)(9686003)(790700001)(38730400002)(110136004)(7696004)(3846002)(55016002)(6306002)(54896002)(86362001)(2906002)(102836003)(6116002)(2501003)(6506006)(77096006)(74316002)(6436002)(8676002)(7736002)(3660700001)(25786009)(54356999)(2900100001)(189998001)(6666003)(8936002)(50986999)(7520500002)(5660300001)(7116003)(5640700003)(478600001)(2351001)(3280700002)(122556002)(5630700001)(6916009)(81166006)(33656002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BM1PR01MB0596; H:BM1PR01MB0596.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: infodigitaldata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 14:52:59.2713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 478f63cc-97aa-4e10-99e0-25353d93f572 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BM1PR01MB0596 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 14:55:13 -0000 Hello I found your company listed in Interop COMPUTEX TAIPEI 2017 and I would lik= e to know if there are possibilities of us working together. We provide B2B database across all target verticals and I would like to kno= w if you are interested in acquiring any such list. Below are some of Target Job Titles: * SmarTEX * InnoVEX * iStyle * Gaming & VR * Business Solutions (including POS & ERP) * Embedded Systems * Components & Parts * Data Storage * Touch Applications & Display Products * Communications & Networking * Mobile Devices * Peripherals & Accessories * Semiconductors & Hospitality Suites * Systems & Solutions * ICT/IoT (Internet of Things) Information fields: Names, Title, Email, Phone, Company Name, Company URL, = Company physical address, SIC Code, Industry, Company Size (Revenue and Emp= loyee) Let me know if you are interested and I will get back to you with the count= s, sample and pricing. Await for your response. Regards, Rose Merline Data Consultant To opt out, please reply with Leave Out in the Subject Line. From owner-freebsd-stable@freebsd.org Fri May 19 06:03:02 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D269D73E14 for ; Fri, 19 May 2017 06:03:02 +0000 (UTC) (envelope-from ocinquin@uci.edu) Received: from mda1.es.uci.edu (mda1.es.uci.edu [128.200.80.3]) (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 108DD16B7 for ; Fri, 19 May 2017 06:03:01 +0000 (UTC) (envelope-from ocinquin@uci.edu) Received: from ismtp2.es.uci.edu (ismtp2.es.uci.edu [128.195.153.32]) by mda1.es.uci.edu (8.14.4/8.14.4) with ESMTP id v4J62ABg342969 for ; Thu, 18 May 2017 23:02:10 -0700 Received: from vcv079231.vpn.uci.edu (vcv079231.vpn.uci.edu [128.195.79.231]) (authenticated bits=0) by ismtp2.es.uci.edu (8.14.4/8.14.4) with ESMTP id v4J622op231276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 May 2017 23:02:03 -0700 X-UCInetID: ocinquin From: Olivier Cinquin Message-Id: <0C9874B5-0F3A-48A7-B6F4-39854D06257A@uci.edu> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Kernel panic in smp rendezvous Date: Thu, 18 May 2017 23:02:01 -0700 In-Reply-To: <20170511100125.GW1622@kib.kiev.ua> Cc: freebsd-stable@freebsd.org To: Konstantin Belousov References: <20170511100125.GW1622@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 06:03:02 -0000 > On May 11, 2017, at 3:01 AM, Konstantin Belousov = wrote: >=20 > On Wed, May 10, 2017 at 03:29:39PM -0700, Olivier Cinquin wrote: >> Hi, >> I'm getting the following kernel panics on recent 11-STABLE = (r317883): >>=20 >> spin lock 0xffffffff81df43d0 (smp rendezvous) held by = 0xfffff8019c7a7000 (tid 100845) too long >> timeout stopping cpus >> panic: spin lock held too long >> cpuid =3D 12 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe3e64caf2a0 >> vpanic() at vpanic+0x186/frame 0xfffffe3e64caf320 >> panic() at panic+0x43/frame 0xfffffe3e64caf380 >> _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x311/frame = 0xfffffe3e64caf3f0 >> smp_targeted_tlb_shootdown() at = smp_targeted_tlb_shootdown+0x101/frame 0xfffffe3e64caf470 >> smp_masked_invlpg_range() at smp_masked_invlpg_range+0x50/frame = 0xfffffe3e64caf4a0 >> pmap_invalidate_range() at pmap_invalidate_range+0x196/frame = 0xfffffe3e64caf4e0 >> vm_thread_stack_dispose() at vm_thread_stack_dispose+0x2f/frame = 0xfffffe3e64caf530 >> thread_free() at thread_free+0x39/frame 0xfffffe3e64caf550 >> thread_reap() at thread_reap+0x10e/frame 0xfffffe3e64caf570 >> proc_reap() at proc_reap+0x6bd/frame 0xfffffe3e64caf5b0 >> proc_to_reap() at proc_to_reap+0x48c/frame 0xfffffe3e64caf600 >> kern_wait6() at kern_wait6+0x49e/frame 0xfffffe3e64caf6b0 >> sys_wait4() at sys_wait4+0x78/frame 0xfffffe3e64caf8a0 >> amd64_syscall() at amd64_syscall+0x6c4/frame 0xfffffe3e64cafa30 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe3e64cafa30 >>=20 >>=20 >> The panics occur sporadically and seemingly randomly. They occur on >> multiple machines with the same configuration, and on older revisions = of >> 11-STABLE as well as r317883 (I cannot easily bisect this down to a >> specific commit given that it can take days or sometimes weeks for = the >> panic to occur). Note that my kernel is compiled with "options = IPSEC", but >> that does not seem to be relevant. >>=20 >> My understanding of the overall problem is that an IPI is sent to all = cores >> by smp_rendezvous_cpus, but that some of the cores do not respond to = it (or >> at least do not respond to it correctly and in time). More = specifically, I >> can find 61 threads that seem to be blocked in cpustop_handler on an = atomic >> operation to indicate that they have stopped in response to the IPI. = This >> operation is CPU_SET_ATOMIC(cpu, &stopped_cpus); CPU_SET_ATOMIC boils = down >> to a call to "atomic_set_long" (not sure where that is itself defined = for >> amd64). Either there is a line numbering problem, or this suggests = that >> perhaps there is a deadlock at this step (unless there's some sort of >> livelock and CPU_SET_ATOMIC is the place where the threads spend most = of >> their time). >>=20 >> Looking at the thread backtraces as a whole, I can see the one that >> triggered the panic, the 61 that are in cpustop_handler, and a lot of >> sleeping threads. I guess each core should have an active thread, and = this >> is an architecture with 64 cores, so that leaves 64 - (1 + 61) =3D 2 = cores >> that are unaccounted for. Interestingly, for 2 different panics for = which I >> have a vmcore file these numbers are the same. For these two panics, = the >> IDs of the cores that are neither in cpustop_handler nor calling the = smp >> rendez vous are not the same (#18 and #19 in one instance, #44 and = #45 in >> the other instance) but in both instances the IDs are consecutive; = perhaps >> that's relevant. >>=20 >> I've uploaded a full set of backtraces at >> https://gist.github.com/cinquin/d63cdf9de01b0b8033c47128868f2d38 and = a >> dmesg at = https://gist.github.com/cinquin/17c0cf6ac7832fd1b683488d08d3e69b >> (in short, the machine is a 4 processor Opteron 6274 system). I'm = pasting below >> an example backtrace of the threads in stopcpu_handler. >>=20 >> Any suggestions as to what the problem might be and how to solve it? = I've >> saved the core and can provide further information. >>=20 >> Thanks >> Olivier Cinquin >>=20 >> A total of 61 threads are along the lines of >>=20 >> #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275 >> #1 0xffffffff8105a6f5 in ipi_nmi_handler () at = /usr/src/sys/x86/x86/mp_x86.c:1231 >> #2 0xffffffff80ef740a in trap (frame=3D0xfffffe3e687f7f30) at = /usr/src/sys/amd64/amd64/trap.c:185 >> #3 0xffffffff80edbd03 in nmi_calltrap () at = /usr/src/sys/amd64/amd64/exception.S:510 >> ... >> (kgdb) frame 0 >> #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275 >> 1275 CPU_SET_ATOMIC(cpu, &stopped_cpus); >> (kgdb) list >> 1270 cpu =3D PCPU_GET(cpuid); >> 1271=09 >> 1272 savectx(&stoppcbs[cpu]); >> 1273=09 >> 1274 /* Indicate that we are stopped */ >> 1275 CPU_SET_ATOMIC(cpu, &stopped_cpus); >> 1276=09 >> 1277 /* Wait for restart */ >> 1278 while (!CPU_ISSET(cpu, &started_cpus)) >> 1279 ia32_pause(); >> (kgdb) p stopped_cpus >> $1 =3D {__bits =3D 0xffffffff81df4368} >> (kgdb) p started_cpus >> $2 =3D {__bits =3D 0xffffffff81df4418} >>=20 >=20 > It would be interesting to see only the backtraces for threads which = are > on CPUs, i.e. all nmi_stop_handler()-threads and others. >=20 > =46rom your description, it looks like that there are two problems, = both > of which might have the same cause. Initial thread broadcasts tlb > shootdown IPI, calling smp_targeted_tlb_shootdown(). The function > locks the smp_ipi_mtx spinlock. After IPI is sent, the function loops > waiting for other cores acknowledging the IPI. The is the > while (*p_cpudone !=3D generation) > ia32_pause(); > loop which reads from other CPU PCPU area. >=20 > Then, other thread decides that it should execute shootdown as well, = and > tries to lock the same smp_ipi_mtx spinlock. It times out due to the > initial thread, and panics. Panic(9) sends broadcast NMI to all cores > except self to stop the machine. This is what you see in the = backtrace > for all except one thread. >=20 > If you do not see NMI handler entrance for the initial thread, then = this > indicates the second problem, any way showing just backtraces for each > CPU would clear the possible confusion. >=20 > The question of why shootdown times out is open anyway. You should > examine pc_smp_tlb_done in each PCPU area to see whether CPUs properly > reacted to the IPI and it is initiator which does not see the update, > or it is some CPU which did not received IPI. >=20 > This might be a CPU errata. I remember much earlier AMD CPUs having an > issue with tight read loop, could be that it is it. Did you tried to > update BIOS ? Also install sysutils/devcpu-data and upgrade microcode = on > the processor online. I skimmed over the AMD document 48063 Rev. 3.24 > "Revision Guide for AMD Family 15h Models 00h-0Fh Processors", nothing > oustanding came out except possibly Errata 619: >=20 > 619 Non-Posted Reads May Block Write Dependent on Probe > Responses > The northbridge may stall indefinitely on non-posted reads when a = posted > write becomes dependent on probe responses. >=20 > You might also try to change the loop I cited above to some variant = like > while (*p_cpudone !=3D generation) { > ia32_pause(); > mfence(); > } > and report whether any of the magic helped. So here's a report on the problem and its probable solution, in case = others find it useful (although it pertains more to my specific machines than = to FreeBSD). I had tried manually updating the processor microcode after booting, = using the updated cpucontrol that was committed last year and microcode downloaded from = https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ tree/amd-ucode. That does not prevent the panic. But your email and the contents of the AMD document you cited prompted = me to update the BIOS (Supermicro / AMI; going from 3.0 to 3.5, if I recall correctly). That seems to have done the trick: I've had a few machines running without hiccups for about a week, with a workload that would = more likely than not have triggered the problem by now if it still existed. In case that information can be of use somehow, adding "mfence()" as suggested above does not fix the problem in presence of the older BIOS. Many thanks for your thoughtful response! Olivier= From owner-freebsd-stable@freebsd.org Fri May 19 16:17:07 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3540DD738E0 for ; Fri, 19 May 2017 16:17:07 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC25136C for ; Fri, 19 May 2017 16:17:07 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id 1C12BD738DF; Fri, 19 May 2017 16:17:07 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BB68D738DE for ; Fri, 19 May 2017 16:17:07 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::3]) (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 DE231136B for ; Fri, 19 May 2017 16:17:06 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.ingresso.co.uk ([2a02:b90:3002:411::6]) by constantine.ingresso.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dBkaO-00027r-1Y for stable@freebsd.org; Fri, 19 May 2017 16:17:04 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dBkaN-0005gl-RQ for stable@freebsd.org; Fri, 19 May 2017 17:17:03 +0100 To: stable@freebsd.org Subject: Static linking of libpam and opie Message-Id: From: Pete French Date: Fri, 19 May 2017 17:17:03 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:17:07 -0000 Am running into a problem trying to compile a piece of code staticly which ultimately uses opie. I get the following: /usr/local/lib/libsasl2.a(otp.o): In function `opie_server_mech_step': otp.c:(.text+0x345): undefined reference to `opiechallenge' otp.c:(.text+0x414): undefined reference to `opieverify' /usr/local/lib/libsasl2.a(otp.o): In function `opie_server_mech_dispose': otp.c:(.text+0x587): undefined reference to `opieverify' cc: error: linker command failed with exit code 1 (use -v to see invocation) If I link dynamicly all works fine (but this isnt an option for me). The culprit here is the latest memcached port which uses sasl, and that in turn requires opie. I cant compile the libmemcached port without SASL (but thats another issue, one for the ports mailing list I think). The thing is, shouldnt the static version of libpam provide this ? I can see a libpam_opie.so file, but of course I cant staticly link against that. Whats the correct thing to do here ? -pete. PS: note that I have no intention of using SASL / OPIE, I just want to get the code compiling again! From owner-freebsd-stable@freebsd.org Fri May 19 16:19:01 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE9D3D73A04 for ; Fri, 19 May 2017 16:19:01 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9D12D1583 for ; Fri, 19 May 2017 16:19:01 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id 9969ED73A03; Fri, 19 May 2017 16:19:01 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99120D73A02 for ; Fri, 19 May 2017 16:19:01 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::3]) (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 6B3431580 for ; Fri, 19 May 2017 16:19:01 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.ingresso.co.uk ([2a02:b90:3002:411::6]) by constantine.ingresso.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dBkcF-00029K-Tf; Fri, 19 May 2017 16:18:59 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dBkcF-0005h9-My; Fri, 19 May 2017 17:18:59 +0100 To: petefrench@ingresso.co.uk, stable@freebsd.org Subject: Re: Static linking of libpam and opie In-Reply-To: Message-Id: From: Pete French Date: Fri, 19 May 2017 17:18:59 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:19:01 -0000 Ignore me. I just found libopie. Duh. Sorry! From owner-freebsd-stable@freebsd.org Sat May 20 03:02:22 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CE8DD75DC6 for ; Sat, 20 May 2017 03:02:22 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 826471186 for ; Sat, 20 May 2017 03:02:22 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: by mailman.ysv.freebsd.org (Postfix) id 7A17CD75DC1; Sat, 20 May 2017 03:02:22 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79461D75DBE; Sat, 20 May 2017 03:02:22 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail5.asahi-net.or.jp (mail5.asahi-net.or.jp [202.224.39.201]) by mx1.freebsd.org (Postfix) with ESMTP id 559451183; Sat, 20 May 2017 03:02:21 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-71-172-4-245.nwrknj.fios.verizon.net [71.172.4.245]) (Authenticated sender: NR2Y-OOT) by mail5.asahi-net.or.jp (Postfix) with ESMTPSA id 402BC11990D; Sat, 20 May 2017 11:56:41 +0900 (JST) Date: Fri, 19 May 2017 22:55:30 -0400 From: Yoshihiro Ota To: stable@freebsd.org Cc: current@freebsd.org, net@freebsd.org Subject: ndis wireless on 11.0-RELESE has been broken and its patch Message-Id: <20170519225530.92dddbb2b18dddbcae5c9f5f@j.email.ne.jp> In-Reply-To: <20170103234048.3e77722e1728a3666377f829@j.email.ne.jp> References: <20150731121226.GJ889@FreeBSD.org> <20170103234048.3e77722e1728a3666377f829@j.email.ne.jp> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.29; i386-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 03:02:22 -0000 Hi, I've been chasing a NDIS wireless bug for a while as I realized network stopped working on some of hardware. I have its PR and also attached a patch. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213237 It will be nice if someone can follow up so that we can have 11.1-RELEASE NDIS wireless working. Regards, Hiro On Tue, 3 Jan 2017 23:40:48 -0500 Yoshihiro Ota wrote: > Hi Gleb, > > Are you still accepting a bug report on this? > I have a laptop that I need to use NDIS driver. > This change impacted and causes kernel panic. > I haven't used this laptop for a quite while and > didn't realize it had stopped working. > > When I setup a wlan0 device with NDIS in wepmode, > "ifconfig wlan0 up" causes kernel memory currupption > and causes next ioctl/sysctl access programs such > as "ps" and "sysctl -a" crash the kernel. > > Regards, > Hiro > > On Fri, 31 Jul 2015 15:12:26 +0300 > Gleb Smirnoff wrote: > > > Hi! > > > > I need to make couple of non-functional but rather large changes > > to the if_ndis driver and will appreciate if anyone signs up to > > test my changes. Please contact me if you can provide help. > > > > -- > > Totus tuus, Glebius. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sat May 20 03:57:16 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83EFCD737D2; Sat, 20 May 2017 03:57:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50A3F1EDF; Sat, 20 May 2017 03:57:16 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x232.google.com with SMTP id q125so45957016pgq.2; Fri, 19 May 2017 20:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a8HugRkNVhu8TZDJKzEycTrdIK2ZIJE0bSPCn1yzX70=; b=tGx/JQhRrCcK8CAO53ZtXIEtxxY7WA/Q8WdnercY7u/JmD+FBn3bAPstu4KEHiwLqb iuR8/SEsxDVVuLx3FLYBBniYjAYmJSbUUJZOpejR1g2FlNfG1xDw5Q6MkSeXtO04pXXo 345vMmg0QKv+Bra19QQ3uq8TL3gcXHQ5/r9yIECI4+RcHmKL6Pj2hqSEkcdwwKYfyCt7 mRTFUPCAMCGZ6QW1VcVw3DMeIN6IVzaqmfr2UnhMpbD0JBVHEHu5/clZ9thv4T205YAO gRerkWYwSlZVzVa1YefHR84GkYmvXZVtbAD+PyNKDirtMgBxXz2ibjhLvhjjDLlxvzXg jtaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a8HugRkNVhu8TZDJKzEycTrdIK2ZIJE0bSPCn1yzX70=; b=PcbX2TYDSv4ow+vvKTG7ME+Lnf4uGqAHy+ly1ukyq8oUqGYPrgsqGozuKcyozBx8MM gOVta4Z5HFaBNOQUbWZfXpYYpmU3OaXDALUPeOCTo77YkpQXnJ1Svj2ZxdXN4oGG596q Ty9zwhDKHYA7f+E4133UdiUNlPiovFZPiCRQvhTdzgQk+kL+XnCe4nhOk/cBusndEccT aL1Zr+mdBxjzuaRL3DwIoUF1XLxAefIE1A6ELoej90XbqHguFNXIkr0rVk5oby1ZzOnC nQzbIoYkFy5Yth5hDqWJoFgx04W3tmgW5sLjo4vV28jwMOs/fJghdFPkwuGlUyxzGgMM 5Elg== X-Gm-Message-State: AODbwcBlgFfb/KZwoLmtR0bkbSH0exom+hD+A9UQybm5MQMDGnFe1eCW MkrGeE0CwILOhNEwYAU6epduIXuPyRQFXHQ= X-Received: by 10.99.181.11 with SMTP id y11mr13420912pge.54.1495252635882; Fri, 19 May 2017 20:57:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.155.47 with HTTP; Fri, 19 May 2017 20:57:15 -0700 (PDT) In-Reply-To: References: <7c059678-4af4-f0c9-ff3b-c6266e02fb7a@gmx.com> <2318D9EB-4271-42C8-AEDB-4BB86607BB3D@kraus-haus.org> <81774CB0-9E06-43AF-B58B-259234111D61@kraus-haus.org> From: "Eric A. Borisch" Date: Fri, 19 May 2017 22:57:15 -0500 Message-ID: Subject: Re: zpool imported twice with different names (was Re: Fwd: ZFS) To: Paul Kraus Cc: FreeBSD Stable , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 03:57:16 -0000 On Thu, May 18, 2017 at 9:18 AM, Eric A. Borisch wrote: > On Wed, May 17, 2017 at 9:38 PM, Eric A. Borisch > wrote: > >> 4) zpool import -f alpha beta succeeds without any complaints. >> >> IV. Alpha no longer exists, Beta exists (with the same GUID as Alpha) AND >> is active. This is an 'atomic' operation from user's point of view, and at >> no point does zpool list show more than one pool >> >> 5) zpool list shows only beta; scrubs fine, life is good.. >> >> V. Beta exists on disk and is active and healthy. Alpha is no more. >> (Except as a ghost in a cache file) >> > > A quick test revealed one other tidbit this morning; if I 'zpool export > beta' at this point in the process (still in live CD OS), everything is OK > on reboot into the installed OS. > > For whoever wants to investigate handling/hand-off between > bootloader/kernel/fully booted, the problem appears when a: > > 1) root pool is renamed, but not 'zpool export'-ed after rename via an > 'external' OS (live CD) > ** and ** > 2) A stale zpool.cache file exists on the pool referring to the original > name. > bug report created: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219411