From owner-freebsd-current@freebsd.org Sun Mar 22 10:38:41 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 32DAE27CC2A for ; Sun, 22 Mar 2020 10:38:41 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48lYrw5c8pz4fDC for ; Sun, 22 Mar 2020 10:38:40 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: by mailman.nyi.freebsd.org (Postfix) id C029127CC28; Sun, 22 Mar 2020 10:38:40 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BFBD127CC27; Sun, 22 Mar 2020 10:38:40 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48lYrv47hwz4fD2; Sun, 22 Mar 2020 10:38:39 +0000 (UTC) (envelope-from shoesoft@gmx.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584873512; bh=QOsLiZEr7ni2AQHTuYIuBehImCKwzMH21kWUWn9HP5A=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=aaYyu/5GJsby5TZcvMjXLWk+9Sp1ocYRb/IToG0EkpEIDC/HiP2rGrbpGHkYdkRRM DQXdW/fLZAfmzOpY1Q1xLVj4GJfPQPIlssgpPQXAzLt1Tpxg2Ej7MPRJQ4WgxKc9QI Hml78il4U1nAz1VnxYCCk7AQinSNIL3gFgBqNzn4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from walrus.pepperland ([81.217.71.61]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mj8qj-1jjYC52UXl-00fBSr; Sun, 22 Mar 2020 11:38:32 +0100 From: Stefan Ehmann To: Alexander Leidinger Cc: current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HOWTO donate CPU to the fight against the Corona-virus Date: Sun, 22 Mar 2020 11:38:31 +0100 Message-ID: <1804877.u6MfGjpqfb@walrus.pepperland> In-Reply-To: <20200321120755.Horde.zo0-HJ_AnsKmqqmFSb98-e8@webmail.leidinger.net> References: <20200319085745.Horde.yAf5603LMT07oVm8NR1Abs6@webmail.leidinger.net> <2005523.RhTPgMbj8J@walrus.pepperland> <20200321120755.Horde.zo0-HJ_AnsKmqqmFSb98-e8@webmail.leidinger.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K1:T8iNjEPeBn2CySH4pW7IGcUJnM136s5lkJu6TvzvGPIAvnyGDCU YyFajW3ySWAr58lW+a77VpccAN4b7YrdmX+8NRCi8cHqM1guhyM/mnUq74g+N0LUH3FXqU3 vo4WjWYenL0mfWSRlqcAmkptuQAwaSNw9xsVSfdtz2lwKHEMeka6sI5XVOABUisUKoK+PIa L0r2JWBa/rlGLC8BliagA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DeQFE2hQhDk=:ciGurVwg0UC62+WxC/w7ET Kt2XKhry1syBvYJiG80F0nYq9Yx7/6UBp0/43dVMdXtU/lIRsPdjYibEi1j4rJgin0aH9SS0E T4RHGgVx+gHKjvqRiX67IL+0/+YERxexdXd0GXzbAffZORnnF6O5Xd9XFWiC4CTz1gvdSqP9M KsUOJvYfJP7b2j6SsqZLN2WaLdZNdrriec6ifglVVVafUy7TrNg8ShAYvkUV68bQ+jgJ0ljXn +T548aMzVfzRY47JYKtW1zOxiD0t0jXP9jC4qe4rYSD0ezi9nN7b/SLv1Q36DXcPH2shmg/Mk An2FjlHZMf1V6j1LCTg329mq4kmUqYNurD6223tohSZmkoCFz7/1nIi6D8verGCFyV9RV3fEz zpFSXoKs4pIUxU8+K+PCeDNORzAAj4zKMQQ8BgBdI4idxTI2MyBJjaDW2DIJA6a6UNQqg3a3z 3eiJJ49DTnboaK5HBa0goOdLxsw9FT+8RMimfrF55cHnkk2hohwKGlHsdBWjEJIXkftQOskVw Hhsngx+CMfLuP+If6Mxp0kbIBVawyn2Ku4AYZHF9AoV4vZddweK3GCT5JcdwaXPxGHx/jIU+x 9uQOw3yd63+zgrpLUO2CkXCumUryQX+G9vsd3lcDOJVbX5AJ+CGY0MYuzM4Eo25ukwNK8dNZS bqPoNvSzNfsW+rtYxFQ+1n/V/vXhgU2yyYyccdxM5rRnJricUZzEaIGoE3JANWf0gwUAs1FaO WqM5n5HSH9xXKt5m9LwuKp2U7Al7HHEtZyGRX002Numwsfs+PIE43nPyahDQs3hYucz4fFIgj F7652BV29vpCLnQ1MY4bG5TRVEn828Z3YGgkLFU/Y3af7ATKN6pHc+LFAAuRyIO0Ju12JMGTw 1om4icNgJLIb6O7+czIqfwwEqm6AyC/nStVKSgyJbW/BHn4TuwgtnOSNXxlbd4nJZYaRb2NFv kgufs9kKOGQAGwRpYfYYzkDao+mxlLCzQDxNKqrju0+wG2PQAKSTtwh2Qs8nrSCT28FDQ24ml p+2h02wPi93IJu+2zarTRWWoRr54bfjU0I9GUPBIukB8+e7vyc8LjAqEkIOR3YmBhKbOCcQY5 V0BW6ak3IrhvbX/GH2IGMqiS/E131Kx6kfHNzqGDun0pf8OHLpnmq4rxuGrAsynM9lYmvKPwd uOArIl3hfpsj0H1XCLCOL8Nsuers6BuAceY7CU6QOuz2XtF5cVnfg2/bkxjgFD9vmwtN/Tl3u EMM2B1fTs+Twj/sv1 X-Rspamd-Queue-Id: 48lYrv47hwz4fD2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=aaYyu/5G; dmarc=none; spf=pass (mx1.freebsd.org: domain of shoesoft@gmx.net designates 212.227.17.21 as permitted sender) smtp.mailfrom=shoesoft@gmx.net X-Spamd-Result: default: False [-2.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; FREEMAIL_FROM(0.00)[gmx.net]; DKIM_TRACE(0.00)[gmx.net:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[21.17.227.212.list.dnswl.org : 127.0.3.1]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[61.71.217.81.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_ENVFROM(0.00)[gmx.net]; DWL_DNSWL_NONE(0.00)[gmx.net.dwl.dnswl.org : 127.0.3.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; URIBL_BLOCKED(0.00)[leidinger.net.multi.uribl.com,libopencl.so.multi.uribl.com,fahbench.github.io.multi.uribl.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gmx.net]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-6.65), ipnet: 212.227.0.0/16(-1.12), asn: 8560(2.18), country: DE(-0.02)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 10:38:41 -0000 On Saturday, March 21, 2020 12:07:55 PM CET Alexander Leidinger wrote: > Quoting Stefan Ehmann (from Sat, 21 Mar 2020 > > 11:38:26 +0100): > > On Thursday, March 19, 2020 8:57:45 AM CET Alexander Leidinger via > > freebsd- > > > > stable wrote: > >> Hi, > >> > >> if someone wants to donate some FreeBSD based CPU resources to the > >> fight against the Corona-virus, here is a quick HOWTO in terms of > >> installing the Folding@Home client on FreeBSD: > >> > >> https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-wi= th-f > >> ree bsd-foldinghome/ > > > > Unfortunately, (using a CPU slot for the same work unit) TPF is 2-3 ti= mes > > slower than on Ubuntu for me. Much of the speed difference seems to > > be related > > to libOpenCL. If remove libOpenCL on Ubuntu, it's still 20-30% faster = than > > on FreeBSD. > > The pure CPU based code should be the same. Someone would have to > trace / reverse engineer what is going on. I'm pretty sure now that libOpenCL is only relevant for GPU slots. I couldn't reproduce that the presence of libOpenCL.so has any effect on C= PU slots. Didn't make much sense anyway, something else must have been going = on. So there's probably no point in getting OpenCL to run on FreeBSD until we = have GPU rendering. The numbers displayed by FAHControl are rather strange: * There is no discernible difference in speed if 1 or all CPU cores are us= ed (but top shows that 600% CPU cycles are burned) - happens on both Ubuntu a= nd Linuxolator * According to the progress bar, Ubuntu completes 1% per minute, but Linuxolator only 0.1% (for the same work unit) Don't know if the numbers displayed are bogus or there is really that much= of a difference. Maybe the issue is only related to a specific WU or to AMD-C= PUs. I've also tried https://fahbench.github.io/ but it's mainly targeted at GP= Us and uses a different Core. From owner-freebsd-current@freebsd.org Sun Mar 22 13:46:44 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 38A80261D89 for ; Sun, 22 Mar 2020 13:46:44 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48lf1v6kwZz48D3 for ; Sun, 22 Mar 2020 13:46:43 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1472) id 996C91E8CF; Sun, 22 Mar 2020 13:46:43 +0000 (UTC) To: freebsd-current@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2020Q1 quarterly status reports Message-Id: <20200322134643.996C91E8CF@freefall.freebsd.org> Date: Sun, 22 Mar 2020 13:46:43 +0000 (UTC) From: Lorenzo Salvadore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 13:46:44 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is April 1, 2020, for work done since the last round of Quarterly Reports: January, 2020 - March, 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly@FreeBSD.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q1 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From owner-freebsd-current@freebsd.org Sun Mar 22 14:54:00 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EFDD0263B2A for ; Sun, 22 Mar 2020 14:54:00 +0000 (UTC) (envelope-from iwtcex@gmail.com) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48lgWX0q4tz4RRp for ; Sun, 22 Mar 2020 14:53:59 +0000 (UTC) (envelope-from iwtcex@gmail.com) Received: by mail-ot1-x32e.google.com with SMTP id k26so10854480otr.2 for ; Sun, 22 Mar 2020 07:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lvb0rouf7m7hmP0Ei1nx/axvwIinwGKab2VJMiW+AJ8=; b=JRbF+Nw1PO0V+IBFckvtv8w+Jn16wbx21k8eeOCY47IF8xUMcXZ4seugLiKN78rwSz 0p0oakRABp4e4+7dhwFGLbOk6TTUJpU+PKLzfVVFjsvSXVXqSKmhsQrfoARi1BK2FhBe eUjXsIdBs+5wnYy2ZsJl8tGyuKimqBqBTsyJNRpf2qZ2opm48nrPu66fYiL9A59a+vmx P0K7po/7v/OS+LGL13kQ6kMu/p+8UjROfinLZxjEtXkYJ5f5SavCDN24sQaeB6DK8//7 BOISmDVQZtqV2KOJtJt3ew6D3HVKKcoEkRbIw9UL7WHfxOlJXIFuASx7Ry9xh6aIh6pl rh+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lvb0rouf7m7hmP0Ei1nx/axvwIinwGKab2VJMiW+AJ8=; b=StM3roU57Y0RSdRbwHIYzWgJh4C8U6Ap+n/gbdXuDitVoVHuFxJNyF4gh8icOmRiC2 zFXO1R8KJ2TiRxCIP47ZTNfFIV2L3JDjakLa5LQ9tn3e8HLOo3Oc2A0LnrGqVu+ZatVQ p4Dhc+xn46ZqGX4OHb4zraQYPa1nvmKUOM80u7leyP7qkb6GF7fcxub8sAAScC5tiJta npFOgQ/fuMk2wYoLDuXtW4GYoE2NukjrOhLSCsF814Aw8bmpAZSy/qwsNqTHx7uWLfAy 8YwCiKeFaeGz3zQgmpLIIk6WKGZzzlUHJe2ruzmr5n68b9KqK46cM3IFtZPwHnl+yTN1 ysfQ== X-Gm-Message-State: ANhLgQ3/lwGfhgrGehmuUPXEB2mL08tZJhE92Q6VOmWs/Mxz4ubSOq28 LgR/nSWpKYJwvgT5REwY9Vc9H28QQ0tUUSWRx/Ne+nbI X-Google-Smtp-Source: ADFU+vuJhFElyWKtKTRS18RHSjDb02wnbQipOlPduNsOlasIJlMqVcFxSXAEM7XrXXsgdYy8USOZgXHJ9ibxKvnfgG0= X-Received: by 2002:a9d:1d67:: with SMTP id m94mr14856132otm.140.1584888838553; Sun, 22 Mar 2020 07:53:58 -0700 (PDT) MIME-Version: 1.0 From: Alex S Date: Sun, 22 Mar 2020 17:53:47 +0300 Message-ID: Subject: Re: HOWTO donate CPU to the fight against the Corona-virus To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48lgWX0q4tz4RRp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=JRbF+Nw1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of iwtcex@gmail.com designates 2607:f8b0:4864:20::32e as permitted sender) smtp.mailfrom=iwtcex@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-7.92), ipnet: 2607:f8b0::/32(-0.56), asn: 15169(-0.68), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[e.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 14:54:01 -0000 Alexander Leidinger wrote: > First step would be to get CUDA support in FreeBSD. Ahem, I have a little patch, consisting of several functions copy-pasted from the Linux driver, which is supposed to enable core CUDA functionality: https://github.com/shkhln/nvshim/issues/1#issuecomment-600358438. This won't work for applications depending on unified memory support, but otherwise should be good enough. From owner-freebsd-current@freebsd.org Sun Mar 22 15:49:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A26C12652BA for ; Sun, 22 Mar 2020 15:49:16 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48lhlH5Qr8z4W2g; Sun, 22 Mar 2020 15:49:15 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id t7so8861002wrw.12; Sun, 22 Mar 2020 08:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=chPeeQPmuOe+FnTiClnnW43EAmF1bDE2GBbaEIXrzS0=; b=FKg6c4Bkvssp7Cunk71F4F623bERFwJugmd1NmG4+UN5cXd/PF2iS+vPGeDJDuUOYV kfEtQsYVoJkBzBFWKD+43QERzZzTvjnTsx4AwSbrEqzAm1/IQeMO0wnkJrUFf7SJ+g7c bGbtQsTB3amzYPuFNB68XUzFmpnVbl20sPsyNo6A/08VNI9pBY4MpVw0fmy4eudR/C41 9t8Ik2h6Ypkr7yEvBQ/ZYSft5u+qnXWN3X5FllXrhxFtN67ZIz01wzUzd91T1tkx3Zwc SVWI3nwez7BJY9mCMyZjs00kp1ILO1JkLtBqgbqCpB7zVBDgwN7c9ZQDQ3DY1pGeAqMU TmMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=chPeeQPmuOe+FnTiClnnW43EAmF1bDE2GBbaEIXrzS0=; b=VNoBvyPCECgkjmgXe1vJpi0H6wCQRMQynz9teQcDer/7qlAwPYPWK1z2OS7NffgW9C js6DZjpldNFEnEGAIQMBweY+tafHFVZ8FXQI1StcvvlgnWe2kUwkrGdAlzIsW7MnHiEz SPhhKjrEKws9Yx8JO+OX9wkrLLETMbo63nhYmq2gFcfKWBEftecvHP/XGxaI+DqSFbFy 7Ky+gVE22jRMLDbNiNDwUxsj9owjkxPAIlvEThuiznjg9v2C1PriuldycEY+cVepmcvG ZwX6+nfrQs397bCNjGCOdVbLBDmibklqfRd7ArMcfo0v2kMFcS0vLhDYJTED/YLUF5DQ 8mxw== X-Gm-Message-State: ANhLgQ2lXfcWvOouD3oHNprJPyHvFRJ+o0JSJoGZBarSWvSWYz3hk67Q bXv/tnUd1XE4UOCJKqx2ltFvBwGoatU46A== X-Google-Smtp-Source: ADFU+vvgOIUoh5s/00b8FUTuW2bPAc+XOjVkGx+Ct0rpGTAPPIx+Zy8e2f6ace6jnCrJjeeb/4WluA== X-Received: by 2002:a05:6000:189:: with SMTP id p9mr24257053wrx.391.1584892153011; Sun, 22 Mar 2020 08:49:13 -0700 (PDT) Received: from ?IPv6:2003:c3:4f46:d213:e54:15ff:fe22:27b1? (p200300C34F46D2130E5415FFFE2227B1.dip0.t-ipconnect.de. [2003:c3:4f46:d213:e54:15ff:fe22:27b1]) by smtp.gmail.com with ESMTPSA id m19sm8036374wml.48.2020.03.22.08.49.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Mar 2020 08:49:12 -0700 (PDT) To: Dimitry Andric Cc: Warner Losh , FreeBSD Current , Bryan Drewery References: <6d70f98f-dd49-a5f9-e7bb-86d6853aa20a@gmail.com> <586FD874-A5AB-4C2B-817B-1F7C53809E9E@FreeBSD.org> <0db3dd22-1b7f-0480-1768-46e0e376c3a9@gmail.com> <2B12E7DF-1A72-4BFA-BF39-0EEC63C3D119@FreeBSD.org> From: h v Autocrypt: addr=henry.vogt@gmail.com; prefer-encrypt=mutual; keydata= mQGiBD85EtkRBADHyFu5eTEtFCd10Z25l1ryaWN6bcfyrGuD06OBsaUHIO3kg45NPbEGXcT4 s4klWZFcWmXWVKkSt6sCCqmjZYb0CLYAJ1rhOC8UBT5ULIts+dVIM9vDEujMk49IsugtEqUW CJFE5wNDpAeH0uXSvv6zn3ZeMiYw3C/yUErYEc7yXwCgvW1hhYg3iCHXrw7T3pwl1JVj5uUD /jpxqMRvnSl923wI+u6XW+uBX93isTErwlCmQecSIDX1d9vWY+LVXrHT2GkCeTtZfAM4HHqy 01y+047gaKRG3PLtTxmI5MgFB3U8jpvd8R/XGpVW+jLljnoiVDEu9LZtsSZtiVtNTZLbYlwc ICa56u8vBnmX3mVhBgSsjUVH1FrhA/93/Ht30cSSpTkPwKipw2Ad4ObBi+fQGIpn74As2+7q Yty6BoAec9Xp+02FyA/uCHZL70LPdZLeeipTAeNMhRhWlzxLVGsjSzbkRjG5uQB1yYtJEoi5 UMGKanxfcGu9ReZZ1lLV10w0muhu7k/JQRk0tEJY/71ywpRTITuixhgHsbQgSGVucnkgVm9n dCA8aHZAdHVlYmluZ2VuLm1wZy5kZT6IXAQTEQIAHAQLBwMCAxUCAwMWAgECHgECF4AFAkWL yzACGQEACgkQiF3PvXvQ0FAtSgCeLRcArT2zPk/zLZUyjOq/U7sakFYAn3PCCCbBa03798LN XRhxCjInjTx6uQENBD85EukQBADXBHQcJeBdnmiBCoCpfTVwhf66orSqBHfnrnrS8qDzfo3p Q6YsL225StuNwt9PNouMAA06IXV3IW8DodGL7j4RT2d2wnpsk3giRN7tqs3EYHuV1eCDEvi2 PLh8PMRoXO7NsYRG4bQ14cp5U6g8FI+ASQF8Yv/1fpYn+X5S2v+/iwADBQQApTJUNcKREGXR dTE1FCt96FC7QDaQwBgEIHKdsIvvFIkI5Of6eP3qbkOXehAtf6GStgjADhDeb9xDLj2fMbPe U/zVPuCHe+e3wECQun+6UhSUdxIIql3cdMBieIaa4Y/DcV0drdXr2bOiSTnR/E4GJqxaZEoC 2ocQfZQj4Bkw9CKIRgQYEQIABgUCPzkS6QAKCRCIXc+9e9DQUBftAJ4iJKziUBZwvQp3Q8Do sH8qz/pPugCfSBs4RUrAJURi5fZ0sDAJQgE+8jc= Subject: Re: cannot build 12.1-RELEASE on latest current-snapshot Message-ID: Date: Sun, 22 Mar 2020 16:49:08 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <2B12E7DF-1A72-4BFA-BF39-0EEC63C3D119@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Rspamd-Queue-Id: 48lhlH5Qr8z4W2g X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=FKg6c4Bk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of henryvogt@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=henryvogt@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.06), ipnet: 2a00:1450::/32(-2.39), asn: 15169(-0.67), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; URIBL_BLOCKED(0.00)[opts.mk.multi.uribl.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[e.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 15:49:16 -0000 Hi again, On 21.03.20 21:52, Dimitry Andric wrote: >> ... > It needs a merge of r355588 ("Fix WITHOUT_CLANG build"), actually. For= > some reason, the logic in 12.1-R's version of src.opts.mk does not work= > correctly. I tried setting MK_SYSTEM_COMPILER=3Dno, but even that does= > not work as it should. If you can, I would use 12-STABLE instead. > > -Dimitry I applied r355588 and now and it proceeds further but bails out again shortly thereafter: --- C U T --- =2E.. Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/yp_xdr.o --- pkru.o --- /usr/src/12.1/lib/libc/x86/sys/pkru.c:74: warning: 'ifunc' attribute directive ignored /usr/src/12.1/lib/libc/x86/sys/pkru.c:109: warning: 'ifunc' attribute directive ignored --- getcontextx.o --- /usr/src/12.1/lib/libc/x86/gen/getcontextx.c:64: warning: 'ifunc' attribute directive ignored /usr/src/12.1/lib/libc/x86/gen/getcontextx.c:103: warning: 'ifunc' attribute directive ignored Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/yplib.o --- __vdso_gettc.o --- /usr/src/12.1/lib/libc/x86/sys/__vdso_gettc.c:75: warning: 'ifunc' attribute directive ignored /usr/src/12.1/lib/libc/x86/sys/__vdso_gettc.c:75: warning: 'rdtsc_mb' used but never defined Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/subr_capability.o --- pkru.o --- {standard input}: Assembler messages: {standard input}:39: Error: no such instruction: `rdpkru' {standard input}:60: Error: no such instruction: `wrpkru' {standard input}:171: Error: no such instruction: `rdpkru' *** [pkru.o] Error code 1 make[4]: stopped in /usr/src/12.1/lib/libc =2EERROR_TARGET=3D'pkru.o' =2EERROR_META_FILE=3D'/usr/obj/usr/src/12.1/amd64.amd64/lib/libc/pkru.o.m= eta' --- C U T --- this looks even more serious to me.. are the other patches to apply ? Best Henry From owner-freebsd-current@freebsd.org Sun Mar 22 16:16:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7E5EF265F2C for ; Sun, 22 Mar 2020 16:16:45 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48ljM04Llqz44m2 for ; Sun, 22 Mar 2020 16:16:44 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.nyi.freebsd.org (Postfix) id 76C2A265F28; Sun, 22 Mar 2020 16:16:44 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 76310265F27; Sun, 22 Mar 2020 16:16:44 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48ljLz344Cz44kb; Sun, 22 Mar 2020 16:16:42 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B165AE8.dip0.t-ipconnect.de [91.22.90.232]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 43F9B3802; Sun, 22 Mar 2020 17:16:34 +0100 (CET) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id A142211EF0; Sun, 22 Mar 2020 17:16:01 +0100 (CET) Date: Sun, 22 Mar 2020 17:16:01 +0100 Message-ID: <20200322171601.Horde.Fx_5DgnwuEuLmZX6QHFEz1V@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org, stable@freebsd.org Subject: Re: HOWTO donate CPU to the fight against the Corona-virus In-Reply-To: <20200319085745.Horde.yAf5603LMT07oVm8NR1Abs6@webmail.leidinger.net> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_Sni3cENejq6R6Pc_EHFbyy2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 48ljLz344Cz44kb X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.82 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; URIBL_BLOCKED(0.00)[leidinger.net.multi.uribl.com]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-3.72)[ip: (-9.78), ipnet: 89.238.64.0/18(-4.89), asn: 34240(-3.92), country: DE(-0.02)]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; SIGNED_PGP(-2.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[232.90.22.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 16:16:45 -0000 This message is in MIME format and has been PGP signed. --=_Sni3cENejq6R6Pc_EHFbyy2 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Alexander Leidinger via freebsd-stable=20=20 =20(from Thu, 19 Mar 2020 08:57:45 +0100): > Hi, > > if someone wants to donate some FreeBSD based CPU resources to the=20=20 >=20fight against the Corona-virus, here is a quick HOWTO in terms of=20=20 >=20installing the Folding@Home client on FreeBSD: > > https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-f= reebsd-foldinghome/ This is now available as a port: biology/linux-foldingathome (thanks 0mp@). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_Sni3cENejq6R6Pc_EHFbyy2 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJed49BAAoJEBINsJsD+NiGRNUQAISAU+C8821CbiUb6GTgyntO KC9ouTAJKk5yXkT1iDF1NK/Tvvajdl9cTXIbfnFj8NwABYAZjt3qvwxLR2SOzSBW 15aiDwIjTvJb3z1eElSSqPoWLaqZxnkTgQ7MxjRqzGzAvqYNmM8nA7kSYSCxeteD uf5QGB2oiWRjdpCxwqAkXZuZwF4x+1PzRMDjsyRDsVrgatbBeja2W4/X1K+kEz0l 19or8Nq9vmnM3BCcz4MYR78mlYq0rlQSCYWzXdiwpqPsxU/ExXiu8B3YD2n20pps 3oCet8y6zR1sEPMXWdAK8OFUSozooL0KwYtyCgLB3G8IB/OTGoae+voI6oRi5MSI V4xcccx088vz4ahjvYfVessFc6KtmuKCOY5T5SY8Nz6Na8rUmgu5oVanonP7aehA mNgKiWTFXFLmnJbASlKpaDzwuMPy8S9fyYBE86E5FmGUtbGokZUEr1AkdxF9VuFJ HBXa1CnWsoeYD7Nq5rquGPCVTS7psgwstgborEbfx9f2+Yz8+pH4MYqlBkVD0zOL 0C40cgIy/suO0A8qQQkNF4wX33K2CjCQBZBCuZi5/iuS8rYa2wAipgydLnepC8HJ qyn96QqC9Sfnfohz6vKpS62oQvOcPanPeIlYY8aVQt1Fosh9ScKccn5lFEV3ClTK xpsIrzQ9rnKgC4wQn7kt =TLns -----END PGP SIGNATURE----- --=_Sni3cENejq6R6Pc_EHFbyy2-- From owner-freebsd-current@freebsd.org Sun Mar 22 16:18:59 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A189B2661EF; Sun, 22 Mar 2020 16:18:59 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48ljPZ5K97z47LZ; Sun, 22 Mar 2020 16:18:58 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 4B27A5E8B; Sun, 22 Mar 2020 16:18:58 +0000 (UTC) Date: Sun, 22 Mar 2020 16:18:58 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-03-15 Message-ID: <20200322161858.GA90037@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 16:18:59 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-03-15 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-03-09 to 2020-03-15. During this period, we have: * 1903 builds (90.1% (+41.9) passed, 9.9% (-41.9) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 293 test runs (75.1% (-12.4) passed, 17.1% (+12.9) unstable, 7.8% (-0.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 34 doc and www builds (88.2% (+5.4) passed, 11.8 (-5.4) failed) Test case status (on 2020-03-15 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | ---------- | --------- | ----- | -------- | | head/amd64 | 7721 (+12) | 7624 (+7) | 0 (0) | 97 (+5) | | head/i386 | 7719 (+12) | 7613 (+4) | 0 (0) | 106 (+8) | | 12-STABLE/amd64 | 7506 (+5) | 7453 (+1) | 0 (0) | 53 (+4) | | 12-STABLE/i386 | 7504 (+5) | 7443 (+1) | 0 (0) | 61 (+4) | | 11-STABLE/amd64 | 6880 (+2) | 6833 (+2) | 0 (0) | 47 (0) | | 11-STABLE/i386 | 6878 (+2) | 6826 (+2) | 0 (0) | 52 (0) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200315 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-mips64-build This job is using devel/gcc6@mips64 port (mips64-gcc6 pacakge) ``` ===> include/rpcsvc (includes) RPCGEN_CPP=/usr/local/bin/mips64-unknown-freebsd12.0-cpp6\ --sysroot=/usr/home/lwhsu/freebsd-obj-gcc6/usr/home/lwhsu/freebsd-src/mips.mips64/tmp\ -B/usr/local/mips64-unknown-freebsd12.0/bin/ rpcgen -C -h -DWANT_NFS3 /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x -o mount.h /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x:1:0: error: '-march=mips1' is not compatible with the selected ABI /*- *** [mount.h] Error code 1 make[4]: stopped in /usr/home/lwhsu/freebsd-src/include/rpcsvc 1 error ``` * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` --- all_subdir_usr.bin/clang/lldb --- /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandler.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' collect2: error: ld returned 1 exit status ``` * https://ci.freebsd.org/job/FreeBSD-head-amd64-test Usually panics when executing sys.netpfil.pf.nat.exhaust For more details: https://bugs.freebsd.org/244703 ## Regressions * 3 tests start failing after llvm10 import * lib.libproc.proc_test.symbol_lookup * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (-5), 579 failures (+5), 806 skipped (0) ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/242689 * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * skip sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/244053 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.geom.class.multipath.misc.fail_on_error (12-STABLE) https://bugs.freebsd.org/244158 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.geom.class.gate.ggate_test.ggated https://bugs.freebsd.org/244737 ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Mon Mar 23 00:56:11 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D1B1F27302A; Mon, 23 Mar 2020 00:56:11 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48lwtM0xbsz44P4; Mon, 23 Mar 2020 00:56:10 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-wr1-x444.google.com with SMTP id p10so2540489wrt.6; Sun, 22 Mar 2020 17:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mx60zlOly3RycrQwigv7uqntUd6EbC/Vc0Wbag9SYpg=; b=CqmLOJybybbnWaNVS0zcPnVmTNF5j7RrxB8Zq/Nqjh5m/50q5ZU2xhuP12zvmg0wzd 7aDHjiONQa0IpMfss5W7AxlitRFc/jyxCkesHjD5GC2BJJyZNIfLkMx6+cLfrqr3beVB 4qAKDtBIbDrEzqm0N2gFWYtfpA/x5n4supM/hTB2x0h59SiUjb8LhQgYAXFOmi9LsQR6 2TB4Ss+cVogxqLhThbyfGSkFas5Os91ZYabRm1wywluf1y9nwoVktxsfJxzxyy9ZYrRY T0mgbRP0QoaJEsDCzc12wmTh2zlWOTFdcHG0xR/QnYDwrXW4TfLyWdq+6NEwJwgV7nTx InJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mx60zlOly3RycrQwigv7uqntUd6EbC/Vc0Wbag9SYpg=; b=FVZ5LdPJvnFU6b7ipLFmuhCHQBFWDDP3OX2MM3XpB782XthQCnZKMq1zYctfjR59Ns grFT9pyK2q7a3lfUJg/w589nEXsSY8v22Ahxbj/AZbk499+FCujBxYlURjfjpKXTjLTj ujFYRogZWVw+jl7d792oZdhYBuo8JYkmnKmq6nbx0iY2d9x7AtgZhEhh5wHPfwNJdehd b5wB3d25+9ra6EWvtm7B+tMO4X8Qeags14dkjWEiKHB7bpNPxLjqqN731JEBzdQbq4A8 fTmCg+M9eN374iFfWb5JieYHy8Rfx9HFTfPZYE5hjqEnx/Wm5yDV5VpBFhuee+K67rKa Ii3g== X-Gm-Message-State: ANhLgQ3JLcy5ZgI0wL/rZWsec0US+1W6TDVTK33eltwvC2rWdUaBw4Xk szw88tCTD1PGjWKDe1lAIzVMBfim9P4CTPmWD+M= X-Google-Smtp-Source: ADFU+vt5kPVl9u6OaruYN5d7hOA2DcV1zqQBcLNC7mShCONQNT/h+zeGlqvaX2xIkqy+h/7Q3WK/zJi4j5FZffncQbg= X-Received: by 2002:adf:b35d:: with SMTP id k29mr26677218wrd.239.1584924969531; Sun, 22 Mar 2020 17:56:09 -0700 (PDT) MIME-Version: 1.0 References: <49B58A7F-0DE2-4BEB-8A8C-D996962FDDE1@me.com> <8C721EA7-09EA-4154-AC29-273B3A881FA4@me.com> In-Reply-To: <8C721EA7-09EA-4154-AC29-273B3A881FA4@me.com> From: Andrey Fesenko Date: Mon, 23 Mar 2020 03:55:58 +0300 Message-ID: Subject: Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H To: Toomas Soome Cc: freebsd-current , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48lwtM0xbsz44P4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=CqmLOJyb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of f0andrey@gmail.com designates 2a00:1450:4864:20::444 as permitted sender) smtp.mailfrom=f0andrey@gmail.com X-Spamd-Result: default: False [-1.99 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.85), ipnet: 2a00:1450::/32(-2.39), asn: 15169(-0.62), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(0.00)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; URIBL_PBL(0.01)[bsdnir.info]; RCVD_IN_DNSWL_NONE(0.00)[4.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 00:56:11 -0000 On Thu, Nov 28, 2019 at 11:31 PM Toomas Soome wrote: > > > On 28. Nov 2019, at 22:20, Andrey Fesenko wrote: > > > > Fixed > > > > Thanks. And yea, that one is nasty. I have some guess but nothing too sol= id=E2=80=A6 it may take time to get figured out. > > Have you tested BIOS boot? > > rgds, > toomas > > > On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome wrote: > >> > >> > >> > >> On 28. Nov 2019, at 22:16, Andrey Fesenko wrote: > >> > >> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome wrote: > >> > >> > >> hi! > >> > >> I did try to reach you, but mail did bounce back=E2=80=A6 > >> > >> unicast ping me:) > >> > >> rgds, > >> toomas > >> > >> On 28. Nov 2019, at 11:43, Andrey Fesenko wrote: > >> > >> Hello, > >> > >> Around starting 20191114 r354699 (memstick tested), my desktop not > >> boot normally. Boot only loader menu (black and white mode) after > >> start i'm see load modules, after this monitor gray, and 15-20s > >> disabled, system block not disable but run silently. system not boot. > >> > >> If i'm change efi (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1 > >> release, system boot normally > >> > >> > >> > >> This video boot second version (Name: "loader.efi") 545 KB > >> https://bsdnir.info/files/efi_fail.mp4 > >> > >> > >> 403 Forbidden > >> > >> :=3D) > >> > >> rgds, > >> toomas > New news ;) r359151 i'm make memstick with custom refind /mnt/ `-- EFI |-- BOOT | |-- bootx64.efi - refind |-- freebsd | `-- loader.efi - freebsd not boot |-- freebsd_lua | `-- loader_lua.efi - not boot |-- freebsd_simple | `-- loader_simp.efi - boot fine From owner-freebsd-current@freebsd.org Mon Mar 23 00:58:05 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E6742736EE for ; Mon, 23 Mar 2020 00:58:05 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48lwwY0yz3z456N; Mon, 23 Mar 2020 00:58:05 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id EED7E17629; Mon, 23 Mar 2020 00:58:04 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.183.1] (unknown [210.160.37.27]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id D6C44B27F; Mon, 23 Mar 2020 01:58:01 +0100 (CET) From: "Kristof Provost" To: FreeBSD-Current Cc: status-updates@freebsdfoundation.org Subject: Bridge project update (Week of March 16th) Date: Mon, 23 Mar 2020 09:57:58 +0900 X-Mailer: MailMate (1.13.1r5671) Message-ID: <5026C2BD-17E3-4705-872D-0E177B1503A5@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 00:58:05 -0000 Hi, A quick status update this week. I’ve been preoccupied with the AsiaBSDcon replacement hackathon (Thanks for organising hrs@!) and repeated changes to my travel plans. I did get the chance to discuss my ideas with manu@, which was very helpful. I believe I have a good idea of how to approach the epoch-ification now, and hope to have a functional prototype in a few weeks. Best regards, Kristof Provost From owner-freebsd-current@freebsd.org Mon Mar 23 07:28:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F7B927B109 for ; Mon, 23 Mar 2020 07:28:01 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48m5ZS4CqPz4S0Z for ; Mon, 23 Mar 2020 07:28:00 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.nyi.freebsd.org (Postfix) id 78F3A27B107; Mon, 23 Mar 2020 07:28:00 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7856227B106; Mon, 23 Mar 2020 07:28:00 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48m5ZQ49Mvz4Rxb; Mon, 23 Mar 2020 07:27:58 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B165AE9.dip0.t-ipconnect.de [91.22.90.233]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 8D1762D3; Mon, 23 Mar 2020 08:27:49 +0100 (CET) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id F1EB212039; Mon, 23 Mar 2020 08:27:16 +0100 (CET) Date: Mon, 23 Mar 2020 08:27:16 +0100 Message-ID: <20200323082716.Horde.O3tWVqsmILTLzk_8GG4EItj@webmail.leidinger.net> From: Alexander Leidinger To: tech-lists , freebsd-stable@freebsd.org, current@freebsd.org Subject: Re: HOWTO donate CPU to the fight against the Corona-virus References: <20200319085745.Horde.yAf5603LMT07oVm8NR1Abs6@webmail.leidinger.net> <20200323013552.GA59811@bastion.zyxst.net> <20200323080524.Horde.zxTyevL5WTbZ-dE7Ni4F9jM@webmail.leidinger.net> In-Reply-To: <20200323080524.Horde.zxTyevL5WTbZ-dE7Ni4F9jM@webmail.leidinger.net> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_j69uadtGDMo1FllNdZyx9TQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 48m5ZQ49Mvz4Rxb X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.83 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-3.74)[ip: (-9.83), ipnet: 2a00:1828::/32(-4.91), asn: 34240(-3.92), country: DE(-0.02)]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[233.90.22.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 07:28:01 -0000 This message is in MIME format and has been PGP signed. --=_j69uadtGDMo1FllNdZyx9TQ Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Alexander Leidinger via freebsd-stable=20=20 =20(from Mon, 23 Mar 2020 08:05:24 +0100): > Quoting tech-lists (from Mon, 23 Mar 2020=20=20 >=2001:35:52 +0000): > >> Is it possible to use this with a cuda-compatible nvidia card and if so = how >> would one go about it? > > First step would be to convince NVidia to provide a driver package=20=20 >=20for FreeBSD with CUDA support. Hmmm... seems we could help NVidia... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224358 - see specially comment #6 + #7 + #13 - implement nvidia-uvm Anyone? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_j69uadtGDMo1FllNdZyx9TQ Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJeeGTUAAoJEBINsJsD+NiGPEkP/1C4kGKYPF3ENFVGRqz73xoU URSfeKbRSnnWXPwNzTXmQb3kuWi8TA0J61QAI6pw9KD50s5ZecdpUGobNIlwHTJS 5kG7CLLljN+hSPt6j3Eb9DzhRQwLjJ0wxX/ZC0vArZcpTwpoqoIFU6IFaAn/k4zs YQuCgCHzzM83dl52YxwT0qyquEquNMxkteMR3gyO4chUk/4Ard5m7XwmbHkzbnst XmkfH1PhzJHZoZp5uUQDIB78iqJe/33eFcke0iVr+inovmciUUEHJ6aNpRmIaiQ/ BcGdBObVpPtFRjvNzwlI2S32bsU0vlKumuD1AC7EvNt2ohfy23WFzfDecI9k3uF4 STiPU1qd8zjfHf5RXDq6/Q7DJ4T/UX22GeiDtrrvZLexbIP3CZ5r3FRa3D52DK2C NPxFhy6gNB9+mfjbIB9HTqUqGxVWwP0hvAyR56VqpVREP5MtsVx7NJt0n8x6mf2a DJFCZxPd4drj4kLucgr2Vuy7sUyhdmJNdd/uY0VOyEw1yF8JInhSn7Dcn1yzskNG +a+0A7j3YA/rSacPNQat5olXMW8j2k2/wMHliYV5wxckMkU0ETsOlQJ5KQSVYYDd XYe0uAiEdCWV96QAikj4RgpeDhmOHxifVId5P073HoU05EUd6KrnICOnBIfkuu5f jzw+9H5HcKWw6i+uUBrH =iP/3 -----END PGP SIGNATURE----- --=_j69uadtGDMo1FllNdZyx9TQ-- From owner-freebsd-current@freebsd.org Mon Mar 23 07:38:40 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B6E3927B601; Mon, 23 Mar 2020 07:38:40 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48m5pm0Cysz4clj; Mon, 23 Mar 2020 07:38:39 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B165AE9.dip0.t-ipconnect.de [91.22.90.233]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id E49AA495; Mon, 23 Mar 2020 08:38:37 +0100 (CET) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 62249119F1; Mon, 23 Mar 2020 08:38:05 +0100 (CET) Date: Mon, 23 Mar 2020 08:38:05 +0100 Message-ID: <20200323083805.Horde.-utvvtraTJPgMTBFRuQ4mTx@webmail.leidinger.net> From: Alexander Leidinger To: Alex S Cc: freebsd-current@freebsd.org, stable@freebsd.org Subject: Re: HOWTO donate CPU to the fight against the Corona-virus In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=__8JNZbqUeL09zhwLtQ7TdyX"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 48m5pm0Cysz4clj X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.82 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-3.73)[ip: (-9.79), ipnet: 89.238.64.0/18(-4.90), asn: 34240(-3.92), country: DE(-0.02)]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[233.90.22.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 07:38:40 -0000 This message is in MIME format and has been PGP signed. --=__8JNZbqUeL09zhwLtQ7TdyX Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Alex S (from Sun, 22 Mar 2020 17:53:47 +0300): > Alexander Leidinger wrote: >> First step would be to get CUDA support in FreeBSD. > > Ahem, I have a little patch, consisting of several functions > copy-pasted from the Linux driver, which is supposed to enable core > CUDA functionality: > https://github.com/shkhln/nvshim/issues/1#issuecomment-600358438. This > won't work for applications depending on unified memory support, but > otherwise should be good enough. Could you plesae describe a little bit more detailed what your shim=20=20 does?=20I have the impression it maps some linux glibc symbols which are=20= =20 used=20in a NVidia library for CUDA which only exists as a linux lib to=20= =20 FreeBSD=20symbols and when some FreeBSD binary then tries to load the=20=20 NVidia=20CUDA lib it is then using the FreeBSD libc/m/pthread. If this is correct, what would be in your opinion the correct way to=20=20 get=20official CUDA support? Something like the following or is more=20=20 needed? =20 - implement nvida-uvm - implement os_lock_user_pages - submit the above to NVidia and ask for the CUDA lob to be compiled=20= =20 for=20FreeBSD Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=__8JNZbqUeL09zhwLtQ7TdyX Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJeeGddAAoJEBINsJsD+NiGt1sP/2QEtWyz5Bk6gCEaqzc5TcFu tZHxwY3b6uau1/PgtRF0ZOxfAHE7rvyRSzQJwFKPHWMS+A+qKvN2JDUaIKUKgH8M nhPVsPX0MBtn3xPNsdqNOg1e+jVf+Eg688LrPy+1/8i5pfhpVQtM/5rEYOJIYTOt ikLXd8Oyl4FkY41Eju89lKOmFVTFgFU02s/YQW2oG96Y3zVCMg0TgQWYK7H3uZLy aCImuyj/XniKtGRmUqqB8e5Ico/8ZNiNTNOPCvBuqiF+iFBvuEJ6XnU449muZuJc sBuoAWZzeGBXi21cuQAQOWcwxLYPuqL5KrHlJvpD4OA4/WGf404zgzbcwGqrcbZ8 zmutGTm1OZ4f9+DUf6wDJDzWpblw8cNKEXq1t7CtujZeYTz5j7q9XKJQs6DxkMou KWEwMsaC8+oPaAlYUgp30igNPiJP8zlNl/33qXOC6K9WOJGSXdTZdlpmRYXE9Cg7 s2HpK+W/On/lODfhpBKXknGYqUvbt2JaiOPxEGRGup9DUREGB7rJC+9MzVZ4d2zJ XKvCX+rpATDkhdUKsEDOvvghkSDPvZBwOaho/8KUho84i/h67lRh/y/9EH6pbYnU 83F2EeL6F47BiCvK97/0Q2ajTsHD+tgm+ouvRy8Zb4Zb+2UAv1+7q7U5bxdhvgaL 2mwkKM1TwZDOzDvQqGTn =qSTG -----END PGP SIGNATURE----- --=__8JNZbqUeL09zhwLtQ7TdyX-- From owner-freebsd-current@freebsd.org Mon Mar 23 20:19:24 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 867DF26D88E for ; Mon, 23 Mar 2020 20:19:24 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48mQhW3Cw2z4PTy for ; Mon, 23 Mar 2020 20:19:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by mailman.nyi.freebsd.org (Postfix) id 320C026D88C; Mon, 23 Mar 2020 20:19:23 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3178326D88B for ; Mon, 23 Mar 2020 20:19:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 48mQhT1KyJz4PR1; Mon, 23 Mar 2020 20:19:20 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id E967C3C0199; Mon, 23 Mar 2020 20:19:18 +0000 (UTC) Date: Mon, 23 Mar 2020 20:19:18 +0000 From: Brooks Davis To: jenkins-admin@FreeBSD.org, current@freebsd.org Cc: emaste@FreeBSD.org, trasz@FreeBSD.org, arichardson@FreeBSD.org Subject: Re: FreeBSD-head-powerpc-build - Build #15561 (r359260) - Failure Message-ID: <20200323201918.GH5399@spindle.one-eyed-alien.net> References: <1246261832.627.1584993476869.JavaMail.jenkins@jenkins.ci.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nHwqXXcoX0o6fKCv" Content-Disposition: inline In-Reply-To: <1246261832.627.1584993476869.JavaMail.jenkins@jenkins.ci.freebsd.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 48mQhT1KyJz4PR1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-6.52 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; IP_SCORE(-3.63)[ip: (-9.52), ipnet: 199.48.128.0/22(-4.75), asn: 36236(-3.82), country: US(-0.05)]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 20:19:24 -0000 --nHwqXXcoX0o6fKCv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm looking into this build error. I believe it's caused by under-specified LIBADD entries (and the corresponding __DP entries) and differing bfd vs lld behavior. Once I've got a failing powerpc build (in progress) I should be able to fix this pretty quickly. -- Brooks On Mon, Mar 23, 2020 at 07:57:50PM +0000, jenkins-admin@FreeBSD.org wrote: > FreeBSD-head-powerpc-build - Build #15561 (r359260) - Failure >=20 > Build information: https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/= 15561/ > Full change log: https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/15= 561/changes > Full build log: https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/155= 61/console >=20 > Status explanation: > "Failure" - the build is suspected being broken by the following changes > "Still Failing" - the build has not been fixed by the following changes a= nd > this is a notification to note that these changes have > not been fully tested by the CI system >=20 > Change summaries: > (Those commits are likely but not certainly responsible) >=20 > 359260 by brooks: > Import the kyua test framework. >=20 > Having kyua in the base system will simplify automated testing in CI and > eliminates bootstrapping issues on new platforms. >=20 > The build of kyua is controlled by WITH(OUT)_TESTS_SUPPORT. >=20 > Reviewed by: emaste > Obtained from: CheriBSD > Sponsored by: DARPA > Differential Revision: https://reviews.freebsd.org/D24103 >=20 > 359255 by brooks: > Add liblutok a lightweight C++ API for lua. >=20 > It is added an INTERNALLIB and not installed. It will be used by kyua. >=20 > This is a preparatory commit for D24103. >=20 > Reviewed by: emaste > Obtained from: CheriBSD > Sponsored by: DARPA >=20 > 359254 by emaste: > arch.7: remove Default Tool Chain footnote about xtoolchain >=20 > MIPS was the last arch to use external toolchain by default but uses > in-tree Clang and lld as of r359233, and now no table entries reference > the footnote. >=20 > 359253 by emaste: > arch.7: update Default Tool Chain intro text >=20 > All FreeBSD archs now use an in-tree toolchain - Clang and ELF Tool > Chain everywhere, and lld everywhere but 32-bit PowerPC (which still > uses ld.bfd). No archs use external toolchain by default. >=20 > Sponsored by: The FreeBSD Foundation >=20 > 359252 by arichardson: > Fix newvers.sh on macOS 10.15 >=20 > It appears that the macOS /bin/sh echo now defaults to -e and therefore t= he > `#define VERSTR` included newline characters instead of \n. This caused c= ompiler > errors due to unterminated strings. Fix by using printf instead of echo. > A less fragile solution might be to bootstrap the in-tree /bin/sh but that > requires more changes. >=20 > Reviewed By: brooks > Differential Revision: https://reviews.freebsd.org/D24136 >=20 > 359251 by arichardson: > Update arch.7 .Dd for r359233 >=20 > Suggested by: lwhsu >=20 > 359248 by trasz: > Add STANDARDS and HISTORY to getcontext(3), makecontext(3), and ucontext(= 3). >=20 > Obtained from: NetBSD > MFC after: 2 weeks > Sponsored by: DARPA >=20 >=20 >=20 > The end of the build log: >=20 > [...truncated 28.68 MB...] > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(require= ments.o): In function `(anonymous namespace)::check_required_user(std::__1:= :basic_string, std::__1::allocator = > const&, utils::config::tree const&)': > requirements.cpp:(.text+0xcf0): undefined reference to `utils::passwd::cu= rrent_user()' > requirements.cpp:(.text+0xd14): undefined reference to `utils::passwd::us= er::is_root() const' > requirements.cpp:(.text+0xd84): undefined reference to `utils::passwd::us= er::is_root() const' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(require= ments.o): In function `(anonymous namespace)::check_required_memory(utils::= units::bytes const&)': > requirements.cpp:(.text+0x146c): undefined reference to `utils::physical_= memory()' > /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: Dwarf Error: found dwarf= version '4', this reader only handles version 2 information. > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.= o): In function `engine::user_node::push_lua(lutok::state&) const': > config.cpp:(.text+0x150): undefined reference to `lutok::state::push_stri= ng(std::__1::basic_string, std::__1::allo= cator > const&)' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.= o): In function `engine::user_node::set_lua(lutok::state&, int)': > config.cpp:(.text+0x1ac): undefined reference to `lutok::state::is_number= (int)' > config.cpp:(.text+0x1c4): undefined reference to `lutok::state::to_intege= r(int)' > config.cpp:(.text+0x1e0): undefined reference to `utils::passwd::find_use= r_by_uid(unsigned int)' > config.cpp:(.text+0x21c): undefined reference to `lutok::state::is_string= (int)' > config.cpp:(.text+0x24c): undefined reference to `lutok::state::to_string= (int)' > config.cpp:(.text+0x258): undefined reference to `utils::passwd::find_use= r_by_name(std::__1::basic_string, std::__= 1::allocator > const&)' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.= o): In function `engine::user_node::set_string(std::__1::basic_string, std::__1::allocator > const&)': > config.cpp:(.text+0x3e0): undefined reference to `utils::passwd::find_use= r_by_name(std::__1::basic_string, std::__= 1::allocator > const&)' > config.cpp:(.text+0x5b0): undefined reference to `utils::passwd::find_use= r_by_uid(unsigned int)' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.= o): In function `engine::load_config(utils::fs::path const&)': > config.cpp:(.text+0xcc8): undefined reference to `utils::config::parser::= parse(utils::fs::path const&)' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.= o): In function `(anonymous namespace)::config_parser::config_parser(utils:= :config::tree&)': > config.cpp:(.text+0xe84): undefined reference to `utils::config::parser::= parser(utils::config::tree&)' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.= o): In function `(anonymous namespace)::config_parser::~config_parser()': > config.cpp:(.text+0xecc): undefined reference to `utils::config::parser::= ~parser()' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(config.= o):(.data.rel.ro+0x58): undefined reference to `typeinfo for utils::config:= :parser' > /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: Dwarf Error: found dwarf= version '4', this reader only handles version 2 information. > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(atf_res= ult.o): In function `engine::atf_result::apply(utils::optional const&) const': > atf_result.cpp:(.text+0x1b60): undefined reference to `utils::process::st= atus::exited() const' > atf_result.cpp:(.text+0x1ba8): undefined reference to `utils::process::st= atus::exitstatus() const' > atf_result.cpp:(.text+0x1c2c): undefined reference to `utils::process::st= atus::exitstatus() const' > atf_result.cpp:(.text+0x1da0): undefined reference to `utils::process::st= atus::exited() const' > atf_result.cpp:(.text+0x1db8): undefined reference to `utils::process::st= atus::exitstatus() const' > atf_result.cpp:(.text+0x1e70): undefined reference to `utils::process::st= atus::signaled() const' > atf_result.cpp:(.text+0x1eb8): undefined reference to `utils::process::st= atus::termsig() const' > atf_result.cpp:(.text+0x1f3c): undefined reference to `utils::process::st= atus::termsig() const' > atf_result.cpp:(.text+0x2140): undefined reference to `utils::process::st= atus::exited() const' > atf_result.cpp:(.text+0x2158): undefined reference to `utils::process::st= atus::exitstatus() const' > atf_result.cpp:(.text+0x2210): undefined reference to `utils::process::st= atus::exited() const' > atf_result.cpp:(.text+0x2228): undefined reference to `utils::process::st= atus::exitstatus() const' > atf_result.cpp:(.text+0x22e0): undefined reference to `utils::process::st= atus::exited() const' > atf_result.cpp:(.text+0x22f8): undefined reference to `utils::process::st= atus::exitstatus() const' > /usr/obj/usr/src/powerpc.powerpc/lib/kyua/engine/libkyua_engine.a(atf_res= ult.o): In function `(anonymous namespace)::format_status(utils::process::s= tatus const&)': > atf_result.cpp:(.text+0x245c): undefined reference to `utils::process::st= atus::exited() const' > atf_result.cpp:(.text+0x2494): undefined reference to `utils::process::st= atus::exitstatus() const' > atf_result.cpp:(.text+0x2540): undefined reference to `utils::process::st= atus::signaled() const' > atf_result.cpp:(.text+0x2578): undefined reference to `utils::process::st= atus::termsig() const' > atf_result.cpp:(.text+0x25a4): undefined reference to `utils::process::st= atus::coredump() const' > c++: error: linker command failed with exit code 1 (use -v to see invocat= ion) > *** [kyua.full] Error code 1 >=20 > make[4]: stopped in /usr/src/usr.bin/kyua > 1 error >=20 > make[4]: stopped in /usr/src/usr.bin/kyua > *** [all_subdir_usr.bin/kyua] Error code 2 >=20 > make[3]: stopped in /usr/src/usr.bin > --- all_subdir_usr.bin/ofed --- > A failure has been detected in another branch of the parallel make >=20 > make[6]: stopped in /usr/src/usr.bin/ofed/libibverbs/ud_pingpong > *** [all_subdir_usr.bin/ofed/libibverbs/ud_pingpong] Error code 2 >=20 > make[5]: stopped in /usr/src/usr.bin/ofed/libibverbs > 1 error >=20 > make[5]: stopped in /usr/src/usr.bin/ofed/libibverbs > *** [all_subdir_usr.bin/ofed/libibverbs] Error code 2 >=20 > make[4]: stopped in /usr/src/usr.bin/ofed > 1 error >=20 > make[4]: stopped in /usr/src/usr.bin/ofed > *** [all_subdir_usr.bin/ofed] Error code 2 >=20 > make[3]: stopped in /usr/src/usr.bin > --- all_subdir_usr.sbin --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /usr/src/usr.sbin/iscsid > *** [all_subdir_usr.sbin/iscsid] Error code 2 >=20 > make[3]: stopped in /usr/src/usr.sbin > --- all_subdir_usr.sbin/jail --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /usr/src/usr.sbin/jail > *** [all_subdir_usr.sbin/jail] Error code 2 >=20 > make[3]: stopped in /usr/src/usr.sbin > 2 errors >=20 > make[3]: stopped in /usr/src/usr.sbin > *** [all_subdir_usr.sbin] Error code 2 >=20 > make[2]: stopped in /usr/src > --- all_subdir_secure --- > A failure has been detected in another branch of the parallel make >=20 > make[5]: stopped in /usr/src/secure/usr.bin/openssl > *** [all_subdir_secure/usr.bin/openssl] Error code 2 >=20 > make[4]: stopped in /usr/src/secure/usr.bin > 1 error >=20 > make[4]: stopped in /usr/src/secure/usr.bin > *** [all_subdir_secure/usr.bin] Error code 2 >=20 > make[3]: stopped in /usr/src/secure > 1 error >=20 > make[3]: stopped in /usr/src/secure > *** [all_subdir_secure] Error code 2 >=20 > make[2]: stopped in /usr/src > --- all_subdir_kerberos5 --- > A failure has been detected in another branch of the parallel make >=20 > make[5]: stopped in /usr/src/kerberos5/usr.bin/kpasswd > *** [all_subdir_kerberos5/usr.bin/kpasswd] Error code 2 >=20 > make[4]: stopped in /usr/src/kerberos5/usr.bin > 1 error >=20 > make[4]: stopped in /usr/src/kerberos5/usr.bin > *** [all_subdir_kerberos5/usr.bin] Error code 2 >=20 > make[3]: stopped in /usr/src/kerberos5 > 1 error >=20 > make[3]: stopped in /usr/src/kerberos5 > *** [all_subdir_kerberos5] Error code 2 >=20 > make[2]: stopped in /usr/src > --- all_subdir_usr.bin --- > --- all_subdir_usr.bin/svn --- > A failure has been detected in another branch of the parallel make >=20 > make[6]: stopped in /usr/src/usr.bin/svn/lib/libapr > *** [all_subdir_usr.bin/svn/lib/libapr] Error code 2 >=20 > make[5]: stopped in /usr/src/usr.bin/svn/lib > 1 error >=20 > make[5]: stopped in /usr/src/usr.bin/svn/lib > *** [all_subdir_usr.bin/svn/lib] Error code 2 >=20 > make[4]: stopped in /usr/src/usr.bin/svn > 1 error >=20 > make[4]: stopped in /usr/src/usr.bin/svn > *** [all_subdir_usr.bin/svn] Error code 2 >=20 > make[3]: stopped in /usr/src/usr.bin > --- all_subdir_usr.bin/vi --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /usr/src/usr.bin/vi > *** [all_subdir_usr.bin/vi] Error code 2 >=20 > make[3]: stopped in /usr/src/usr.bin > --- all_subdir_tests --- > A failure has been detected in another branch of the parallel make >=20 > make[6]: stopped in /usr/src/tests/sys/fs/fusefs > *** [all_subdir_tests/sys/fs/fusefs] Error code 2 >=20 > make[5]: stopped in /usr/src/tests/sys/fs > 1 error >=20 > make[5]: stopped in /usr/src/tests/sys/fs > *** [all_subdir_tests/sys/fs] Error code 2 >=20 > make[4]: stopped in /usr/src/tests/sys > 1 error >=20 > make[4]: stopped in /usr/src/tests/sys > *** [all_subdir_tests/sys] Error code 2 >=20 > make[3]: stopped in /usr/src/tests > 1 error >=20 > make[3]: stopped in /usr/src/tests > *** [all_subdir_tests] Error code 2 >=20 > make[2]: stopped in /usr/src > --- all_subdir_lib --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /usr/src/lib/libc > *** [all_subdir_lib/libc] Error code 2 >=20 > make[3]: stopped in /usr/src/lib > 1 error >=20 > make[3]: stopped in /usr/src/lib > *** [all_subdir_lib] Error code 2 >=20 > make[2]: stopped in /usr/src > --- all_subdir_usr.bin --- > --- all_subdir_usr.bin/clang --- > A failure has been detected in another branch of the parallel make >=20 > make[5]: stopped in /usr/src/usr.bin/clang/clang > *** [all_subdir_usr.bin/clang/clang] Error code 2 >=20 > make[4]: stopped in /usr/src/usr.bin/clang > 1 error >=20 > make[4]: stopped in /usr/src/usr.bin/clang > *** [all_subdir_usr.bin/clang] Error code 2 >=20 > make[3]: stopped in /usr/src/usr.bin > 5 errors >=20 > make[3]: stopped in /usr/src/usr.bin > *** [all_subdir_usr.bin] Error code 2 >=20 > make[2]: stopped in /usr/src > 6 errors >=20 > make[2]: stopped in /usr/src > *** [everything] Error code 2 >=20 > make[1]: stopped in /usr/src > 1 error >=20 > make[1]: stopped in /usr/src > *** [buildworld] Error code 2 >=20 > make: stopped in /usr/src > 1 error >=20 > make: stopped in /usr/src > Build step 'Execute shell' marked build as failure > [WARNINGS]Skipping publisher since build result is FAILURE > FTP: Current build result is [FAILURE], not going to run. > [PostBuildScript] - [INFO] Executing post build scripts. > [PostBuildScript] - [INFO] Build does not have any of the results [SUCCES= S]. Did not execute build step #0. > [PostBuildScript] - [INFO] Executing post build scripts. > [FreeBSD-head-powerpc-build] $ /bin/sh -xe /tmp/jenkins346459227306226550= 6.sh > + sh freebsd-ci/scripts/jail/clean.sh > clean jail FreeBSD-head-powerpc-build > Checking for post-build > Performing post-build step > Checking if email needs to be generated > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any --nHwqXXcoX0o6fKCv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJeeRnGAAoJEKzQXbSebgfATeEH/REn2GOj+eCQiOhcikKjVWhJ c2pcJ1OzTHEmwzrZNX9+79FWguIN+lD21zz1OZj0rXoETn1Vw3KhSj78pksOZ4iE jrUyXE8a0nMqm3/99FjFMDWU4DIPYCH5dVrxtDi0y38caNq+j4fwU7PDSFMJ5N/I uGNxHuCQJzoo4ck1m4AXo+PvQYnH2QM3NDinPQ1nN6zi2SjCmPSgt7XE3e2QSS7J 7lmrupyu7J3SGmFHr9KO6LoUSXxL4MN5l1COxYRsDf+0C7XfDsKDm4uJ/nf2g6Uc UMoQqmAVfe5DOSeICtq/NTVBthGHC0++SqNpNbV97LfLzAk9+9h6oKvlUh7KEuA= =t+Jy -----END PGP SIGNATURE----- --nHwqXXcoX0o6fKCv-- From owner-freebsd-current@freebsd.org Mon Mar 23 20:59:28 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 165DC26E8F9 for ; Mon, 23 Mar 2020 20:59:28 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "darth.immure.com", Issuer "darth.immure.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48mRZl1vJXz4CVk for ; Mon, 23 Mar 2020 20:59:26 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTPS id 02NKvUOr022549 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 23 Mar 2020 15:57:30 -0500 (CDT) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.15.2/Submit) id 02NKvU9A022548 for freebsd-current@freebsd.org; Mon, 23 Mar 2020 15:57:30 -0500 (CDT) (envelope-from bob) Date: Mon, 23 Mar 2020 15:57:30 -0500 From: Bob Willcox To: current list Subject: make fetchindex in /usr/ports failing with Authentication error Message-ID: <20200323205730.GC14538@rancor.immure.com> Reply-To: Bob Willcox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 48mRZl1vJXz4CVk X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bob@rancor.immure.com has no SPF policy when checking 108.84.10.9) smtp.mailfrom=bob@rancor.immure.com X-Spamd-Result: default: False [3.54 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bob@immure.com]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[immure.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[0.998,0]; IP_SCORE(0.34)[ip: (0.17), ipnet: 108.64.0.0/11(0.08), asn: 7018(1.52), country: US(-0.05)]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[bob@immure.com,bob@rancor.immure.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7018, ipnet:108.64.0.0/11, country:US]; FROM_NEQ_ENVFROM(0.00)[bob@immure.com,bob@rancor.immure.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 20:59:28 -0000 I just updated my /usr/ports on my 13.0-current system and after that completed I tried to run 'make fetchindex' and got a continuous stream of these errors written to the display: fetch: https://www.FreeBSD.org/ports/INDEX-13.bz2: Authentication error Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34370576384:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: Anyone have any idea what I have wrong or am missing? This was previously working on this system (and make fetchindex works on my 12.1 systems ok). Thanks, Bob -- Bob Willcox | It's possible that the whole purpose of your life is to bob@immure.com | serve as a warning to others. Austin, TX | From owner-freebsd-current@freebsd.org Mon Mar 23 21:01:04 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 004BE26EBAF for ; Mon, 23 Mar 2020 21:01:04 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48mRcb6F2Bz4DFn for ; Mon, 23 Mar 2020 21:01:03 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D5DBC26EBAA; Mon, 23 Mar 2020 21:01:03 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D564B26EBA9; Mon, 23 Mar 2020 21:01:03 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 48mRcZ1qqnz4DFB; Mon, 23 Mar 2020 21:01:02 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 48mRcP5dJjz3m0v; Mon, 23 Mar 2020 21:00:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id Qfh-LAlX1f-v; Mon, 23 Mar 2020 21:00:53 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:cd3b:bf24:3448:4c23]) by mail.daemonic.se (Postfix) with ESMTPSA id 48mRcP154mz3lcX; Mon, 23 Mar 2020 21:00:53 +0000 (UTC) Subject: Re: users of xorg, in particular on FreeBSD 11.3 From: Niclas Zeising To: x11@FreeBSD.org, stable@FreeBSD.org, ports@FreeBSD.org, current@FreeBSD.org Reply-To: x11@FreeBSD.org References: Message-ID: Date: Mon, 23 Mar 2020 22:00:52 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48mRcZ1qqnz4DFB X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [1.38 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_SPAM_LONG(0.94)[0.940,0]; NEURAL_SPAM_MEDIUM(0.44)[0.435,0]; ASN(0.00)[asn:36236, ipnet:2607:f740:d::/48, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 21:01:04 -0000 In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the=20 upcoming 11.4) back to use the legacy rule set. This means that once=20 you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should=20 work as normal, and the environment variable XKB_DEFAULT_RULES does not=20 need to be changed. If you are on FreeBSD 12 or later, and are using xf96-input-keyboard,=20 you might still need to set this env variable. Please see the=20 instructions below. Regards On 2020-03-21 00:41, Niclas Zeising wrote: > [ This is cross-posted across several mailing lists for maximum=20 > visibility.=C2=A0 Please respect reply-to and keep replies to x11@FreeB= SD.org=20 > . Thank you! ] >=20 > In order to improve support when using evdev to manage input devices, i= n=20 > particular keyboards, we have switched the default in x11/libxkbcommon=20 > to the evdev instead of the legacy ruleset.=C2=A0 This was done in port= s=20 > r528813 . >=20 > On FreeBSD 11.3, the default configuration still requires the legacy=20 > ruleset. >=20 > If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard=20 > on FreeBSD 12 or later, you need to change the ruleset used by=20 > x11/libxkbcommon. >=20 > If you have issues with your keyboard, most notably arrow keys, and if=20 > /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being=20 > used, you need to switch to legacy rules by setting the environment=20 > variable XKB_DEFAULT_RULES to xorg. >=20 > The easiest way to accomplish this is by adding it to your shell startu= p=20 > file. >=20 > As an example, for users of [t]csh, put > =C2=A0 setenv XKB_DEFAULT_RULES xorg > in ~/.login >=20 > For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put > export XKB_DEFAULT_RULES=3Dxorg > in ~/.profile >=20 > Regards --=20 Niclas Zeising FreeBSD Graphics Team From owner-freebsd-current@freebsd.org Mon Mar 23 21:14:24 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3BBB326F58C for ; Mon, 23 Mar 2020 21:14:24 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48mRw004wRz4VhV for ; Mon, 23 Mar 2020 21:14:24 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E8B7A26F586; Mon, 23 Mar 2020 21:14:23 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E7CE326F584; Mon, 23 Mar 2020 21:14:23 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (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 48mRvz1c96z4Vg1; Mon, 23 Mar 2020 21:14:23 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 48mRvx1xQGz3m0B; Mon, 23 Mar 2020 21:14:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id WtAOwtcE-uqS; Mon, 23 Mar 2020 21:14:20 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:cd3b:bf24:3448:4c23]) by mail.daemonic.se (Postfix) with ESMTPSA id 48mRvw4sdbz3lcX; Mon, 23 Mar 2020 21:14:20 +0000 (UTC) Subject: Re: users of xorg, in particular on FreeBSD 11.3 From: Niclas Zeising To: x11@FreeBSD.org, stable@FreeBSD.org, ports@FreeBSD.org, current@FreeBSD.org Reply-To: x11@FreeBSD.org References: Message-ID: <1e391a4a-5e02-bc82-9143-fd609781ad84@freebsd.org> Date: Mon, 23 Mar 2020 22:14:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48mRvz1c96z4Vg1 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [1.74 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_SPAM_LONG(1.00)[0.996,0]; NEURAL_SPAM_MEDIUM(0.74)[0.743,0]; ASN(0.00)[asn:36236, ipnet:176.58.89.0/24, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 21:14:24 -0000 On 2020-03-23 22:00, Niclas Zeising wrote: > In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the=20 ^^^^^^^^ This should be r529003, sorry about that. > upcoming 11.4) back to use the legacy rule set.=C2=A0 This means that o= nce=20 > you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should=20 > work as normal, and the environment variable XKB_DEFAULT_RULES does not= =20 > need to be changed. >=20 > If you are on FreeBSD 12 or later, and are using xf96-input-keyboard,=20 > you might still need to set this env variable.=C2=A0 Please see the=20 > instructions below. >=20 > Regards >=20 > On 2020-03-21 00:41, Niclas Zeising wrote: >> [ This is cross-posted across several mailing lists for maximum=20 >> visibility.=C2=A0 Please respect reply-to and keep replies to=20 >> x11@FreeBSD.org . Thank you! ] >> >> In order to improve support when using evdev to manage input devices,=20 >> in particular keyboards, we have switched the default in=20 >> x11/libxkbcommon to the evdev instead of the legacy ruleset.=C2=A0 Thi= s was=20 >> done in ports r528813 . >> >> On FreeBSD 11.3, the default configuration still requires the legacy=20 >> ruleset. >> >> If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard= =20 >> on FreeBSD 12 or later, you need to change the ruleset used by=20 >> x11/libxkbcommon. >> >> If you have issues with your keyboard, most notably arrow keys, and if= =20 >> /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being= =20 >> used, you need to switch to legacy rules by setting the environment=20 >> variable XKB_DEFAULT_RULES to xorg. >> >> The easiest way to accomplish this is by adding it to your shell=20 >> startup file. >> >> As an example, for users of [t]csh, put >> =C2=A0=C2=A0 setenv XKB_DEFAULT_RULES xorg >> in ~/.login >> >> For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put >> export XKB_DEFAULT_RULES=3Dxorg >> in ~/.profile >> >> Regards >=20 >=20 Regards --=20 Niclas Zeising From owner-freebsd-current@freebsd.org Mon Mar 23 21:35:04 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C3E0D270A7F for ; Mon, 23 Mar 2020 21:35:03 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "darth.immure.com", Issuer "darth.immure.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48mSMp4nf3z3DPq for ; Mon, 23 Mar 2020 21:35:02 +0000 (UTC) (envelope-from bob@rancor.immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.15.2/8.15.2) with ESMTPS id 02NLXA1r022673 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 23 Mar 2020 16:33:10 -0500 (CDT) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.15.2/8.15.2/Submit) id 02NLXAES022672 for freebsd-current@freebsd.org; Mon, 23 Mar 2020 16:33:10 -0500 (CDT) (envelope-from bob) Date: Mon, 23 Mar 2020 16:33:10 -0500 From: Bob Willcox To: current list Subject: Re: make fetchindex in /usr/ports failing with Authentication error Message-ID: <20200323213310.GD14538@rancor.immure.com> Reply-To: Bob Willcox References: <20200323205730.GC14538@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200323205730.GC14538@rancor.immure.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 48mSMp4nf3z3DPq X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bob@rancor.immure.com has no SPF policy when checking 108.84.10.9) smtp.mailfrom=bob@rancor.immure.com X-Spamd-Result: default: False [3.54 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bob@immure.com]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[immure.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[0.996,0]; IP_SCORE(0.34)[ip: (0.17), ipnet: 108.64.0.0/11(0.08), asn: 7018(1.51), country: US(-0.05)]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[bob@immure.com,bob@rancor.immure.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7018, ipnet:108.64.0.0/11, country:US]; FROM_NEQ_ENVFROM(0.00)[bob@immure.com,bob@rancor.immure.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 21:35:04 -0000 Nevermind. I found an email that I had received last month that explained that I had to make install ca_root_nss. Did that and all is well with make fetchindex now. Bob On Mon, Mar 23, 2020 at 03:57:30PM -0500, Bob Willcox wrote: > I just updated my /usr/ports on my 13.0-current system and after that completed I tried to > run 'make fetchindex' and got a continuous stream of these errors written to the display: > > fetch: https://www.FreeBSD.org/ports/INDEX-13.bz2: Authentication error > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 > 34370576384:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > > Anyone have any idea what I have wrong or am missing? This was previously working on this > system (and make fetchindex works on my 12.1 systems ok). > > Thanks, > Bob > > -- > Bob Willcox | It's possible that the whole purpose of your life is to > bob@immure.com | serve as a warning to others. > Austin, TX | > _______________________________________________ > 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" -- Bob Willcox | It's possible that the whole purpose of your life is to bob@immure.com | serve as a warning to others. Austin, TX | From owner-freebsd-current@freebsd.org Mon Mar 23 23:53:47 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 80D18273F9E for ; Mon, 23 Mar 2020 23:53:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670059.outbound.protection.outlook.com [40.107.67.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48mWRs2q5zz4PfT for ; Mon, 23 Mar 2020 23:53:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oAavEKInfzqKsNSisb6KNM2ZulqnPt9YwTQAGMSiMDg8A0RuLfqZ4IpIrko8zBGUMxRC/ek/wXNXYMSW12NA8Q/xrcKjZAe3GcHJ6OKkxO53+cIcJq+eB8DrpisBrRFBht02CN1Yw8qjaXCGVUQfXtHtWmr8jMrENoB5p+pskawL+A7N3aNnPiqkkktQ1t9ZtbdSpmW3cetNn4pXiwh/CzmFBBeSEYQzGgQMrRxb51Jsh0rZ+gW3MeUn28pzo8qdmB7TsBsVKfa9L05oUMdZNesBAuZqfSOSKqS9sNkXgiN3cRhEnL4FWxGP2TXB8PJaTfY2ZpsmGtgkqSvNRON8Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sp79liBBKaFxoAa5bEzeA19b6TqcaYFXJpP5I/p7AxE=; b=ftN27lOUXWX1WxASzkxHXQMOazcB3PaBaSFeJCwl4m15QPHAMScjfpgt7lI2+ropfLF1CAj4+/DqXaM8zolmejSWfFz/RVWOwZ93qvMMqEr/jfeQpWabpGKpQ/CNDj5yiHX4i5Xrc2icLzwtEUNYnBor2szfY8S2DKu8xBwufODCDMlr2RfQOoBhd7rhTIzos3P5NGmB2V2IsCM7EqQgAhb5E8lZ7QGBmtGjqRWEnDQR3Sgg2eMXxCM3iovJINZEMnyfHdxObtELciXorcTcfarD9gmBrnyepIGnRBqBWaSJxeW0IHX+D502vqtenoZGKDe2PxwS9iT8CsDShGnIfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3921.CANPRD01.PROD.OUTLOOK.COM (52.132.85.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Mon, 23 Mar 2020 23:53:43 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f%5]) with mapi id 15.20.2835.021; Mon, 23 Mar 2020 23:53:34 +0000 From: Rick Macklem To: Alexander Leidinger , John-Mark Gurney CC: "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Thread-Topic: TLS certificates for NFS-over-TLS floating client Thread-Index: AQHWAWnI+UIiEJS9mke8ubtYdFBhyw== Date: Mon, 23 Mar 2020 23:53:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ab9639e1-1d24-4788-daa7-08d7cf8565cc x-ms-traffictypediagnostic: QB1PR01MB3921: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(366004)(396003)(136003)(376002)(110136005)(966005)(478600001)(76116006)(52536014)(33656002)(2906002)(4326008)(9686003)(55016002)(5660300002)(186003)(86362001)(8676002)(7696005)(6506007)(8936002)(81166006)(81156014)(786003)(64756008)(66946007)(66446008)(71200400001)(66476007)(316002)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3921; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Dc8Ktp1WQchmBq+TCK91t67ExOeYJT39mZdRwVUTySMYEQfGNeDDUsEks2FFJOncAWst/dg22MToz3kQJAMkFkQPDoM3LbLk96LMg1/xgQjTaAKN/Lless74uGahfogP1KS8zoLkOureSJoBxw7iNupPUBfwzdp5n4OJrQjoTLBWQ9KjX9i0r5HaOWhrELckbNPD21Lm07hUzstithykmzEoWNYRw/EWCzGPszCiLSY6EHXHqCbiD8yYUIg9TE6a/oUoTQwFRuBXQC0eBYc5/R23OGX8CFLkFFOtadrVhzjtjV/EdhymuQegJXhWWVAEZLejmiXmzK4m1wqkZO9Bt2H40jkLxbbe5s0kmmUZcYNT2gKLDJ0Z9WNMzPxFrkqSTYwfPNa469ol13Q34FqzUsuUSpL/iz3vH56OykpdRwvr2n4vpOKqlvWFxR18ZouqhwQp9Fj+964SJUgJikbZBLDHlO0rkit4tjgQxRnoOc7ZA82SayyYhQJrPfkwqp9wVw9jfL1r4wJB/x4v8jhzqw== x-ms-exchange-antispam-messagedata: BNKihki0b2Nit9ESsAO2jGN3EsqfzWxCDxeyzAdtpm1W1NeHozoLG8zPuFX/4nG5oaOGIc5+XdqsNVN6BvTsilfNSWEIhLx6od1SIujAXf1CkLBlq+5vNKQxfcAleoCX8QWkSb11YHGlHxEI4aDqtlUmDyDSMbcJNYGDZyb9LFmrnbBhu3dFInlekkVPkpOS6DgNHhp8N9+yKch3X7bsnQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: ab9639e1-1d24-4788-daa7-08d7cf8565cc X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 23:53:34.1228 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: movSKP4mSVdESybc0sxlvYBk/r13y5+gft6su9BX39LNMlApxXsX9mUORVjdJIckd6Jr+xEiDCW3Nmq+Ix2loQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3921 X-Rspamd-Queue-Id: 48mWRs2q5zz4PfT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.59 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.63 / 15.00]; FAKE_REPLY(1.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[59.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.38)[ipnet: 40.64.0.0/10(-3.75), asn: 8075(-3.12), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 23:53:47 -0000 Alexander Leidinger wrote:=0A= John-Mark Gurney wrote:=0A= >>Rick Macklem wrote:=0A= >>> to be the best solution. The server can verify that the certificate=A0 = =0A= >>> was issued by=0A= >>> the local CA. Unfortunately, if the client is compromised and the=A0 = =0A= >>> certificate is copied=0A= >>> to another client, that client would gain access.=0A= >>=0A= >> This is why CRLs/OSCP is necessary, but there isn't anything you can do= =0A= >> to prevent that.=A0 This is both a better situation than what we have=0A= >> today (no auth/confidentiality), and if you tie the cert to an IP, it's= =0A= >> of limited use, and better than today...=0A= >=0A= >There are multiple ways to handle that:=0A= >=A0 - First of all, you can just validate based upon "cert is signed by=A0= =0A= >trusted CA".=0A= >=A0 - Then you can require that the CN matches the hostname and the=A0 =0A= >reverse lookup matches.=0A= >=A0 - Or (similar to browsers today) you can ignore the CN and require=A0 = =0A= >that the hostnames of the client matches one of the subject=A0 =0A= >alternative name (SAN) entries (requires reverse DNS lookup to work=A0 =0A= >and match).=0A= At this point, I have three variants in the code (strictest to less strict)= :=0A= 1 - A "-h" command line option on the server handshake daemon (called rpctl= ssd).=0A= This requires that all clients have=0A= certificates that validate and have the FQDN acquired via reverse DNS = of=0A= the IP address of the client for the TCP connection (getnameinfo(NI_NA= MEREQD))=0A= in either the subjectAltName or CommonName. (I call X509_check_host()= =0A= and this is what I understand it checks.)=0A= --> This case implies that the NFS server admin. does not "trust" the= =0A= client's IP address enough to apply exports(5) line(s)to it to = decide to=0A= allow the client to do an NFS mount.=0A= (An NFS server *might* be willing to allow client(s) to mount via any = IP address=0A= for the #2 case below and not use this option.)=0A= 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indica= te=0A= if the client provided a certificate and whether or not it verified.= =0A= Then the "-tlscert" option on the appropriate exports(5) line(s) =0A= indicates that the client must have provided a certificate that verifi= ed.=0A= --> For this case (and #3), the server admin. is willing to "trust" th= e client's=0A= IP address enough to apply exports(5) rules to it.=0A= --> This is the case where a floating (no fixed IP) laptop could have = a=0A= certificate signed by a site local CA.=0A= 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s).=0A= In this case, the client must use TLS so that data is encrypted on the= wire,=0A= but does not need to have a certificate.=0A= --> The NFS server admin. "trusts" the client IP address enough that t= hey=0A= are willing to allow the client to mount based on that IP, but w= ants the=0A= data to be encrypted on the wire.=0A= - Avoids the bother of generating certificates for the client(s)= .=0A= =0A= A part of this (as discussed in the IETF draft) is to make this easy enough= to=0A= use that it does get used. (sec=3Dkrb5p achieves both user authentication a= nd=0A= data encryption on the wire, but does not get widely used, due to the need= =0A= to run a KDC, etc).=0A= =0A= Comments on the above options is welcome, since this does need to be=0A= reviewed by users.=0A= =0A= rick=0A= =0A= =0A= At this point you prevent simple cert theft as additionally you=A0 =0A= require that someone also has to be able to modify the DNS (or NFS=A0 =0A= server hosts file, but then he probably can already add an additional=A0 = =0A= cert to the truststore of nfsd).=0A= =0A= Additional protection is possible by also adding the IP to the SAN. I=A0 = =0A= haven't put an effort into evaluating if either IP or DNS is enough=A0 =0A= from a security point of view, or if it makes a difference if the "IP=A0 = =0A= in SAN" case has an additional benefit in terms of security if it is=A0 =0A= in addition to the reverse DNS requirement.=0A= =0A= Yes this makes it more inconvenient to change the IP of a host, but if=A0 = =0A= all the policy possibilities are up to the admin to configure (e.g.=A0 =0A= "cert is signed by trusted CA" as a default, and all the other=A0 =0A= possibilities as an option for nfsd), it is up to the admin and the=A0 =0A= security requirement.=0A= =0A= In general, all the possibilities are can either be distinct, or=A0 =0A= accumulative. There is also the possibility that you do not go with=A0 =0A= any CA but configure X self-signed certs for X clients as being=A0 =0A= trusted and the cert of the client needs to be an exact match with one=A0 = =0A= of the X self-signed certs in the truststore.=0A= =0A= Whatever the policy(/ies) is/are in nfsd, I suggest to make it=A0 =0A= explicit in the docs what is required and what is checked for each=A0 =0A= policy. And even if it may be obvious for you Rick, please also print=A0 = =0A= out why a client was rejected. Unfortunately I've seen a lot of cases=A0 = =0A= where the error is a simple/frustrating "certificate rejected", but no=A0 = =0A= info which part of the certificate check failed.=0A= =0A= Bye,=0A= Alexander.=0A= -- =0A= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=0A= http://www.FreeBSD.org=A0=A0=A0 netchild@FreeBSD.org=A0 : PGP 0x8F31830F9F2= 772BF= From owner-freebsd-current@freebsd.org Tue Mar 24 11:37:34 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 95E352A2991 for ; Tue, 24 Mar 2020 11:37:34 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48mq3X1k66z3FTv; Tue, 24 Mar 2020 11:37:10 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id h9so20966998wrc.8; Tue, 24 Mar 2020 04:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=pWBHZgx9z7WXNOUPXJvFCtNqejtV2oHwPhDRvBFFuzw=; b=uiXsiORfK7C+X4REZl7UIpKORfUa8yf6WdUZcqaa+H1msP+p04TZYZLeZUwp98ln0r gcRfnWqEGyk28QTUSkS8xYId0EYAxBnL8T1K+Thj4IDazVh8m+hchCSGlt+Q/46afFan gOPyHRG5jhf2EVJU8qPGp28vHlxvImmbL3DHU0/nHIto4teh6R9hd32cmjnjrLG/9AKu 3WntPDn7Vwba/lKqJF+eF0mRtbokXz8Fj31oWrQHHWd9vsd3/vhhgjIU9wUFDsZblj/c vrtJv9JrVYV9QxrTY0Pz1qlb4xFXOhjLPiJzYDQRKzdfy8M2Q6U5nfInBVgDijp/b7EL AsQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pWBHZgx9z7WXNOUPXJvFCtNqejtV2oHwPhDRvBFFuzw=; b=UpG8sVgJmmqsdZggZmJvpPd71dmN/7Hvg9dIugiK5MwVsTGO65maB1Ijaiv+ahrV1/ J0NoTAD+O74lCn9j477exx1px5xx89HRvgO7SYuyugTpCmom4kzN1fSxD+w0uLPS5ixk QE1Tb/tE6+oeha1KMJkKzapr9ayN0+zZ/m885eGPYmZNFgwXyRY66f7Pi6Rwm8z/hxKp lZKuY48VANxX1LaxwcGq2iqgXNIEA1ZviF1JXaHMF0+UIG9n5PmhKrpTk7TJ15Agh2ky nsFa5M9dnAKEYtFJtXfcwucGEcTwxFMzeM3XcuWngg+/LGm51JW6crh0pgSZEI71mcUa OluA== X-Gm-Message-State: ANhLgQ0g/3QgduxpBQlJ61Eqi9runWNeNmCO+/F1eV9cpKQe6X+JURV/ 37eRY2F9zbuS3UH9sMWO9Y9b2gtz8Q8= X-Google-Smtp-Source: ADFU+vvAmTTMbUyE5NFcKwT+1ntFeL2uH4cetiX2OKBQkmOmVqWpF83MZfmR2OD1o2TKXQ46OabS8Q== X-Received: by 2002:adf:b650:: with SMTP id i16mr35652057wre.316.1585049821481; Tue, 24 Mar 2020 04:37:01 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id t10sm5833656wrx.38.2020.03.24.04.37.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Mar 2020 04:37:00 -0700 (PDT) Subject: VirtualBox segmentation fault, 5.2.34_1 on FreeBSD-CURRENT r359249 To: Kyle Evans Cc: FreeBSD References: From: Graham Perrin Message-ID: <868363c6-5120-d9c6-b691-48c60c1c5dc1@gmail.com> Date: Tue, 24 Mar 2020 11:36:59 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 48mq3X1k66z3FTv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=uiXsiORf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::436 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.00)[ip: (-9.11), ipnet: 2a00:1450::/32(-2.39), asn: 15169(-0.49), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[78.147.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[6.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 11:37:34 -0000 On 20/03/2020 01:24, Kyle Evans wrote: > On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin wrote: >> Is this maybe related to >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I >> make a separate bug report? >> > Please throw a tentative "Me too" on that PR; I'm investigating it, > then we'll see if they're related or requires yet another PR. Locally built 5.2.34_1 not working on -CURRENT. Should I open a new bug? grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v Tue 24 Mar 2020 10:49:01 GMT FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG grahamperrin@momh167-gjp4-8570p:~ % virtualbox Segmentation fault grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod emulators/virtualbox-ose 5.2.34_1 poudriere emulators/virtualbox-ose-kmod 5.2.34 poudriere grahamperrin@momh167-gjp4-8570p:~ % grep virtualbox /var/log/messages Mar 22 21:22:40 momh167-gjp4-8570p pkg[26037]: virtualbox-ose-kmod reinstalled: 5.2.34 -> 5.2.34 Mar 22 21:23:05 momh167-gjp4-8570p pkg[26037]: virtualbox-ose reinstalled: 5.2.34_1 -> 5.2.34_1 Mar 23 01:38:52 momh167-gjp4-8570p pkg[77976]: virtualbox-ose reinstalled: 5.2.34_1 -> 5.2.34_1 Mar 23 05:03:36 momh167-gjp4-8570p pkg[52378]: virtualbox-ose reinstalled: 5.2.34_1 -> 5.2.34_1 Mar 23 15:44:12 momh167-gjp4-8570p pkg[27169]: virtualbox-ose reinstalled: 5.2.34_1 -> 5.2.34_1 Mar 24 08:19:51 momh167-gjp4-8570p pkg[49646]: virtualbox-ose reinstalled: 5.2.34_1 -> 5.2.34_1 grahamperrin@momh167-gjp4-8570p:~ % grep -v \# /usr/local/etc/poudriere.d/make.conf WITHOUT_LLVM_TARGET_ALL= MESA_LLVM_VER=${LLVM_DEFAULT} grahamperrin@momh167-gjp4-8570p:~ % From owner-freebsd-current@freebsd.org Tue Mar 24 12:33:59 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC5822A4DE7 for ; Tue, 24 Mar 2020 12:33:59 +0000 (UTC) (envelope-from 21cencturyayush@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48mrJp370kz45xK for ; Tue, 24 Mar 2020 12:33:46 +0000 (UTC) (envelope-from 21cencturyayush@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id t20so6216266uao.7 for ; Tue, 24 Mar 2020 05:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Na5n+1GMzPnSKRRieJd0pExVr8TlOH0/uQBUTWe4GYI=; b=M4/L+Od0w3toAT+TlVhO0YPfRuc+t4l19lNEFUVOU4CyVQMNWvUOACe3GCyIKwfgBu kRUoEAJFGIWQ+c0rP9isveSdA3ynsddSQzhhnIb/7r3M8qVmthKn+g9R29LuiKMTuKBU TT0hi6o/r2S+0pGHz+8wo8AgszOVlozcs0ccloKcxq1itbdlhwvc5C06Zqx+YIyIv7VD qSp7YtwMuZY3n9t/bYy3KwHUIAr8BV57xT1vkTlYNLiZr5jAGuX44gbpIEsoRxM/gWLM XXIhHGfsjCKMmRWDZtfJ+IWvxTt+B0Ded2ByrqdCI3DiQH/y1LlDt5feaU3O0FOmf+1Y 3Y/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Na5n+1GMzPnSKRRieJd0pExVr8TlOH0/uQBUTWe4GYI=; b=Di+bheC8igKpX3/Gh4q02lmyPOS75w+YBGqGYuByyy5QgkxlPZh/rHrCcMFhLChH5C oxKaYpGSWY9BPDJ5W7t+9iSIUCk7ZwP0DBHDGJBJClrQ5X8Re2qYxaNnqbfgSpy1U2ZS a03fTlpQ0e+AziAowzv0ggoOR4yq0+wulnzDbF5IcdvIAFRMs25NS4DliSVDQFIgSNWl eoo1i715zJWahNpsedf+78is3bvDKgJh6SWIbVR3d11fdqbNxeeGOx6+RP+Qh8muS6pr MvNnsZSRnC7WJlXNFjCQOJbWvIPQmnKHcZCSAPYqXT85BY7bobY5LTbqof43hdTgpdeC 48Dg== X-Gm-Message-State: ANhLgQ0HYZAQXtDgvB3yftjIZLg3F6SWfWmQHCG6TpYq9kilPiPJe4+8 QK+dJ+OFa6EePgVQen1LKemdiIYoMByQT62YOtut8SJtFfs= X-Google-Smtp-Source: ADFU+vvFQ+794qc1qHtKOUPv1PMpIzQytXSOFfRn2p2MbSeMLQosCbOWpzC9wlbqTOayb+YOdWymgQT5BK1GZq0hNiQ= X-Received: by 2002:ab0:714b:: with SMTP id k11mr17437645uao.97.1585053217824; Tue, 24 Mar 2020 05:33:37 -0700 (PDT) MIME-Version: 1.0 From: Ayush Dwivedi <21cencturyayush@gmail.com> Date: Tue, 24 Mar 2020 18:03:26 +0530 Message-ID: Subject: FreeBSD 13.0-CURRENT-amd64 VM Image(qcow2) does not boot in OVMF To: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 48mrJp370kz45xK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=M4/L+Od0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of 21cencturyayush@gmail.com designates 2607:f8b0:4864:20::92e as permitted sender) smtp.mailfrom=21cencturyayush@gmail.com X-Spamd-Result: default: False [-1.70 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[mail-ua1-x92e.google.com]; HFILTER_HELO_NORES_A_OR_MX(0.30)[mail-ua1-x92e.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.26), ipnet: 2607:f8b0::/32(-0.38), asn: 15169(-0.49), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[e.2.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 12:34:00 -0000 Hello everybody, This is Ayush. I am trying to run the FreeBSD 13.0-CURRENT-amd64 VM image(qcow2) on my Arch Linux using QEMU(using the virt-manager ). It boots just fine when I boot with BIOS as the firmware but it does not boot when I am using UEFI firmware(ovmf) to run the VM. The EFI Shell loads. I have checked the boot order priority 1 is given to HARD DISK only still it does not boot. I read some related issues mainly this [1] .(actually I tried booting CURRENT using it's bootonly ISO image as well). I have Intel Core i5-2520M CPU.(I choose Hypervisor default CPU for my VM image) Regards, Ayush Dwivedi From owner-freebsd-current@freebsd.org Tue Mar 24 14:41:06 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F102E2A768F for ; Tue, 24 Mar 2020 14:41:06 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48mv7c24zbz3PqD for ; Tue, 24 Mar 2020 14:40:59 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B165972.dip0.t-ipconnect.de [91.22.89.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id E912818B7 for ; Tue, 24 Mar 2020 15:40:46 +0100 (CET) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id C71871238A for ; Tue, 24 Mar 2020 15:40:12 +0100 (CET) Date: Tue, 24 Mar 2020 15:40:12 +0100 Message-ID: <20200324154012.Horde.0jAAoCNOnQrWFXTjlEpT0Ck@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-current@freebsd.org Subject: Re: make fetchindex in /usr/ports failing with Authentication error References: <20200323205730.GC14538@rancor.immure.com> <20200323213310.GD14538@rancor.immure.com> In-Reply-To: <20200323213310.GD14538@rancor.immure.com> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_nZnOUaFy4OBpJlTUCCFN24C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 48mv7c24zbz3PqD X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.84 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; URIBL_BLOCKED(0.00)[leidinger.net.multi.uribl.com]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-3.74)[ip: (-9.83), ipnet: 2a00:1828::/32(-4.91), asn: 34240(-3.92), country: DE(-0.02)]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; SIGNED_PGP(-2.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[114.89.22.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 14:41:07 -0000 This message is in MIME format and has been PGP signed. --=_nZnOUaFy4OBpJlTUCCFN24C Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Bob Willcox (from Mon, 23 Mar 2020 16:33:10 -0500)= : > Nevermind. I found an email that I had received last month that=20=20 >=20explained that I > had to make install ca_root_nss. Did that and all is well with make=20=20 >=20fetchindex > now. On -current you can alternatively run "certctl rehash". This will=20=20 enable=20the same certs than the ca_root_nss port. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_nZnOUaFy4OBpJlTUCCFN24C Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJeehvMAAoJEBINsJsD+NiGkiYP/iB9HIiA2jbrgPcpRAdQ0iSc vr7khTtZFw6Z5GuTuTnbS9IEQmuvb9w5aqCyHHE+RrIUPhbIAXbFbVofL2IILryW 2FDc7cImcbTBoH/5eryXFFEyGyAqN+j+vQQOofNBcGiw6osgCrARBPq76vO+z1VH 7fFxuhYISpQEYGoX+Hs/lNPIdrkFgdBK+TsBFRTKFKrYljFyGjtvzuBIztLN2exL rolYecW+pEJ36irW3pRIMfO0zKGPJA9j9V4FD1yP3WIVkH0Ie8GSfPD6TP9O3nq2 2KeY3+IFdTkbjiZXrzFkq1Sc8tcxZ//Dfi9/3hq8Vt3M5wYF6GrJtERMSNo6j9tp 2OiIbHRTK0j0gKO/+TFQWG+TFIxKdxvz1RWgq8NfiNxPEuNmLZBQr6UjYwvsQZs9 /Kop0P3JGDDdrqD7n9xzU37vZTZF9pp7LM2H+pYJ2y0UQ9omNr3Y2MGIMx8CbZkc ynLjpTFz4NMZL955opTcZXqhnDgg0ieODZ4L8BDH32mhL/K48Ec3zPxJcubAZEjN 3AT6P9jMCX1f7PFvfwH4TFDtXNVZhclE2xDqgI8x04cgJCATnjwpe06rnN589zXL XPPV2c2PM4a3KSFnBzBZUvv1uQ3evdIffTPYQd4i/pBvaOIQq7OHB/CSFw+pwIHj 0BkeKa9eoIDxKHcML8Sn =kR/J -----END PGP SIGNATURE----- --=_nZnOUaFy4OBpJlTUCCFN24C-- From owner-freebsd-current@freebsd.org Wed Mar 25 04:46:12 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CCBBC27504C; Wed, 25 Mar 2020 04:46:12 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48nFtp5wGFz4HrP; Wed, 25 Mar 2020 04:46:10 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 03E051B9E4; Wed, 25 Mar 2020 04:46:01 +0000 (UTC) Date: Wed, 25 Mar 2020 04:46:00 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-03-22 Message-ID: <20200325044600.GA2244@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 04:46:13 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.)a FreeBSD CI Weekly Report 2020-03-22 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-03-16 to 2020-03-22. During this period, we have: * 1907 builds (90.7% (+0.6) passed, 9.3% (-0.6) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 307 test runs (95.4% (+20.3) passed, 3.3% (-13.8) unstable, 1.3% (-6.5 exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 33 doc and www builds (78.8% (-9.4) passed, 21.2 (+9.4) failed) Test case status (on 2020-03-22 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | ------- | | head/amd64 | 7722 (+1) | 7625 (+1) | 0 (0) | 97 (0) | | head/i386 | 7720 (+1) | 7614 (+1) | 0 (0) | 106 (0) | | 12-STABLE/amd64 | 7506 (0) | 7453 (0) | 0 (0) | 53 (0) | | 12-STABLE/i386 | 7504 (0) | 7440 (-3) | 0 (0) | 64 (+3) | | 11-STABLE/amd64 | 6880 (0) | 6833 (0) | 0 (0) | 47 (0) | | 11-STABLE/i386 | 6878 (0) | 6826 (0) | 0 (0) | 52 (0) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200322 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-mips64-build This error was encountered when this job was using devel/gcc6@mips64 port (mips64-gcc6 pacakge) This job was switched to use clang/lld on 2020-03-24. Gcc job will be added later. ``` ===> include/rpcsvc (includes) RPCGEN_CPP=/usr/local/bin/mips64-unknown-freebsd12.0-cpp6\ --sysroot=/usr/home/lwhsu/freebsd-obj-gcc6/usr/home/lwhsu/freebsd-src/mips.mips64/tmp\ -B/usr/local/mips64-unknown-freebsd12.0/bin/ rpcgen -C -h -DWANT_NFS3 /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x -o mount.h /usr/home/lwhsu/freebsd-src/include/rpcsvc/mount.x:1:0: error: '-march=mips1' is not compatible with the selected ABI /*- *** [mount.h] Error code 1 make[4]: stopped in /usr/home/lwhsu/freebsd-src/include/rpcsvc 1 error ``` * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` --- all_subdir_usr.bin/clang/lldb --- /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandler.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:926: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * 3 tests start failing after llvm10 import * lib.libproc.proc_test.symbol_lookup * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (-5), 579 failures (+5), 806 skipped (0) ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/242689 * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * skip sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/244053 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.geom.class.multipath.misc.fail_on_error (12-STABLE) https://bugs.freebsd.org/244158 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated https://bugs.freebsd.org/244737 ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Wed Mar 25 23:10:31 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5BE1426623F for ; Wed, 25 Mar 2020 23:10:31 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48nkNp1qlYz46pn for ; Wed, 25 Mar 2020 23:10:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 02PNA6L7006212 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Mar 2020 16:10:06 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 02PNA5Mi006211; Wed, 25 Mar 2020 16:10:05 -0700 (PDT) (envelope-from jmg) Date: Wed, 25 Mar 2020 16:10:05 -0700 From: John-Mark Gurney To: Rick Macklem Cc: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <20200325231005.GQ4213@funkthat.com> Mail-Followup-To: Rick Macklem , Alexander Leidinger , "freebsd-current@FreeBSD.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Wed, 25 Mar 2020 16:10:06 -0700 (PDT) X-Rspamd-Queue-Id: 48nkNp1qlYz46pn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.67 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.40)[ip: (-1.03), ipnet: 208.87.216.0/21(-0.52), asn: 32354(-0.41), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.58)[-0.582,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.887,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 23:10:31 -0000 Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +0000: > Alexander Leidinger wrote: > John-Mark Gurney wrote: > >>Rick Macklem wrote: > >>> to be the best solution. The server can verify that the certificate  > >>> was issued by > >>> the local CA. Unfortunately, if the client is compromised and the  > >>> certificate is copied > >>> to another client, that client would gain access. > >> > >> This is why CRLs/OSCP is necessary, but there isn't anything you can do > >> to prevent that.  This is both a better situation than what we have > >> today (no auth/confidentiality), and if you tie the cert to an IP, it's > >> of limited use, and better than today... > > > >There are multiple ways to handle that: > >  - First of all, you can just validate based upon "cert is signed by  > >trusted CA". > >  - Then you can require that the CN matches the hostname and the  > >reverse lookup matches. > >  - Or (similar to browsers today) you can ignore the CN and require  > >that the hostnames of the client matches one of the subject  > >alternative name (SAN) entries (requires reverse DNS lookup to work  > >and match). > At this point, I have three variants in the code (strictest to less strict): > 1 - A "-h" command line option on the server handshake daemon (called rpctlssd). > This requires that all clients have > certificates that validate and have the FQDN acquired via reverse DNS of > the IP address of the client for the TCP connection (getnameinfo(NI_NAMEREQD)) > in either the subjectAltName or CommonName. (I call X509_check_host() > and this is what I understand it checks.) > --> This case implies that the NFS server admin. does not "trust" the > client's IP address enough to apply exports(5) line(s)to it to decide to > allow the client to do an NFS mount. > (An NFS server *might* be willing to allow client(s) to mount via any IP address > for the #2 case below and not use this option.) > 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indicate > if the client provided a certificate and whether or not it verified. > Then the "-tlscert" option on the appropriate exports(5) line(s) > indicates that the client must have provided a certificate that verified. > --> For this case (and #3), the server admin. is willing to "trust" the client's > IP address enough to apply exports(5) rules to it. > --> This is the case where a floating (no fixed IP) laptop could have a > certificate signed by a site local CA. > 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s). > In this case, the client must use TLS so that data is encrypted on the wire, > but does not need to have a certificate. > --> The NFS server admin. "trusts" the client IP address enough that they > are willing to allow the client to mount based on that IP, but wants the > data to be encrypted on the wire. > - Avoids the bother of generating certificates for the client(s). > > A part of this (as discussed in the IETF draft) is to make this easy enough to > use that it does get used. (sec=krb5p achieves both user authentication and > data encryption on the wire, but does not get widely used, due to the need > to run a KDC, etc). > > Comments on the above options is welcome, since this does need to be > reviewed by users. Maybe I'm missing the option where the cert needs to be authenticated, but matching against IP/dns name does not need to be done. Or is this a case of #2. I'm just confused by the first point of #2 in that the server admin is wiling to trust the IP address... I'd like to see where CN or other field is freeform/provided by exports entry, and validated to gain access to those resources... i.e. it doesn't matter what IP or DNS name the client is, it's based solely on the certificate. This would allow roaming users.. This maybe be addressed by #2 point 2, but it isn't clear in your description that it isn't dns tied or something else... As the CA admin, they control what is valid/gets signed in the CN or other fields, so this is safe to do... If you can't trust your CA to sign only valid (to your policy) certs, then you shouldn't be using that CA.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Wed Mar 25 23:51:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B31AC267488 for ; Wed, 25 Mar 2020 23:51:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660046.outbound.protection.outlook.com [40.107.66.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48nlHv22qjz4N5w for ; Wed, 25 Mar 2020 23:51:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sd+bC/mPvEsVGs0G1005EP9QdLgYUcppKYFP11hOp0thrOyKsW+ER25xY6G0QGmc1VAQb9RyQDk2F2FnWUlyqRkD4HeeCCUEJyAL9DoyDK1/ksgkeqA8oHyWuwUcFDTHXOkLG6/Ldkvoefa6r/vr+gXQTsY2Bryfe5arKkAe4ILYwhaM7nJMRE/jkHAf4xYwMk6XwUNBFeJ3v81UQH78exsfE+5PfJZ95KM5iO+p/8dK1EpMgK3GP2eFBJsO/YnXnbYesEJloIN2p+i5WJTYwAulEyVdPBnEApZuJ8blyAYeFtgkcLTEn+pAqYaA7599HvFqxzamtk8cor/rMcB4GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vVH4bzMTYlJadhEBtRO1y+gsFUog8zF7EHdEQV0HbBE=; b=Ideme+f6Nv92tskbwAIRinGFy3nXa13UmKrtVPLjCL8i51avja/BOJwhU2K9YxjwpWr+I3QiRznw/ZzwBtd3HOcSsXq6vLVeVVLs9EwnzU4rwkZPB4Ael9hJXD0cGXiq8Khl/nZnqxUx3ddeGM6FvElv3qd/K+w/o2MxMMo8W9xilXSW9fI2Vv4iF6/M63ClSitI8bMP08gFCObLIZ8gVMGk3tSobUn4m+AwXIv8BVVnsBh7MDbR0C/NWLM02JWNeFhZmapT9lACjGsQDO4DENpqyKBDhOu+9FUNopSgdwHKNafWayQXN7xoPzAy5UIt5Ys+RvdyAioxQ3vWtbmM0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3396.CANPRD01.PROD.OUTLOOK.COM (52.132.88.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.15; Wed, 25 Mar 2020 23:50:56 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f%5]) with mapi id 15.20.2835.023; Wed, 25 Mar 2020 23:50:56 +0000 From: Rick Macklem To: John-Mark Gurney CC: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Thread-Topic: TLS certificates for NFS-over-TLS floating client Thread-Index: AQHWAWnI+UIiEJS9mke8ubtYdFBhy6hZ8jaAgAAC+s0= Date: Wed, 25 Mar 2020 23:50:56 +0000 Message-ID: References: , <20200325231005.GQ4213@funkthat.com> In-Reply-To: <20200325231005.GQ4213@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf8d351d-6193-405e-5048-08d7d1175c92 x-ms-traffictypediagnostic: QB1PR01MB3396: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(376002)(39860400002)(346002)(81156014)(316002)(81166006)(8676002)(86362001)(786003)(8936002)(54906003)(52536014)(5660300002)(2906002)(64756008)(66556008)(71200400001)(33656002)(66476007)(66946007)(66446008)(4326008)(6506007)(478600001)(186003)(55016002)(6916009)(9686003)(76116006)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3396; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kzhYiBLoReZkTuVj3FrgWcnsN9HrLfshSIpN5GF3x5rvoZU6+/i3GdCJwmDrPsSp5df6mu718x6DVKb3V2Upxbdyuc2jQW7HLT+Ygp3ZxzR31mqTQw0idOprGlMByVTIzm7T0G8d0yIpT6WdFBWBQhfbLe34nAs9ugCJaClA+6HNNqLYqioJDjjDIzkddZeymLW/53KVQpzMrB7pNFhbOTBoaitp5BAOgWeYkAILn8FQJZbbCyJ4zw+otriF+ZAMX0GecKEtqbzZ+hd7cV2OXza36tYWa3taIdDxqlQDPKBEDrE5b6GeLgD4oXLi27345q+Esx7M5R/q/E5Pt/B98dWN1dNgsq+z6SsYEYXki6xeCyYz4/dPfY0EZe4wwcF7FJZcA7oXPKXuLPmwpwbaawbOpU2rAXZoz+uaOrAwkKpwEVsQvbvwa5HE/5d/cp1F x-ms-exchange-antispam-messagedata: mLWKHLUosv7PGYv3JV511FjRZ/nrT3EoppL5MXVxIGL1V897tFpyDibHFIo+KYxpuYiiwYK6DH/lUbZDPyzbxtFs8oxJlOjrPgBAycY/grYfs15pHXjt5x/Wj5mCqfWMTKDO8F8JnXDU/nIFPoMzAtFWTqqNf935NAglauGnKh3QrXY9PEr1BPUAuxCG46bzsQjg00kiNE4T0+9wyEQ40Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: cf8d351d-6193-405e-5048-08d7d1175c92 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2020 23:50:56.2900 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rN3OwfNVw6sbtu9Dxc/MTlTK6WzkbC4kQH3hnEJN8Wxs1BIWe18irhnsEpE5cI/B93gLiIChY8qaLkXgeaEs5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3396 X-Rspamd-Queue-Id: 48nlHv22qjz4N5w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.46 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.68 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[46.66.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.38)[ipnet: 40.64.0.0/10(-3.75), asn: 8075(-3.13), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 23:51:17 -0000 John-Mark Gurney wrote:=0A= >Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +0000:=0A= >> Alexander Leidinger wrote:=0A= >> John-Mark Gurney wrote:=0A= >> >>Rick Macklem wrote:=0A= >> >>> to be the best solution. The server can verify that the certificate= =0A= >> >>> was issued by=0A= >> >>> the local CA. Unfortunately, if the client is compromised and the=0A= >> >>> certificate is copied=0A= >> >>> to another client, that client would gain access.=0A= >> >>=0A= >> >> This is why CRLs/OSCP is necessary, but there isn't anything you can = do=0A= >> >> to prevent that. This is both a better situation than what we have= =0A= >> >> today (no auth/confidentiality), and if you tie the cert to an IP, it= 's=0A= >> >> of limited use, and better than today...=0A= >> >=0A= >> >There are multiple ways to handle that:=0A= >> >=A0 - First of all, you can just validate based upon "cert is signed by= =0A= >> >trusted CA".=0A= >> >=A0 - Then you can require that the CN matches the hostname and the=0A= >> >reverse lookup matches.=0A= >> >=A0 - Or (similar to browsers today) you can ignore the CN and require= =0A= >> >that the hostnames of the client matches one of the subject=0A= >> >alternative name (SAN) entries (requires reverse DNS lookup to work=0A= >> >and match).=0A= >> At this point, I have three variants in the code (strictest to less stri= ct):=0A= >> 1 - A "-h" command line option on the server handshake daemon (called rp= ctlssd).=0A= >> This requires that all clients have=0A= >> certificates that validate and have the FQDN acquired via reverse D= NS of=0A= >> the IP address of the client for the TCP connection (getnameinfo(NI= _NAMEREQD))=0A= >> in either the subjectAltName or CommonName. (I call X509_check_host= ()=0A= >> and this is what I understand it checks.)=0A= >> --> This case implies that the NFS server admin. does not "trust" t= he=0A= >> client's IP address enough to apply exports(5) line(s)to it = to decide to=0A= >> allow the client to do an NFS mount.=0A= >> (An NFS server *might* be willing to allow client(s) to mount via a= ny IP address=0A= >> for the #2 case below and not use this option.)=0A= >> 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to ind= icate=0A= >> if the client provided a certificate and whether or not it verified= .=0A= >> Then the "-tlscert" option on the appropriate exports(5) line(s)=0A= >> indicates that the client must have provided a certificate that ver= ified.=0A= >> --> For this case (and #3), the server admin. is willing to "trust"= the client's=0A= >> IP address enough to apply exports(5) rules to it.=0A= >> --> This is the case where a floating (no fixed IP) laptop could ha= ve a=0A= >> certificate signed by a site local CA.=0A= >> 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s).= =0A= >> In this case, the client must use TLS so that data is encrypted on = the wire,=0A= >> but does not need to have a certificate.=0A= >> --> The NFS server admin. "trusts" the client IP address enough tha= t they=0A= >> are willing to allow the client to mount based on that IP, bu= t wants the=0A= >> data to be encrypted on the wire.=0A= >> - Avoids the bother of generating certificates for the client= (s).=0A= >>=0A= >> A part of this (as discussed in the IETF draft) is to make this easy eno= ugh to=0A= >> use that it does get used. (sec=3Dkrb5p achieves both user authenticatio= n and=0A= >> data encryption on the wire, but does not get widely used, due to the ne= ed=0A= >> to run a KDC, etc).=0A= >>=0A= >> Comments on the above options is welcome, since this does need to be=0A= >> reviewed by users.=0A= >=0A= >Maybe I'm missing the option where the cert needs to be authenticated,=0A= >but matching against IP/dns name does not need to be done. Or is this=0A= >a case of #2. I'm just confused by the first point of #2 in that the=0A= >server admin is wiling to trust the IP address...=0A= Yes, that is #2. "trust the IP address" probably wasn't a good way to=0A= express it. I was simply trying to say "the NFS server admin. is willing to= =0A= use the client IP address to select rules via the exports(5) file".=0A= =0A= >I'd like to see where CN or other field is freeform/provided by exports=0A= >entry, and validated to gain access to those resources... i.e. it=0A= >doesn't matter what IP or DNS name the client is, it's based solely on=0A= >the certificate. This would allow roaming users.. This maybe be=0A= >addressed by #2 point 2, but it isn't clear in your description that=0A= >it isn't dns tied or something else...=0A= Yes, for #2 the daemon only validates the certificate (actually uses the op= enssl=0A= default verification library function). It does not filter the certificate'= s CN or=0A= other fields in any way. (It does have the implication that all the NFS cli= ents=0A= could use the same certificate. I'm not sure that would be a good plan, sin= ce=0A= revoking the certificate would revoke it for all clients and having it on N= clients=0A= would increase the risk of it being compromised, but ...)=0A= --> The only way I can see that the server can enforce each client to use a= =0A= separate certificate for each client is by using #1.=0A= =0A= I had originally planned on some "secret" in the certificate (like a CN nam= e=0A= that satisfies some regular expression or ???) but others convinced me that= =0A= that wouldn't provide anything beyond knowing that the certificate was=0A= signed by the appropriate CA, so I have not implemented anything.=0A= =0A= >As the CA admin, they control what is valid/gets signed in the CN or=0A= >other fields, so this is safe to do... If you can't trust your CA to=0A= >sign only valid (to your policy) certs, then you shouldn't be using=0A= >that CA..=0A= Yes, that is my thinking for #2, as suggested by others.=0A= (For cases like using LetsEncrypt, my impression, which could be wrong, is= =0A= that anyone with a well known DNS name can get a certificate. As such,=0A= without using #1, those certificates seem meaningless to the NFS server to= me?)=0A= =0A= I, personally, don't think many NFS admins. will want #1, but if they happe= n=0A= to have NFS clients with well known DNS addresses, they can enable this che= ck.=0A= I think it is also a required capability according to the draft that will b= ecome=0A= an RFC at some point. (At some point I need to re-read the draft to try and= =0A= make sure I am playing by the rules. When I first read it, I thought that s= ite=0A= local CAs were not allowed, but the author clarified that site local CAs ar= e=0A= meant to be allowed.)=0A= =0A= Thanks for the comments, rick=0A= =0A= --=0A= John-Mark Gurney Voice: +1 415 225 5579=0A= =0A= "All that I will do, has been done, All that I have, has not."=0A= From owner-freebsd-current@freebsd.org Thu Mar 26 00:42:10 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 015872698D3 for ; Thu, 26 Mar 2020 00:42:10 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48nmQg3nN5z3DPZ for ; Thu, 26 Mar 2020 00:42:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 02Q0fs9T014890 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Mar 2020 17:41:54 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 02Q0fsLt014889; Wed, 25 Mar 2020 17:41:54 -0700 (PDT) (envelope-from jmg) Date: Wed, 25 Mar 2020 17:41:54 -0700 From: John-Mark Gurney To: Rick Macklem Cc: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <20200326004154.GT4213@funkthat.com> Mail-Followup-To: Rick Macklem , Alexander Leidinger , "freebsd-current@FreeBSD.org" References: <20200325231005.GQ4213@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Wed, 25 Mar 2020 17:41:54 -0700 (PDT) X-Rspamd-Queue-Id: 48nmQg3nN5z3DPZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.87 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.39)[ip: (-1.00), ipnet: 208.87.216.0/21(-0.50), asn: 32354(-0.40), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.80)[-0.796,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.882,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 00:42:10 -0000 Rick Macklem wrote this message on Wed, Mar 25, 2020 at 23:50 +0000: > John-Mark Gurney wrote: > >Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +0000: > >> Alexander Leidinger wrote: > >> John-Mark Gurney wrote: > >> >>Rick Macklem wrote: > >> >>> to be the best solution. The server can verify that the certificate > >> >>> was issued by > >> >>> the local CA. Unfortunately, if the client is compromised and the > >> >>> certificate is copied > >> >>> to another client, that client would gain access. > >> >> > >> >> This is why CRLs/OSCP is necessary, but there isn't anything you can do > >> >> to prevent that. This is both a better situation than what we have > >> >> today (no auth/confidentiality), and if you tie the cert to an IP, it's > >> >> of limited use, and better than today... > >> > > >> >There are multiple ways to handle that: > >> >  - First of all, you can just validate based upon "cert is signed by > >> >trusted CA". > >> >  - Then you can require that the CN matches the hostname and the > >> >reverse lookup matches. > >> >  - Or (similar to browsers today) you can ignore the CN and require > >> >that the hostnames of the client matches one of the subject > >> >alternative name (SAN) entries (requires reverse DNS lookup to work > >> >and match). > >> At this point, I have three variants in the code (strictest to less strict): > >> 1 - A "-h" command line option on the server handshake daemon (called rpctlssd). > >> This requires that all clients have > >> certificates that validate and have the FQDN acquired via reverse DNS of > >> the IP address of the client for the TCP connection (getnameinfo(NI_NAMEREQD)) > >> in either the subjectAltName or CommonName. (I call X509_check_host() > >> and this is what I understand it checks.) > >> --> This case implies that the NFS server admin. does not "trust" the > >> client's IP address enough to apply exports(5) line(s)to it to decide to > >> allow the client to do an NFS mount. > >> (An NFS server *might* be willing to allow client(s) to mount via any IP address > >> for the #2 case below and not use this option.) > >> 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indicate > >> if the client provided a certificate and whether or not it verified. > >> Then the "-tlscert" option on the appropriate exports(5) line(s) > >> indicates that the client must have provided a certificate that verified. > >> --> For this case (and #3), the server admin. is willing to "trust" the client's > >> IP address enough to apply exports(5) rules to it. > >> --> This is the case where a floating (no fixed IP) laptop could have a > >> certificate signed by a site local CA. > >> 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s). > >> In this case, the client must use TLS so that data is encrypted on the wire, > >> but does not need to have a certificate. > >> --> The NFS server admin. "trusts" the client IP address enough that they > >> are willing to allow the client to mount based on that IP, but wants the > >> data to be encrypted on the wire. > >> - Avoids the bother of generating certificates for the client(s). > >> > >> A part of this (as discussed in the IETF draft) is to make this easy enough to > >> use that it does get used. (sec=krb5p achieves both user authentication and > >> data encryption on the wire, but does not get widely used, due to the need > >> to run a KDC, etc). > >> > >> Comments on the above options is welcome, since this does need to be > >> reviewed by users. > > > >Maybe I'm missing the option where the cert needs to be authenticated, > >but matching against IP/dns name does not need to be done. Or is this > >a case of #2. I'm just confused by the first point of #2 in that the > >server admin is wiling to trust the IP address... > Yes, that is #2. "trust the IP address" probably wasn't a good way to > express it. I was simply trying to say "the NFS server admin. is willing to > use the client IP address to select rules via the exports(5) file". > > >I'd like to see where CN or other field is freeform/provided by exports > >entry, and validated to gain access to those resources... i.e. it > >doesn't matter what IP or DNS name the client is, it's based solely on > >the certificate. This would allow roaming users.. This maybe be > >addressed by #2 point 2, but it isn't clear in your description that > >it isn't dns tied or something else... > Yes, for #2 the daemon only validates the certificate (actually uses the openssl > default verification library function). It does not filter the certificate's CN or > other fields in any way. (It does have the implication that all the NFS clients > could use the same certificate. I'm not sure that would be a good plan, since > revoking the certificate would revoke it for all clients and having it on N clients > would increase the risk of it being compromised, but ...) > --> The only way I can see that the server can enforce each client to use a > separate certificate for each client is by using #1. > > I had originally planned on some "secret" in the certificate (like a CN name > that satisfies some regular expression or ???) but others convinced me that > that wouldn't provide anything beyond knowing that the certificate was > signed by the appropriate CA, so I have not implemented anything. Yeah, having a "secret" in the CN doesn't make sense, but what does make sense is allowing the exports line to specify what the CN should contain to be authenticated... Say as a corp, you issue personal certificates to everyone. This is because you require everyone to sign and/or encrypt their email w/ S/MIME. Each cert includes the email address of that person, so you could simply do something like: /home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com And anyone who has the certificate w/ alice@example.com that was signed by the public key in /etc/company.pem would be granted access to the export /home/alice. If it allowed ANY cert signed by the CA specified, then that introduces an authentication problem, as now if Malory is a coworker of Alice could also access Alice's home directory... IMO, this is one auth feature that MUST be supported... Now that I reread your comments, it sounds like any certificate would be allowed in #2 as long as it is valid, and that would only be marginally better than verification by IP, and in some ways worse, in that now any user could pretend to be any other user, or you have to do something crazy like have a CA per user. I'm wonder if your use of the term secret was the problem, and not the idea... Anything that goes in the client cert is by definition public... TLS prior to 1.3 sends the client cert in clear text... But keying based upon the contents of the cert is fine, as that's the point of what a cert is.. It's trusting the CA to say that the CN and other fields in the cert corresponds to this user, and you can use parts of the cert, like the CN to decide which user the public key in the cert corresponds to. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Thu Mar 26 14:33:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 38AD72A181E for ; Thu, 26 Mar 2020 14:33:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48p6t44y2Kz41MX for ; Thu, 26 Mar 2020 14:33:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HcIBzFQ4+lzAWWlFlHKzynZmLT2/OlreANIYFFhSz2YWv8Yhk7JuL7YubDUuo4N9APOFHvB+K85SOyXzzMPJR+Ad06yxbeVgvQ71nztoTH7wqusSczpZGUNpbxpp8qxlGEnF0Zc6JQTwLO2/tLEZOM8cRCXgJ8e1HeqK/GCPEpA2wukGl4zHdmmlJs764vFLva7gDJWdscu9TlOKIXv5YiaAcS17AuKye/SegEW37E71OrZ6rmg7O8X6HRtWlKtoP636CUp9ohLDenTeJ6lUMX91EtWJ2fhJB1w3CPjRu57RVD2oiszt8X8QoezqcrRFM6Zwkgt9gvECSRATbiT0tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7SiNmBwqmmP6U/9aVBrOSKnaOYLf3MPaTGcia8U/8g0=; b=aidyeRtbvEUxnwAKDQEKBNPdYJ9uuEFjmJOuDnCR+rBdzjXx2MmkstLYIR/21UWijUnJ2hhIGpxtj5M/XsCVTY+e/ie5/kbHEeVrGJWhd5Ab8rkSgXeodyYHM9w+hroUClDaTy7m7Kbkhgy0ng1YNqK9W7hgUUMIl2Ve5XNeOBOOQdlatTvpnO6CBfGVuCNrHgK7krQHSOwuq57dVOi95YrtZc68MU8q5NVYI0wk/BDpdxV2XcOgo848hcOSf5lYZbSPa0QTnrXU3nZclvZOHKxp12RQGLOzRN1kbbNlpuuxPJy63uA1691gvGIEmBPUOZnG7Aq0cWOy1/gk2YJd3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3940.CANPRD01.PROD.OUTLOOK.COM (52.132.88.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Thu, 26 Mar 2020 14:33:19 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f%5]) with mapi id 15.20.2835.023; Thu, 26 Mar 2020 14:33:12 +0000 From: Rick Macklem To: John-Mark Gurney CC: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Thread-Topic: TLS certificates for NFS-over-TLS floating client Thread-Index: AQHWAWnI+UIiEJS9mke8ubtYdFBhy6hZ8jaAgAAC+s2AABatAIAA3gv9 Date: Thu, 26 Mar 2020 14:33:12 +0000 Message-ID: References: <20200325231005.GQ4213@funkthat.com> , <20200326004154.GT4213@funkthat.com> In-Reply-To: <20200326004154.GT4213@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b50e2cc-8b93-40ba-2100-08d7d1929d07 x-ms-traffictypediagnostic: QB1PR01MB3940: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39850400004)(396003)(376002)(366004)(346002)(6506007)(8676002)(5660300002)(55016002)(52536014)(9686003)(33656002)(2906002)(81156014)(786003)(7696005)(316002)(6916009)(186003)(71200400001)(478600001)(86362001)(81166006)(8936002)(76116006)(66946007)(64756008)(66476007)(66446008)(66556008)(54906003)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3940; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UYRWUQBPzMPpbFwFj+0NVGz6gRNzRu3/ULAcKtJtgUcxCSXk1JoYK2Jjh9ovYMtpGYPhfjQP7dXwOBekt/qmgIMjYhBkQWxeXGJ5h+9XOoIl9LwKAY0O29pBzRn+w5OHCaD8MU3mhLpNOpA4WjwuyogEeLxUnDyjK9Xve74UrD56LNTOb8RrrEKmkk5/kVrF5WemHiECxyqbQM1pjJsYtQ2BQc2i/krNApfndIyZNIdZovkoEy4XtgE82ktz5/hYdugUeDiXI8sB5HEnPDMEJuUU5nNtZ3OeAPJmFkx/WVI3/s/psprURa8X0smbFsynIeFV3Mxoq+EGabVa+wGPaRpZNll9ZY2cme7ziyZ2/TgXhUSY0oPClgYAO8B8zWGVvYFQkwhvtvOKEj58Qe4pgPyNRO6dfsQ/pBmu6oDzbXA2oRYxKuvS2G3bWdB3WSJ1 x-ms-exchange-antispam-messagedata: 8zZTycvRKHobnRMuH9Y7ZMQxZCSKtcrDLmz04mWo7YzJ1FM8vDR+yAZ9i3MDrvYZ5mRNjtBRNxp7SOQ6TwtgefPrqw2jB0mWyzcokZI+AVbpw+l1EC9KtI81qeVxPoM0BCg6anxjMML8LeMfwXT9pGFd2UThSWcI06L2yijqUKE/xt6nqWStJCTFL3+AU1ebXvRB0frMAmVacaT1SpXCFw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 4b50e2cc-8b93-40ba-2100-08d7d1929d07 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2020 14:33:12.5265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TGNUJVbq4f+QKktugZ9AiAjviS79I8g2no3z8SixFX/g26qgQH1KfM6uBi3/MHnySx1fQva/6ayeF5oSxeZbdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3940 X-Rspamd-Queue-Id: 48p6t44y2Kz41MX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::631 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.74 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.44)[ipnet: 2a01:111:f000::/36(-4.03), asn: 8075(-3.13), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 14:33:50 -0000 John-Mark Gurney wrote:=0A= [lots of stuff snipped]=0A= >Rick Macklem wrote:=0A= >> I had originally planned on some "secret" in the certificate (like a CN = name=0A= >> that satisfies some regular expression or ???) but others convinced me t= hat=0A= >> that wouldn't provide anything beyond knowing that the certificate was= =0A= >> signed by the appropriate CA, so I have not implemented anything.=0A= >=0A= >Yeah, having a "secret" in the CN doesn't make sense, but what does make= =0A= >sense is allowing the exports line to specify what the CN should contain= =0A= >to be authenticated...=0A= >=0A= >Say as a corp, you issue personal certificates to everyone. This is=0A= >because you require everyone to sign and/or encrypt their email w/=0A= >S/MIME. Each cert includes the email address of that person, so you=0A= >could simply do something like:=0A= >/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com=0A= >=0A= >And anyone who has the certificate w/ alice@example.com that was signed=0A= >by the public key in /etc/company.pem would be granted access to the=0A= >export /home/alice.=0A= >=0A= >If it allowed ANY cert signed by the CA specified, then that introduces=0A= >an authentication problem, as now if Malory is a coworker of Alice=0A= >could also access Alice's home directory...=0A= >=0A= >IMO, this is one auth feature that MUST be supported...=0A= The draft does not address user authentication, only machine authentication= .=0A= --> ie. The certificate is used to decide if a system can do a mount.=0A= Users are still identified via user credentials in the RPC message he= ader.=0A= For AUTH_SYS, that still means .=0A= Otherwise, you need to use Kerberos (sec=3Dkrb5[ip]).=0A= You could use "tls,sec=3Dkrb5" for a mount, but the only advantage th= at=0A= might have over "sec=3Dkrb5p" is performance, if there is hardware as= sist=0A= for TLS or something like that.=0A= =0A= >Now that I reread your comments, it sounds like any certificate would be= =0A= >allowed in #2 as long as it is valid, and that would only be marginally=0A= >better than verification by IP, and in some ways worse, in that now any=0A= >user could pretend to be any other user, or you have to do something=0A= >crazy like have a CA per user.=0A= The case where I see #2 is useful is where this discussion started some wee= ks ago.=0A= The example I started with was:=0A= /home -tls -network 192.168.1.0 -mask 255.255.255.0=0A= /home -tlscert=0A= =0A= This says that machines on the local lan can mount and do not need to have= =0A= certificates, but must use TLS so data is encrypted on the wire.=0A= Mounts from anywhere else (presumably laptops) are allowed so long as they = have a=0A= certificate signed by me (as in the site local CA).=0A= I trust these machines enough that I am willing to allow them to use AUTH_S= YS,=0A= which is what 99.9...% of NFS mounts do now.=0A= (So, I'd agree that the site local certificate is not a lot better than IP = address=0A= for client machine identity, just that it is an alternative that can be us= eful.=0A= Without TLS, a line like "/home" allows anyone to mount /home from anywher= e=0A= and I think you'd agree that few NFS admins. will want to do that. I'm ass= uming=0A= no external firewall for this example.)=0A= =0A= Now, your suggestion of identifying a user via the CN and then having the= =0A= server do all RPCs for the mount as that user is an interesting one.=0A= My concern w.r.t. implementing it would be interoperability.=0A= Put another way, if other servers such as Linux, Netapp,... don't adopt it= =0A= (and they won't until there is a draft/RFC specifying it), it would be=0A= FreeBSD server specific and I'd like to avoid that.=0A= There was some discussion w.r.t. user authentication via certificates=0A= during development of the draft, but they decided to defer that work for=0A= now, so they could get something in place for machine authentication first.= =0A= (If I understood the discussion on nfsv4@ietf.org.)=0A= =0A= rick=0A= =0A= >I'm wonder if your use of the term secret was the problem, and not the=0A= >idea... Anything that goes in the client cert is by definition public...= =0A= >TLS prior to 1.3 sends the client cert in clear text... But keying=0A= >based upon the contents of the cert is fine, as that's the point of=0A= >what a cert is.. It's trusting the CA to say that the CN and other=0A= >fields in the cert corresponds to this user, and you can use parts of=0A= >the cert, like the CN to decide which user the public key in the cert=0A= >corresponds to.=0A= =0A= --=0A= John-Mark Gurney Voice: +1 415 225 5579=0A= =0A= "All that I will do, has been done, All that I have, has not."=0A= From owner-freebsd-current@freebsd.org Thu Mar 26 14:59:51 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D1D52A2107 for ; Thu, 26 Mar 2020 14:59:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::615]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48p7S65hcNz4B58 for ; Thu, 26 Mar 2020 14:59:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L5CRIg1K9ZJoPENUojJgXkrRr47nBb/cWVeq5eZDg6AHss9tUOJMLkljaixEtCnq06KjBkDCn206NS5LGX761fMRrXaMtsu7OPYJp6eJi34K1894x4bWnQZUTBrJlnHrnPpJ1Slahyu39rZXnAGR+hcbFdn8vqu7CTTXdvqhaT8i3ii8cX3DyOD04zG9qshSgStHNXY8q9VUbmCNHq/MBIssWHCzrY84uFomGhTT3u4157No0nHYvgbfWcJe3Slxg0em5mQ7BvQGroYN0BifQhEq3GzutahR5OnEc8DeueNDxewdo7b6dWHw7cgwJLWth19Ag+RXAih2jPBbkAS7ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WHr9/5q9MecWUlYDByf5hORcPrdQdpARlFlIhZJ/ldA=; b=mA6Of/A6zW1AvztYxGj2aOUhvkHo/b0Pl2O4fn3t9xa1i7fSkdqMblORrbTajr1qOupfru4V6nHD8ziS0/r6PONj0XaIJgXIuDt3+9Dw1Vof9nzA/YczvYTrSnzX/AIwRNzJMNdaZFHgJnGuf9Oo6FT97uHYXV/go7NKVu2TM+Y4zLZI3z7e9lYm6XfjPdF2WFvyeYq4/hC7OLjK/0hdt/9wRztK9c679zoM0Ky6a13j3odOgPx/ibnvZ25G+chrzIiebthD7G5HcS9k6FB6ybmDHE095Mh73ifUn3QA/ryuN+qXUAPCUppSZzT7EFCI/2nVe745OGiGLFobb77rug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3539.CANPRD01.PROD.OUTLOOK.COM (52.132.89.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Thu, 26 Mar 2020 14:59:23 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f%5]) with mapi id 15.20.2835.023; Thu, 26 Mar 2020 14:59:23 +0000 From: Rick Macklem To: John-Mark Gurney CC: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Thread-Topic: TLS certificates for NFS-over-TLS floating client Thread-Index: AQHWAWnI+UIiEJS9mke8ubtYdFBhy6hZ8jaAgAAC+s2AABatAIAA3gv9gAANKB0= Date: Thu, 26 Mar 2020 14:59:23 +0000 Message-ID: References: <20200325231005.GQ4213@funkthat.com> , <20200326004154.GT4213@funkthat.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8e3e5248-fd07-487e-fd16-08d7d1964547 x-ms-traffictypediagnostic: QB1PR01MB3539: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(136003)(366004)(53546011)(6506007)(7696005)(66946007)(66556008)(64756008)(66446008)(316002)(478600001)(786003)(86362001)(66476007)(52536014)(5660300002)(966005)(76116006)(2906002)(54906003)(55016002)(9686003)(33656002)(71200400001)(8936002)(186003)(81156014)(4326008)(8676002)(2940100002)(81166006)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3539; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DJujv0Ay7n+Y1RlOTKQls5i4h1uF5eahnrrHKTm5GgnQM+2DKloUI3Va61JboAHyRAh9a9G/a2DsZUVTEBf2ckQkmpxDGNnLQMfIKfPXFMQXF9cZDzJPEEzLjq7HMp8YcsPAFVuKJRiW9liT9ghZLtjJri59/THUVXg6HhlXlg8poUpdvlDCvBWiok5qWK65I1aNbisCE6iiBFYmDBShMVuHIeKfuYFSzwcKoY3BLZawI2Gl6Ugez8kU2rw1C4Of4lOfSBcHC3Q61Q9Z8gBCCUAdXkx7yrTmOgMtC+GfeqhK0zFQDqLsH9neBchU9L/fl4AGLvTjazmnsjA3SdCiTMvKl21d5g2Z7gPV+sIX8MyBcWyZ69NekiKBEiAP/aOa/yDbYwHhK4t3jyJ35P8anUxmsAKZfkThotqmL574uhMtNvuyWRPp/qjjmTtH7rQaWmwnj4GQ1fGSH33xV49ROSRMFuwpFrVlj+nvnc6BROlUcxMs15t0FzfUShQzOWs5+jo3ipHthFCSNkntNb65oA== x-ms-exchange-antispam-messagedata: btFADF+Y1rgKz1bqx1aObjfSKWYPPkkulsxMia8KcUGXYExXkX7rhPUtCDRZAThZZctmx9KwqMZkqDeMiciCMfiI+XHKeYRqJM2QP8y4bovqVDDI7ltSMvSBUkHoHxfvfwL3YfZ7FI0qHtrqNxXQL2hmDEXsH/mZPajlQSOg80zFCsTmZ+CBSC9krWyoTUo1QCX94T/Xh8b8BxBKQzIA/A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 8e3e5248-fd07-487e-fd16-08d7d1964547 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2020 14:59:23.3150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hn32F78Vpsb0mMt1AD85to7aV7yrusZDeURGYUv7wMWvjcvXJn//GLZGBHbE0htcvUL6KuBVrxErbo9mZUbPlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3539 X-Rspamd-Queue-Id: 48p7S65hcNz4B58 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::615 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.74 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.44)[ipnet: 2a01:111:f000::/36(-4.03), asn: 8075(-3.13), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 14:59:51 -0000 Sorry about the top post, but I thought of a few things to add to my last post to this thread... 1 - I agree that for systems like laptops, the line between machine and user authentication is fuzzy. 2 - I do like your idea of having an exports(5) option that specifies a CN that identifies a user and then does all RPCs as that user. I'm not sure if an issuer needs to be specified (or even can be speci= fied), since the CAfile argument to the rpctlssd daemon determines if a cert= ificate from a particular CA will verify and the verification must happen bef= ore the exports(5) export options can be applied. (Basically, certificate ver= ification happens via a NULL RPC that does a STARTTLS when a TCP connection to the server is first established.) 3 - I'll post to nfsv4@ietf.org to see what others think of this, since it = would not require any changes to the draft/RFC. 4 - Although it does require a revision to the export_args structure, I thi= nk it is worth doing even if others don't implement it. Again, thanks for your comments, rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Rick Macklem Sent: Thursday, March 26, 2020 10:33 AM To: John-Mark Gurney Cc: Alexander Leidinger; freebsd-current@FreeBSD.org Subject: Re: TLS certificates for NFS-over-TLS floating client John-Mark Gurney wrote: [lots of stuff snipped] >Rick Macklem wrote: >> I had originally planned on some "secret" in the certificate (like a CN = name >> that satisfies some regular expression or ???) but others convinced me t= hat >> that wouldn't provide anything beyond knowing that the certificate was >> signed by the appropriate CA, so I have not implemented anything. > >Yeah, having a "secret" in the CN doesn't make sense, but what does make >sense is allowing the exports line to specify what the CN should contain >to be authenticated... > >Say as a corp, you issue personal certificates to everyone. This is >because you require everyone to sign and/or encrypt their email w/ >S/MIME. Each cert includes the email address of that person, so you >could simply do something like: >/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com > >And anyone who has the certificate w/ alice@example.com that was signed >by the public key in /etc/company.pem would be granted access to the >export /home/alice. > >If it allowed ANY cert signed by the CA specified, then that introduces >an authentication problem, as now if Malory is a coworker of Alice >could also access Alice's home directory... > >IMO, this is one auth feature that MUST be supported... The draft does not address user authentication, only machine authentication= . --> ie. The certificate is used to decide if a system can do a mount. Users are still identified via user credentials in the RPC message he= ader. For AUTH_SYS, that still means . Otherwise, you need to use Kerberos (sec=3Dkrb5[ip]). You could use "tls,sec=3Dkrb5" for a mount, but the only advantage th= at might have over "sec=3Dkrb5p" is performance, if there is hardware as= sist for TLS or something like that. >Now that I reread your comments, it sounds like any certificate would be >allowed in #2 as long as it is valid, and that would only be marginally >better than verification by IP, and in some ways worse, in that now any >user could pretend to be any other user, or you have to do something >crazy like have a CA per user. The case where I see #2 is useful is where this discussion started some wee= ks ago. The example I started with was: /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert This says that machines on the local lan can mount and do not need to have certificates, but must use TLS so data is encrypted on the wire. Mounts from anywhere else (presumably laptops) are allowed so long as they = have a certificate signed by me (as in the site local CA). I trust these machines enough that I am willing to allow them to use AUTH_S= YS, which is what 99.9...% of NFS mounts do now. (So, I'd agree that the site local certificate is not a lot better than IP = address for client machine identity, just that it is an alternative that can be us= eful. Without TLS, a line like "/home" allows anyone to mount /home from anywher= e and I think you'd agree that few NFS admins. will want to do that. I'm ass= uming no external firewall for this example.) Now, your suggestion of identifying a user via the CN and then having the server do all RPCs for the mount as that user is an interesting one. My concern w.r.t. implementing it would be interoperability. Put another way, if other servers such as Linux, Netapp,... don't adopt it (and they won't until there is a draft/RFC specifying it), it would be FreeBSD server specific and I'd like to avoid that. There was some discussion w.r.t. user authentication via certificates during development of the draft, but they decided to defer that work for now, so they could get something in place for machine authentication first. (If I understood the discussion on nfsv4@ietf.org.) rick >I'm wonder if your use of the term secret was the problem, and not the >idea... Anything that goes in the client cert is by definition public... >TLS prior to 1.3 sends the client cert in clear text... But keying >based upon the contents of the cert is fine, as that's the point of >what a cert is.. It's trusting the CA to say that the CN and other >fields in the cert corresponds to this user, and you can use parts of >the cert, like the CN to decide which user the public key in the cert >corresponds to. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ 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-current@freebsd.org Fri Mar 27 07:49:05 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B0D4A26D33A for ; Fri, 27 Mar 2020 07:49:05 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48pYrp4W6vz4Mdc for ; Fri, 27 Mar 2020 07:48:58 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: by mailman.nyi.freebsd.org (Postfix) id 5ABB526D338; Fri, 27 Mar 2020 07:48:50 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5410926D336; Fri, 27 Mar 2020 07:48:50 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward103o.mail.yandex.net (forward103o.mail.yandex.net [37.140.190.177]) (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 48pYrB1GLKz4MTh; Fri, 27 Mar 2020 07:48:24 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback20o.mail.yandex.net (mxback20o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::71]) by forward103o.mail.yandex.net (Yandex) with ESMTP id 77ACF5F8017A; Fri, 27 Mar 2020 10:48:14 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback20o.mail.yandex.net (mxback/Yandex) with ESMTP id lqfV92whFj-mD6GbFKv; Fri, 27 Mar 2020 10:48:13 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1585295293; bh=7KDc+mlqaxPiIXhVAu1rq5V1k7I9L0IXpdzKTg2gg/Q=; h=Message-Id:Date:Subject:To:From; b=B8Dn/07UmJmzRB0gqrvatkHjqgDMcXJJZWqG935HqA4EmMKW4DZBgezg6ECPC6TPU S71B8e0nHiJ83z7oC8OelBPhTMOBhktPVc5XHm0IbA4KJGtS61fb0g2O1zYU2RC0ql ojDZ34uWyMecL531X8pxMe7GH6fNoV+AiOvrkAgw= Received: by myt6-4218ece6190d.qloud-c.yandex.net with HTTP; Fri, 27 Mar 2020 10:48:13 +0300 From: Alexander V. Chernikov To: "current@FreeBSD.org" , net Subject: CFT: Next-hop objects and scalable multipath routing MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 27 Mar 2020 07:48:13 +0000 Message-Id: <1607511585294876@vla1-b2d94eaf2344.qloud-c.yandex.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Rspamd-Queue-Id: 48pYrB1GLKz4MTh X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=B8Dn/07U; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 37.140.190.177 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-6.30 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:37.140.128.0/18]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ipfw.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-3.70)[ip: (-9.79), ipnet: 37.140.128.0/18(-4.89), asn: 13238(-3.85), country: RU(0.01)]; DKIM_TRACE(0.00)[ipfw.ru:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_LOW(-0.10)[177.190.140.37.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13238, ipnet:37.140.128.0/18, country:RU]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 07:49:05 -0000 I would like to introduce an implementation of scalable multipath routing. Previous implementation (RADIX_MPATH) focused on a simpler case like having 2 defaults, with performance falling linearly proportional to the number of paths. That implementation was also tightly coupled lookup algorithm details with the routing details, making it hard to hack both. The proposed one allows O(1) lookup and is more cache-efficient with the large amount of routes. Furthermore, multipath functionality is based on the number of internal changes, modernizing the old routing code. Most of the changes revolves around introducing the concept of _nexthops_. Nexthops are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. Nexthops are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Multipath implementation adds _nexthop groups_ which are basically collection of nexthops weights, compiled into an array, to allow direct nexthop selection. More detailed technical description is available at [1]. Any comments/suggestions are welcome! Presentation of the similar functionality in the other OS: [2] Next-hop objects support was implemented in FRR in 2019 [3]. Next steps: As these changes decouples routing code details from algorithm details and abstracts callers, it is much easier to introduce a number of other relevant features. The most important proposed features are: nexthop-based route installation and custom per-address-family route lookup algorithms. The former targets improving convergence times for the large-fib boxes, while the latter may improve dataplane performance, especially for IPv6. How to test: fetch the patch from https://reviews.freebsd.org/D24141 rebuild kernel with ROUTE_MPATH option (already added to amd64 GENERIC) Optionally, rebuild world to get netstat nexthops/multipath groups reporting. Use route(8) to add multiple routes for the same destination, optionally specifying weight. Example: add 2:1 load balancing for the default route: route add -net default 192.168.53.1 -weight 100 route add -net default 192.168.53.2 -weight 200 netstat -4rnW .. Destination Gateway Flags Nhop# Mtu Netif Expire default 192.168.53.1 UGS 4 1500 em0 default 192.168.53.2 UGS 5 1500 em0 netstat -4onW Nexthop data Idx Type IFA Gateway Flags Use Mtu Netif Addrif Refcnt Prepend .. 4 v4/gw 192.168.53.128 192.168.53.1 GS 0 1500 em0 2 5 v4/gw 192.168.53.128 192.168.53.2 GS 0 1500 em0 1 Nexthop groups data MpIdx NHIdx Weigh Slots Gateway Netif Refcnt 1 ---- ---- ---- ---- ---- 1 4 100 1 192.168.53.1 em0 5 200 2 192.168.53.2 em0 [1] https://reviews.freebsd.org/D24141 [2] https://linuxplumbersconf.org/event/4/contributions/434/attachments/251/436/nexthop-objects-talk.pdf [3] https://github.com/FRRouting/frr/commit/d9f5b2f50f53d625986dbd47cd12778c9f841f0c From owner-freebsd-current@freebsd.org Fri Mar 27 13:40:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE79F27617E for ; Fri, 27 Mar 2020 13:40:50 +0000 (UTC) (envelope-from ruslanngaripov@gmail.com) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48pjfV3D3wz4bl1 for ; Fri, 27 Mar 2020 13:40:32 +0000 (UTC) (envelope-from ruslanngaripov@gmail.com) Received: by mail-lj1-x230.google.com with SMTP id q19so10176275ljp.9 for ; Fri, 27 Mar 2020 06:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=sYivrsQTr+WDD73nJ7bvrgm3gAK/n0ls/5sfXMdfCnk=; b=kfBmB7kw+pUHbQDqzvHy4SDhue3a1pwbOzDCBfl+0qaNysd2fSq7bQw4jciwLIWLaZ uA4dkv3Pew+Swltdyz5aywJ2lFKwy/cp+1t/1x9++cXKgplqO2R/T1YUn+2bnkO8r8Mc vTmwHFBFzOqo9lA5b8OqGCsqJrnc0yJLMkvhK78SsmBmXag3ogxmGxNx/Hc8+dGZyYTF uWUxZVXam29rEsEovvAxVTC9nvFZvk1noQ0tXOeXd+uRoI/dGjVq6IaB/BU6WxC97w/P SdYIFwp1Qwoj3/LjUUYngvhVOkcw8LSs+tkPU9ry28QdyfFQZm9vtgwA4IwTE6hnT1Ly wPUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=sYivrsQTr+WDD73nJ7bvrgm3gAK/n0ls/5sfXMdfCnk=; b=dqlJa1MTZ69bFkAVqlP4vpz9r6B24N8kFl15bi3DPAFJaequM96C920jh+UIsJDAJC En6pep7EfMJ6l3EIwJDvBBGL/l2AS7Eb95b4Lw5O6EvUYhCzuqM+OscXF8PX3RqxPBqL TmnuJCdCyEuJ/o3m/YYaCLL9CN3f2EczMsOD5YphppnIBVQPASQer78fa4cZ022wmzis 36QxeRtBqLGaOirqNaHEBfz0sA6WwGCI0INWv5vzTO7XC83x8cAccOTWJ419pOMzp3jw I7SUAaxTwrVdJguNspdF245h/xUtUWjQJ22u5Obyp3S3NUIJ7PPLzzgk+NNmLXMF9fuw +CHQ== X-Gm-Message-State: AGi0PuaZB3GQylA56o5Cz4E0TPv250Dl8USKFPwiQd/aXcBuDobF660t 6uu+pWkC080BIrZUHUC9CdIyje7WMcA= X-Google-Smtp-Source: APiQypIxQfjwF4vHxB62FjW2uv7/O9Z3Besa3WAJ/+P9xogiLs0NIKdMpMFpBoUDviHjrlHuMrbNBA== X-Received: by 2002:a2e:3a16:: with SMTP id h22mr1647716lja.81.1585316422756; Fri, 27 Mar 2020 06:40:22 -0700 (PDT) Received: from [192.168.1.3] ([46.48.69.183]) by smtp.gmail.com with ESMTPSA id q4sm3386152lfp.18.2020.03.27.06.40.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Mar 2020 06:40:22 -0700 (PDT) To: freebsd-current@freebsd.org From: Ruslan Garipov Subject: buildworld failed (usr.bin/kyua) Message-ID: <98e2187e-ca29-1cc0-46e2-f684c828274d@gmail.com> Date: Fri, 27 Mar 2020 18:40:18 +0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48pjfV3D3wz4bl1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=kfBmB7kw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ruslanngaripov@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=ruslanngaripov@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.18), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.47), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[0.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 13:40:51 -0000 I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351. End of the build log: $ su root -c "make -j16 buildworld" ... ld: error: unable to find library -lkyua_cli_pie ld: error: unable to find library -lkyua_drivers_pie ld: error: unable to find library -lkyua_model_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_engine_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_utils_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_store_pie ld: error: unable to find library -lkyua_model_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_utils_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_engine_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_utils_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_model_pie ld: error: unable to find library -llutok_pie ld: error: unable to find library -lkyua_store_pie ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors) c++: error: linker command failed with exit code 1 (use -v to see invocation) --- all_subdir_lib --- --- cpuset_getdomain.po --- --- all_subdir_usr.bin --- *** [kyua] Error code 1 make[4]: stopped in /usr/src/usr.bin/kyua 1 error make[4]: stopped in /usr/src/usr.bin/kyua *** [all_subdir_usr.bin/kyua] Error code 2 ... May be it's related to r359260[1]. Therefore, here is my TEST-settings: $ fgrep TEST /etc/src.conf WITHOUT_GOOGLETEST= WITHOUT_TESTS= WITH_TESTS_SUPPORT= Also what has confused me: it's a virtual machine which failed to build. A physical one built userland and kernel just fine. Both the physical and virtual machines have almost the same (differ only by CPU "selection" options) make.conf and src.conf and different kernel configurations. Both the machines were FreeBSD 13.0-CURRENT amd64 r359231. I've started to build on clean systems (no /usr/obj at all). Can anyone help me to resolve this issue? I apologize in advance if I will delay my further replies, due to world wide health situation. Thanks! [1] https://lists.freebsd.org/pipermail/svn-src-head/2020-March/134800.html From owner-freebsd-current@freebsd.org Fri Mar 27 16:43:54 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 168DB27A8A1 for ; Fri, 27 Mar 2020 16:43:54 +0000 (UTC) (envelope-from groenveld@acm.org) Received: from mail.groenveld.us (mail.groenveld.us [207.68.114.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48pnjn1SxGz3KgF for ; Fri, 27 Mar 2020 16:43:39 +0000 (UTC) (envelope-from groenveld@acm.org) Received: from mail.groenveld.us (localhost [127.0.0.1]) by mail.groenveld.us (8.14.4+Sun/8.14.4) with ESMTP id 02RGip68017715 for ; Fri, 27 Mar 2020 12:44:51 -0400 (EDT) Message-Id: <202003271644.02RGip68017715@groenveld.us> From: John D Groenveld X-uri: To: freebsd-current@freebsd.org Subject: Re: link_elf_obj: symbol bcmp undefined In-reply-to: Your message of "Mon, 16 Mar 2020 22:25:01 -0400." <202003170225.02H2P1eu012093@groenveld.us> References: <202003170225.02H2P1eu012093@groenveld.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17713.1585327491.1@mail.groenveld.us> Date: Fri, 27 Mar 2020 12:44:51 -0400 X-Rspamd-Queue-Id: 48pnjn1SxGz3KgF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 207.68.114.134 is neither permitted nor denied by domain of groenveld@acm.org) smtp.mailfrom=groenveld@acm.org X-Spamd-Result: default: False [-1.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.77)[-0.767,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.85)[-0.851,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[acm.org]; IP_SCORE(0.11)[asn: 701(0.59), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:207.68.96.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 16:43:54 -0000 I reproduced with current CURRENT and updated BigID 244962: $ sysctl -n kern.version FreeBSD 13.0-CURRENT #0 r359311: Thu Mar 26 04:34:44 UTC 2020 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC $ uname -U 1300085 Is the magic awk that the virtualbox port is using to generate a kernel module from userspace code broken? A clue stick gently or harshly applied to my noggin would be very much appreciated. John groenveld@acm.org From owner-freebsd-current@freebsd.org Fri Mar 27 20:07:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E292727FDE4 for ; Fri, 27 Mar 2020 20:07:27 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 48ptDl0pzCz48jj for ; Fri, 27 Mar 2020 20:07:18 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 460AB3C0199; Fri, 27 Mar 2020 20:07:08 +0000 (UTC) Date: Fri, 27 Mar 2020 20:07:08 +0000 From: Brooks Davis To: Ruslan Garipov Cc: freebsd-current@freebsd.org Subject: Re: buildworld failed (usr.bin/kyua) Message-ID: <20200327200708.GA12101@spindle.one-eyed-alien.net> References: <98e2187e-ca29-1cc0-46e2-f684c828274d@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <98e2187e-ca29-1cc0-46e2-f684c828274d@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 48ptDl0pzCz48jj X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-6.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-3.63)[ip: (-9.53), ipnet: 199.48.128.0/22(-4.75), asn: 36236(-3.82), country: US(-0.05)]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 20:07:28 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote: > I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351. >=20 > End of the build log: >=20 > $ su root -c "make -j16 buildworld" > ... > ld: error: unable to find library -lkyua_cli_pie > ld: error: unable to find library -lkyua_drivers_pie > ld: error: unable to find library -lkyua_model_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_engine_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_utils_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_store_pie > ld: error: unable to find library -lkyua_model_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_utils_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_engine_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_utils_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_model_pie > ld: error: unable to find library -llutok_pie > ld: error: unable to find library -lkyua_store_pie > ld: error: too many errors emitted, stopping now (use -error-limit=3D0 > to see all errors) > c++: error: linker command failed with exit code 1 (use -v to see > invocation) > --- all_subdir_lib --- > --- cpuset_getdomain.po --- > --- all_subdir_usr.bin --- > *** [kyua] Error code 1 >=20 > make[4]: stopped in /usr/src/usr.bin/kyua > 1 error >=20 > make[4]: stopped in /usr/src/usr.bin/kyua > *** [all_subdir_usr.bin/kyua] Error code 2 > ... >=20 > May be it's related to r359260[1]. Therefore, here is my TEST-settings: >=20 > $ fgrep TEST /etc/src.conf > WITHOUT_GOOGLETEST=3D > WITHOUT_TESTS=3D > WITH_TESTS_SUPPORT=3D >=20 > Also what has confused me: it's a virtual machine which failed to build. > A physical one built userland and kernel just fine. Both the physical > and virtual machines have almost the same (differ only by CPU > "selection" options) make.conf and src.conf and different kernel > configurations. Both the machines were FreeBSD 13.0-CURRENT amd64 > r359231. I've started to build on clean systems (no /usr/obj at all). >=20 > Can anyone help me to resolve this issue? I've replicated this issue and it goes back the the way WITH_TESTS_SUPPORT was implemented way back in r273449 This patch fixes WITHOUT_TESTS=3Dt WITH_TESTS_SUPPORT=3Dt for me. Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.inc1 (revision 359367) +++ Makefile.inc1 (working copy) @@ -1100,7 +1100,7 @@ @echo "--------------------------------------------------------------" ${_+_}cd ${.CURDIR}; \ ${WMAKE} -DNO_FSCHG MK_HTML=3Dno -DNO_LINT MK_MAN=3Dno \ - MK_PROFILE=3Dno MK_TESTS=3Dno MK_TESTS_SUPPORT=3D${MK_TESTS} libraries + MK_PROFILE=3Dno MK_TESTS=3Dno libraries everything: .PHONY @echo @echo "-------------------------------------------------------------- I've not committed it yet because I'm trying to figure out why this was needed. I simply don't see how there could be a race between lib/aft and libexec/aft as described. I suspect this may have been an error. -- Brooks --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJeflzrAAoJEKzQXbSebgfAiqkH/1YUJ3ZJT1UNtQmnMqkM5F3z zghRq+qqZmxHgbGmyV+SuxQb/uhb2ayuwG9eed2j596DCKHFXpyPl2iA9FQqRMoG 0qux+fdqE7ywL02u50iTgv6Z063FJo/uQPuWD/4Ix7uYdNLjTEnflLpC6sE0T7RG gbr0cEkv+oUKYKcX3DIKcsmj5hr3qA/oQc1OfInuY7XnzHS3M3V5GkBNu4mL1KNz z2FclPYUeaZ9smIslSuURuE5V4jFGltQKW3+Ilp6OwxmyzLPmSQgemQAsfUl10HC IBFQZJPNGNX6GlDMEDLLSVd+hLbo/ziTRvI23xDpUYcM0X1WbPM8tL76falP7mU= =c+j/ -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-current@freebsd.org Fri Mar 27 21:49:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EFD0D262645 for ; Fri, 27 Mar 2020 21:49:16 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48pwVM1CCQz3Jxf for ; Fri, 27 Mar 2020 21:49:14 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 02RLnhga073386 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 27 Mar 2020 14:49:49 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 From: Chris Reply-To: bsd-lists@BSDforge.com To: freebsd-current Subject: When will the FreeBSD (u)EFI work? Date: Fri, 27 Mar 2020 14:49:49 -0700 Message-Id: <1dd9599e57a5371aa569ecdcedaa220e@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48pwVM1CCQz3Jxf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.45 / 15.00]; NEURAL_HAM_MEDIUM(-0.57)[-0.570,0]; NEURAL_SPAM_LONG(0.12)[0.122,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 21:49:17 -0000 On an experiment of the FreeBSD EFI implementation=2E I installed a copy of releng/12 from install media=2E Which left me with: # gpart show ada0 =3D> 40 312581728 ada0 GPT (149G) 40 409600 1 efi (200M) 409640 31047680 2 freebsd-ufs (15G) 31457320 7680000 3 freebsd-swap (3=2E7G) 74788904 237792864 - free - (141G) On this Intel based system, I can stab the F12 key to pick my UEFI bootable OS, or let it boot according to the order I setup in the BIOS=2E So far, so good=2E I needed a copy of releng/13 to also work with=2E Installed a copy from install media=2E Which left me with: # gpart show ada0 =3D> 40 312581728 ada0 GPT (149G) 40 409600 1 efi (200M) 409640 31047680 2 freebsd-ufs (15G) 31457320 7680000 3 freebsd-swap (3=2E7G) 39137320 532480 4 efi (260M) 39669800 35119104 5 freebsd-ufs (17G) 74788904 237792864 - free - (113G) I *assumed* that the install would activate the new install, and I would boot straight into it=2E But no=2E I am still on the previous install, and worse, I can't get into the new install -- even if picking it via stabbing the F12 key=2E I *still* end up in the previous install=2E So looking at what might be causing it=2E I found the following: # releng/12 # mount -t msdosfs /dev/ada0p1 /mnt/ # ls /mnt/efi/boot/ BOOTx64=2Eefi startup=2Ensh # cat /mnt/efi/boot/startup=2Ensh BOOTx64=2Eefi # umount /mnt/ releng/13 # mount -t msdosfs /dev/ada0p4 /mnt/ # ls /mnt/EFI/freebsd/ loader=2Eefi Why the difference? When will FreeBSD (u)EFI work as expected? Thanks in advance for any insights! --Chris From owner-freebsd-current@freebsd.org Fri Mar 27 22:11:18 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0392B262CCF for ; Fri, 27 Mar 2020 22:11:17 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48pwzQ15NLz3x23 for ; Fri, 27 Mar 2020 22:10:57 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-wr1-f68.google.com with SMTP id 31so13427164wrs.3 for ; Fri, 27 Mar 2020 15:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jYRQHqUu0R0JVKseWlkdIn+tag+bnaaEgHuf6pTF/OE=; b=AOa3HyWjNzPF81okrRd7O1uYuJ+Idpl4DOeKbVQWb2y0UdOfr50w3Kj3Ee+bNsMRuK ZD2IOE5Qta83NS1XtaHubwbdBamQviFlOOZsnLA1UGPWNH6xLKqpDOj6GEzXyige8A29 6LaZuZ8wZc79AHTXzHuETqOaYhGe2wnAIUajJ6koeZi/gEQ0RveDMoXqMC3wIWZU0Uow K11YkSpz4ctKA8zXdR76ee1lvcuKzm794ZFio8CuqnHodIXHO5uzsDTdbKP+hZVoOSfa l+8n+/aHz+9Oz0hrF5NOZyTcr/3DxZwgOfHYEVeBGy4m5mADcYjvpIXL79Oz31XhMcmL ru/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jYRQHqUu0R0JVKseWlkdIn+tag+bnaaEgHuf6pTF/OE=; b=L60kk/HXecKO59pYoYvHb8cMBJJiylp4spaWA8JJ8PyoL8Dobpup6D4asLQq3IM57f oxbKM45EV5rV9AdeaR3b9i4T5g9WFPRFz3K3NuPFsk7nBx7v1eUMdn1do9dgvdDZveJq +D1u3MlSlA98jPRloRypn9E+xwnsp8J4wWDHVA0SWDEu8qxEUlsykUFkNNuOTSDlz1wY Ts0qFQH3lHsZ2Nkv9odKPheoG/hV8pjFCBUPRg2Epdb5Gd4O33xoLcgebLWPjiwWMcVO L+KdjTmsSvhdSRaoDknMYFq0L2x2AUmJnGUJFYlCHPh65wRmCBPfG0shDr7LlqBsI0xN LJpg== X-Gm-Message-State: ANhLgQ3SshuHg3mbrdyo/TwP0F+qAHRAWdaDPYlpqiE06WYsGiuQj7vd Rgrbucwo3NIkZEpOC16Oj7GNe1RL5NyjoyGC8x8WSaBUqFk= X-Google-Smtp-Source: ADFU+vs0NWAKyP6QJUXlE9vXYBjo0u04cs2mdMmm9NIVNH9853ZZ8ovqODjAgbO4zi7CkT5HDD+EqkwyDED1UUjh4kE= X-Received: by 2002:adf:d0cb:: with SMTP id z11mr1703752wrh.1.1585347048780; Fri, 27 Mar 2020 15:10:48 -0700 (PDT) MIME-Version: 1.0 References: <1dd9599e57a5371aa569ecdcedaa220e@udns.ultimatedns.net> In-Reply-To: <1dd9599e57a5371aa569ecdcedaa220e@udns.ultimatedns.net> From: Andrey Fesenko Date: Sat, 28 Mar 2020 01:10:37 +0300 Message-ID: Subject: Re: When will the FreeBSD (u)EFI work? To: bsd-lists@bsdforge.com Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48pwzQ15NLz3x23 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=AOa3HyWj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of f0andrey@gmail.com designates 209.85.221.68 as permitted sender) smtp.mailfrom=f0andrey@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-8.50), ipnet: 209.85.128.0/17(-1.07), asn: 15169(-0.47), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[68.221.85.209.list.dnswl.org : 127.0.5.0]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[68.221.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 22:11:18 -0000 On Sat, Mar 28, 2020 at 12:53 AM Chris wrote: > > On an experiment of the FreeBSD EFI implementation. I installed > a copy of releng/12 from install media. Which left me with: > # gpart show ada0 > => 40 312581728 ada0 GPT (149G) > 40 409600 1 efi (200M) > 409640 31047680 2 freebsd-ufs (15G) > 31457320 7680000 3 freebsd-swap (3.7G) > 74788904 237792864 - free - (141G) > > On this Intel based system, I can stab the F12 key to pick > my UEFI bootable OS, or let it boot according to the order > I setup in the BIOS. So far, so good. > I needed a copy of releng/13 to also work with. Installed a copy > from install media. Which left me with: > # gpart show ada0 > => 40 312581728 ada0 GPT (149G) > 40 409600 1 efi (200M) > 409640 31047680 2 freebsd-ufs (15G) > 31457320 7680000 3 freebsd-swap (3.7G) > 39137320 532480 4 efi (260M) > 39669800 35119104 5 freebsd-ufs (17G) > 74788904 237792864 - free - (113G) > I *assumed* that the install would activate the new install, and I > would boot straight into it. But no. I am still on the previous > install, and worse, I can't get into the new install -- even if > picking it via stabbing the F12 key. I *still* end up in the previous > install. So looking at what might be causing it. I found the following: > # releng/12 > # mount -t msdosfs /dev/ada0p1 /mnt/ > > # ls /mnt/efi/boot/ > BOOTx64.efi > startup.nsh > > # cat /mnt/efi/boot/startup.nsh > BOOTx64.efi > > # umount /mnt/ > > releng/13 > # mount -t msdosfs /dev/ada0p4 /mnt/ > > # ls /mnt/EFI/freebsd/ > loader.efi > > Why the difference? When will FreeBSD (u)EFI work as expected? > > Thanks in advance for any insights! > Require only single efi part See https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/ From owner-freebsd-current@freebsd.org Fri Mar 27 22:51:46 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C5B03263DF1 for ; Fri, 27 Mar 2020 22:51:46 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48pxtS2Q0qz4CgC for ; Fri, 27 Mar 2020 22:51:43 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 02RMqCpS074397 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 27 Mar 2020 15:52:18 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: freebsd-current In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Andrey Fesenko Subject: Re: When will the FreeBSD (u)EFI work? Date: Fri, 27 Mar 2020 15:52:18 -0700 Message-Id: <79dcf9ff2e4a233552bb1dff28c723ac@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48pxtS2Q0qz4CgC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.48 / 15.00]; NEURAL_HAM_MEDIUM(-0.85)[-0.847,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.63)[-0.629,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 22:51:46 -0000 On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey@gmail=2Ecom said > On Sat, Mar 28, 2020 at 12:53 AM Chris wrote: > > > > On an experiment of the FreeBSD EFI implementation=2E I installed > > a copy of releng/12 from install media=2E Which left me with: > > # gpart show ada0 > > =3D> 40 312581728 ada0 GPT (149G) > > 40 409600 1 efi (200M) > > 409640 31047680 2 freebsd-ufs (15G) > > 31457320 7680000 3 freebsd-swap (3=2E7G) > > 74788904 237792864 - free - (141G) > > > > On this Intel based system, I can stab the F12 key to pick > > my UEFI bootable OS, or let it boot according to the order > > I setup in the BIOS=2E So far, so good=2E > > I needed a copy of releng/13 to also work with=2E Installed a copy > > from install media=2E Which left me with: > > # gpart show ada0 > > =3D> 40 312581728 ada0 GPT (149G) > > 40 409600 1 efi (200M) > > 409640 31047680 2 freebsd-ufs (15G) > > 31457320 7680000 3 freebsd-swap (3=2E7G) > > 39137320 532480 4 efi (260M) > > 39669800 35119104 5 freebsd-ufs (17G) > > 74788904 237792864 - free - (113G) > > I *assumed* that the install would activate the new install, and I > > would boot straight into it=2E But no=2E I am still on the previous > > install, and worse, I can't get into the new install -- even if > > picking it via stabbing the F12 key=2E I *still* end up in the previous > > install=2E So looking at what might be causing it=2E I found the following: > > # releng/12 > > # mount -t msdosfs /dev/ada0p1 /mnt/ > > > > # ls /mnt/efi/boot/ > > BOOTx64=2Eefi > > startup=2Ensh > > > > # cat /mnt/efi/boot/startup=2Ensh > > BOOTx64=2Eefi > > > > # umount /mnt/ > > > > releng/13 > > # mount -t msdosfs /dev/ada0p4 /mnt/ > > > > # ls /mnt/EFI/freebsd/ > > loader=2Eefi > > > > Why the difference? When will FreeBSD (u)EFI work as expected? > > > > Thanks in advance for any insights! > > >=20 > Require only single efi part >=20 > See > https://forums=2Efreebsd=2Eorg/threads/two-freebsd-installations-and-efi=2E7396= 8/ Thanks for they reply, and link, Andrey! Well that confirms it=2E FreeBSD, unlike other OS implementations, will not permit booting your chosen "version" via EFI=2E That is; not without dropping to the loader prompt, or changing the status of slices, or boot entries pri= or to reboot=2E :( Looks like I'll need to install a third party OS, or bootmanager to use Fre= eBSD=2E Sigh=2E=2E=2E There *may* be hope in the future (https://bugs=2Efreebsd=2Eorg/bugzilla/show_b= ug=2Ecgi?id=3D207940) Thanks again, Andrey=2E Greatly appreciated! :) --Chris From owner-freebsd-current@freebsd.org Fri Mar 27 23:28:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 97602264AAF for ; Fri, 27 Mar 2020 23:28:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48pyh42MC7z4R5l for ; Fri, 27 Mar 2020 23:27:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf36.google.com with SMTP id c28so5803767qvb.10 for ; Fri, 27 Mar 2020 16:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IVv6ieGkgqWejEtSgI/C4I6MDSVoMr2nK/RcbXZcbo0=; b=Iv8w4uA/wiC3fFFVU32qxLrgF0Wpw1Gq18msLguJQVyjS8pTNXX1oXCh/OoJvp7PBj qYu5KIfjNk1/Chd2tOkQXzZAS7Irq9zokiwPxzZpNZr1DLPGm9Y03xhRqYAXf3vOzmJU 5aH1YWYehQZIBcEVeDkcTtSoU72kvEpnyAfptR1HScbKs7xJx/DpAF1OJkOfrtpexYCQ EelQzJbMF5B0fSxVTSDW547ojBZUPdq03PaosRwLMLParQgQXl1CwGy6XsuFPYk66msH LD8cjaqFEg4r9dZF8T4iwM4rrYWFZ/VaSrOGPO6vOvs9fkI5nCodCE9k5mjVt6P26+Vr B6gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IVv6ieGkgqWejEtSgI/C4I6MDSVoMr2nK/RcbXZcbo0=; b=aDFZjqjN4xG5V0ulKBB917lVDYkJqXtLGDPiJz4MYFVntO9eskUrxUpkRwzwjaJ+2m hgTnBmghriJHGYVeymKbbYvVpb1L44ztRiMsbuc28y7Bu9odTpa2FEDpsHxRRa1cHW/G GCVOa8wr9g3Jm1gz3aL8j5ufLJjh4+VDjqOizaQk2vsO/Tjq9GFJJWFHKUVoIQ6C7NEm Ygoz13IyKu3tSsxJ/1BxSz/lsAAMfcWW11nMSy+NaXyPtjmSHDTR5X1Pip8EZQtfxUNk aIQovpWFVWIemx5DjWhjx558uEMjsir33IVw5yWqeoBzShI8f2dePT1VGWMrPVRcIqSn SLBA== X-Gm-Message-State: ANhLgQ3d6vkfjr8ilyT8ji44Q6Qb2tCBsZKiodRG8TJD1Rydmp7CYqd7 GR/a12BSgSKnvtmuhP8q0U5/J+yKNqNH92FbfIkfp6Rn X-Google-Smtp-Source: ADFU+vt+oCDtTRUAB1yOv+mPNJgDN2LfVi/eBlb2eQY8Czz9tvLP4eCxQ/4dtKjyP9UoIZxfW1EZfZjphy60O18/OFs= X-Received: by 2002:a0c:a8e2:: with SMTP id h34mr1711734qvc.22.1585351658420; Fri, 27 Mar 2020 16:27:38 -0700 (PDT) MIME-Version: 1.0 References: <79dcf9ff2e4a233552bb1dff28c723ac@udns.ultimatedns.net> In-Reply-To: <79dcf9ff2e4a233552bb1dff28c723ac@udns.ultimatedns.net> From: Warner Losh Date: Fri, 27 Mar 2020 17:27:27 -0600 Message-ID: Subject: Re: When will the FreeBSD (u)EFI work? To: Chris H Cc: Andrey Fesenko , freebsd-current X-Rspamd-Queue-Id: 48pyh42MC7z4R5l X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Iv8w4uA/; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f36) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.35 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-1.35)[ip: (-5.87), ipnet: 2607:f8b0::/32(-0.37), asn: 15169(-0.47), country: US(-0.05)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[6.3.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 23:28:01 -0000 On Fri, Mar 27, 2020 at 4:54 PM Chris wrote: > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey@gmail.com said > > > On Sat, Mar 28, 2020 at 12:53 AM Chris wrote: > > > > > > On an experiment of the FreeBSD EFI implementation. I installed > > > a copy of releng/12 from install media. Which left me with: > > > # gpart show ada0 > > > => 40 312581728 ada0 GPT (149G) > > > 40 409600 1 efi (200M) > > > 409640 31047680 2 freebsd-ufs (15G) > > > 31457320 7680000 3 freebsd-swap (3.7G) > > > 74788904 237792864 - free - (141G) > > > > > > On this Intel based system, I can stab the F12 key to pick > > > my UEFI bootable OS, or let it boot according to the order > > > I setup in the BIOS. So far, so good. > > > I needed a copy of releng/13 to also work with. Installed a copy > > > from install media. Which left me with: > > > # gpart show ada0 > > > => 40 312581728 ada0 GPT (149G) > > > 40 409600 1 efi (200M) > > > 409640 31047680 2 freebsd-ufs (15G) > > > 31457320 7680000 3 freebsd-swap (3.7G) > > > 39137320 532480 4 efi (260M) > > > 39669800 35119104 5 freebsd-ufs (17G) > > > 74788904 237792864 - free - (113G) > > > I *assumed* that the install would activate the new install, and I > > > would boot straight into it. But no. I am still on the previous > > > install, and worse, I can't get into the new install -- even if > > > picking it via stabbing the F12 key. I *still* end up in the previous > > > install. So looking at what might be causing it. I found the following: > > > # releng/12 > > > # mount -t msdosfs /dev/ada0p1 /mnt/ > > > > > > # ls /mnt/efi/boot/ > > > BOOTx64.efi > > > startup.nsh > > > > > > # cat /mnt/efi/boot/startup.nsh > > > BOOTx64.efi > > > > > > # umount /mnt/ > > > > > > releng/13 > > > # mount -t msdosfs /dev/ada0p4 /mnt/ > > > > > > # ls /mnt/EFI/freebsd/ > > > loader.efi > > > > > > Why the difference? When will FreeBSD (u)EFI work as expected? > > > > > > Thanks in advance for any insights! > > > > > > > Require only single efi part > > > > See > > > https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968/ > Thanks for they reply, and link, Andrey! > Well that confirms it. FreeBSD, unlike other OS implementations, will not > permit booting your chosen "version" via EFI. It does today. If you use efibootmgr, you can boot exactly what you want. I do it all the time... Though your BIOS may overwrite the EFI vars if you set too many (I'm looking at you supermicro). When you use the efi BootXXXX variables, it's possible to boot one of many different things on the system... Though I've not done 11, just 12 and current. > That is; not without dropping > to the loader prompt, or changing the status of slices, or boot entries > prior to > reboot. :( > Not needed. > Looks like I'll need to install a third party OS, or bootmanager to use > FreeBSD. > Sigh... > Again, not needed. Though there may be a few things that need to be MFC'd if you want 11 on that list... > There *may* be hope in the future ( > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940) > This would require you to stop to select on the way up... Or am I not understanding what you want? We should add that functionality to loader.efi, since boot1.efi is in the process of being deprecated... It should be a simple LUA script there... > Thanks again, Andrey. Greatly appreciated! :) > From owner-freebsd-current@freebsd.org Fri Mar 27 23:35:40 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BA095265103 for ; Fri, 27 Mar 2020 23:35:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 48pys36hYzz4V1x; Fri, 27 Mar 2020 23:35:35 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 256013C0199; Fri, 27 Mar 2020 23:29:03 +0000 (UTC) Date: Fri, 27 Mar 2020 23:29:03 +0000 From: Brooks Davis To: Brooks Davis Cc: Ruslan Garipov , freebsd-current@freebsd.org Subject: Re: buildworld failed (usr.bin/kyua) Message-ID: <20200327232903.GA36720@spindle.one-eyed-alien.net> References: <98e2187e-ca29-1cc0-46e2-f684c828274d@gmail.com> <20200327200708.GA12101@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20200327200708.GA12101@spindle.one-eyed-alien.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 48pys36hYzz4V1x X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 23:35:40 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 27, 2020 at 08:07:08PM +0000, Brooks Davis wrote: > On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote: > > I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351. > >=20 > > End of the build log: > >=20 > > $ su root -c "make -j16 buildworld" > > ... > > ld: error: unable to find library -lkyua_cli_pie > > ld: error: unable to find library -lkyua_drivers_pie > > ld: error: unable to find library -lkyua_model_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_engine_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_utils_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_store_pie > > ld: error: unable to find library -lkyua_model_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_utils_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_engine_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_utils_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_model_pie > > ld: error: unable to find library -llutok_pie > > ld: error: unable to find library -lkyua_store_pie > > ld: error: too many errors emitted, stopping now (use -error-limit=3D0 > > to see all errors) > > c++: error: linker command failed with exit code 1 (use -v to see > > invocation) > > --- all_subdir_lib --- > > --- cpuset_getdomain.po --- > > --- all_subdir_usr.bin --- > > *** [kyua] Error code 1 > >=20 > > make[4]: stopped in /usr/src/usr.bin/kyua > > 1 error > >=20 > > make[4]: stopped in /usr/src/usr.bin/kyua > > *** [all_subdir_usr.bin/kyua] Error code 2 > > ... > >=20 > > May be it's related to r359260[1]. Therefore, here is my TEST-settings: > >=20 > > $ fgrep TEST /etc/src.conf > > WITHOUT_GOOGLETEST=3D > > WITHOUT_TESTS=3D > > WITH_TESTS_SUPPORT=3D > >=20 > > Also what has confused me: it's a virtual machine which failed to build. > > A physical one built userland and kernel just fine. Both the physical > > and virtual machines have almost the same (differ only by CPU > > "selection" options) make.conf and src.conf and different kernel > > configurations. Both the machines were FreeBSD 13.0-CURRENT amd64 > > r359231. I've started to build on clean systems (no /usr/obj at all). > >=20 > > Can anyone help me to resolve this issue? >=20 > I've replicated this issue and it goes back the the way > WITH_TESTS_SUPPORT was implemented way back in r273449 >=20 > This patch fixes WITHOUT_TESTS=3Dt WITH_TESTS_SUPPORT=3Dt for me. >=20 > Index: Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.inc1 (revision 359367) > +++ Makefile.inc1 (working copy) > @@ -1100,7 +1100,7 @@ > @echo > "--------------------------------------------------------------" > ${_+_}cd ${.CURDIR}; \ > ${WMAKE} -DNO_FSCHG MK_HTML=3Dno -DNO_LINT MK_MAN=3Dno \ > - MK_PROFILE=3Dno MK_TESTS=3Dno MK_TESTS_SUPPORT=3D${MK_TESTS} > libraries > + MK_PROFILE=3Dno MK_TESTS=3Dno libraries > everything: .PHONY > @echo > @echo > "-------------------------------------------------------------- >=20 > I've not committed it yet because I'm trying to figure out why this was > needed. I simply don't see how there could be a race between lib/aft and > libexec/aft as described. I suspect this may have been an error. I've committed a different fix in r359382. The above change fixed the case at hand, but broke the default. -- Brooks --envbJBWh7q8WU6mo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJefow+AAoJEKzQXbSebgfAVTMH/2t4S9zvP2VdmUekfPFaPNWA sq9TQPypamACNUOjdLcz6gTnOjrHa29sUMh+LEbaHXM53MwNF3EwZDeY7YXh3zpX b/wX72v7x2rpyrPd8Eu5nLDC4jYHWiKcSBXT4yLedIQOgd+/WDZH2ugDWhLHvuZ8 ygf9+umt8eYbsK6msjrYP0QNZMVTmMVbBPYrw3EfbY/tnnmpcsJfeWKeTiDJA8lO TVHh7geABAzE3tEz1Pn0ubLjjKAoX09NF0ybKwcR9NJn02BwOT2/o9LZFcG5Z/rh Q2Wn+xe/2+lbssnhp0i6UbGOTI4xd/FXfCIjcEhSKFzjhw1oNv1jlo79gzJQN1o= =Afqh -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-current@freebsd.org Sat Mar 28 00:43:55 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 146DF266DAE for ; Sat, 28 Mar 2020 00:43:55 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48q0Mm0hN0z3wZV for ; Sat, 28 Mar 2020 00:43:48 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id AA834266D90; Sat, 28 Mar 2020 00:43:40 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D6E4266D8E for ; Sat, 28 Mar 2020 00:43:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q0MQ3z3Dz3RJM for ; Sat, 28 Mar 2020 00:43:29 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C7DA.dip0.t-ipconnect.de [46.82.199.218]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 02S0hGwm066407 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Mar 2020 01:43:20 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 02S0hGSp043196 for ; Sat, 28 Mar 2020 01:43:16 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 02S0h4Qx009681 for ; Sat, 28 Mar 2020 01:43:16 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <202003280043.02S0h4Qx009681@fire.js.berklix.net> To: current@freebsd.org Subject: src/usr.bin/kyua breaks on manbuild.sh: Permission denied From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ Date: Sat, 28 Mar 2020 01:43:04 +0100 X-Rspamd-Queue-Id: 48q0MQ3z3Dz3RJM X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [1.33 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[berklix.com]; NEURAL_SPAM_MEDIUM(0.05)[0.048,0]; NEURAL_SPAM_LONG(0.38)[0.380,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(0.00)[ip: (0.02), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 00:43:55 -0000 src/usr.bin/kyua breaks on manbuild.sh: Permission denied Example: cd /usr/src cat .ctm_status src-cur 14430 cat .svn_revision 359319 uname -a FreeBSD lapr.js.berklix.net 13.0-CURRENT FreeBSD 13.0-CURRENT #14410: Sun Mar 15 16:28:46 CET 2020 jhs@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64 cd /usr/src/usr.bin/kyua ; make /usr/src/contrib/kyua/doc/manbuild.sh -v "CONFDIR=/etc/kyua" -v "DOCDIR=/nonexistant" -v "EGDIR=/usr/share/examples/kyua" -v "MISCDIR=/usr/share/kyua/misc" -v "PACKAGE=kyua" -v "STOREDIR=/usr/share/kyua/store" -v "TESTSDIR=/usr/tests" -v "VERSION=0.13" /usr/src/contrib/kyua/doc/kyua-about.1.in kyua-about.1 /bin/sh: /usr/src/contrib/kyua/doc/manbuild.sh: Permission denied *** Error code 126 l /usr/src/contrib/kyua/doc/manbuild.sh -rw-r--r-- 1 jhs staff 5187 Mar 25 12:34 /usr/src/contrib/kyua/doc/manbuild.sh chmod a+x /usr/src/contrib/kyua/doc/manbuild.sh make # succeeds but wrong solution chmod a-x /usr/src/contrib/kyua/doc/manbuild.sh cd /usr/src/usr.bin/kyua ; make clean source `which unsetenv.csh` # SH is not set make clean ; make /bin/sh: /usr/src/contrib/kyua/doc/manbuild.sh: Permission denied *** src/usr.bin/kyua/Makefile.orig Wed Mar 25 12:34:45 2020 --- src/usr.bin/kyua/Makefile Sat Mar 28 01:38:21 2020 *************** *** 49,55 **** .PATH: ${KYUA_SRCDIR}/doc .for man in ${MAN} ${man}: ${man}.in ! ${SH} ${KYUA_SRCDIR}/doc/manbuild.sh \ -v "CONFDIR=${KYUA_CONFDIR}" \ -v "DOCDIR=${KYUA_DOCDIR}" \ -v "EGDIR=${KYUA_EGDIR}" \ --- 49,55 ---- .PATH: ${KYUA_SRCDIR}/doc .for man in ${MAN} ${man}: ${man}.in ! /bin/sh ${KYUA_SRCDIR}/doc/manbuild.sh \ -v "CONFDIR=${KYUA_CONFDIR}" \ -v "DOCDIR=${KYUA_DOCDIR}" \ -v "EGDIR=${KYUA_EGDIR}" \ The diff above works, but is not sophisticated enough to represent what someone is trying to do with SH ? Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ UK stole 750,000 votes from EU Brits: http://stolenvotes.uk http://petition.parliament.uk/petitions/300059 http://berklix.uk/brexit/#russia Limit Corona: http://berklix.eu/corona/ From owner-freebsd-current@freebsd.org Sat Mar 28 01:05:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A69DD267DCD for ; Sat, 28 Mar 2020 01:05:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48q0rT0z9Qz44J7 for ; Sat, 28 Mar 2020 01:05:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 5DA0B267DBF; Sat, 28 Mar 2020 01:05:04 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 39145267DBE for ; Sat, 28 Mar 2020 01:05:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q0r56gtMz44CV for ; Sat, 28 Mar 2020 01:04:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f45.google.com with SMTP id v3so11698184iot.11 for ; Fri, 27 Mar 2020 18:04:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WGp0LEDO5N4Ly9gk6+/0PTKG+ZQNpiqwdrdfhwCvlLU=; b=LFRBGNWVenEGgFbczfPdxPUkNnJVS33s1YQZ8DxHBS5ZStjqxho6xBJUL0j7m2GW01 TwUjqkw6qCHTMtB5CuSSliUoPfrAAJ2CVSma+W/NcMApj4nvT6TRg9ZWP5Vi/dCKJNGM iWTIKZv+jpQI6uC2sJXSd5JhySgw5iO7F3V7lZYfQd6xqhXSFOFPFlV5+ZafWjhuxcb6 +X1YVua7Fw6uYLpuwvgU7DXtacl+ecAWIvmpqhHGxYQ4uig/W+Jn+Dsmih/Hfxl+nxw5 FuqzqTfeTQvjdhk1bRlB9JsAf37guojKIY2ObIW+cgJNN/EmVKffN1FroJDxGapXf0jX 1wzA== X-Gm-Message-State: ANhLgQ1+rzcc8cRDtqcH7wS+GH632zU2JKyEo7QQWVCtJTXn8XLbp9XP BsUPqVLnjryE1zfEZa9ZS5lzC9b67FUWTeIy/6qL7Q== X-Google-Smtp-Source: ADFU+vtHaQVeuE5ndIjjDW3RmLbWrDhF4yX3woC1PzyhPkLaZXYMeCtxLBMkM/mtq8l90NA3D2/aq2xtmaG/7f4pfvA= X-Received: by 2002:a6b:c8d4:: with SMTP id y203mr1305078iof.111.1585357485327; Fri, 27 Mar 2020 18:04:45 -0700 (PDT) MIME-Version: 1.0 References: <202003280043.02S0h4Qx009681@fire.js.berklix.net> In-Reply-To: <202003280043.02S0h4Qx009681@fire.js.berklix.net> From: Ed Maste Date: Fri, 27 Mar 2020 21:04:33 -0400 Message-ID: Subject: Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied To: "Julian H. Stacey" Cc: current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48q0r56gtMz44CV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; DBL_FAIL(0.00)[query timed out]; SURBL_MULTI_FAIL(0.00)[query timed out]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[45.166.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.17)[ip: (-4.28), ipnet: 209.85.128.0/17(-1.05), asn: 15169(-0.47), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[45.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 01:05:16 -0000 On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey wrote: > > l /usr/src/contrib/kyua/doc/manbuild.sh > -rw-r--r-- 1 jhs staff 5187 Mar 25 12:34 /usr/src/contrib/kyua/doc/manbuild.sh Indeed, this is the problem. manbuild.sh is +x in svn and in the git mirror, so it appears something's broken in ctm. From owner-freebsd-current@freebsd.org Sat Mar 28 01:11:02 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 993492681FC for ; Sat, 28 Mar 2020 01:11:02 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48q0z5233Vz46Hk for ; Sat, 28 Mar 2020 01:10:57 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 1C81D2681B9; Sat, 28 Mar 2020 01:10:49 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA05C2681B7 for ; Sat, 28 Mar 2020 01:10:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q0ys63h7z4607; Sat, 28 Mar 2020 01:10:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pj1-x1030.google.com with SMTP id v13so4624561pjb.0; Fri, 27 Mar 2020 18:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P3OnxlbEgoMwK5PspWkJ9LgkNGjybDJE443HwYytmTw=; b=l902Gk25RgGjEzkesesfH9ZPczf8v2uQob1iPFD9exaCIQn60k5Tkubpf3e/jedjRM O99N2QckxBvGav3ReJVL74uPTYXTv5cuacltyrT6+yCjTl6URg/0WX6X76HFY05hDwHz YReJp/OCN/pFDNNTjdeigU5wwUvs2/8K6tCxVGLvwNG2X1cBN0KoTtx0GtKmt0tSnto7 lQnqj+pq0t1q9u2HTCnZyEfr2bukEX3ZnzxeabtCh4VZJX5siY8JFcGd+EzqYUxOz0TA r/IJBXnR4HfzL0nv4mVmw1yMxdmfFLpj00YY19S0M9aH26n5z/qYTHdSBOynnA8ujeWg Rjgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P3OnxlbEgoMwK5PspWkJ9LgkNGjybDJE443HwYytmTw=; b=FhRF8Gf1dviJdamjBUQRbpjaizqCC/MNsIM90IFkrHvgVjvoj6HKCCw/sUGYNzolU7 i+8lMqXliQZIGqeG4JlK3oJ1QgP9gHLPtmNlrdlejhNxisW6dKplCXg/bG1ePwGExO3R FiyFvQTOpOOgVPnDYJPanVw+s64OGZb8pRmF6pbgN9bqDJ8eg/l5pbjCh3QN77uQXH7K q9g3cjVQYvE0mHcnZ07QzyKT/3bZMdYSjuINVA48n3VJG6Niyums+fmorxXtxxUzyWPs p04VF4PATfXfOGncSs4XxL+It1je1761VdtW2lwdHHgjV+b1webRgsQtCde9TPrCZ8Pg PNPg== X-Gm-Message-State: ANhLgQ3NblnCTwxXSrG6+UdzfgaX1YPzpsggPKVCOEs/lZ+JN1b4/NcH X1uPKArdVNMc9X8MNXFy5lYrdvJkm/8= X-Google-Smtp-Source: ADFU+vuEr++nRoC/P90GFvMthEDnqcpaMRSWOdXru2z86K+xDID6EnZo+Yvu2slkzf4ao+iO4dKiKA== X-Received: by 2002:a17:90a:2307:: with SMTP id f7mr2278181pje.152.1585357835045; Fri, 27 Mar 2020 18:10:35 -0700 (PDT) Received: from [192.168.20.26] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id nk12sm4714825pjb.41.2020.03.27.18.10.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2020 18:10:34 -0700 (PDT) From: Enji Cooper Message-Id: <217CD2BD-85B9-4CB5-BAD3-6D5099996FF2@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied Date: Fri, 27 Mar 2020 18:10:33 -0700 In-Reply-To: Cc: "Julian H. Stacey" , current To: Ed Maste References: <202003280043.02S0h4Qx009681@fire.js.berklix.net> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48q0ys63h7z4607 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 01:11:02 -0000 > On Mar 27, 2020, at 6:04 PM, Ed Maste wrote: >=20 > On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey = wrote: >>=20 >> l /usr/src/contrib/kyua/doc/manbuild.sh >> -rw-r--r-- 1 jhs staff 5187 Mar 25 12:34 = /usr/src/contrib/kyua/doc/manbuild.sh >=20 > Indeed, this is the problem. manbuild.sh is +x in svn and in the git > mirror, so it appears something's broken in ctm. Hi Julian, I just worked around the issue by bypassing the manpage = generation as part of buildworld: = https://svnweb.freebsd.org/base?view=3Drevision&revision=3D359385 = . = While the approach you took makes wonderful sense, I thought it was best = to not have to continually rebuild the manpages for little to no gain. Thank you very much for the report/submitted patch :)! -Enji= From owner-freebsd-current@freebsd.org Sat Mar 28 01:15:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 87FF42687F8 for ; Sat, 28 Mar 2020 01:15:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48q14V0pMTz47s6 for ; Sat, 28 Mar 2020 01:15:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 786142687E6; Sat, 28 Mar 2020 01:15:29 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 76C8A2687E5 for ; Sat, 28 Mar 2020 01:15:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q14061lvz47l4 for ; Sat, 28 Mar 2020 01:15:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f177.google.com with SMTP id a6so10565341ilr.4 for ; Fri, 27 Mar 2020 18:15:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sfoSwhCiRBQLaEXOc6XB0DinhJAUXMG6HkJpGgSDt3s=; b=EizddXyFPOGjATtFgueEt/VaR7CNBfw4+lta6x4/eArSmXdk3ir+Ael7p8Zt2eovoN RlG5dOWF178+7rkjceeMgNHbUhWJM072YJDiiKlX8Q++F+b7iaInrEJNAfSJ9BRyUpHt txeMZkIwkOqA5eb+MifZltYoboiIBNLeZE3KzFoBfD5RL2eWtogxxMSZx1c1OIUUIDs7 FGcsiQIpDZc0CnicpKIzQKF936iZ6GRJaQykPUewdsGsZU/rCq6vZyUhGlPG4cU1nzT7 vVEr9Pa55hXiX5m+8NFXvYlWTW3FW1AkuBClFjn1joolG+7yF+pvfWeEiYzg3vLIfGXV Yk6w== X-Gm-Message-State: ANhLgQ14phyfogrS361z4z6V9ZmvA/2mOUVQem1Q/NGVvHcrjra9qn08 OCDOsN5VnWwq+CZMpShDxyc9qR/B3NxbgJREX1lcfA== X-Google-Smtp-Source: ADFU+vuJ2kMfZw3cHREEB20ufVCdEwaDjcuwxLiAbfDckazXU0+ApKZmE39XNbAiP5bclDd53eqnui7CD7zmHlL8Dwc= X-Received: by 2002:a92:778e:: with SMTP id s136mr1934706ilc.256.1585358103666; Fri, 27 Mar 2020 18:15:03 -0700 (PDT) MIME-Version: 1.0 References: <202003280043.02S0h4Qx009681@fire.js.berklix.net> <217CD2BD-85B9-4CB5-BAD3-6D5099996FF2@gmail.com> In-Reply-To: <217CD2BD-85B9-4CB5-BAD3-6D5099996FF2@gmail.com> From: Ed Maste Date: Fri, 27 Mar 2020 21:14:50 -0400 Message-ID: Subject: Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied To: Enji Cooper Cc: "Julian H. Stacey" , current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48q14061lvz47l4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.177 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[177.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.72)[ip: (-7.05), ipnet: 209.85.128.0/17(-1.05), asn: 15169(-0.47), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[177.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 01:15:42 -0000 On Fri, 27 Mar 2020 at 21:11, Enji Cooper wrote:> > > Hi Julian, > I just worked around the issue by bypassing the manpage generation as par= t of buildworld: https://svnweb.freebsd.org/base?view=3Drevision&revision= =3D359385 . While the approach you took makes wonderful sense, I thought it= was best to not have to continually rebuild the manpages for little to no = gain. We have lots of scripts in the tree so if there's some problem with permissions with an obscure source code distribution tool those problems should be fixed instead. From owner-freebsd-current@freebsd.org Sat Mar 28 01:31:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B33F269C13 for ; Sat, 28 Mar 2020 01:31:19 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q1QV58y8z4DrZ for ; Sat, 28 Mar 2020 01:31:14 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 02S1VhBN076744 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 27 Mar 2020 18:31:50 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: freebsd-current Subject: Re: When will the FreeBSD (u)EFI work? Date: Fri, 27 Mar 2020 18:31:50 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48q1QV58y8z4DrZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.36 / 15.00]; NEURAL_HAM_MEDIUM(-0.55)[-0.550,0]; NEURAL_SPAM_LONG(0.19)[0.192,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 01:31:19 -0000 On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh imp@bsdimp=2Ecom said > On Fri, Mar 27, 2020 at 4:54 PM Chris wrote: >=20 > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey@gmail=2Ecom sa= id > > > > > On Sat, Mar 28, 2020 at 12:53 AM Chris wrote= : > > > > > > > > On an experiment of the FreeBSD EFI implementation=2E I installed > > > > a copy of releng/12 from install media=2E Which left me with: > > > > # gpart show ada0 > > > > =3D> 40 312581728 ada0 GPT (149G) > > > > 40 409600 1 efi (200M) > > > > 409640 31047680 2 freebsd-ufs (15G) > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > > > > 74788904 237792864 - free - (141G) > > > > > > > > On this Intel based system, I can stab the F12 key to pick > > > > my UEFI bootable OS, or let it boot according to the order > > > > I setup in the BIOS=2E So far, so good=2E > > > > I needed a copy of releng/13 to also work with=2E Installed a copy > > > > from install media=2E Which left me with: > > > > # gpart show ada0 > > > > =3D> 40 312581728 ada0 GPT (149G) > > > > 40 409600 1 efi (200M) > > > > 409640 31047680 2 freebsd-ufs (15G) > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > > > > 39137320 532480 4 efi (260M) > > > > 39669800 35119104 5 freebsd-ufs (17G) > > > > 74788904 237792864 - free - (113G) > > > > I *assumed* that the install would activate the new install, and I > > > > would boot straight into it=2E But no=2E I am still on the previous > > > > install, and worse, I can't get into the new install -- even if > > > > picking it via stabbing the F12 key=2E I *still* end up in the previo= us > > > > install=2E So looking at what might be causing it=2E I found the follow= ing: > > > > # releng/12 > > > > # mount -t msdosfs /dev/ada0p1 /mnt/ > > > > > > > > # ls /mnt/efi/boot/ > > > > BOOTx64=2Eefi > > > > startup=2Ensh > > > > > > > > # cat /mnt/efi/boot/startup=2Ensh > > > > BOOTx64=2Eefi > > > > > > > > # umount /mnt/ > > > > > > > > releng/13 > > > > # mount -t msdosfs /dev/ada0p4 /mnt/ > > > > > > > > # ls /mnt/EFI/freebsd/ > > > > loader=2Eefi > > > > > > > > Why the difference? When will FreeBSD (u)EFI work as expected? > > > > > > > > Thanks in advance for any insights! > > > > > > > > > > Require only single efi part > > > > > > See > > > > > https://forums=2Efreebsd=2Eorg/threads/two-freebsd-installations-and-efi=2E73= 968/ > > Thanks for they reply, and link, Andrey! > > Well that confirms it=2E FreeBSD, unlike other OS implementations, will n= ot > > permit booting your chosen "version" via EFI=2E >=20 >=20 Firstly, *huge* thanks for your informative reply, Warner! > It does today=2E If you use efibootmgr, you can boot exactly what you want=2E= I > do it all the time=2E=2E=2E Though your BIOS may overwrite the EFI vars if you > set too many (I'm looking at you supermicro)=2E When you use the efi BootXX= XX > variables, it's possible to boot one of many different things on the > system=2E=2E=2E Though I've not done 11, just 12 and current=2E Well=2E That's the thing=2E I *am* on 12 && 13=2E Well *trying* to get into 13=2E When I started this whole thing, I had some 15 entries returned by efibootm= gr(8) -v=2E So I trimmed the list down to the 2 my BIOS presents as UEFI: Boot0015 UEFI: WDC WD1600JS-98MHB0 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xf= fff,0x0)/HD(4,GPT,6688c5af-6f93=2E=2E=2E Boot0011* UEFI: WDC WD1600JS-98MHB0 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xf= fff,0x0)/HD(1,GPT,260d2df2-6a10=2E=2E=2E another entry created when I installed releng/13: Boot0014 FreeBSD (ada0p4) HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x= 2553028,0x82000)/File(\EFI\free=2E=2E=2E and a Windows reference (currently not installed)=2E I activated *both* Boot0015 and Boot0011: efibootmgr -a 0015 0011=2E Output confirmed success=2E Bounced box, choose Boot= 0015=2E Which booted initial releng/12 install=2E Fail=2E OK Try something different; efibootmgr -a 0014 -L FreeBSD-13=2E Output confirms the -L switch is broken, = but 00114 is active=2E Bounce box && choose 0014=2E Boots to initial releng/12 install=2E Conclusion; FreeBSD EFI/ESP is not ready for prime time=2E :( Thanks again for the reply, Warner! :) --Chris >=20 >=20 > > That is; not without dropping > > to the loader prompt, or changing the status of slices, or boot entries > > prior to > > reboot=2E :( > > >=20 > Not needed=2E >=20 >=20 > > Looks like I'll need to install a third party OS, or bootmanager to use > > FreeBSD=2E > > Sigh=2E=2E=2E > > >=20 > Again, not needed=2E Though there may be a few things that need to be MFC'd > if you want 11 on that list=2E=2E=2E >=20 >=20 > > There *may* be hope in the future ( > > https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D207940) > > >=20 > This would require you to stop to select on the way up=2E=2E=2E Or am I not > understanding what you want? >=20 > We should add that functionality to loader=2Eefi, since boot1=2Eefi is in the > process of being deprecated=2E=2E=2E It should be a simple LUA script there=2E=2E=2E >=20 >=20 > > Thanks again, Andrey=2E Greatly appreciated! :) > > From owner-freebsd-current@freebsd.org Sat Mar 28 02:02:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AAB4126B896 for ; Sat, 28 Mar 2020 02:02:01 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48q25r3xBgz4QZC for ; Sat, 28 Mar 2020 02:01:52 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id 58E4E26B848; Sat, 28 Mar 2020 02:01:46 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5366326B846 for ; Sat, 28 Mar 2020 02:01:46 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q25Y6cYSz4QVF; Sat, 28 Mar 2020 02:01:37 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C7DA.dip0.t-ipconnect.de [46.82.199.218]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 02S1Ffto067027 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Mar 2020 02:15:45 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 02S1FfWd043490; Sat, 28 Mar 2020 02:15:41 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 02S1FTvb011219; Sat, 28 Mar 2020 02:15:41 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <202003280115.02S1FTvb011219@fire.js.berklix.net> To: Ed Maste cc: current Subject: Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 27 Mar 2020 21:04:33 -0400." Date: Sat, 28 Mar 2020 02:15:29 +0100 X-Rspamd-Queue-Id: 48q25Y6cYSz4QVF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.48 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.10)[-0.104,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.32)[-0.320,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(0.00)[ip: (0.02), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RSPAMD_URIBL_FAIL(0.00)[query timed out] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 02:02:01 -0000 Ed Maste wrote: > On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey wrote: > > > > l /usr/src/contrib/kyua/doc/manbuild.sh > > -rw-r--r-- 1 jhs staff 5187 Mar 25 12:34 /usr/src/contrib/kyua/doc/manbuild.sh > > Indeed, this is the problem. manbuild.sh is +x in svn and in the git > mirror, so it appears something's broken in ctm. Thanks Ed ! I've logged in on the CTM generator server to investigate. http://ctm.berklix.org Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ UK stole 750,000 votes from EU Brits: http://stolenvotes.uk http://petition.parliament.uk/petitions/300059 http://berklix.uk/brexit/#russia Limit Corona: http://berklix.eu/corona/ From owner-freebsd-current@freebsd.org Sat Mar 28 03:28:13 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4971226E5A1 for ; Sat, 28 Mar 2020 03:28:13 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q41P0lsHz3F46 for ; Sat, 28 Mar 2020 03:28:07 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 02S3SYQD078422 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 27 Mar 2020 20:28:40 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Subject: Re: When will the FreeBSD (u)EFI work? Date: Fri, 27 Mar 2020 20:28:40 -0700 Message-Id: <4f8f3e359207b923a6a3e49a1405a832@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48q41P0lsHz3F46 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.06 / 15.00]; NEURAL_HAM_MEDIUM(-0.17)[-0.172,0]; NEURAL_SPAM_LONG(0.12)[0.116,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 03:28:13 -0000 On Fri, 27 Mar 2020 18:31:50 -0700 bsd-lists@BSDforge=2Ecom said > On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh imp@bsdimp=2Ecom said >=20 > > On Fri, Mar 27, 2020 at 4:54 PM Chris wrote: > >=20 > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey@gmail=2Ecom = said > > > > > > > On Sat, Mar 28, 2020 at 12:53 AM Chris wro= te: > > > > > > > > > > On an experiment of the FreeBSD EFI implementation=2E I installed > > > > > a copy of releng/12 from install media=2E Which left me with: > > > > > # gpart show ada0 > > > > > =3D> 40 312581728 ada0 GPT (149G) > > > > > 40 409600 1 efi (200M) > > > > > 409640 31047680 2 freebsd-ufs (15G) > > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > > > > > 74788904 237792864 - free - (141G) > > > > > > > > > > On this Intel based system, I can stab the F12 key to pick > > > > > my UEFI bootable OS, or let it boot according to the order > > > > > I setup in the BIOS=2E So far, so good=2E > > > > > I needed a copy of releng/13 to also work with=2E Installed a copy > > > > > from install media=2E Which left me with: > > > > > # gpart show ada0 > > > > > =3D> 40 312581728 ada0 GPT (149G) > > > > > 40 409600 1 efi (200M) > > > > > 409640 31047680 2 freebsd-ufs (15G) > > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > > > > > 39137320 532480 4 efi (260M) > > > > > 39669800 35119104 5 freebsd-ufs (17G) > > > > > 74788904 237792864 - free - (113G) > > > > > I *assumed* that the install would activate the new install, and = I > > > > > would boot straight into it=2E But no=2E I am still on the previous > > > > > install, and worse, I can't get into the new install -- even if > > > > > picking it via stabbing the F12 key=2E I *still* end up in the prev= ious > > > > > install=2E So looking at what might be causing it=2E I found the > > following: > > > > > # releng/12 > > > > > # mount -t msdosfs /dev/ada0p1 /mnt/ > > > > > > > > > > # ls /mnt/efi/boot/ > > > > > BOOTx64=2Eefi > > > > > startup=2Ensh > > > > > > > > > > # cat /mnt/efi/boot/startup=2Ensh > > > > > BOOTx64=2Eefi > > > > > > > > > > # umount /mnt/ > > > > > > > > > > releng/13 > > > > > # mount -t msdosfs /dev/ada0p4 /mnt/ > > > > > > > > > > # ls /mnt/EFI/freebsd/ > > > > > loader=2Eefi > > > > > > > > > > Why the difference? When will FreeBSD (u)EFI work as expected? > > > > > > > > > > Thanks in advance for any insights! > > > > > > > > > > > > > Require only single efi part > > > > > > > > See > > > > > > > > > https://forums=2Efreebsd=2Eorg/threads/two-freebsd-installations-and-efi=2E73= 968/ > > > Thanks for they reply, and link, Andrey! > > > Well that confirms it=2E FreeBSD, unlike other OS implementations, will= not > > > permit booting your chosen "version" via EFI=2E > >=20 > >=20 > Firstly, *huge* thanks for your informative reply, Warner! > > It does today=2E If you use efibootmgr, you can boot exactly what you wan= t=2E I > > do it all the time=2E=2E=2E Though your BIOS may overwrite the EFI vars if y= ou > > set too many (I'm looking at you supermicro)=2E When you use the efi Boot= XXXX > > variables, it's possible to boot one of many different things on the > > system=2E=2E=2E Though I've not done 11, just 12 and current=2E > Well=2E That's the thing=2E I *am* on 12 && 13=2E Well *trying* to get into 13=2E > When I started this whole thing, I had some 15 entries returned by > efibootmgr(8) -v=2E > So I trimmed the list down to the 2 my BIOS presents as UEFI: > Boot0015 UEFI: WDC WD1600JS-98MHB0 > PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(4,GPT,6688c5af-6f93=2E=2E=2E > Boot0011* UEFI: WDC WD1600JS-98MHB0 > PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(1,GPT,260d2df2-6a10=2E=2E=2E > another entry created when I installed releng/13: > Boot0014 FreeBSD (ada0p4) > HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EF= I\free=2E=2E=2E > and a Windows reference (currently not installed)=2E > I activated *both* Boot0015 and Boot0011: > efibootmgr -a 0015 0011=2E Output confirmed success=2E Bounced box, choose > Boot0015=2E Which booted > initial releng/12 install=2E Fail=2E OK Try something different; > efibootmgr -a 0014 -L FreeBSD-13=2E Output confirms the -L switch is broken= , > but 00114 is active=2E > Bounce box && choose 0014=2E Boots to initial releng/12 install=2E >=20 > Conclusion; FreeBSD EFI/ESP is not ready for prime time=2E :( >=20 > Thanks again for the reply, Warner! :) >=20 > --Chris > >=20 > >=20 > > > That is; not without dropping > > > to the loader prompt, or changing the status of slices, or boot entri= es > > > prior to > > > reboot=2E :( > > > > >=20 > > Not needed=2E > >=20 > >=20 > > > Looks like I'll need to install a third party OS, or bootmanager to u= se > > > FreeBSD=2E > > > Sigh=2E=2E=2E > > > > >=20 > > Again, not needed=2E Though there may be a few things that need to be MFC= 'd > > if you want 11 on that list=2E=2E=2E > >=20 > >=20 > > > There *may* be hope in the future ( > > > https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D207940) > > > > >=20 > > This would require you to stop to select on the way up=2E=2E=2E Or am I not > > understanding what you want? > >=20 > > We should add that functionality to loader=2Eefi, since boot1=2Eefi is in t= he > > process of being deprecated=2E=2E=2E It should be a simple LUA script there=2E=2E= =2E Isn't everything confined to stand/ ? I'd like to try and write all this so that FreeBSD performs EFI/ESP booting in a more intuitive way=2E It seems odd to me, that I can install Windows, an= d it'll add FreeBSD to the (efi) boot menu, but not vis-a-vis=2E --Chris > >=20 > >=20 > > > Thanks again, Andrey=2E Greatly appreciated! :) > > > >=20 >=20 > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Sat Mar 28 06:31:34 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5F24E271BA3; Sat, 28 Mar 2020 06:31:34 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q84s2qnxz3Ndq; Sat, 28 Mar 2020 06:31:24 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id p10so14354579wrt.6; Fri, 27 Mar 2020 23:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=gCRr12nEWATdKy7KVNvTzWrukmqkgg7fa1+RdL6xk8w=; b=p0uB+/5rl8rkl95YToKsDsY1g3o3o9G2GnJyhBEb1Sqqzb5KZ9eeOjkITlOoWZwXEy UScKQPygdCoRQcOFx1C4ejDJedyUON8VBZIYIMRcSr4lKEY/4Jm3nrgQiP2cjhtdOaSD umn5L2EV3x1PvgRlVeuTCEmVPjzOqV/ntFck34RcAbcwuiar8WOCYRhUNKACOFDKd7qt yhE5BoqVOs5Z0jUVkiN3UP7k6eFSItXOZ6AILKbCCpMKRu1ugmDvyKytvyAneNkIgjy2 7C/bxvSRSXh4LSqIy9EQEXcT56Bqp00AaqMNweCR84kJkz/OGIn7XTCvcKCRHDNTMJxj yNsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=gCRr12nEWATdKy7KVNvTzWrukmqkgg7fa1+RdL6xk8w=; b=XOEhqsQJTxEL9vRuKKhN63Z2ALiYX4aQ+Oo29aeWd1E1YOvegm2YB8I/rhxgxHv6Gx tYO9yyrVmFgN1BlYRZmdeAZqgCKueaKIPPPDE0Y6pP1TpW8QjDOT787fvg7Osqvvi47u Yvb6NEr9mEaRfM0Po4noophLyU9SGfaNOU4/snLvLm7K4F+txrUKBWcg1aNYfV0npngg D1IAlXTAcHeH75ZxE95bn0X5JkEd9B/ZzPnfmnz/ijZAU5D5mnmRBRyX98ZDwp67/suL Knn24kSdeJjDRuIjcm3YDwyikVu8+C9vNd+fTpRJZMH+s4UagPZ3hwLNX6dMZcg6J6Fp 6pMA== X-Gm-Message-State: ANhLgQ2yiYq9v5YyAoIxWL29BVVjaw3vKZQiAR65GO7SGR0CmKEgitiq I05I7OMxrJBlfVqO96GSwLA0lnxG2OA= X-Google-Smtp-Source: ADFU+vvu/G/GI8s2WZJcd0XJfM04gAjeiCdSjVaRniaCw+95kaR1AUezh4qNJgteLmq9lNx4K7T1nw== X-Received: by 2002:a5d:490f:: with SMTP id x15mr3173305wrq.47.1585377073583; Fri, 27 Mar 2020 23:31:13 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id n2sm12341249wro.25.2020.03.27.23.31.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Mar 2020 23:31:12 -0700 (PDT) To: freebsd-current@freebsd.org Cc: FreeBSD questions From: Graham Perrin Subject: USB microphones with FreeBSD-CURRENT Message-ID: <5c93c4d2-897b-0671-b29a-9fde6031adf5@gmail.com> Date: Sat, 28 Mar 2020 06:31:11 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 48q84s2qnxz3Ndq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=p0uB+/5r; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[78.147.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-9.24), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.47), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[a.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 06:31:34 -0000 I can't get web browsers to recognise USB microphones. USB output (e.g. to my headphones) is OK. USB input (e.g. from the microphone part of the headphones) is not. Any suggestions? From : grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v Sun 22 Mar 2020 08:49:07 GMT FreeBSD 13.0-CURRENT #0 r359068: Wed Mar 18 21:14:12 GMT 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG grahamperrin@momh167-gjp4-8570p:~ % cat /dev/sndstat Installed devices: pcm0: (play) pcm1: (play/rec) pcm2: (play/rec) pcm3: (play/rec) default pcm4: (rec) No devices installed from userspace. grahamperrin@momh167-gjp4-8570p:~ % sysctl hw.snd.default_unit hw.snd.default_unit: 3 grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' firefox www/firefox 74.0_5,1 FreeBSD grahamperrin@momh167-gjp4-8570p:~ % From owner-freebsd-current@freebsd.org Sat Mar 28 06:43:41 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E006327210B for ; Sat, 28 Mar 2020 06:43:41 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q8Lp3Hw6z3xr7 for ; Sat, 28 Mar 2020 06:43:29 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x441.google.com with SMTP id j17so14304497wru.13 for ; Fri, 27 Mar 2020 23:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=NQmuGBrkHyikY8qqeumuuSVr8trI3mk5GKtoSSGc/Uk=; b=mt6hBGBczlPnFfDaIydaEWRDGNZyV/b4g1Lsh0p0PkaCem/pM04UntHp5fjvaZrWvw 0ADSAqSw+vofi02EiL4OtYTjK6d8LUEeNtHoxSej1x7hepGt1OPVnyCu4WqHgjBuQJIZ BQWUTw6zqTKl7sa3DZEFF1xSvneQ1A8i3mFdJ8NBuSmABEm71mo6D2krI3LJtzQx2Gvi BTPapHkXGFtO7PvBGoHFf8KSY+wqSF/btKr2RNxoyM4dTRSlukV86xXQ5BErQnMFTyfz XEjAThSzJuFihNCIfsqeyWogiXNmVY5oSt0q2NJDuaml8CDexh7OO1/oenbCsYngSypk 90sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=NQmuGBrkHyikY8qqeumuuSVr8trI3mk5GKtoSSGc/Uk=; b=bMapTEyQk9+XAgFIoiiBcgmW41kdVo0PLUXmkjD4Ur78CDLoZ7dHNZuWM88Myr/1zH jVw02sC2ujLY59TF+1y8VqcHCR4DN7tfNE/T65zDlgtJMYYfU6X1ASGZanU/yP3xwnTV r3DOO6GX1Da/Pvv2OSP1GeospEyQxnSXnlvPoUqREbEkQyxHzx8T1DBeCfWActOigwpb izYllSbJDmh+2QVyP1d/J0kR1GOUebDObz4D7wIrhzV0o33Kavf/9IFHojVeqDA2KyEU WDtkpudGwBhNTA5o3C2xHtuXVDV+Kq24j5NGhOeCmUSC6sG0OtCRtWnX9ozOH/v7Z17U LryQ== X-Gm-Message-State: ANhLgQ0SMPd7gmZ0A+741m8FmDJPdKtDirCNZFuz7ONzbOF5k6wzYtLD nt1sN9v9M8ps+Ol3IjO/ZhFI5HqaZ/0= X-Google-Smtp-Source: ADFU+vvgmo+czSJVNvfo3gJbcnf+H7BomBEvMyzjfhriSLPSW1u/LvUIwu5NkwnGPSrajuUCZdlKSg== X-Received: by 2002:adf:e98a:: with SMTP id h10mr3458942wrm.370.1585377800666; Fri, 27 Mar 2020 23:43:20 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id a192sm11754555wme.5.2020.03.27.23.43.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Mar 2020 23:43:20 -0700 (PDT) To: freebsd-current@freebsd.org From: Graham Perrin Subject: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max' Message-ID: <87190f4d-4b0a-ce41-fd16-503baf9c6125@gmail.com> Date: Sat, 28 Mar 2020 06:43:19 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 48q8Lp3Hw6z3xr7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=mt6hBGBc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::441 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.00)[ip: (2.52), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.47), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[78.147.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[1.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 06:43:42 -0000 This occurs when I enable OpenZFS: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max' Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD? From : grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max sysctl: unknown oid 'vfs.zfs.arc_max' grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v Wed 25 Mar 2020 04:52:22 GMT FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG grahamperrin@momh167-gjp4-8570p:~ % kldstat | grep zfs  2    1 0xffffffff82108000   58ac58 openzfs.ko grahamperrin@momh167-gjp4-8570p:~ % grep zfs /boot/loader.conf # zfs_load="YES" openzfs_load="YES" grahamperrin@momh167-gjp4-8570p:~ % grep zfs /etc/sysctl.conf vfs.zfs.min_auto_ashift=12 # HP EliteBook 8570p 16 GB memory vfs.zfs.arc_max defaults to 15523106816 # vfs.zfs.arc_max="7761553408" vfs.zfs.arc_max="2147483648" grahamperrin@momh167-gjp4-8570p:~ % zfs-stats -a … From owner-freebsd-current@freebsd.org Sat Mar 28 06:54:02 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2B1772724F5 for ; Sat, 28 Mar 2020 06:54:02 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q8Zh4nzcz42Bk for ; Sat, 28 Mar 2020 06:53:46 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 02S6rWkY078581 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Mar 2020 23:53:32 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 02S6rVt2078580; Fri, 27 Mar 2020 23:53:31 -0700 (PDT) (envelope-from jmg) Date: Fri, 27 Mar 2020 23:53:31 -0700 From: John-Mark Gurney To: Rick Macklem Cc: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <20200328065331.GU4213@funkthat.com> Mail-Followup-To: Rick Macklem , Alexander Leidinger , "freebsd-current@FreeBSD.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 27 Mar 2020 23:53:33 -0700 (PDT) X-Rspamd-Queue-Id: 48q8Zh4nzcz42Bk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.13 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.38)[ip: (-0.98), ipnet: 208.87.216.0/21(-0.49), asn: 32354(-0.39), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.55)[-0.552,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.40)[-0.401,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 06:54:02 -0000 Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +0000: > John-Mark Gurney wrote: > [lots of stuff snipped] > >Rick Macklem wrote: > >> I had originally planned on some "secret" in the certificate (like a CN name > >> that satisfies some regular expression or ???) but others convinced me that > >> that wouldn't provide anything beyond knowing that the certificate was > >> signed by the appropriate CA, so I have not implemented anything. > > > >Yeah, having a "secret" in the CN doesn't make sense, but what does make > >sense is allowing the exports line to specify what the CN should contain > >to be authenticated... > > > >Say as a corp, you issue personal certificates to everyone. This is > >because you require everyone to sign and/or encrypt their email w/ > >S/MIME. Each cert includes the email address of that person, so you > >could simply do something like: > >/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com > > > >And anyone who has the certificate w/ alice@example.com that was signed > >by the public key in /etc/company.pem would be granted access to the > >export /home/alice. > > > >If it allowed ANY cert signed by the CA specified, then that introduces > >an authentication problem, as now if Malory is a coworker of Alice > >could also access Alice's home directory... > > > >IMO, this is one auth feature that MUST be supported... > The draft does not address user authentication, only machine authentication. > --> ie. The certificate is used to decide if a system can do a mount. > Users are still identified via user credentials in the RPC message header. > For AUTH_SYS, that still means . > Otherwise, you need to use Kerberos (sec=krb5[ip]). > You could use "tls,sec=krb5" for a mount, but the only advantage that > might have over "sec=krb5p" is performance, if there is hardware assist > for TLS or something like that. > > >Now that I reread your comments, it sounds like any certificate would be > >allowed in #2 as long as it is valid, and that would only be marginally > >better than verification by IP, and in some ways worse, in that now any > >user could pretend to be any other user, or you have to do something > >crazy like have a CA per user. > The case where I see #2 is useful is where this discussion started some weeks ago. > The example I started with was: > /home -tls -network 192.168.1.0 -mask 255.255.255.0 > /home -tlscert > > This says that machines on the local lan can mount and do not need to have > certificates, but must use TLS so data is encrypted on the wire. > Mounts from anywhere else (presumably laptops) are allowed so long as they have a > certificate signed by me (as in the site local CA). > I trust these machines enough that I am willing to allow them to use AUTH_SYS, > which is what 99.9...% of NFS mounts do now. > (So, I'd agree that the site local certificate is not a lot better than IP address > for client machine identity, just that it is an alternative that can be useful. > Without TLS, a line like "/home" allows anyone to mount /home from anywhere > and I think you'd agree that few NFS admins. will want to do that. I'm assuming > no external firewall for this example.) > > Now, your suggestion of identifying a user via the CN and then having the > server do all RPCs for the mount as that user is an interesting one. > My concern w.r.t. implementing it would be interoperability. > Put another way, if other servers such as Linux, Netapp,... don't adopt it > (and they won't until there is a draft/RFC specifying it), it would be > FreeBSD server specific and I'd like to avoid that. > There was some discussion w.r.t. user authentication via certificates > during development of the draft, but they decided to defer that work for > now, so they could get something in place for machine authentication first. > (If I understood the discussion on nfsv4@ietf.org.) There's a fine line between machine and user authentication when you can add -mapall=someuser. :) Yes, a certificate may be used to identify a machine, but if any machine can be identified by any cert as it appears that #2 is proposed to do, then you're not actually identifying a machine, you're identifying group of machines... Though per the draft, this is explicitly allowed. It'd be nice to be able to identify particular machines though, and be able to set the options based upon that.. > >I'm wonder if your use of the term secret was the problem, and not the > >idea... Anything that goes in the client cert is by definition public... > >TLS prior to 1.3 sends the client cert in clear text... But keying > >based upon the contents of the cert is fine, as that's the point of > >what a cert is.. It's trusting the CA to say that the CN and other > >fields in the cert corresponds to this user, and you can use parts of > >the cert, like the CN to decide which user the public key in the cert > >corresponds to. Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:59 +0000: > Sorry about the top post, but I thought of a few things to add to my > last post to this thread... > 1 - I agree that for systems like laptops, the line between machine and > user authentication is fuzzy. yep, exactly. IMO, laptops are more important for this work, and where you want to identify per machine at a finer grain level than server machines... > 2 - I do like your idea of having an exports(5) option that specifies a CN > that identifies a user and then does all RPCs as that user. > I'm not sure if an issuer needs to be specified (or even can be specified), > since the CAfile argument to the rpctlssd daemon determines if a certificate > from a particular CA will verify and the verification must happen before the > exports(5) export options can be applied. (Basically, certificate verification > happens via a NULL RPC that does a STARTTLS when a TCP connection to > the server is first established.) Yeah, this will need some work, but IMO is fine as a future improvement... Yeah, this could be a bit tricky from a code perspective.. I don't know how well most SSL libraries are being able to auth client certs via different roots after the fact... One option, but maybe not a great option would be to verify the cert after the connection is established.. You could extract the cert identify the candidate export lines, and then attempt a cert verification w/ a specified root if a default one isn't specified... Not exactly clean, but as long as the client can't proceed without this check, shouldn't be a major problem... > 3 - I'll post to nfsv4@ietf.org to see what others think of this, since it would not > require any changes to the draft/RFC. > 4 - Although it does require a revision to the export_args structure, I think it is > worth doing even if others don't implement it. Thanks. Let me know if you'd like code reviews as well... > Again, thanks for your comments, rick And thanks for doing the work! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Sat Mar 28 07:24:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1B214272F70 for ; Sat, 28 Mar 2020 07:24:42 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q9G63Rdmz4DD4 for ; Sat, 28 Mar 2020 07:24:30 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id w10so14475297wrm.4 for ; Sat, 28 Mar 2020 00:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=TgtLsQRnh6Q1Uwtr/bdELRo2fJQK68WjULg1JTfEvy0=; b=qilKZ2O4r6uZmFMzCGOA4hBarCvSzFGVKL1zHMW97LRsMD+JIfmDCRUwhUhx6G1+wU GamPMHw9BGkM65T+98H69Wfa8EwzVP+sVSHdhaZnAsZPnENJ7OiUPFAVVsA3iqGEt9BT +AGmgDW79h7u+vgjqRyLT5EXS0Yn9cBJzay7VhzWrhVWtw8BSJRTaBMrpYLa6OpDNK/Z GwKhc1SKHs8EhfDxKx25skfGCUBbqVRbSzX0W0SvyVrVog0mxAxx64laRk6lQTHAtVgz 5+0aEsQAbTFIRtlBtTiH5H28AhF7YJdvBzxbkcx2g14VXTg4hA3OXWTBIb3r+uH4Njxl 3VCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=TgtLsQRnh6Q1Uwtr/bdELRo2fJQK68WjULg1JTfEvy0=; b=aI9eHEsz4/0GF+wD+L4HabXeFk/HMyWtgUvRvzfoHuK8QUjsDsOCSRuDFGibahMtD5 jdkWyKx4U5QHu0grCt1Bet3ZC+nIAOUoaiOTAJEt06wRXFJ2eHd6p2A94NZcCZjPES84 RJeIfXU+MIj2QYKYAgPRGm+VSHBN4hPhpOAdLLYnCpWYSuG2R22U+qA+NAvlySIvWx24 DI3bSYVFvKSUDP0Ln0S89sGtIt6+oQEqAa8gXSrb2hYSNgLWmF9OxnMj9N1CLT2st3+t FMe9dFM8H7MWVhIpesW9OG4Z6VFrAHqrjE3WM+NjK/UTCwI7WnRvtPk3gYTvrm7CRpAT onyQ== X-Gm-Message-State: ANhLgQ0BeY+9kbRJhrRMOV7C5o7KrPeNLJYwd51Vx+zW+kZfAGpCc4Tx gUyaCY0zqlpNJTrLkIBM/VjubuK2g3c= X-Google-Smtp-Source: ADFU+vurV4aTQVnI1vXS2h4T0zQ+6LVSCmzdDimgG0XxO5+m793vc3ynT6S4fTDuUJ5tpJ4V+ky7iw== X-Received: by 2002:adf:f50d:: with SMTP id q13mr3626203wro.374.1585380258405; Sat, 28 Mar 2020 00:24:18 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id l12sm11573155wrt.73.2020.03.28.00.24.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Mar 2020 00:24:17 -0700 (PDT) To: freebsd-current@freebsd.org From: Graham Perrin Subject: ZFS: destroying snapshots without compromising boot environments Message-ID: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> Date: Sat, 28 Mar 2020 07:24:17 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 48q9G63Rdmz4DD4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qilKZ2O4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::433 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[78.147.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.09), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.47), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[3.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 07:24:42 -0000 I imagine that some of the 2019 snapshots below are redundant. Can I safely destroy any of them? $ zfs list -t snapshot NAME                                                     USED AVAIL  REFER  MOUNTPOINT copperbowl/ROOT/Waterfox@2020-03-20-06:19:45            67.0M -  59.2G  - copperbowl/ROOT/r359249b@2019-08-18-04:04:53            5.82G -  40.9G  - copperbowl/ROOT/r359249b@2019-08-18-11:28:31            4.32G -  40.7G  - copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0          9.43G -  43.4G  - copperbowl/ROOT/r359249b@2019-09-19-20:03:26            5.13G -  43.3G  - copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0          7.67G -  44.6G  - copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0          7.66G -  55.2G  - copperbowl/ROOT/r359249b@2020-01-11-14:15:47            7.41G -  56.2G  - copperbowl/ROOT/r359249b@2020-03-17-21:57:17            12.0G -  59.2G  - copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers     8K -  1.24G  - copperbowl/poudriere/jails/head@clean                    328K -  1.89G  - $ beadm list BE       Active Mountpoint  Space Created Waterfox -      -           12.2G 2020-03-10 18:24 r357746f -      -            1.3G 2020-03-20 06:19 r359249b NR     /          148.9G 2020-03-28 01:19 $ beadm list -aDs BE/Dataset/Snapshot                              Active Mountpoint  Space Created Waterfox   copperbowl/ROOT/Waterfox                       -      - 137.0M 2020-03-10 18:24     r359249b@2020-03-17-21:57:17                 - -           59.2G 2020-03-17 21:57   copperbowl/ROOT/Waterfox@2020-03-20-06:19:45   - -           67.0M 2020-03-20 06:19 r357746f   copperbowl/ROOT/r357746f                       - -            1.2G 2020-03-20 06:19     Waterfox@2020-03-20-06:19:45                 - -           59.2G 2020-03-20 06:19 r359249b   copperbowl/ROOT/r359249b@2019-08-18-04:04:53   - -            5.8G 2019-08-18 04:04   copperbowl/ROOT/r359249b@2019-08-18-11:28:31   - -            4.3G 2019-08-18 11:28   copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - -            9.4G 2019-09-13 18:45   copperbowl/ROOT/r359249b@2019-09-19-20:03:26   - -            5.1G 2019-09-19 20:03   copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - -            7.7G 2019-09-24 20:45   copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - -            7.7G 2020-01-09 17:05   copperbowl/ROOT/r359249b@2020-01-11-14:15:47   - -            7.4G 2020-01-11 14:15   copperbowl/ROOT/r359249b@2020-03-17-21:57:17   - -           12.0G 2020-03-17 21:57   copperbowl/ROOT/r359249b                       NR /           59.0G 2020-03-28 01:19 $ From owner-freebsd-current@freebsd.org Sat Mar 28 09:08:03 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D2913275854 for ; Sat, 28 Mar 2020 09:08:03 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztbu10021601.me.com (pv50p00im-ztbu10021601.me.com [17.58.6.57]) (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 48qCYP5t7Jz3NR5 for ; Sat, 28 Mar 2020 09:07:53 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztbu10021601.me.com (Postfix) with ESMTPSA id 5EA6A6E0578; Sat, 28 Mar 2020 09:07:41 +0000 (UTC) From: Toomas Soome Message-Id: <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: When will the FreeBSD (u)EFI work? Date: Sat, 28 Mar 2020 11:07:38 +0200 In-Reply-To: <4f8f3e359207b923a6a3e49a1405a832@udns.ultimatedns.net> Cc: freebsd-current@freebsd.org To: "bsd-lists@bsdforge.com" References: <4f8f3e359207b923a6a3e49a1405a832@udns.ultimatedns.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-03-28_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2003280086 X-Rspamd-Queue-Id: 48qCYP5t7Jz3NR5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[148.52.235.80.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[57.6.58.17.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(0.00)[ip: (-5.36), ipnet: 17.58.0.0/20(-2.06), asn: 714(-2.42), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_LOW(-1.00)[me.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 09:08:03 -0000 > On 28. Mar 2020, at 05:28, Chris wrote: >=20 > On Fri, 27 Mar 2020 18:31:50 -0700 bsd-lists@BSDforge.com = said >=20 >> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh imp@bsdimp.com said >> > On Fri, Mar 27, 2020 at 4:54 PM Chris = wrote: >> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko = f0andrey@gmail.com said >> > > >> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris = wrote: >> > > > > >> > > > > On an experiment of the FreeBSD EFI implementation. I = installed >> > > > > a copy of releng/12 from install media. Which left me with: >> > > > > # gpart show ada0 >> > > > > =3D> 40 312581728 ada0 GPT (149G) >> > > > > 40 409600 1 efi (200M) >> > > > > 409640 31047680 2 freebsd-ufs (15G) >> > > > > 31457320 7680000 3 freebsd-swap (3.7G) >> > > > > 74788904 237792864 - free - (141G) >> > > > > >> > > > > On this Intel based system, I can stab the F12 key to pick >> > > > > my UEFI bootable OS, or let it boot according to the order >> > > > > I setup in the BIOS. So far, so good. >> > > > > I needed a copy of releng/13 to also work with. Installed a = copy >> > > > > from install media. Which left me with: >> > > > > # gpart show ada0 >> > > > > =3D> 40 312581728 ada0 GPT (149G) >> > > > > 40 409600 1 efi (200M) >> > > > > 409640 31047680 2 freebsd-ufs (15G) >> > > > > 31457320 7680000 3 freebsd-swap (3.7G) >> > > > > 39137320 532480 4 efi (260M) >> > > > > 39669800 35119104 5 freebsd-ufs (17G) >> > > > > 74788904 237792864 - free - (113G) >> > > > > I *assumed* that the install would activate the new install, = and I >> > > > > would boot straight into it. But no. I am still on the = previous >> > > > > install, and worse, I can't get into the new install -- even = if >> > > > > picking it via stabbing the F12 key. I *still* end up in the = previous >> > > > > install. So looking at what might be causing it. I found the >> > following: >> > > > > # releng/12 >> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/ >> > > > > >> > > > > # ls /mnt/efi/boot/ >> > > > > BOOTx64.efi >> > > > > startup.nsh >> > > > > >> > > > > # cat /mnt/efi/boot/startup.nsh >> > > > > BOOTx64.efi >> > > > > >> > > > > # umount /mnt/ >> > > > > >> > > > > releng/13 >> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/ >> > > > > >> > > > > # ls /mnt/EFI/freebsd/ >> > > > > loader.efi >> > > > > >> > > > > Why the difference? When will FreeBSD (u)EFI work as = expected? >> > > > > >> > > > > Thanks in advance for any insights! >> > > > > >> > > > >> > > > Require only single efi part >> > > > >> > > > See >> > > > >> > > >> > = https://forums.freebsd.org/threads/two-freebsd-installations-and-efi.73968= / >> > > Thanks for they reply, and link, Andrey! >> > > Well that confirms it. FreeBSD, unlike other OS implementations, = will not >> > > permit booting your chosen "version" via EFI. >> > > Firstly, *huge* thanks for your informative reply, Warner! >> > It does today. If you use efibootmgr, you can boot exactly what you = want. I >> > do it all the time... Though your BIOS may overwrite the EFI vars = if you >> > set too many (I'm looking at you supermicro). When you use the efi = BootXXXX >> > variables, it's possible to boot one of many different things on = the >> > system... Though I've not done 11, just 12 and current. >> Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into = 13. >> When I started this whole thing, I had some 15 entries returned by >> efibootmgr(8) -v. >> So I trimmed the list down to the 2 my BIOS presents as UEFI: >> Boot0015 UEFI: WDC WD1600JS-98MHB0 >> = PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(4,GPT,6688c5af-6f93... >> Boot0011* UEFI: WDC WD1600JS-98MHB0 >> = PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(1,GPT,260d2df2-6a10... >> another entry created when I installed releng/13: >> Boot0014 FreeBSD (ada0p4) >> = HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\EFI= \free... >> and a Windows reference (currently not installed). >> I activated *both* Boot0015 and Boot0011: >> efibootmgr -a 0015 0011. Output confirmed success. Bounced box, = choose >> Boot0015. Which booted >> initial releng/12 install. Fail. OK Try something different; >> efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is = broken, >> but 00114 is active. >> Bounce box && choose 0014. Boots to initial releng/12 install. >> Conclusion; FreeBSD EFI/ESP is not ready for prime time. :( >> Thanks again for the reply, Warner! :) >> --Chris How loader is working is that it does search for *first* =E2=80=9Cusable=E2= =80=9D freebsd partition and will use it. Usable is defined as having = /boot/loader.efi. Therefore, you may have 2 or more freebsd instances on the disk, it = really does not matter, only first is used. If you have multiple disks, = you can have different order on second disk. Why it is so? We do build loader.efi and we do copy it to the ESP, and = currently there is no way to tell where is the root file system. How could we tell where from to load the OS? Well, there are few options = to think about: 1. record the hint into the loader.efi binary - this would need special = installer and would break signing. 2. record EFI variable - it should reflect OS instance version and that = version should be bound with specific loader binary. Coordination is = pain there. 3. record partition to loader.env file=20 The current loader code is reading "/efi/freebsd/loader.env=E2=80=9D = from ESP. IMO this sounds most promising, but would need support from = installer or manual setup. Would work as is with multiple ESP instances. = Would need versioned /efi/freebsdXX directories for single shared ESP = and installer update. 4. We still do have BE menu in loader, populated automatically from zfs = snapshots. It can be complemented with entries from file based index (I = wrote about that idea already). This would allow to create simple switch = to different instance or initiate chain load of third party boot loader. just few bits, toomas >> > > > > That is; not without dropping >> > > to the loader prompt, or changing the status of slices, or boot = entries >> > > prior to >> > > reboot. :( >> > > >> > > Not needed. >> > > > > Looks like I'll need to install a third party OS, or = bootmanager to use >> > > FreeBSD. >> > > Sigh... >> > > >> > > Again, not needed. Though there may be a few things that need to = be MFC'd >> > if you want 11 on that list... >> > > > > There *may* be hope in the future ( >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207940) >> > > >> > > This would require you to stop to select on the way up... Or am I = not >> > understanding what you want? >> > > We should add that functionality to loader.efi, since boot1.efi = is in the >> > process of being deprecated... It should be a simple LUA script = there... > Isn't everything confined to stand/ ? > I'd like to try and write all this so that FreeBSD performs EFI/ESP = booting > in a more intuitive way. It seems odd to me, that I can install = Windows, and > it'll add FreeBSD to the (efi) boot menu, but not vis-a-vis. >=20 > --Chris >> > > > > Thanks again, Andrey. Greatly appreciated! :) >> > > >> _______________________________________________ >> 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 = " >=20 >=20 > _______________________________________________ > 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-current@freebsd.org Sat Mar 28 09:31:58 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6E17276011; Sat, 28 Mar 2020 09:31:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48qD4w1wBlz42Kt; Sat, 28 Mar 2020 09:31:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id CE30226003E; Sat, 28 Mar 2020 10:31:32 +0100 (CET) Subject: Re: USB microphones with FreeBSD-CURRENT To: Graham Perrin , freebsd-current@freebsd.org Cc: FreeBSD questions References: <5c93c4d2-897b-0671-b29a-9fde6031adf5@gmail.com> From: Hans Petter Selasky Message-ID: Date: Sat, 28 Mar 2020 10:31:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <5c93c4d2-897b-0671-b29a-9fde6031adf5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48qD4w1wBlz42Kt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.67)[ip: (-9.20), ipnet: 2a01:4f8::/29(-2.59), asn: 24940(-1.56), country: DE(-0.02)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 09:31:58 -0000 On 2020-03-28 07:31, Graham Perrin wrote: > I can't get web browsers to recognise USB microphones. > > USB output (e.g. to my headphones) is OK. > > USB input (e.g. from the microphone part of the headphones) is not. > > Any suggestions? > > From : > What are the mixer values? mixer -f /dev/mixerN Are you sure the volume is set high enough? --HPS From owner-freebsd-current@freebsd.org Sat Mar 28 11:26:40 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5FC6F2789B4 for ; Sat, 28 Mar 2020 11:26:40 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qGd80Stvz3GGV for ; Sat, 28 Mar 2020 11:26:19 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id cf14so14707921edb.13 for ; Sat, 28 Mar 2020 04:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sg48IdkpIlEGbGjV7I0sBugSaRs17pvcx0ogapg6JQA=; b=u9zLrVYyg83UmSMz6w1bMLl5EiR2CJSGOsNemBhlBKbl3j0W5NRgSjksNa89eNBl1l Vh1UaSwcAG1Tvgnz1xvNwRtnABClNrfX/1wg1lBT37F2sOr4nC08k2neTVRZs5mdwDhc UbzfcpMVUJteB53a09BO4jKX3z/62qpKfrJ+T2KSWEzl8u0eWkxPnw/hVKfFI0BPQTXa EJz4AG6PSGU3D8lO3CxR9DPiZQlakuFWELZ75nNOVcs4UyLToOX0arBf27iMpmahQMdx 9QcQ8+4Ootna4VlWjgxfJ5dNW7DAg12dNPUvmTTsKl8evRnB+9pUaPNEgcmYAk+ShVB8 O7jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sg48IdkpIlEGbGjV7I0sBugSaRs17pvcx0ogapg6JQA=; b=NgG8ERs177EPRo/7KxhPbXvZVC/4/dzwY+bTJ2VwT1IhaJFuD/R+FtcQxQ9GJXAOkV +acimP45wGryCVAZEuoXZcIF3vM5f59/ZS9y1y34MHh/47NEQC/tdVdHyC8iP6HsZ2YC JsgG8UcNuCDbHgGetcRvXNbvRJ0jOYkXZSNKsrIJrnBYJcmlz57nAJ1tSxiQKho4AWsY GQ5yYs1qpd7bbLoTAT569062EtQl5mg8vd++gee9mg/QHbecLFriIP8ndgJS9Jowq7Qb oX3POQS0tqFisD08ApWK6d9PezwUznr/BIQuJYwA6oIOYFcb7wtKHJqrULb22uflJuO6 1CUw== X-Gm-Message-State: ANhLgQ0OTl8AVhYN1Oth4hg3kE7gdqR6gK9Jf2kXyioS2uX21B+hZh0N ofjj2yTQTLZ2x1vVKIGVIEfd/305GXDac2Xa6o6GtbHC X-Google-Smtp-Source: ADFU+vsgRpZV7edxCwy+1i6uHiEIcT7MBE0CeKJGs2JmKAu8BQkTZuvvJ65ZnvD//tAJ+sD8qpWUS7aqzaaxVEVrS3I= X-Received: by 2002:adf:d0cb:: with SMTP id z11mr4495237wrh.1.1585394284301; Sat, 28 Mar 2020 04:18:04 -0700 (PDT) MIME-Version: 1.0 References: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> In-Reply-To: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> From: Andrey Fesenko Date: Sat, 28 Mar 2020 14:17:53 +0300 Message-ID: Subject: Re: ZFS: destroying snapshots without compromising boot environments To: Graham Perrin Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48qGd80Stvz3GGV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=u9zLrVYy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of f0andrey@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=f0andrey@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-9.59), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.47), country: US(-0.05)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 11:26:40 -0000 On Sat, Mar 28, 2020 at 10:30 AM Graham Perrin wrote: > > I imagine that some of the 2019 snapshots below are redundant. > > Can I safely destroy any of them? > > $ zfs list -t snapshot > NAME USED AVAIL > REFER MOUNTPOINT > copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 67.0M - 59.2G - > copperbowl/ROOT/r359249b@2019-08-18-04:04:53 5.82G - 40.9G - > copperbowl/ROOT/r359249b@2019-08-18-11:28:31 4.32G - 40.7G - > copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 9.43G - 43.4G - > copperbowl/ROOT/r359249b@2019-09-19-20:03:26 5.13G - 43.3G - > copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 7.67G - 44.6G - > copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 7.66G - 55.2G - > copperbowl/ROOT/r359249b@2020-01-11-14:15:47 7.41G - 56.2G - > copperbowl/ROOT/r359249b@2020-03-17-21:57:17 12.0G - 59.2G - > copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G - > copperbowl/poudriere/jails/head@clean 328K - 1.89G - > $ beadm list > BE Active Mountpoint Space Created > Waterfox - - 12.2G 2020-03-10 18:24 > r357746f - - 1.3G 2020-03-20 06:19 > r359249b NR / 148.9G 2020-03-28 01:19 > $ beadm list -aDs > BE/Dataset/Snapshot Active Mountpoint > Space Created > > Waterfox > copperbowl/ROOT/Waterfox - - 137.0M > 2020-03-10 18:24 > r359249b@2020-03-17-21:57:17 - - 59.2G > 2020-03-17 21:57 > copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 - - 67.0M > 2020-03-20 06:19 > > r357746f > copperbowl/ROOT/r357746f - - 1.2G > 2020-03-20 06:19 > Waterfox@2020-03-20-06:19:45 - - 59.2G > 2020-03-20 06:19 > > r359249b > copperbowl/ROOT/r359249b@2019-08-18-04:04:53 - - 5.8G > 2019-08-18 04:04 > copperbowl/ROOT/r359249b@2019-08-18-11:28:31 - - 4.3G > 2019-08-18 11:28 > copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - - 9.4G > 2019-09-13 18:45 > copperbowl/ROOT/r359249b@2019-09-19-20:03:26 - - 5.1G > 2019-09-19 20:03 > copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - - 7.7G > 2019-09-24 20:45 > copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - - 7.7G > 2020-01-09 17:05 > copperbowl/ROOT/r359249b@2020-01-11-14:15:47 - - 7.4G > 2020-01-11 14:15 > copperbowl/ROOT/r359249b@2020-03-17-21:57:17 - - 12.0G > 2020-03-17 21:57 > copperbowl/ROOT/r359249b NR / 59.0G > 2020-03-28 01:19 > $ beadm destroy ? ;) From owner-freebsd-current@freebsd.org Sat Mar 28 11:49:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 275442792E5 for ; Sat, 28 Mar 2020 11:49:50 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 48qH804vKMz3PbL for ; Sat, 28 Mar 2020 11:49:36 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 02SBb1p4046851; Sat, 28 Mar 2020 04:37:01 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 02SBb1bG046850; Sat, 28 Mar 2020 04:37:01 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202003281137.02SBb1bG046850@gndrsh.dnsmgr.net> Subject: Re: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max' In-Reply-To: <87190f4d-4b0a-ce41-fd16-503baf9c6125@gmail.com> To: Graham Perrin Date: Sat, 28 Mar 2020 04:37:01 -0700 (PDT) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 48qH804vKMz3PbL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.33)[-0.328,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ZRD_FAIL(0.00)[query timed out]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.33)[0.328,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.03), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 11:49:50 -0000 > This occurs when I enable OpenZFS: > > OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max' > > Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD? > > From : > > grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max > sysctl: unknown oid 'vfs.zfs.arc_max' > grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v > Wed 25 Mar 2020 04:52:22 GMT > FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 > root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > grahamperrin@momh167-gjp4-8570p:~ % kldstat | grep zfs > ?2??? 1 0xffffffff82108000?? 58ac58 openzfs.ko > grahamperrin@momh167-gjp4-8570p:~ % grep zfs /boot/loader.conf > # zfs_load="YES" > openzfs_load="YES" > grahamperrin@momh167-gjp4-8570p:~ % grep zfs /etc/sysctl.conf > vfs.zfs.min_auto_ashift=12 > # HP EliteBook 8570p 16 GB memory vfs.zfs.arc_max defaults to 15523106816 > # vfs.zfs.arc_max="7761553408" > vfs.zfs.arc_max="2147483648" > grahamperrin@momh167-gjp4-8570p:~ % zfs-stats -a Is zfs actually loaded? kldstat | grep zfs Does perhaps openZfs use a seperate tree? sysctl -a | grep arc_max -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sat Mar 28 11:52:58 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0CFF4279535 for ; Sat, 28 Mar 2020 11:52:58 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qHCb045Kz3Qk9 for ; Sat, 28 Mar 2020 11:52:42 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id d5so15002109wrn.2 for ; Sat, 28 Mar 2020 04:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4/YtOdlM3Mx0Do/y/3D8rVYPeVHEWRajuBJOFZBxnGQ=; b=rOrc4jeZh/mSa/qmxFVfEeTmpGecyKPQvByyurbQ1au0N2aYVl4DvlDaS8eAzcgLlc 2O3K0rLp/5aWX9U2/z/PGOBAV8qzW4UKIGZ/ouoJGz8RciotGLSPONLypWYgNPuQ76LL 3c2Xh25lAYvZtNiTXeHAZMiGyA9BM/fmn0//GfUd23ZIkqr9vGcxhsKP0fmrEhCzmfFM 01zpKWUTuBlu4pWjlB5uFZ7mnCZlbTs2uMS9ThhmTC9FrV+uO+6BbLfx1jQJeCxVVY8h 86mOwlxUY2z8Cju61CGke149yAc4zpLKQJg5956abPFZ897UQKV7JOUn9Q7cyBo21ALU IOwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4/YtOdlM3Mx0Do/y/3D8rVYPeVHEWRajuBJOFZBxnGQ=; b=eXxK223EYu6pce3GT2J5+VHQ7sg0hPvY5ujVeQNvOQaeFtURNhsgt/HynJBSNYCIkK PRnAJ3IXv5P+kgWRiiErTzW1J/BMY5FCbXZq3WKVz6GSMTlGT6mDPO6M8x9ccjBOcJO9 cJBI6dFJXWhBH2CNIkqylUL/BfBdbtk3v9GImZ0K7gnk9wtTd+joN5Idypi+hbOE0wBL gcf9Gv4rqBmeEIjv7bpBRSP5CV1L5WLn3zfN4rcVCy05qDBtRi9Z/HrSxIXqLShDKARa rET7tmvFz2PXfFlnbbASZ0awhztam9LXzRCUzPZx5bWFapwje+gMptJXFoDljZWEm7XR 9k/Q== X-Gm-Message-State: ANhLgQ3f1S7wW+/O2kGLzlcMxzM1Fp0tBK5bFa+yb73j0edW3Hein0Up tVs+2D7PHjdBnu9fSDrGdtmdqZfu1dQXV86ilX8= X-Google-Smtp-Source: ADFU+vuQL8GFvB+dyZMpSIgvLKy697bueiJzEEyuTjNVI2m7dLeJnQQcJO/P6RpBDacrnmdqjCchhPz0j5yxdqkPBPI= X-Received: by 2002:a05:6000:1251:: with SMTP id j17mr4644849wrx.228.1585396354209; Sat, 28 Mar 2020 04:52:34 -0700 (PDT) MIME-Version: 1.0 References: <4f8f3e359207b923a6a3e49a1405a832@udns.ultimatedns.net> <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> In-Reply-To: <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> From: Andrey Fesenko Date: Sat, 28 Mar 2020 14:52:23 +0300 Message-ID: Subject: Re: When will the FreeBSD (u)EFI work? To: Toomas Soome Cc: "bsd-lists@bsdforge.com" , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48qHCb045Kz3Qk9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=rOrc4jeZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of f0andrey@gmail.com designates 2a00:1450:4864:20::429 as permitted sender) smtp.mailfrom=f0andrey@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.35), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.47), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[9.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 11:52:58 -0000 On Sat, Mar 28, 2020 at 12:14 PM Toomas Soome wrote: > > > > > On 28. Mar 2020, at 05:28, Chris wrote: > > > > On Fri, 27 Mar 2020 18:31:50 -0700 bsd-lists@BSDforge.com said > > > >> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh imp@bsdimp.com said > >> > On Fri, Mar 27, 2020 at 4:54 PM Chris wrote= : > >> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey@gmail= .com said > >> > > > >> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris = wrote: > >> > > > > > >> > > > > On an experiment of the FreeBSD EFI implementation. I installe= d > >> > > > > a copy of releng/12 from install media. Which left me with: > >> > > > > # gpart show ada0 > >> > > > > =3D> 40 312581728 ada0 GPT (149G) > >> > > > > 40 409600 1 efi (200M) > >> > > > > 409640 31047680 2 freebsd-ufs (15G) > >> > > > > 31457320 7680000 3 freebsd-swap (3.7G) > >> > > > > 74788904 237792864 - free - (141G) > >> > > > > > >> > > > > On this Intel based system, I can stab the F12 key to pick > >> > > > > my UEFI bootable OS, or let it boot according to the order > >> > > > > I setup in the BIOS. So far, so good. > >> > > > > I needed a copy of releng/13 to also work with. Installed a co= py > >> > > > > from install media. Which left me with: > >> > > > > # gpart show ada0 > >> > > > > =3D> 40 312581728 ada0 GPT (149G) > >> > > > > 40 409600 1 efi (200M) > >> > > > > 409640 31047680 2 freebsd-ufs (15G) > >> > > > > 31457320 7680000 3 freebsd-swap (3.7G) > >> > > > > 39137320 532480 4 efi (260M) > >> > > > > 39669800 35119104 5 freebsd-ufs (17G) > >> > > > > 74788904 237792864 - free - (113G) > >> > > > > I *assumed* that the install would activate the new install, a= nd I > >> > > > > would boot straight into it. But no. I am still on the previou= s > >> > > > > install, and worse, I can't get into the new install -- even i= f > >> > > > > picking it via stabbing the F12 key. I *still* end up in the p= revious > >> > > > > install. So looking at what might be causing it. I found the > >> > following: > >> > > > > # releng/12 > >> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/ > >> > > > > > >> > > > > # ls /mnt/efi/boot/ > >> > > > > BOOTx64.efi > >> > > > > startup.nsh > >> > > > > > >> > > > > # cat /mnt/efi/boot/startup.nsh > >> > > > > BOOTx64.efi > >> > > > > > >> > > > > # umount /mnt/ > >> > > > > > >> > > > > releng/13 > >> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/ > >> > > > > > >> > > > > # ls /mnt/EFI/freebsd/ > >> > > > > loader.efi > >> > > > > > >> > > > > Why the difference? When will FreeBSD (u)EFI work as expected? > >> > > > > > >> > > > > Thanks in advance for any insights! > >> > > > > > >> > > > > >> > > > Require only single efi part > >> > > > > >> > > > See > >> > > > > >> > > > >> > https://forums.freebsd.org/threads/two-freebsd-installations-and-efi= .73968/ > >> > > Thanks for they reply, and link, Andrey! > >> > > Well that confirms it. FreeBSD, unlike other OS implementations, w= ill not > >> > > permit booting your chosen "version" via EFI. > >> > > Firstly, *huge* thanks for your informative reply, Warner! > >> > It does today. If you use efibootmgr, you can boot exactly what you = want. I > >> > do it all the time... Though your BIOS may overwrite the EFI vars i= f you > >> > set too many (I'm looking at you supermicro). When you use the efi B= ootXXXX > >> > variables, it's possible to boot one of many different things on the > >> > system... Though I've not done 11, just 12 and current. > >> Well. That's the thing. I *am* on 12 && 13. Well *trying* to get into = 13. > >> When I started this whole thing, I had some 15 entries returned by > >> efibootmgr(8) -v. > >> So I trimmed the list down to the 2 my BIOS presents as UEFI: > >> Boot0015 UEFI: WDC WD1600JS-98MHB0 > >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(4,GPT,6688c5af-6f93= ... > >> Boot0011* UEFI: WDC WD1600JS-98MHB0 > >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(1,GPT,260d2df2-6a10= ... > >> another entry created when I installed releng/13: > >> Boot0014 FreeBSD (ada0p4) > >> HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(= \EFI\free... > >> and a Windows reference (currently not installed). > >> I activated *both* Boot0015 and Boot0011: > >> efibootmgr -a 0015 0011. Output confirmed success. Bounced box, choose > >> Boot0015. Which booted > >> initial releng/12 install. Fail. OK Try something different; > >> efibootmgr -a 0014 -L FreeBSD-13. Output confirms the -L switch is bro= ken, > >> but 00114 is active. > >> Bounce box && choose 0014. Boots to initial releng/12 install. > >> Conclusion; FreeBSD EFI/ESP is not ready for prime time. :( > >> Thanks again for the reply, Warner! :) > >> --Chris > > > How loader is working is that it does search for *first* =E2=80=9Cusable= =E2=80=9D freebsd partition and will use it. Usable is defined as having /b= oot/loader.efi. > > Therefore, you may have 2 or more freebsd instances on the disk, it reall= y does not matter, only first is used. If you have multiple disks, you can = have different order on second disk. > > Why it is so? We do build loader.efi and we do copy it to the ESP, and cu= rrently there is no way to tell where is the root file system. > > How could we tell where from to load the OS? Well, there are few options = to think about: > > 1. record the hint into the loader.efi binary - this would need special i= nstaller and would break signing. > 2. record EFI variable - it should reflect OS instance version and that v= ersion should be bound with specific loader binary. Coordination is pain th= ere. > 3. record partition to loader.env file > > The current loader code is reading "/efi/freebsd/loader.env=E2=80=9D from= ESP. IMO this sounds most promising, but would need support from installer= or manual setup. Would work as is with multiple ESP instances. Would need = versioned /efi/freebsdXX directories for single shared ESP and installer up= date. > > 4. We still do have BE menu in loader, populated automatically from zfs s= napshots. It can be complemented with entries from file based index (I wrot= e about that idea already). This would allow to create simple switch to dif= ferent instance or initiate chain load of third party boot loader. > With ZFS may work set bootfs on zpool From owner-freebsd-current@freebsd.org Sat Mar 28 12:02:14 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 033A3279E4F for ; Sat, 28 Mar 2020 12:02:13 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48qHQH31Hcz3ysk for ; Sat, 28 Mar 2020 12:01:59 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from [46.98.8.56] (helo=thinkpad.flex-it.com.ua) by mail.flex-it.com.ua with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jIA9p-000PVZ-I8 for freebsd-current@FreeBSD.org; Sat, 28 Mar 2020 14:01:45 +0200 To: freebsd-current@FreeBSD.org From: Alexandr Krivulya Subject: kernel build failed Message-ID: <672d55ce-0949-2397-0a3c-3a86020381a4@shurik.kiev.ua> Date: Sat, 28 Mar 2020 14:01:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-Rspamd-Queue-Id: 48qHQH31Hcz3ysk X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of shuriku@shurik.kiev.ua designates 193.239.74.7 as permitted sender) smtp.mailfrom=shuriku@shurik.kiev.ua X-Spamd-Result: default: False [-5.66 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shurik.kiev.ua]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-3.36)[ip: (-8.89), ipnet: 193.239.72.0/22(-4.44), asn: 35297(-3.55), country: UA(0.07)]; RECEIVED_SPAMHAUS_PBL(0.00)[56.8.98.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:35297, ipnet:193.239.72.0/22, country:UA]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 12:02:14 -0000 Hello, on latest CURRENT kernel fails to build: ===> aesni (all) [Creating objdir /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...] machine -> /usr/src/sys/amd64/include x86 -> /usr/src/sys/x86/include awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h ln -sf /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/opt_bus.h opt_bus.h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/opencrypto/cryptodev_if.m -h cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -I/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG -MD -MF.depend.genoffset.o -MTgenoffset.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx -std=iso9899:1999  /usr/src/sys/kern/genoffset.c sh /usr/src/sys/kern/genoffset.sh genoffset.o > offset.inc cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -I/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG -MD -MF.depend.aesni_ghash.o -MTaesni_ghash.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -Wno-error-cast-qual -mno-aes -mno-avx -std=iso9899:1999 -Werror -mmmx -msse -msse4 -maes -mpclmul /usr/src/sys/crypto/aesni/aesni_ghash.c /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h' file not found #include          ^~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. make[4]: stopped in /usr/src/sys/modules/aesni *** Error code 1 Stop. make[3]: stopped in /usr/src/sys/modules *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src From owner-freebsd-current@freebsd.org Sat Mar 28 12:36:14 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1400227B157 for ; Sat, 28 Mar 2020 12:36:14 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48qJ9Q1GbCz4CFw for ; Sat, 28 Mar 2020 12:35:53 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id 02SCZhOX073017; Sat, 28 Mar 2020 12:35:43 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id 02SCZgct073016; Sat, 28 Mar 2020 05:35:42 -0700 (PDT) (envelope-from david) Date: Sat, 28 Mar 2020 05:35:42 -0700 From: David Wolfskill To: Alexandr Krivulya Cc: freebsd-current@freebsd.org Subject: Re: kernel build failed Message-ID: <20200328123542.GR1511@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Alexandr Krivulya , freebsd-current@freebsd.org References: <672d55ce-0949-2397-0a3c-3a86020381a4@shurik.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZhNdhxK/fAeJ7yzd" Content-Disposition: inline In-Reply-To: <672d55ce-0949-2397-0a3c-3a86020381a4@shurik.kiev.ua> X-Rspamd-Queue-Id: 48qJ9Q1GbCz4CFw X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-7.03 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; SEM_URIBL_FRESH15_UNKNOWN_FAIL(0.00)[query timed out]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.63)[ip: (-9.70), ipnet: 107.192.0.0/12(-4.85), asn: 7018(1.45), country: US(-0.05)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 12:36:14 -0000 --ZhNdhxK/fAeJ7yzd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 28, 2020 at 02:01:39PM +0200, Alexandr Krivulya wrote: > Hello, > on latest CURRENT kernel fails to build: >=20 > =3D=3D=3D> aesni (all) > [Creating objdir /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules= /usr/src/sys/modules/aesni...] > ... > /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h' > file not found > #include > =A0=A0=A0=A0=A0=A0=A0=A0 ^~~~~~~~~~~~~ > 1 error generated. > *** Error code 1 > .... I had no issues updating from r359325 to r359356 yesterday, or from r359356 to r359389 today (using META_MODE). Peace, david --=20 David H. Wolfskill david@catwhisker.org It's disingenuous to claim a low rate of infection based on test results if the tests are not done. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ZhNdhxK/fAeJ7yzd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl5/RJ5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcmyzwgA1i3sZIA8nEboQLqRGHqqY5UUBP9Et+F+7DK03Ze7AYGkk9mOF6i0VM2X DhUso7+UxrVPsT7eg8KADtd8VAlLKCCQTXibxm0/GQrAZFztv3S0edWtut3MxrV7 Yks9tSyzjeaQ7TBVmkYUMlK2e/r7AzpJFQbTyivktO0D75Tm3RPJNGxCUv9Wcy6F 8oA+TWQb6OUgIRV0EU1LNRpKdS3uDHQhD0WVXlvfB9jGRj/wtGr4cT0ZTLIDwq4i lAfCtcbe679DP7JbKvwwMxRj5wPCQ6lBj0fO3PkzjG5q7IXwN578Kt1AehmEz8GE l3+275pez5q9wmPkmTsf1KnilXOQfA== =45S3 -----END PGP SIGNATURE----- --ZhNdhxK/fAeJ7yzd-- From owner-freebsd-current@freebsd.org Sat Mar 28 12:45:30 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD59727B76D; Sat, 28 Mar 2020 12:45:30 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qJNS4Rnnz4GHq; Sat, 28 Mar 2020 12:45:28 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 1577219926; Sat, 28 Mar 2020 12:45:20 +0000 (UTC) From: Jan Beich To: Graham Perrin Cc: freebsd-current@freebsd.org, FreeBSD questions Subject: Re: USB microphones with FreeBSD-CURRENT References: <5c93c4d2-897b-0671-b29a-9fde6031adf5@gmail.com> Date: Sat, 28 Mar 2020 13:45:13 +0100 In-Reply-To: <5c93c4d2-897b-0671-b29a-9fde6031adf5@gmail.com> (Graham Perrin's message of "Sat, 28 Mar 2020 06:31:11 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 12:45:31 -0000 Graham Perrin writes: > I can't get web browsers to recognise USB microphones. > > USB output (e.g. to my headphones) is OK. > > USB input (e.g. from the microphone part of the headphones) is not. > > Any suggestions? Firefox uses "pulse-rust" cubeb backend *by default* if "pulseaudio" package is installed. getUserMedia is supposed to preset a dropdown menu to select a microphone. Make sure pulseaudio actually recognizes the desired microphone e.g., debug via "pactl list" and "parec". I don't have a mic but, looking at the code, only pulse-rust or pulse backends on Linux/FreeBSD support selecting non-default audio device. It maybe possible to use other backends but if audio device used for output and input are different that'd require routing defaults which can be done via config file (e.g., ~/.asoundrc) or externally via virtual_oss. > pcm3: (play/rec) default > pcm4: (rec) Are these distinct physical devices? > hw.snd.default_unit: 3 Have you tried using 4? From owner-freebsd-current@freebsd.org Sat Mar 28 12:48:31 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8A1E527BD04 for ; Sat, 28 Mar 2020 12:48:31 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48qJRt6wD2z4Hk6 for ; Sat, 28 Mar 2020 12:48:26 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from [46.98.8.56] (helo=thinkpad.flex-it.com.ua) by mail.flex-it.com.ua with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.93.0.4 (FreeBSD)) (envelope-from ) id 1jIAss-00019Q-Tl for freebsd-current@freebsd.org; Sat, 28 Mar 2020 14:48:18 +0200 Subject: Re: kernel build failed To: freebsd-current@freebsd.org References: <672d55ce-0949-2397-0a3c-3a86020381a4@shurik.kiev.ua> <20200328123542.GR1511@albert.catwhisker.org> From: Alexandr Krivulya Message-ID: <4ee54436-0c15-41c3-3581-053da0a08181@shurik.kiev.ua> Date: Sat, 28 Mar 2020 14:48:13 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200328123542.GR1511@albert.catwhisker.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 48qJRt6wD2z4Hk6 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of shuriku@shurik.kiev.ua designates 193.239.74.7 as permitted sender) smtp.mailfrom=shuriku@shurik.kiev.ua X-Spamd-Result: default: False [-5.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[56.8.98.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shurik.kiev.ua]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-3.40)[ip: (-9.00), ipnet: 193.239.72.0/22(-4.50), asn: 35297(-3.60), country: UA(0.07)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:35297, ipnet:193.239.72.0/22, country:UA]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 12:48:31 -0000 28.03.20 14:35, David Wolfskill пишет: > On Sat, Mar 28, 2020 at 02:01:39PM +0200, Alexandr Krivulya wrote: >> Hello, >> on latest CURRENT kernel fails to build: >> >> ===> aesni (all) >> [Creating objdir /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/aesni...] >> ... >> /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 'wmmintrin.h' >> file not found >> #include >>          ^~~~~~~~~~~~~ >> 1 error generated. >> *** Error code 1 >> .... > I had no issues updating from r359325 to r359356 yesterday, or from > r359356 to r359389 today (using META_MODE). So what may be a reason? I tried: - remove and checkout source tree - remove /usr/obj wmmintrin.h is present under /usr/src/contrib/llvm-project/clang/lib/Headers/wmmintrin.h /etc/make.conf: KERNCONF=GENERIC-NODEBUG MALLOC_PRODUCTION=yes no /etc/src.conf From owner-freebsd-current@freebsd.org Sat Mar 28 15:19:36 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 48E982A4F89 for ; Sat, 28 Mar 2020 15:19:36 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48qMpD5hJxz4fYY for ; Sat, 28 Mar 2020 15:19:32 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id E6AF93743D; Sat, 28 Mar 2020 15:19:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net E6AF93743D Subject: Re: ZFS: destroying snapshots without compromising boot environments To: freebsd-current@freebsd.org References: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> Cc: Graham Perrin From: Allan Jude Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Message-ID: <1c2b71fa-b25c-21d4-2115-ddb3d7b129b2@freebsd.org> Date: Sat, 28 Mar 2020 11:19:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q9qqlRXHnqCpZ00izS58VdX9AJ9vWQZAa" X-Rspamd-Queue-Id: 48qMpD5hJxz4fYY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.20 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.70)[-0.703,0]; NEURAL_HAM_LONG(-0.49)[-0.492,0]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 15:19:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q9qqlRXHnqCpZ00izS58VdX9AJ9vWQZAa Content-Type: multipart/mixed; boundary="2G6d4ZqVaO9DxYGQDQAC3R7x6XjPcYGFZ"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Cc: Graham Perrin Message-ID: <1c2b71fa-b25c-21d4-2115-ddb3d7b129b2@freebsd.org> Subject: Re: ZFS: destroying snapshots without compromising boot environments References: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> In-Reply-To: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> --2G6d4ZqVaO9DxYGQDQAC3R7x6XjPcYGFZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2020-03-28 03:24, Graham Perrin wrote: > I imagine that some of the 2019 snapshots below are redundant. >=20 > Can I safely destroy any of them? >=20 > $ zfs list -t snapshot > NAME=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 USED AVAIL=C2=A0 > REFER=C2=A0 MOUNTPOINT > copperbowl/ROOT/Waterfox@2020-03-20-06:19:45=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 67.0M -=C2=A0 59.2G=C2=A0 - > copperbowl/ROOT/r359249b@2019-08-18-04:04:53=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5.82G -=C2=A0 40.9G=C2=A0 - > copperbowl/ROOT/r359249b@2019-08-18-11:28:31=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4.32G -=C2=A0 40.7G=C2=A0 - > copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 9.43G -=C2=A0 43.4G=C2=A0 - > copperbowl/ROOT/r359249b@2019-09-19-20:03:26=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5.13G -=C2=A0 43.3G=C2=A0 - > copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 7.67G -=C2=A0 44.6G=C2=A0 - > copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 7.66G -=C2=A0 55.2G=C2=A0 - > copperbowl/ROOT/r359249b@2020-01-11-14:15:47=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7.41G -=C2=A0 56.2G=C2=A0 - > copperbowl/ROOT/r359249b@2020-03-17-21:57:17=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 12.0G -=C2=A0 59.2G=C2=A0 - > copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers=C2=A0=C2=A0=C2=A0= =C2=A0 8K -=C2=A0 1.24G=C2=A0 - > copperbowl/poudriere/jails/head@clean=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 328K -=C2=A0 1.89G=C2=A0 - > $ beadm list > BE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active Mountpoint=C2=A0 Space Cr= eated > Waterfox -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 12.2G 2020-03-10 18:24 > r357746f -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.3G 2020-03-20 06:19 > r359249b NR=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 148.9G 2020-03-28 01:19 > $ beadm list -aDs > BE/Dataset/Snapshot=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Active Mountpoint=C2=A0 > Space Created >=20 > Waterfox > =C2=A0 copperbowl/ROOT/Waterfox=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 137.0M > 2020-03-10 18:24 > =C2=A0=C2=A0=C2=A0 r359249b@2020-03-17-21:57:17=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = - -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 59.2G > 2020-03-17 21:57 > =C2=A0 copperbowl/ROOT/Waterfox@2020-03-20-06:19:45=C2=A0=C2=A0 - -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 67.0M > 2020-03-20 06:19 >=20 > r357746f > =C2=A0 copperbowl/ROOT/r357746f=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 1.2G > 2020-03-20 06:19 > =C2=A0=C2=A0=C2=A0 Waterfox@2020-03-20-06:19:45=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = - -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 59.2G > 2020-03-20 06:19 >=20 > r359249b > =C2=A0 copperbowl/ROOT/r359249b@2019-08-18-04:04:53=C2=A0=C2=A0 - -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5.8G > 2019-08-18 04:04 > =C2=A0 copperbowl/ROOT/r359249b@2019-08-18-11:28:31=C2=A0=C2=A0 - -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4.3G > 2019-08-18 11:28 > =C2=A0 copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 9.4G > 2019-09-13 18:45 > =C2=A0 copperbowl/ROOT/r359249b@2019-09-19-20:03:26=C2=A0=C2=A0 - -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5.1G > 2019-09-19 20:03 > =C2=A0 copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7.7G > 2019-09-24 20:45 > =C2=A0 copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7.7G > 2020-01-09 17:05 > =C2=A0 copperbowl/ROOT/r359249b@2020-01-11-14:15:47=C2=A0=C2=A0 - -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7.4G > 2020-01-11 14:15 > =C2=A0 copperbowl/ROOT/r359249b@2020-03-17-21:57:17=C2=A0=C2=A0 - -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 12.0G > 2020-03-17 21:57 > =C2=A0 copperbowl/ROOT/r359249b=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 NR /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 59.0G > 2020-03-28 01:19 > $ >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" You can try to destroy the snapshot, if it is the basis of a clone, then you will get an error, that you'd need to destroy the BE first, so you might decide to keep that snapshot. As long as you don't use the -R flag to zfs destroy dataset@snapshot, it will not destroy the clones. You can also use 'zfs promote' to make the clone into the parent, making the original parent into the clone. This allows you to destroy that original and the snapshot while keeping the clone. --=20 Allan Jude --2G6d4ZqVaO9DxYGQDQAC3R7x6XjPcYGFZ-- --q9qqlRXHnqCpZ00izS58VdX9AJ9vWQZAa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJef2r5AAoJEBmVNT4SmAt+MPcP/jGCOfLA0BQwWf6TOUu4M22U 8wbfUSbSPpw+I3BrJf8UOEmhuwmJF69mF+P+/kfmzLtyxkZx0Q0RtllOzH7/g6jn R/u3D1z/QmPT9RXyr4glbECRWf4UFq913jMQh3oojqFFLa/G9OS9TRkDF+nP4yd9 HTs+V5J0g2Cjv7ZiL1MFad5DPYtZUlMImmrKuaLwtkEw5CEQIyHrA6EDDQUvhq+l mCLeSb7ijXaPiq/zunNWBEYAJ+jzyPpqYh1BNTZuclVcnMGKRWrQIzy9JmP7hDN4 CX+8lxkjteEc/ASLwpmZk2is6k08t/1gHq9LYXRhiesRFQWh1y7im5pqzO341uxb ZaOnGPDPKTzAlonorw369DPikJ8HVvsutlW8XvlVr3ph0M+CKtA6Gkz/lzlC76sq hQsCjBwAZX8pS0DRdi/DggCXfjGrxehy3jja1VJf36o1PZXDnbfSPIlsLVBIN8IJ mlwmxnHI3zdQm1lgFi08v0Jc+7XUux7XjkgNysR2s7SaNuKXnbO2+/e4ydI/oXWW TYn1I20WPYKrtwZCf2ffDJnQtM63IsFfg6hkwCcWSrUprKT7QxeWVOtJck8Adj0X kpjuP2ULqgbAKE3tP2cAELXjth2NjYQzo22wkJcCUe6Zo6sD6c2DiTachvHb5E8S jdwc44GDRr770k71rjiQ =GK7M -----END PGP SIGNATURE----- --q9qqlRXHnqCpZ00izS58VdX9AJ9vWQZAa-- From owner-freebsd-current@freebsd.org Sat Mar 28 15:26:56 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 611362A53A7 for ; Sat, 28 Mar 2020 15:26:56 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [IPv6:2001:470:1:474::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48qMyh3Kpbz3DWP for ; Sat, 28 Mar 2020 15:26:51 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id D3E1337432; Sat, 28 Mar 2020 15:17:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net D3E1337432 Subject: Re: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max' To: freebsd-current@freebsd.org References: <87190f4d-4b0a-ce41-fd16-503baf9c6125@gmail.com> Cc: Graham Perrin From: Allan Jude Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Message-ID: <45066356-898c-cf76-0606-8d04109e0f4b@freebsd.org> Date: Sat, 28 Mar 2020 11:17:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <87190f4d-4b0a-ce41-fd16-503baf9c6125@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bMFL43Ilv7nWsUkUktqJgw0FXacCZ1dTz" X-Rspamd-Queue-Id: 48qMyh3Kpbz3DWP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.27 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.72)[-0.717,0]; NEURAL_HAM_LONG(-0.55)[-0.550,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 15:26:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bMFL43Ilv7nWsUkUktqJgw0FXacCZ1dTz Content-Type: multipart/mixed; boundary="JVAzIt71sQbFC0nzgJSQ8laDjsvsK8EQT"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Cc: Graham Perrin Message-ID: <45066356-898c-cf76-0606-8d04109e0f4b@freebsd.org> Subject: Re: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max' References: <87190f4d-4b0a-ce41-fd16-503baf9c6125@gmail.com> In-Reply-To: <87190f4d-4b0a-ce41-fd16-503baf9c6125@gmail.com> --JVAzIt71sQbFC0nzgJSQ8laDjsvsK8EQT Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2020-03-28 02:43, Graham Perrin wrote: > This occurs when I enable OpenZFS: >=20 > OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max' >=20 > Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeB= SD? >=20 > From : >=20 > grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max > sysctl: unknown oid 'vfs.zfs.arc_max' > grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v > Wed 25 Mar 2020 04:52:22 GMT > FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 > root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBU= G > grahamperrin@momh167-gjp4-8570p:~ % kldstat | grep zfs > =C2=A02=C2=A0=C2=A0=C2=A0 1 0xffffffff82108000=C2=A0=C2=A0 58ac58 openz= fs.ko > grahamperrin@momh167-gjp4-8570p:~ % grep zfs /boot/loader.conf > # zfs_load=3D"YES" > openzfs_load=3D"YES" > grahamperrin@momh167-gjp4-8570p:~ % grep zfs /etc/sysctl.conf > vfs.zfs.min_auto_ashift=3D12 > # HP EliteBook 8570p 16 GB memory vfs.zfs.arc_max defaults to 155231068= 16 > # vfs.zfs.arc_max=3D"7761553408" > vfs.zfs.arc_max=3D"2147483648" > grahamperrin@momh167-gjp4-8570p:~ % zfs-stats -a >=20 > =E2=80=A6 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" The OpenZFS, the variable is vfs.zfs.arc.max Basically 'arc' was converted to a subtree. We should add some backwards compat sysctls to cover some of these renames etc so configs and scripts don't break etc. --=20 Allan Jude --JVAzIt71sQbFC0nzgJSQ8laDjsvsK8EQT-- --bMFL43Ilv7nWsUkUktqJgw0FXacCZ1dTz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJef2qRAAoJEBmVNT4SmAt+0sAQALSmalwKjbaTX90+B1J0AKC7 9QPOA3M98XF4T/E5GKkY7JGk01KHpWTQLYLkQ00aofGmyCHzkvMvxZEn+aIMPMZN o7DlHiqwpXh+Nwk7QhbdHyu91jobDdWDOk6v2bKY4C4TSCsJLU4VZpnzgwkj0/bi Hb08J6F/WN4Yjjgv41Rc3aehA8fC3W6QeI+I0SuPahs6aE84BMlnqY6JIhmv43DJ QfoyIQXawkCUxuNpMhyZG8yijrhDHI48s8RSlXHqh+QZHE0PO3H+9jmBAFXHiQqw gld3JoZuBwZUBHxl9ZWDIBXIwoYOBw+zeaKuGR5MPOHxdYAjR8/VuzTUADk1GzCG qPzxS/SqmvLhGRU3Y7eCIZZ+fLnsSeOdK2YtxQnAAiLGA/2iQaxduYzZSTASeqnk MkxvMinI8CUNGdAyjN0z+H/mt0VFhTu4kVSQXqHnToizNqsZBgXE8SjXvzRW0Ivd pSRnvYV2VJNAQ1hRHtlP5hffcBatibUDhogkgORStUu9siYOfUkFKi2rt6HNnYLW Lqlo20h0E9bHqxq3xrHJROpxQ0bCO08Yv8Nk0ndsUVrH75kWK55QFdh8n73PvDAL 21r4G7Q4evZQKNXzudQ4CCQm6wcq8SP1aV3dbnxRfzD56iSeLiwvq4Htk7qK6hOm s4AQnQ8bdn5mvLO2bVer =5Tdu -----END PGP SIGNATURE----- --bMFL43Ilv7nWsUkUktqJgw0FXacCZ1dTz-- From owner-freebsd-current@freebsd.org Sat Mar 28 15:36:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 542612A58C2 for ; Sat, 28 Mar 2020 15:36:42 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qN9t0Bk3z3J1Q; Sat, 28 Mar 2020 15:36:32 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id t7so15326184wrw.12; Sat, 28 Mar 2020 08:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Qlw9PMpkzyEeQUoV5wPKk2XRtrCsd5dAfZp9s7oj1r8=; b=pFO47l7oP+dNqb5Bwpx64wI3zzGYIdHnqOT4I4treyc+CUhBExK0wXUGDrzY8puVag ODNnSsbac4AhCgtXuBBi2xQLsQzSJ63XsuFGEAosgHZ6YREQwyLwJA6WmHeQCxzXEq1o 6WrLaEX795rVjGQC9REC7udyWkmZqqxpx8THX2bn7LbC44CyronjItyLMlQYKfod5dHE D7cT4f77jtNP55miRn1vc/gfznVupxcr5vyMR8VOj9DIgPkL8EKU9O4hSTiz8USMCKtQ 3zvsOBMKRmMBH03sll5qdcRrcWxntCoU+wsON+7BTzmw8XSb1eygNNrQuRJ4euTCdiIx okow== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Qlw9PMpkzyEeQUoV5wPKk2XRtrCsd5dAfZp9s7oj1r8=; b=hmYFlVqWGAqOaxJKVvY6p7jw/cc13RyLJihgwvmrpqaOA5Ee8SNuNTSZEqfMsuYQS6 RQ98FR70Ou54YGG21xKOZPXdijNVflh5WMYH1pLXbkiVsRJ2kFoU/q7MdBKI/tf+VzfO 6spuoPuoUDeFkVacaX+/x16VGRG6MNi7f2eX80KKW7L1yKUpzjuX2hU65o+6kaf37vGt wWgcbxNdsVkxor8aq5Bcni+VSvrNWsrURwQh6Fx3n04zXa5LpgUQqmZuGm1cpCUwbBNn F7SysAnlONP1GD9CVP5r7FkD55764YPz7KaolN1MH0ddtiUKVxSpFx95Ig9KZqnf760T GITw== X-Gm-Message-State: ANhLgQ1KoBGO2HcsnIeSgBZujj9i5d/oIhUjOhtsDdMCI3es/K3/TZDK THqDSmC2IPyb8IVLKQluWCzOFL8cpdY= X-Google-Smtp-Source: ADFU+vs+nB1LMfFbkp55Mv96wOHS1EurSt09tASq5+5K1sLILZdyGbFE2M7ma7kayj+v3bDuWvOBRQ== X-Received: by 2002:adf:9dca:: with SMTP id q10mr5212348wre.11.1585409781972; Sat, 28 Mar 2020 08:36:21 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id g127sm13181519wmf.10.2020.03.28.08.36.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Mar 2020 08:36:21 -0700 (PDT) Subject: Re: ZFS: destroying snapshots without compromising boot environments To: Allan Jude References: <14266e74-e2cc-ec14-187a-4bc9c9e6c32a@gmail.com> <1c2b71fa-b25c-21d4-2115-ddb3d7b129b2@freebsd.org> Cc: freebsd-current@freebsd.org From: Graham Perrin Message-ID: <01524fd0-ae7b-028b-6259-5da485b48886@gmail.com> Date: Sat, 28 Mar 2020 15:36:20 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1c2b71fa-b25c-21d4-2115-ddb3d7b129b2@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 48qN9t0Bk3z3J1Q X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=pFO47l7o; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[78.147.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-9.26), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.47), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[a.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 15:36:42 -0000 On 28/03/2020 15:19, Allan Jude wrote: > You can try to destroy the snapshot, if it is the basis of a clone, then > you will get an error, that you'd need to destroy the BE first, so you > might decide to keep that snapshot. As long as you don't use the -R flag > to zfs destroy dataset@snapshot, it will not destroy the clones. > > You can also use 'zfs promote' to make the clone into the parent, making > the original parent into the clone. This allows you to destroy that > original and the snapshot while keeping the clone. Perfect, thank you. I was nervous about destruction without warning. Below, are the differences (in measurement) between beadm and bectl to be expected? ---- root@momh167-gjp4-8570p:~ # beadm list BE       Active Mountpoint  Space Created Waterfox -      -           15.9G 2020-03-10 18:24 r357746f -      -            1.3G 2020-03-20 06:19 r359249b NR     /           74.7G 2020-03-28 01:19 root@momh167-gjp4-8570p:~ # beadm list -aDs BE/Dataset/Snapshot                            Active Mountpoint Space Created Waterfox   copperbowl/ROOT/Waterfox                     -      - 137.0M 2020-03-10 18:24     r359249b@2020-03-17-21:57:17               -      - 59.2G 2020-03-17 21:57   copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 -      - 67.0M 2020-03-20 06:19 r357746f   copperbowl/ROOT/r357746f                     -      - 1.2G 2020-03-20 06:19     Waterfox@2020-03-20-06:19:45               -      - 59.2G 2020-03-20 06:19 r359249b   copperbowl/ROOT/r359249b@2020-03-17-21:57:17 -      - 15.7G 2020-03-17 21:57   copperbowl/ROOT/r359249b                     NR     / 59.0G 2020-03-28 01:19 root@momh167-gjp4-8570p:~ # bectl list BE       Active Mountpoint Space Created Waterfox -      -          204M  2020-03-10 18:24 r357746f -      -          1.21G 2020-03-20 06:19 r359249b NR     /          74.7G 2020-03-28 01:19 root@momh167-gjp4-8570p:~ # bectl list -aDs BE/Dataset/Snapshot                              Active Mountpoint Space Created Waterfox   copperbowl/ROOT/Waterfox                       -      - 204M  2020-03-10 18:24   Waterfox@2020-03-20-06:19:45                   -      - 67.0M 2020-03-20 06:19 r357746f   copperbowl/ROOT/r357746f                       -      - 1.21G 2020-03-20 06:19 r359249b   copperbowl/ROOT/r359249b                       NR     / 74.7G 2020-03-28 01:19   r359249b@2020-03-17-21:57:17                   -      - 15.7G 2020-03-17 21:57 root@momh167-gjp4-8570p:~ # zfs list -t snapshot NAME                                                     USED AVAIL  REFER  MOUNTPOINT copperbowl/ROOT/Waterfox@2020-03-20-06:19:45            67.0M -  59.2G  - copperbowl/ROOT/r359249b@2020-03-17-21:57:17            15.7G -  59.2G  - copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers     8K -  1.24G  - copperbowl/poudriere/jails/head@clean                    328K -  1.89G  - root@momh167-gjp4-8570p:~ # zfs destroy copperbowl/ROOT/r359249b@2020-03-17-21:57:17 cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17': snapshot has dependent clones use '-R' to destroy the following datasets: copperbowl/ROOT/r357746f copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 copperbowl/ROOT/Waterfox root@momh167-gjp4-8570p:~ # date ; uname -v Sat Mar 28 15:30:57 GMT 2020 FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@momh167-gjp4-8570p:~ # From owner-freebsd-current@freebsd.org Sat Mar 28 16:11:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EFAAF2A6804 for ; Sat, 28 Mar 2020 16:11:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670047.outbound.protection.outlook.com [40.107.67.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qNxm2NCBz41Sc for ; Sat, 28 Mar 2020 16:11:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MfKJqU0FM70MYHcmLmSXRhGhYRCtdn79dzSHInNtFsPjbutE969a8TDjrKGsZKh417uBek0FKZzzcqITHZlQVebSd59JX92K6pro3i0ROcKosXmbnUxQDdFgxrIK+anEBADc3iFEZ2C0Q3W9KJEA8/y84sGyDB40ZQ62/joQx8M7AiVU1kR182VKuk8ICmTf+hpqkxjbS3n/Y91CJjcnc0vsKWzTq8B8qGZBt55EN8iqX/qJyGuakbDmuJZQQ48hb37lhRpkDmqg4VPJSG7K1p6ucHVooH0lgtA5/psbt+2fOd/GWhSODu3ZaFWeN0ayWts3YZaQ3xMS1b4AL4OBFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iHvUSTDse+5UOgWAwM7T/A0IkxxkgLlj+TJGXvZMETY=; b=D4K6bn5X+H4OmQQdo5WATirL/iShNEwUrjEafF1eqOYy+Dgp3sc/E465gnlt0oECE774IfUoYyjkDNlnE2kpRyf6Uis0/epKrf7I7lirELH/td7B/tnAogoSH13rTUB1uRe74b7OTYEveMnFpVXfwxz4vkrBT7rS4XpIRvfj86z+q2MZfOTL+z8ki+6gXFk3BOy/ub27YzybmB3ip45wHCadRbwtESn0moy2sBFxMdEBibVFshCZCgq5WmppXovenGUZcLMIGG1GjRFwbmYsQn2utezrWN+KiViDDa8d7BeUNa9l2mmizqKuaNCrwZrFnXbR3pLyhIaFoHlYzTxeNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3140.CANPRD01.PROD.OUTLOOK.COM (52.132.89.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Sat, 28 Mar 2020 16:10:58 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f%5]) with mapi id 15.20.2856.019; Sat, 28 Mar 2020 16:10:49 +0000 From: Rick Macklem To: John-Mark Gurney CC: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Thread-Topic: TLS certificates for NFS-over-TLS floating client Thread-Index: AQHWBM20voRSAnj550my91BNnYCx3qheIHLx Date: Sat, 28 Mar 2020 16:10:49 +0000 Message-ID: References: , <20200328065331.GU4213@funkthat.com> In-Reply-To: <20200328065331.GU4213@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71fbf7bc-21ae-406d-ef9a-08d7d33294a2 x-ms-traffictypediagnostic: QB1PR01MB3140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(396003)(136003)(8676002)(9686003)(8936002)(81166006)(55016002)(81156014)(71200400001)(4326008)(33656002)(2906002)(66946007)(76116006)(66446008)(64756008)(66556008)(66476007)(478600001)(316002)(786003)(5660300002)(54906003)(86362001)(7696005)(186003)(6506007)(52536014)(30864003)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3140; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h0HQNv4VuYpLfn/c8TItil02YrsB8iYjQ4VqGNGH1mTpKmlqZxwcy+ywKAx8r3/D5RSEWM0yE2cojEDVwxk23WKximBNOgXfZu27OyauhNKlbbNG3n/Pt0KNnrBMnAYmdjaZmXB7RTkZStNp2YaKwXhnKbZzIpomc4V9jrSuCNIPfQ/fAYjOOuD5+dZcj1Klw9I8CIm2HdhvloHYfL4+t4rkqpajHrLkq0p/jfhCfOjYTKgFcL49y8SPUzIRT/HJHlS6V/QjCTi5wAmThbW+bck6gk6TiLtYymDtvtl+7Om1eLkX1olk9lgRYNQd7gDAToBoUe8JoFeEAH/1LxvsuEf+wgohrop7ePNvmB4iilfyKQTdHwYALBtvSr4rtVa4P+LuAxu7Q/otl/lN4yMD0nJE/iqMms7/f4oZHuhasuV72J3J3i1JPkcWbfJApz3M x-ms-exchange-antispam-messagedata: hlXRA6nq7Z9dowm3HV1TzQt6JC6avjAEv7wiagYnGgmIq2DF15yB6kAvf0dgIYyU+ZuRKXmlLHQfQBgAStkCSlxQK3QCB8aKnE+luestlVpYGRxz9jtcmLMavF15YoVsNZosp7T1hsGJVn1+TUkSmM3QtD9jbE26Lf/HuikUmgSBCJhjE8MVy283exRm/gjmes0GJOJ57OACC9AM0yGi2Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 71fbf7bc-21ae-406d-ef9a-08d7d33294a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2020 16:10:49.0576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SwwLR82zNSBgNudPKaIyVuS/zXNqXE4eMsBdaPhSU//v9u3JMvJct2ieFKhM2WASxjjmOHkto39LIyNdtq3kmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3140 X-Rspamd-Queue-Id: 48qNxm2NCBz41Sc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.47 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.69 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[47.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.39)[ipnet: 40.64.0.0/10(-3.75), asn: 8075(-3.13), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 16:11:22 -0000 John-Mark Gurney wrote:=0A= >Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +0000:=0A= >> John-Mark Gurney wrote:=0A= >> [lots of stuff snipped]=0A= >> >Rick Macklem wrote:=0A= >> >> I had originally planned on some "secret" in the certificate (like a = CN name=0A= >> >> that satisfies some regular expression or ???) but others convinced m= e that=0A= >> >> that wouldn't provide anything beyond knowing that the certificate wa= s=0A= >> >> signed by the appropriate CA, so I have not implemented anything.=0A= >> >=0A= >> >Yeah, having a "secret" in the CN doesn't make sense, but what does mak= e=0A= >> >sense is allowing the exports line to specify what the CN should contai= n=0A= >> >to be authenticated...=0A= >> >=0A= >> >Say as a corp, you issue personal certificates to everyone. This is=0A= >> >because you require everyone to sign and/or encrypt their email w/=0A= >> >S/MIME. Each cert includes the email address of that person, so you=0A= >> >could simply do something like:=0A= >> >/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com= =0A= >> >=0A= >> >And anyone who has the certificate w/ alice@example.com that was signed= =0A= >> >by the public key in /etc/company.pem would be granted access to the=0A= >> >export /home/alice.=0A= >> >=0A= >> >If it allowed ANY cert signed by the CA specified, then that introduces= =0A= >> >an authentication problem, as now if Malory is a coworker of Alice=0A= >> >could also access Alice's home directory...=0A= >> >=0A= >> >IMO, this is one auth feature that MUST be supported...=0A= Here's what I have just coded up:=0A= - If an option is set for the server TLS handshake daemon and it gets a ver= ified=0A= certificate from the client=0A= - It looks at the CN and if it is of the form "user@domain", it tries to = translate=0A= "user@domain" to a POSIX using the same mechanism that= =0A= nfsuserd(8) currently uses. ("user@domain" is what NFSv4 uses for a fil= e Owner.)=0A= - Then all RPCs on this TCP connection are done using the above,=0A= ignoring the authenticator in the RPC message header. (Yes, similar = to the=0A= -mapall exports option.)=0A= I have also added a "-tlscnuser" exports option that would require all clie= nts=0A= to have the above form of certificate. (Without this exports option, the ab= ove=0A= would work assuming the daemon option is set, but other mounts would be=0A= allowed as well.)=0A= =0A= The problem of handling multiple "user" domains has never been solved.=0A= (That is what your -tlsroot option was intended to do assuming a 1 to 1=0A= relationship between CA root and username domains, I think?)=0A= The problem is that getpwnam(3) needs to know how to look up user names=0A= for these different "domain" values. (Now, both nfsused(8) and this daemon= =0A= only strips off the default domain, if it matches, and then hands the rest = of=0A= the string to getpwnam(2).)=0A= =0A= Although "user@domain" isn't exactly an email address, they often are the= =0A= same string in practice.=0A= =0A= I have not yet posted to nfsv4@ietf.org to see what they think.=0A= However, I don't think there is any changes in the draft required to do thi= s.=0A= Also, I think interoperability should be ok, since it is controlled by whoe= ver=0A= issues the certificate for the client and the NFS client will normally just= =0A= handle this certificate opaquely.=0A= =0A= Btw, the server TLS handshake daemon does do a SSL_CTX_set_client_CA_list()= ,=0A= so it tells the client which CA (usually only one) that it wants a certific= ate for.=0A= =0A= >> The draft does not address user authentication, only machine authenticat= ion.=0A= >> --> ie. The certificate is used to decide if a system can do a mount.=0A= >> Users are still identified via user credentials in the RPC message= header.=0A= >> For AUTH_SYS, that still means .=0A= >> Otherwise, you need to use Kerberos (sec=3Dkrb5[ip]).=0A= >> You could use "tls,sec=3Dkrb5" for a mount, but the only advantage= that=0A= >> might have over "sec=3Dkrb5p" is performance, if there is hardware= assist=0A= >> for TLS or something like that.=0A= >>=0A= >> >Now that I reread your comments, it sounds like any certificate would b= e=0A= >> >allowed in #2 as long as it is valid, and that would only be marginally= =0A= >> >better than verification by IP, and in some ways worse, in that now any= =0A= >> >user could pretend to be any other user, or you have to do something=0A= >> >crazy like have a CA per user.=0A= >> The case where I see #2 is useful is where this discussion started some = weeks ago.=0A= >> The example I started with was:=0A= >> /home -tls -network 192.168.1.0 -mask 255.255.255.0=0A= >> /home -tlscert=0A= >>=0A= >> This says that machines on the local lan can mount and do not need to ha= ve=0A= >> certificates, but must use TLS so data is encrypted on the wire.=0A= >> Mounts from anywhere else (presumably laptops) are allowed so long as th= ey have a=0A= >> certificate signed by me (as in the site local CA).=0A= >> I trust these machines enough that I am willing to allow them to use AUT= H_SYS,=0A= >> which is what 99.9...% of NFS mounts do now.=0A= >> (So, I'd agree that the site local certificate is not a lot better than = IP address=0A= >> for client machine identity, just that it is an alternative that can be= useful.=0A= >> Without TLS, a line like "/home" allows anyone to mount /home from anyw= here=0A= >> and I think you'd agree that few NFS admins. will want to do that. I'm = assuming=0A= >> no external firewall for this example.)=0A= >>=0A= >> Now, your suggestion of identifying a user via the CN and then having th= e=0A= >> server do all RPCs for the mount as that user is an interesting one.=0A= >> My concern w.r.t. implementing it would be interoperability.=0A= >> Put another way, if other servers such as Linux, Netapp,... don't adopt = it=0A= >> (and they won't until there is a draft/RFC specifying it), it would be= =0A= >> FreeBSD server specific and I'd like to avoid that.=0A= >> There was some discussion w.r.t. user authentication via certificates=0A= >> during development of the draft, but they decided to defer that work for= =0A= >> now, so they could get something in place for machine authentication fir= st.=0A= >> (If I understood the discussion on nfsv4@ietf.org.)=0A= >=0A= >There's a fine line between machine and user authentication when you can= =0A= >add -mapall=3Dsomeuser. :)=0A= Yes, I agree. You can argue what I've coded as explained above is just serv= er=0A= implementation and has nothing to do with the draft, which covers what goes= =0A= "on-the-wire", similar to "-mapall".=0A= =0A= >Yes, a certificate may be used to identify a machine, but if any machine= =0A= >can be identified by any cert as it appears that #2 is proposed to do, the= n=0A= >you're not actually identifying a machine, you're identifying group of=0A= >machines... Though per the draft, this is explicitly allowed.=0A= >=0A= >It'd be nice to be able to identify particular machines though, and be=0A= >able to set the options based upon that..=0A= Well, the only thing the server has to use for exports(5) is the client's I= P address.=0A= In a sense, you can say that "alice@example.com" identifies the machine tha= t=0A= Alice uses.=0A= =0A= At least, it means that if the certificate with "alice@example.com" in it i= s copied=0A= to a different machine, that machine will access the NFS server as "alice" = as well=0A= and cannot access files that Alice cannot access.=0A= =0A= >> >I'm wonder if your use of the term secret was the problem, and not the= =0A= >> >idea... Anything that goes in the client cert is by definition public.= ..=0A= >> >TLS prior to 1.3 sends the client cert in clear text... But keying=0A= >> >based upon the contents of the cert is fine, as that's the point of=0A= >> >what a cert is.. It's trusting the CA to say that the CN and other=0A= >> >fields in the cert corresponds to this user, and you can use parts of= =0A= >> >the cert, like the CN to decide which user the public key in the cert= =0A= >> >corresponds to.=0A= >=0A= >Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:59 +0000:=0A= >> Sorry about the top post, but I thought of a few things to add to my=0A= >> last post to this thread...=0A= >> 1 - I agree that for systems like laptops, the line between machine and= =0A= >> user authentication is fuzzy.=0A= >=0A= >yep, exactly. IMO, laptops are more important for this work, and where=0A= >you want to identify per machine at a finer grain level than server=0A= >machines...=0A= >=0A= >> 2 - I do like your idea of having an exports(5) option that specifies a = CN=0A= >> that identifies a user and then does all RPCs as that user.=0A= >> I'm not sure if an issuer needs to be specified (or even can be sp= ecified),=0A= >> since the CAfile argument to the rpctlssd daemon determines if a c= ertificate=0A= >> from a particular CA will verify and the verification must happen = before the=0A= >> exports(5) export options can be applied. (Basically, certificate = verification=0A= >> happens via a NULL RPC that does a STARTTLS when a TCP connection = to=0A= >> the server is first established.)=0A= >=0A= >Yeah, this will need some work, but IMO is fine as a future=0A= >improvement...=0A= >=0A= >Yeah, this could be a bit tricky from a code perspective.. I don't know=0A= >how well most SSL libraries are being able to auth client certs via=0A= >different roots after the fact... One option, but maybe not a great=0A= >option would be to verify the cert after the connection is established..= =0A= >=0A= >You could extract the cert identify the candidate export lines, and=0A= >then attempt a cert verification w/ a specified root if a default one=0A= >isn't specified... Not exactly clean, but as long as the client can't=0A= >proceed without this check, shouldn't be a major problem...=0A= Well, the certificate verification normally occurs during the handshake=0A= using the location information provided via SSL_CTX_load_verify_locations()= .=0A= However, this does not included checking for specific fields in the certifi= cate.=0A= =0A= The daemon could pass the subjectName from the certificate into the kernel= =0A= for use by the exports(5) handling code later, but then another upcall to a= =0A= daemon needs to be done to translate the subjectName to .=0A= Since even nfsuserd(8) only knows how to do this for a default domain,=0A= that would be a lot more work and I don't think it gains anything at this= =0A= time.=0A= getpwnam(3) needs to be done in userland and is a little bit scary to do,= =0A= since it could get hung on a broken LDAP server or similar.=0A= If done by the TLS handshake daemon, that means new mounts hang, but=0A= at least current mounts keep working.=0A= =0A= >> 3 - I'll post to nfsv4@ietf.org to see what others think of this, since = it would not=0A= >> require any changes to the draft/RFC.=0A= >> 4 - Although it does require a revision to the export_args structure, I = think it is=0A= >> worth doing even if others don't implement it.=0A= Oh, and implementing what is described above did not require the export_arg= s structure to be revised.=0A= =0A= rick=0A= =0A= Thanks. Let me know if you'd like code reviews as well...=0A= =0A= > Again, thanks for your comments, rick=0A= =0A= And thanks for doing the work!=0A= =0A= --=0A= John-Mark Gurney Voice: +1 415 225 5579=0A= =0A= "All that I will do, has been done, All that I have, has not."=0A= From owner-freebsd-current@freebsd.org Sat Mar 28 16:32:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 582C52A70FF for ; Sat, 28 Mar 2020 16:32:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qPQ939cGz48SC; Sat, 28 Mar 2020 16:32:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 39F44F3CD; Sat, 28 Mar 2020 16:32:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::f1a1:8a1f:779d:88b6] (unknown [IPv6:2001:470:7a58:0:f1a1:8a1f:779d:88b6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8CA335AC59; Sat, 28 Mar 2020 17:32:07 +0100 (CET) From: Dimitry Andric Message-Id: <9E22D99A-63CB-4CCB-B3C1-3838F1769BED@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F22C500A-A40C-4B03-9536-7C95CCDCE960"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: kernel build failed Date: Sat, 28 Mar 2020 17:32:00 +0100 In-Reply-To: <4ee54436-0c15-41c3-3581-053da0a08181@shurik.kiev.ua> Cc: freebsd-current@freebsd.org To: Alexandr Krivulya References: <672d55ce-0949-2397-0a3c-3a86020381a4@shurik.kiev.ua> <20200328123542.GR1511@albert.catwhisker.org> <4ee54436-0c15-41c3-3581-053da0a08181@shurik.kiev.ua> X-Mailer: Apple Mail (2.3445.104.14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 16:32:19 -0000 --Apple-Mail=_F22C500A-A40C-4B03-9536-7C95CCDCE960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 28 Mar 2020, at 13:48, Alexandr Krivulya = wrote: >=20 > 28.03.20 14:35, David Wolfskill =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On Sat, Mar 28, 2020 at 02:01:39PM +0200, Alexandr Krivulya wrote: >>> Hello, >>> on latest CURRENT kernel fails to build: >>>=20 >>> =3D=3D=3D> aesni (all) >>> [Creating objdir = /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modul= es/aesni...] >>> ... >>> /usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: = 'wmmintrin.h' >>> file not found >>> #include >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>> *** Error code 1 >>> .... >> I had no issues updating from r359325 to r359356 yesterday, or from >> r359356 to r359389 today (using META_MODE). >=20 > So what may be a reason? I tried: > - remove and checkout source tree > - remove /usr/obj >=20 > wmmintrin.h is present under = /usr/src/contrib/llvm-project/clang/lib/Headers/wmmintrin.h >=20 > /etc/make.conf: > KERNCONF=3DGENERIC-NODEBUG > MALLOC_PRODUCTION=3Dyes >=20 > no /etc/src.conf This typically happens if you don't run "make buildworld", or at least "make kernel-toolchain" before running "make buildkernel", and your userland is missing those headers, for some reason. (Usually people seem to do a WITHOUT_CLANG installation or strip out 'unnecessary' stuff manually...) -Dimitry --Apple-Mail=_F22C500A-A40C-4B03-9536-7C95CCDCE960 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXn98AAAKCRCwXqMKLiCW oySLAJsFk3SdAvty2KkfSeYcdZaT67CO2ACgy1zvN3OfhYSkXC0VS7cag8u4+Tw= =CQiQ -----END PGP SIGNATURE----- --Apple-Mail=_F22C500A-A40C-4B03-9536-7C95CCDCE960-- From owner-freebsd-current@freebsd.org Sat Mar 28 16:35:54 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E28472A71D4 for ; Sat, 28 Mar 2020 16:35:54 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qPVJ5lTqz49bg; Sat, 28 Mar 2020 16:35:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 2369AF3CE; Sat, 28 Mar 2020 16:35:45 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id E279A15DC5; Sat, 28 Mar 2020 17:35:41 +0100 (CET) From: "Kristof Provost" To: FreeBSD-Current Cc: status-updates@freebsdfoundation.org Subject: Bridge project update (Week of March 23rd) Date: Sat, 28 Mar 2020 17:35:41 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <3386C86D-6752-4D42-83B2-82741923C0D2@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 16:35:55 -0000 Hi, This week I got a prototype patch running, along the ideas discussed last week. Essentially, we keep the BRIDGE_LOCK for any add/delete of interfaces or rt entries, but use CK_LIST and epoch in the data path. This is a relatively straightforward change, and currently passes the regression tests (WITNESS/INVARIANTS enabled). I’ve also run traffic through it without issue. My current test setup fails to generate sufficient packets to truly stress the code. I’m hoping to get access to a more suitable setup next week so I can usefully measure the improvement. The prototype patch is also running on my home gateway right now. So far so good! Assuming no major issues come up in the next week or two I hope to post the patch for initial review in the near future. Best regards, Kristof From owner-freebsd-current@freebsd.org Sat Mar 28 19:56:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9362B264333 for ; Sat, 28 Mar 2020 19:56:50 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qTy56QH7z4SqD for ; Sat, 28 Mar 2020 19:56:45 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 02SJvFZY008567 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 28 Mar 2020 12:57:21 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> From: Chris Reply-To: bsd-lists@BSDforge.com To: Toomas Soome Subject: Re: When will the FreeBSD (u)EFI work? Date: Sat, 28 Mar 2020 12:57:21 -0700 Message-Id: <344e85545cfc47c9835fc5918e5b1dc1@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48qTy56QH7z4SqD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.02 / 15.00]; NEURAL_HAM_MEDIUM(-0.63)[-0.631,0]; NEURAL_HAM_LONG(-0.39)[-0.390,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 19:56:50 -0000 On Sat, 28 Mar 2020 11:07:38 +0200 Toomas Soome tsoome@me=2Ecom said > > On 28=2E Mar 2020, at 05:28, Chris wrote: > >=20 > > On Fri, 27 Mar 2020 18:31:50 -0700 bsd-lists@BSDforge=2Ecom > > said > >=20 > >> On Fri, 27 Mar 2020 17:27:27 -0600 Warner Losh imp@bsdimp=2Ecom said > >> > On Fri, Mar 27, 2020 at 4:54 PM Chris wrote= : > >> > > > On Sat, 28 Mar 2020 01:10:37 +0300 Andrey Fesenko f0andrey@gmail= =2Ecom > > said > >> > > > >> > > > On Sat, Mar 28, 2020 at 12:53 AM Chris > > wrote: > >> > > > > > >> > > > > On an experiment of the FreeBSD EFI implementation=2E I installe= d > >> > > > > a copy of releng/12 from install media=2E Which left me with: > >> > > > > # gpart show ada0 > >> > > > > =3D> 40 312581728 ada0 GPT (149G) > >> > > > > 40 409600 1 efi (200M) > >> > > > > 409640 31047680 2 freebsd-ufs (15G) > >> > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > >> > > > > 74788904 237792864 - free - (141G) > >> > > > > > >> > > > > On this Intel based system, I can stab the F12 key to pick > >> > > > > my UEFI bootable OS, or let it boot according to the order > >> > > > > I setup in the BIOS=2E So far, so good=2E > >> > > > > I needed a copy of releng/13 to also work with=2E Installed a co= py > >> > > > > from install media=2E Which left me with: > >> > > > > # gpart show ada0 > >> > > > > =3D> 40 312581728 ada0 GPT (149G) > >> > > > > 40 409600 1 efi (200M) > >> > > > > 409640 31047680 2 freebsd-ufs (15G) > >> > > > > 31457320 7680000 3 freebsd-swap (3=2E7G) > >> > > > > 39137320 532480 4 efi (260M) > >> > > > > 39669800 35119104 5 freebsd-ufs (17G) > >> > > > > 74788904 237792864 - free - (113G) > >> > > > > I *assumed* that the install would activate the new install, a= nd I > >> > > > > would boot straight into it=2E But no=2E I am still on the previou= s > >> > > > > install, and worse, I can't get into the new install -- even i= f > >> > > > > picking it via stabbing the F12 key=2E I *still* end up in the > > previous > >> > > > > install=2E So looking at what might be causing it=2E I found the > >> > following: > >> > > > > # releng/12 > >> > > > > # mount -t msdosfs /dev/ada0p1 /mnt/ > >> > > > > > >> > > > > # ls /mnt/efi/boot/ > >> > > > > BOOTx64=2Eefi > >> > > > > startup=2Ensh > >> > > > > > >> > > > > # cat /mnt/efi/boot/startup=2Ensh > >> > > > > BOOTx64=2Eefi > >> > > > > > >> > > > > # umount /mnt/ > >> > > > > > >> > > > > releng/13 > >> > > > > # mount -t msdosfs /dev/ada0p4 /mnt/ > >> > > > > > >> > > > > # ls /mnt/EFI/freebsd/ > >> > > > > loader=2Eefi > >> > > > > > >> > > > > Why the difference? When will FreeBSD (u)EFI work as expected? > >> > > > > > >> > > > > Thanks in advance for any insights! > >> > > > > > >> > > > > >> > > > Require only single efi part > >> > > > > >> > > > See > >> > > > > >> > > > >> > > > https://forums=2Efreebsd=2Eorg/threads/two-freebsd-installations-and-efi=2E73= 968/ > >> > > Thanks for they reply, and link, Andrey! > >> > > Well that confirms it=2E FreeBSD, unlike other OS implementations, w= ill > > not > >> > > permit booting your chosen "version" via EFI=2E > >> > > Firstly, *huge* thanks for your informative reply, Warner! > >> > It does today=2E If you use efibootmgr, you can boot exactly what you = want=2E > > I > >> > do it all the time=2E=2E=2E Though your BIOS may overwrite the EFI vars i= f you > >> > set too many (I'm looking at you supermicro)=2E When you use the efi > > BootXXXX > >> > variables, it's possible to boot one of many different things on the > >> > system=2E=2E=2E Though I've not done 11, just 12 and current=2E > >> Well=2E That's the thing=2E I *am* on 12 && 13=2E Well *trying* to get into = 13=2E > >> When I started this whole thing, I had some 15 entries returned by > >> efibootmgr(8) -v=2E > >> So I trimmed the list down to the 2 my BIOS presents as UEFI: > >> Boot0015 UEFI: WDC WD1600JS-98MHB0 > >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(4,GPT,6688c5af-6f93= =2E=2E=2E > >> Boot0011* UEFI: WDC WD1600JS-98MHB0 > >> PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x0,0xffff,0x0)/HD(1,GPT,260d2df2-6a10= =2E=2E=2E > >> another entry created when I installed releng/13: > >> Boot0014 FreeBSD (ada0p4) > >> > > HD(4,GPT,6688c5af-6f93-11ea-adbb-4c72b9f5e07f,0x2553028,0x82000)/File(\= EFI\free=2E=2E=2E > >> and a Windows reference (currently not installed)=2E > >> I activated *both* Boot0015 and Boot0011: > >> efibootmgr -a 0015 0011=2E Output confirmed success=2E Bounced box, choose > >> Boot0015=2E Which booted > >> initial releng/12 install=2E Fail=2E OK Try something different; > >> efibootmgr -a 0014 -L FreeBSD-13=2E Output confirms the -L switch is bro= ken, > >> but 00114 is active=2E > >> Bounce box && choose 0014=2E Boots to initial releng/12 install=2E > >> Conclusion; FreeBSD EFI/ESP is not ready for prime time=2E :( > >> Thanks again for the reply, Warner! :) > >> --Chris >=20 >=20 Thank you very much for your reply, Toomas=2E > How loader is working is that it does search for *first* =E2=80=9Cusable= =E2=80=9D freebsd > partition and will use it=2E Usable is defined as having /boot/loader=2Eefi=2E Yes, I understand how this is currently implemented=2E :) >=20 > Therefore, you may have 2 or more freebsd instances on the disk, it reall= y > does not matter, only first is used=2E If you have multiple disks, you can = have > different order on second disk=2E Just a thought along these lines=2E=2E=2E If, for every install, an additional ef= i ESP were created (how it's done now)=2E If the search were for the *first* usable freebsd slice/partition were done incrementally, that is, counting from the ESPs current location on disk=2E It would more often than not, find the install that created ESP it's working from=2E Just one possibility that could be done at near zero cost=2E >=20 > Why it is so? We do build loader=2Eefi and we do copy it to the ESP, and > currently there is no way to tell where is the root file system=2E See above=2E >=20 > How could we tell where from to load the OS? Well, there are few options = to > think about: >=20 > 1=2E record the hint into the loader=2Eefi binary - this would need special > installer and would break signing=2E > 2=2E record EFI variable - it should reflect OS instance version and that > version should be bound with specific loader binary=2E Coordination is pain > there=2E > 3=2E record partition to loader=2Eenv file=20 >=20 > The current loader code is reading "/efi/freebsd/loader=2Eenv=E2=80=9D from= ESP=2E IMO > this sounds most promising, but would need support from installer or manu= al > setup=2E Would work as is with multiple ESP instances=2E Would need versioned > /efi/freebsdXX directories for single shared ESP and installer update=2E >=20 > 4=2E We still do have BE menu in loader, populated automatically from zfs > snapshots=2E It can be complemented with entries from file based index (I w= rote > about that idea already)=2E This would allow to create simple switch to > different instance or initiate chain load of third party boot loader=2E Only drawback is that it is limited to zfs(8)=2E Other thoughts that come to mind: - embedding the GUID hash into the loader that points to the new install=2E - menu, similar to the BE menu you indicated above=2E - adding an additional jump in the UEFI entry already created for the insta= ll that points to the install associated with the newly added loader=2E Lastly=2E It appears that much of what we're currently using was simply hijacked from Linux=2E Why? We're not a Linux=2E The UEFI spec is fairly broad, and gives much leeway for implementing something quite exotic, if we were so inclined=2E Thanks again, for all the time you put into your reply, Toomas! :) --Chris >=20 > just few bits, > toomas >=20 > >> > > > > That is; not without dropping > >> > > to the loader prompt, or changing the status of slices, or boot en= tries > >> > > prior to > >> > > reboot=2E :( > >> > > > >> > > Not needed=2E > >> > > > > Looks like I'll need to install a third party OS, or bootmanag= er to > > use > >> > > FreeBSD=2E > >> > > Sigh=2E=2E=2E > >> > > > >> > > Again, not needed=2E Though there may be a few things that need to b= e > > MFC'd > >> > if you want 11 on that list=2E=2E=2E > >> > > > > There *may* be hope in the future ( > >> > > https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D207940) > >> > > > >> > > This would require you to stop to select on the way up=2E=2E=2E Or am I = not > >> > understanding what you want? > >> > > We should add that functionality to loader=2Eefi, since boot1=2Eefi is= in > > the > >> > process of being deprecated=2E=2E=2E It should be a simple LUA script ther= e=2E=2E=2E > > Isn't everything confined to stand/ ? > > I'd like to try and write all this so that FreeBSD performs EFI/ESP boo= ting > > in a more intuitive way=2E It seems odd to me, that I can install Windows= , and > > it'll add FreeBSD to the (efi) boot menu, but not vis-a-vis=2E > >=20 > > --Chris > >> > > > > Thanks again, Andrey=2E Greatly appreciated! :) > >> > > From owner-freebsd-current@freebsd.org Sat Mar 28 22:07:01 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 46941268190 for ; Sat, 28 Mar 2020 22:07:01 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qXr94P4Bz4JYG for ; Sat, 28 Mar 2020 22:06:49 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-qt1-x842.google.com with SMTP id m33so11932790qtb.3 for ; Sat, 28 Mar 2020 15:06:49 -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; bh=U0fwZtUGk4TtbdgB5CHkF+rQkTPWxWS+8dQzc5aO4NY=; b=qoU9KuiaBPRjFxBW5Ln8Mphd+rxoawMC2GfcN7kpNSLAeROYC750z99fZNtyrDHs2P lgRveHBi/idFnN1AIJDrZ0wdMOm3DIBtB549LAQ2WovZ9geKNd3kWdmegqv739/g/1c9 79/vLKQK+ScFo+9gnj2s7lLaqjt8K/2emdLvI+RvNlXm9QYaX/YhFuJQVmfia//+G6yu 8r/ZDjYrTiNv82jb44jZ5LFjCK5FNGJKqPoZh9B5uJlpB8zl/jl3QQB+8SwJFAakHdo8 KwclrIBCitQx0+hgJjYYKW/9V1xbLkfuLl0Nb3S4EV7xg2q4ulxX2Tg6TVItHCJAeG3V 3uJw== 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; bh=U0fwZtUGk4TtbdgB5CHkF+rQkTPWxWS+8dQzc5aO4NY=; b=IndwheitgtRqZiGuxfw2twGLFPAb//XWma6i+bUuSzJnHKri1MEvBjkVK32UFqPGOr UN+9U/YLr6v/xGER88cTIaim8nd1PrZcJJUoUW4DfwY8vd856o/3TY9ofywKNk/6GjrI UZXXWyA3MGuedTb1Gr7XG8+fK2BEFnsSdP5pxgoehSOJ1AjKDS3ziqPaXuw2IOQy/KCB Jlga9MIIqGQ99RshPw+vr8yyfN8P/6lxiFH9t2njl2YvbK4evLDS+t5o6wj/6/YJMnU/ ztJmG02n5C0uIw647rNvGYUvkdXL5X1a4rrYCMJPb2yV753jSEgfSohQwPqbCgDll/fV 4jSA== X-Gm-Message-State: ANhLgQ1dj32jAkVu/ke9TznJQLHvovn3cWVvtUcF5aglCD/ME4XhCYgV eOVB7gZeJVCnUqHI2tqBj1mOUpQZQoQY1aLo0CeuV2kC X-Google-Smtp-Source: ADFU+vugq0zT0We+v1yO+9rZCmdaRAN8r/Wf1lM+FfgnbIJdVxMV7aI29/nXTIpABvvA3RFQT1sw20yjy/8EYCQVAaU= X-Received: by 2002:a02:1444:: with SMTP id 65mr4986317jag.84.1585432748152; Sat, 28 Mar 2020 14:59:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:bc7:0:0:0:0:0 with HTTP; Sat, 28 Mar 2020 14:59:07 -0700 (PDT) In-Reply-To: <344e85545cfc47c9835fc5918e5b1dc1@udns.ultimatedns.net> References: <318FDBAF-448F-4C55-A9A8-69D71A73E43B@me.com> <344e85545cfc47c9835fc5918e5b1dc1@udns.ultimatedns.net> From: grarpamp Date: Sat, 28 Mar 2020 17:59:07 -0400 Message-ID: Subject: Re: When will the FreeBSD (u)EFI work? To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48qXr94P4Bz4JYG X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qoU9Kuia; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::842 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (0.03), ipnet: 2607:f8b0::/32(-0.36), asn: 15169(-0.46), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 22:07:02 -0000 List users please adhere to email formatting netiquette and *stop* blockquoting massive amounts of reply text, it is not necessary, trim it out leaving only the few lines of what you are replying to directly above your reply.