From owner-freebsd-stable@freebsd.org Sun Jun 11 10:37:32 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41B6DC78CD3; Sun, 11 Jun 2017 10:37:32 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5F4C9D2; Sun, 11 Jun 2017 10:37:31 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v5BAbTel080220; Sun, 11 Jun 2017 12:37:30 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id B8AD3F8F; Sun, 11 Jun 2017 12:37:29 +0200 (CEST) Message-ID: <593D1D5C.907@omnilan.de> Date: Sun, 11 Jun 2017 12:37:16 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, FreeBSD virtualization Subject: panic: Memory modified after free in zio_create, passthru in use [Was: 11.1-pre runtime Undefined symbol "xdr_accepted_reply" /lib/libc.so.7] References: <59369A15.2010901@omnilan.de> In-Reply-To: <59369A15.2010901@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sun, 11 Jun 2017 12:37:30 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 10:37:32 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 06.06.2017 14:03 (localtime): > Hello, > > suddenly, I'm getting this error: > /lib/libc.so.7: Undefined symbol "xdr_accepted_reply" > > Very mysterious: It showed up on a running system, which worked > flawlessly for some hours. And that host has root-fs (/) mounted > readonly from a memorydisk. So to my understanding, it's completely > impossible that /lib/libc.so.7 is corrupted since last boot. > > I'm completely out of ideas what could cause this strange error during > "normal" operation. > > Normal operation in this case is serving as a bhyve test machine. > I first noticed that error after one guest - with passthru device > attached - was shut down. > > My suspicion is some undiscovered passthru interference... Since I > noticed one other _very_ strange passthru-effect: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215740 Hello, this time I caught a panic with a debuging kernel under 11.1-BETA1, which again occured after shuting down a VM which had ppt in use: cpuid = 5 KDB: stack backtrace: #0 0xffffffff805bf327 at kdb_backtrace+0x67 #1 0xffffffff8057f266 at vpanic+0x186 #2 0xffffffff8057f2e3 at panic+0x43 #3 0xffffffff8082eaeb at trash_ctor+0x4b #4 0xffffffff8082aaec at uma_zalloc_arg+0x52c #5 0xffffffff813b54a6 at zio_add_child+0x26 #6 0xffffffff813b5a05 at zio_create+0x385 #7 0xffffffff813b6de2 at zio_vdev_child_io+0x232 #8 0xffffffff81396be0 at vdev_mirror_io_start+0x370 #9 0xffffffff813bc629 at zio_vdev_io_start+0x4a9 #10 0xffffffff813b76bc at zio_execute+0x36c #11 0xffffffff813b6868 at zio_nowait+0xb8 #12 0xffffffff81396bec at vdev_mirror_io_start+0x37c #13 0xffffffff813bc383 at zio_vdev_io_start+0x203 #14 0xffffffff813b76bc at zio_execute+0x36c #15 0xffffffff805d10dd at taskqueue_run_locked+0x13d #16 0xffffffff805d1e78 at taskqueue_thread_loop+0x88 #17 0xffffffff80543844 at fork_exit+0x84 #0 doadump (textdump=) at pcpu.h:222 #1 0xffffffff8057ece0 in kern_reboot (howto=260) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff8057f2a0 in vpanic (fmt=, ap=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff8057f2e3 in panic (fmt=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff8082eaeb in trash_ctor (mem=, size=, arg=, flags=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_dbg.c:80 #5 0xffffffff8082aaec in uma_zalloc_arg (zone=0xfffff8001febc680, udata=0xfffff8001ad5f340, flags=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_core.c:2152 #6 0xffffffff813b54a6 in zio_add_child (pio=0xfffff8026f350b88, cio=0xfffff8002478b7b0) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:460 #7 0xffffffff813b5a05 in zio_create (pio=0xfffff8026f350b88, spa=, txg=433989, bp=, data=0xfffffe0058afa000, size=1024, type=, priority=ZIO_PRIORITY_ASYNC_WRITE, flags=, vd=, offset=, zb=, pipeline=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:690 #8 0xffffffff813b6de2 in zio_vdev_child_io (pio=0xfffff8026f350b88, bp=, vd=, offset=325398016, data=, size=1024, type=, flags=1048704, done=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1141 #9 0xffffffff81396be0 in vdev_mirror_io_start (zio=0xfffff8026f350b88) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:488 #10 0xffffffff813bc629 in zio_vdev_io_start (zio=0xfffff8026f350b88) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3143 #11 0xffffffff813b76bc in zio_execute (zio=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1681 #12 0xffffffff813b6868 in zio_nowait (zio=0xfffff8026f350b88) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1739 #13 0xffffffff81396bec in vdev_mirror_io_start (zio=0xfffff8026f7a7b88) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:488 #14 0xffffffff813bc383 in zio_vdev_io_start (zio=0xfffff8026f7a7b88) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3021 #15 0xffffffff813b76bc in zio_execute (zio=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1681 #16 0xffffffff805d10dd in taskqueue_run_locked (queue=0xfffff8001ab5a700) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/subr_taskqueue.c:454 #17 0xffffffff805d1e78 in taskqueue_thread_loop (arg=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/subr_taskqueue.c:741 #18 0xffffffff80543844 in fork_exit (callout=0xffffffff805d1df0 , arg=0xfffff8001aa90720, frame=0xfffffe043f609ac0) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_fork.c:1042 #19 0xffffffff808598ae in fork_trampoline () at /usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:611 #20 0x0000000000000000 in ?? () This machine is usually rock solid, but shows most strange errors each time I utilize "passthru" with bhyve. Besides runngin a debug kernel, I don't know how to help tracking this down. I can imagine that above quoted PR and the unexplainable »lib/libc.so.7: Undefined symbol "xdr_accepted_reply"« error all have the same undiscovered cause, which shows up as soon as byhve and passtrhu are involved. Please, can anybody of the xperts add a comment? Thanks, -harry From owner-freebsd-stable@freebsd.org Sun Jun 11 18:12:27 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DF58D8BD7B for ; Sun, 11 Jun 2017 18:12:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5745B717C4 for ; Sun, 11 Jun 2017 18:12:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 56914D8BD7A; Sun, 11 Jun 2017 18:12:27 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55F7BD8BD79; Sun, 11 Jun 2017 18:12:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 10269717C1; Sun, 11 Jun 2017 18:12:26 +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 v5BICPIo001685; Sun, 11 Jun 2017 18:12:25 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5BICPG5001684; Sun, 11 Jun 2017 11:12:25 -0700 (PDT) (envelope-from david) Date: Sun, 11 Jun 2017 11:12:25 -0700 From: David Wolfskill To: stable@freebsd.org Subject: Re: post ino64: lockd no runs? Message-ID: <20170611172022.GA3184@albert.catwhisker.org> Reply-To: stable@freebsd.org Mail-Followup-To: stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline In-Reply-To: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:12:27 -0000 --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > of my systems after a full rebuild of src and ports. No log entries > offer any insight as to why :-( >=20 > imb I don't tend to use NFS on my systems that are running head, so I haven't had occasion to test this as stated. However, I just completed my weekly update of the "prooduction" systems here at home, running stable/11. And I find that lockd seems to be ... claiming that all is well, but declining to run (for long). To the best of my knowledge, that was not the case until this last update, which was from: FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 to FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/= 319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.= org:/common/S1/obj/usr/src/sys/ALBERT amd64 The "glaringly obvious" symptom in my case is that I am now unable to (directly) save an email message from within mutt(1) by appending it to an NFS-resident file. (Saving it to a local file, then using cat(1) to append that to the NFS- resident file & removing the local copy works....) After a few variations on a theme of: albert(11.1)[5] sudo service lockd restart lockd not running? Starting lockd. albert(11.1)[6] echo $? 0 albert(11.1)[7] service lockd status lockd is not running. I finally(!) thought to ask ktrace what's going on (as tailing /var/log/messages was completely unproductive, even after enabling rc_debug). So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of the output of kdump(1), I see that the trace ends with: ... 2811 rpc.lockd NAMI "/var/run/logpriv" 2786 sh CALL read(0xa,0x627fc0,0x400) 2786 sh GIO fd 10 read 0 bytes "" 2811 rpc.lockd RET connect 0 2786 sh RET read 0 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) 2786 sh CALL exit(0) 2811 rpc.lockd GIO fd 3 wrote 39 bytes "<30>Jun 11 15:43:10 rpc.lockd: Starting" 2811 rpc.lockd RET sendto 39/0x27 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) 2811 rpc.lockd RET sigaction 0 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffea40) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL exit(0x1) Then, when I tried to send this message, I started getting more whines =66rom mutt(1). I finall gave up and rebooted from the previous environment: FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 and lockd is running: albert(11.1-P)[2] service lockd status lockd is running as pid 629. albert(11.1-P)[3]=20 so mutt(1) is not pitchng a hisssy-fit every time I try to save or send a message. In light of the above, I have Bcced: this message to current@ (where the thread originated) and sent it (and set replies) to stable@. I have a test system, last updated to stable/11 as of mid-October last year; lockd was running on it, as well (which is why I tried going back to last week's image). I'm happy to update it to points where lockd may be broken, if it might help figure out what's broken and how to fix it. Peace, david --=20 David H. Wolfskill david@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZPYgJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XCHQIAKKEI5ugUyQLXysilReYaY2r 7iHfEmIPzuIvklDjgGgzhOSsz61vCvUa9NeRizlMexaan/9rBM41+9mIJqJ281nR kPdRL4ctCRz9wjSf0ASR2M5Y9bApzKCh19E23YSNEfejzBZBMyfQC9griCAi2fmL QmDkbevxTkdfAjsnS+HipeU306rdLX4b71q/4uL+y9tJyB9ZRbzEJ5MlXIahZd/g jO+pGAfX+jJK1nN3Hdkwac3feH4Gnr9TwAk5AwL3Ta8rSp47l+ESIaqcL8rdA1Rh fJMgXf6DwawCWJhlmBbeKk8bO1659Skxknc6UZhd/lUsptjkOyIj4pxRUpUbNkM= =RNn/ -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- From owner-freebsd-stable@freebsd.org Sun Jun 11 18:17:18 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B277D8BF47 for ; Sun, 11 Jun 2017 18:17:18 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B8EE71A62 for ; Sun, 11 Jun 2017 18:17:18 +0000 (UTC) (envelope-from eborisch@gmail.com) Received: by mail-pg0-x234.google.com with SMTP id f185so38697314pgc.0 for ; Sun, 11 Jun 2017 11:17:18 -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=fjSH561vDNzChxdcuoInLeETPp6XjVYFcQsNw/1wWHI=; b=I+NgWvTGkhg+wmA4MsV5Yq7JVmKH4GZ/9JokwB3lqOByrnv5VWmRCIZwiAryGF01BE ALOQF+RBTj24s07uiJOPXWpqlYlpQwwhThR5Hrt61m/eCpzu7OKz9zZEmHmmR60vAtaH 5wR8nXWn2kEvmOxBG4Y/oDIdPdvkExZv6C+ywVojImWqUE0N4W/d+Ngagaru87Wc4BbI Q5tTN5xpfJZ+sIOg/aJInQPvcRCEWjQ3dKVaTd+eQmTMBn3ZiRscO5275Pq+Y8ZWJJyM xfPracUwZI+oTLHfyNOzUk7lw9g5rlHR0axRYtcWgGiXvy+HQQ7IEyceDCjBGhldKqO/ 9/Rw== 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=fjSH561vDNzChxdcuoInLeETPp6XjVYFcQsNw/1wWHI=; b=pTsOkL7PtJfBe/4694X0mOmQ0MO/RzUsIWCmCYJTGCTkbw22H+JPv3yPLauRFc5iY0 17CzihEqtivBPEDJShVjrXOA88uqABt6hzrtaO2qDl37i/mrHuF1noHBwLq92mtGLXJX xV3jQlkrHUwy1VtBins/fsmC6HRkKwfaDSGMI0vuTq34446BNlaBvqaDqeQvEAIsow2r LTbQTXTlHfXJPRZMKsdgGXQAQLo0jIhbpUkDTpucQxhajT9SRKwfryr1TTmOYJXZ0vCr MSGgqlCtuDIUPLJiPR3ZnQzyDRK2bm0OfeyjTjSo+j6LKOo5mndBPa7PJW/46pK8aR1y PviA== X-Gm-Message-State: AODbwcBZfY4/PqChyOq7/gQeoANu6jmdncLSryGvWYmQpj50W9YiLXts HlNb7ljScN7QB7Q3X41wi5cIpmA9lS4ieRM= X-Received: by 10.99.181.67 with SMTP id u3mr54255888pgo.89.1497205037393; Sun, 11 Jun 2017 11:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.129.149 with HTTP; Sun, 11 Jun 2017 11:17:16 -0700 (PDT) In-Reply-To: References: From: "Eric A. Borisch" Date: Sun, 11 Jun 2017 13:17:16 -0500 Message-ID: Subject: Re: Can't boot (zfs-on-root) with "options EARLY_AP_STARTUP" and "device pf" To: FreeBSD Stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:17:18 -0000 FWIW, it appears to be crashing for an integer divide fault in pf_purge_thread in the 'pf_purge' process. If i turn on INVARIAINTS and INVARIANT_SUPPORT, it boots. Perhaps a race? - Eric On Fri, Jun 9, 2017 at 5:04 PM, Eric A. Borisch wrote: > Good afternoon, > > I tried to update the kernel on my Lenovo x230 (stable/11), and I would > get crashes on boot. *I am running a non-GENERIC kernel.* Bisecting the > changes from last-known-good, I found that I couldn't boot on any kernel > past after r318752. The next change to the kernel, r318763 [1], turned on > EARLY_AP_STARTUP by default. > > I've narrowed it down to what appears to be a conflict with 'options > EARLY_AP_STARTUP' and 'device pf'. I can build a farily vanilla kernel with > these set, and it crashes on boot. (I have a few other options set to > enable root-on-zfs-on-geli.) > > Any suggestions, other than 'don't do that?', > - Eric > > [1] https://svnweb.freebsd.org/base?view=revision&revision=318763 > From owner-freebsd-stable@freebsd.org Sun Jun 11 18:48:29 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD7F0D8C8ED for ; Sun, 11 Jun 2017 18:48:29 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA3E72AE6 for ; Sun, 11 Jun 2017 18:48:29 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9EC3ED8C8EC; Sun, 11 Jun 2017 18:48:29 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E48BD8C8EB for ; Sun, 11 Jun 2017 18:48:29 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7252872AE5 for ; Sun, 11 Jun 2017 18:48:29 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id K7uNdxNkIETFpK7uOdp6sV; Sun, 11 Jun 2017 12:48:21 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=LWSFodeU3zMA:10 a=JAf30KXuAAAA:8 a=capo1NdyAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=ultTwZIKIEoFYwmveK8A:9 a=CjuIK1q_8ugA:10 a=v2312BZ5C20A:10 a=GEL62FyrTCmHtEug2d3R:22 a=9rL3IfpHMVDODJIA5_Zr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 7CEFEC35 for ; Sun, 11 Jun 2017 11:48:19 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v5BIl4Jw011214 for ; Sun, 11 Jun 2017 11:47:04 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201706111847.v5BIl4Jw011214@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: stable@freebsd.org Subject: Re: post ino64: lockd no runs? In-Reply-To: Message from David Wolfskill of "Sun, 11 Jun 2017 11:12:25 -0700." <20170611172022.GA3184@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jun 2017 11:47:04 -0700 X-CMAE-Envelope: MS4wfLvtda9Mpi+1o5kYVSMvCI6QhMiuUOxyeQKopWxCC7PHSbgs7/W7u/ORH0Xom/jPFNxirKklhRlq8q94OFjtmA8NysSCL1Pfm86zJH+0s7ZWMnnFizQZ aBd+dfZhq2UfhN9KVf3FWe1cXYOKazmUj6e2L7UjrxTMR7I3SIXC1oO5J5f1Wu/5jXSLTQK5qD/MFg== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:48:29 -0000 In message <20170611172022.GA3184@albert.catwhisker.org>, David Wolfskill write s: > > --0eh6TmSyL6TZE2Uz > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > > of my systems after a full rebuild of src and ports. No log entries > > offer any insight as to why :-( > >=20 > > imb > > I don't tend to use NFS on my systems that are running head, so I > haven't had occasion to test this as stated. > > However, I just completed my weekly update of the "prooduction" systems > here at home, running stable/11. And I find that lockd seems to be ... > claiming that all is well, but declining to run (for long). > > To the best of my knowledge, that was not the case until this last > update, which was from: > > FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = > r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= > atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > > to > > FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/= > 319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.= > org:/common/S1/obj/usr/src/sys/ALBERT amd64 > > The "glaringly obvious" symptom in my case is that I am now unable > to (directly) save an email message from within mutt(1) by appending > it to an NFS-resident file. (Saving it to a local file, then using > cat(1) to append that to the NFS- resident file & removing the local > copy works....) > > After a few variations on a theme of: > > albert(11.1)[5] sudo service lockd restart > lockd not running? > Starting lockd. > albert(11.1)[6] echo $? > 0 > albert(11.1)[7] service lockd status > lockd is not running. > > I finally(!) thought to ask ktrace what's going on (as tailing > /var/log/messages was completely unproductive, even after enabling > rc_debug). > > So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of > the output of kdump(1), I see that the trace ends with: > > ... > 2811 rpc.lockd NAMI "/var/run/logpriv" > 2786 sh CALL read(0xa,0x627fc0,0x400) > 2786 sh GIO fd 10 read 0 bytes > "" > 2811 rpc.lockd RET connect 0 > 2786 sh RET read 0 > 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) > 2786 sh CALL exit(0) > 2811 rpc.lockd GIO fd 3 wrote 39 bytes > "<30>Jun 11 15:43:10 rpc.lockd: Starting" > 2811 rpc.lockd RET sendto 39/0x27 > 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) > 2811 rpc.lockd RET sigaction 0 > 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) > 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address > 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffea40) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) > 2811 rpc.lockd RET sigprocmask 0 > 2811 rpc.lockd CALL exit(0x1) > > Then, when I tried to send this message, I started getting more whines > =66rom mutt(1). I finall gave up and rebooted from the previous > environment: > > FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = > r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= > atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > > and lockd is running: > > albert(11.1-P)[2] service lockd status > lockd is running as pid 629. > albert(11.1-P)[3]=20 > > so mutt(1) is not pitchng a hisssy-fit every time I try to save or > send a message. > > > In light of the above, I have Bcced: this message to current@ (where > the thread originated) and sent it (and set replies) to stable@. > > > I have a test system, last updated to stable/11 as of mid-October > last year; lockd was running on it, as well (which is why I tried > going back to last week's image). I'm happy to update it to points > where lockd may be broken, if it might help figure out what's broken > and how to fix it. I'm running lockd on recent -CURRENT systems. No issues so far. Locking works as expected. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-stable@freebsd.org Sun Jun 11 18:58:40 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4318CD8CBA6 for ; Sun, 11 Jun 2017 18:58:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2A50273060 for ; Sun, 11 Jun 2017 18:58:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 26899D8CBA5; Sun, 11 Jun 2017 18:58:40 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 243DED8CBA4 for ; Sun, 11 Jun 2017 18:58:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 9CDD07305E for ; Sun, 11 Jun 2017 18:58:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5BIwUV6072223 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 11 Jun 2017 21:58:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5BIwUV6072223 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5BIwU3h072222 for stable@freebsd.org; Sun, 11 Jun 2017 21:58:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 11 Jun 2017 21:58:30 +0300 From: Konstantin Belousov To: stable@freebsd.org Subject: Re: post ino64: lockd no runs? Message-ID: <20170611185830.GS2088@kib.kiev.ua> References: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> <20170611172022.GA3184@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170611172022.GA3184@albert.catwhisker.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:58:40 -0000 On Sun, Jun 11, 2017 at 11:12:25AM -0700, David Wolfskill wrote: > 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) > 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address If you revert r319614 on stable/11, does the problem go away ? From owner-freebsd-stable@freebsd.org Sun Jun 11 20:51:27 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6B22B9484E for ; Sun, 11 Jun 2017 20:51:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CDBB07622A for ; Sun, 11 Jun 2017 20:51:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id CD043B9484D; Sun, 11 Jun 2017 20:51:27 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC62FB9484B for ; Sun, 11 Jun 2017 20:51:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 7F27776229 for ; Sun, 11 Jun 2017 20:51:26 +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 v5BKpP0W003011; Sun, 11 Jun 2017 20:51:25 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5BKpOJC003010; Sun, 11 Jun 2017 13:51:24 -0700 (PDT) (envelope-from david) Date: Sun, 11 Jun 2017 13:51:24 -0700 From: David Wolfskill To: Konstantin Belousov Cc: stable@freebsd.org Subject: Re: post ino64: lockd no runs? Message-ID: <20170611205124.GD1284@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , stable@freebsd.org References: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> <20170611172022.GA3184@albert.catwhisker.org> <20170611185830.GS2088@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LKTjZJSUETSlgu2t" Content-Disposition: inline In-Reply-To: <20170611185830.GS2088@kib.kiev.ua> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 20:51:28 -0000 --LKTjZJSUETSlgu2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 11, 2017 at 09:58:30PM +0300, Konstantin Belousov wrote: > On Sun, Jun 11, 2017 at 11:12:25AM -0700, David Wolfskill wrote: > > 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) > > 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address >=20 > If you revert r319614 on stable/11, does the problem go away ? > .... As it happens, apparently so. I was able to reproduce the symptom on my build machine: freebeast(11.1)[1] uname -a && service lockd status=20 FreeBSD freebeast.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #366 r31982= 3M/319823:1100514: Sun Jun 11 03:55:49 PDT 2017 root@freebeast.catwhisk= er.org:/co mmon/S1/obj/usr/src/sys/GENERIC amd64 lockd is not running. freebeast(11.1)[2]=20 I then "cloned" slice 1 to slice 3, and on slice 3's /usr/src, I used "svn diff" and "svn patch --reverse-diff" to effectively revert r319614, then rebooted from slice 3, did a normal src-based update; rebooted, and: freebeast(11.1)[1] uname -a && service lockd status FreeBSD freebeast.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #367 r31982= 3M/319823:1100514: Sun Jun 11 13:31:49 PDT 2017 root@freebeast.catwhisk= er.org:/co mmon/S3/obj/usr/src/sys/GENERIC amd64 lockd is running as pid 600. freebeast(11.1)[2] If there's a patch someone would like me to try that's a bit more involved than just reverting r319614, I'm up for it. Peace, david --=20 David H. Wolfskill david@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --LKTjZJSUETSlgu2t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZPa1MXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XTIcH/jiXxKW0ziC4rULETmQeFQDT QWN5antV7wZTDk8v2fjq6qOtOrStE2eXGFCvhbAAJoEkYb0a3ykq+q+aBeJaItJj qeTnd8+q6cn4bgThan3fzKSgb0D/wFpSA5no0DfnzIrAW/k4uE3wELteoaxSwqS9 rT1UToT2enAIASemZVL8rkrFCzSIkq6eqs7xEHKAG/mObMIyNsKBvZ97iZr10/hb I3pugsTbn8s8cVmdU1SEHQSAn/iVOxq/3c+o9hURwxwv2tp6eE74HIqJNdRHOF1R ZMIGwOYkJsgpM6i1baIC8iHakSjqzfJh6syKq/7lqMpLf5ioG0Q81z8+zVs7fMg= =Ei9D -----END PGP SIGNATURE----- --LKTjZJSUETSlgu2t-- From owner-freebsd-stable@freebsd.org Sun Jun 11 21:04:14 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B50BCB952A4 for ; Sun, 11 Jun 2017 21:04:14 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66093770F6 for ; Sun, 11 Jun 2017 21:04:14 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-qt0-x230.google.com with SMTP id u12so108107407qth.0 for ; Sun, 11 Jun 2017 14:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fKtSGhABDs++ePa/oQtI6F7JOBPxqJ3UaGWPI+s818c=; b=lmKTFQOaU+wLDICAQ55jphgBzBJNTIi16Ho5vnvOzrR0dvi+KTeHHifDfYn0l1RCNu ORvkYu/mSx/pMBvkFVztND5iqusBlpKus3EENX6yBqaJ+GG1Wu0NB81ktWUMI/azS92x mZ0LoOxXgJkvfDKJY2u0bkVMoUrX4pFTxEMZXevfyZavrwCg0YVv/zThvZvTyuxADOOB oHGVuvWZpxjKJUyjSR+Lu4TdXdV843+ObR29yg6cD63DHiChB0rviNODOLvENWB58yl0 yjP6CjjhQylQ51tEh2JAcenGVoD1M3KhnnPfsX/dZAE2Y/fDAT6oI+EOeFI9Crh8evU1 pGUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fKtSGhABDs++ePa/oQtI6F7JOBPxqJ3UaGWPI+s818c=; b=aJbt2Ycob7hs16Oa9EF3klOXQ0vzzX/CT7AMt8yI1ajHdKkxmWKgVZ9t6EoTxmum3g nYTh6dYbKfBhqf1wFVaGmFTSNCeaPW+sdXnDPH15M9uKm87lCWMHmv1voVo4NGrl7fm7 gHVhHKh+D/VCauR4doqH2QQ1f044Fyn6uXhRBvFIeOdlQ3XbjDI/SViVbZ7yuG0XMvLY 6er3Cu9BWEXK26hikvfNnic35qIDIp760eOkeIcTOZKN7hKamCUWYBaOz+Gx1m9F4hi1 tSpRXECLOzKzy7jhXuzlqSSBgaS3AChwtD75CoquqXeme4KSycyMjEnjiC4p4AGYoEsk uzHg== X-Gm-Message-State: AKS2vOxgbhI4D8Z5LkEjGskiBFfla1GmAnW/x1NnXteu+KD4hYuSztPb ogZS4Pv1ohu9T/Itdof5q/A92VT0nCRe X-Received: by 10.55.105.133 with SMTP id e127mr62542290qkc.19.1497215053096; Sun, 11 Jun 2017 14:04:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.171 with HTTP; Sun, 11 Jun 2017 14:04:12 -0700 (PDT) X-Originating-IP: [203.99.129.1] In-Reply-To: <20170610123435.GB69235@FreeBSD.org> References: <20170610123435.GB69235@FreeBSD.org> From: Jonathan Chen Date: Mon, 12 Jun 2017 09:04:12 +1200 Message-ID: Subject: Re: FreeBSD 11.1-BETA1 Now Available To: Glen Barber Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 21:04:14 -0000 On 11 June 2017 at 00:34, Glen Barber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > The first BETA build of the 11.1-RELEASE release cycle is now available. > > Installation images are available for: > > o 11.1-BETA1 amd64 GENERIC > o 11.1-BETA1 i386 GENERIC > o 11.1-BETA1 powerpc GENERIC > o 11.1-BETA1 powerpc64 GENERIC64 > o 11.1-BETA1 sparc64 GENERIC > o 11.1-BETA1 armv6 BANANAPI > o 11.1-BETA1 armv6 BEAGLEBONE > o 11.1-BETA1 armv6 CUBIEBOARD > o 11.1-BETA1 armv6 CUBIEBOARD2 > o 11.1-BETA1 armv6 CUBOX-HUMMINGBOARD > o 11.1-BETA1 armv6 GUMSTIX > o 11.1-BETA1 armv6 RPI-B > o 11.1-BETA1 armv6 RPI2 > o 11.1-BETA1 armv6 PANDABOARD > o 11.1-BETA1 armv6 WANDBOARD > o 11.1-BETA1 aarch64 GENERIC > > Note regarding arm/armv6 images: For convenience for those without > console access to the system, a freebsd user with a password of > freebsd is available by default for ssh(1) access. Additionally, > the root user password is set to root. It is strongly recommended > to change the password for both users after gaining access to the > system. [...] I was hoping for an aarch64 RPI3 image for SD cards to try out FreeBSD 11.1. There's a memstick image, but I don't think that will work for the RPI3? Cheers. -- Jonathan Chen From owner-freebsd-stable@freebsd.org Sun Jun 11 22:54:09 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B5CFBEED7F for ; Sun, 11 Jun 2017 22:54:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0370F79C4B for ; Sun, 11 Jun 2017 22:54:08 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7FEFABEED79; Sun, 11 Jun 2017 22:54:08 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F7F9BEED78; Sun, 11 Jun 2017 22:54:08 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 D85B879C47; Sun, 11 Jun 2017 22:54:06 +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 v5BMs2fk003670; Sun, 11 Jun 2017 22:54:05 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5BI8ugc001605; Sun, 11 Jun 2017 11:08:56 -0700 (PDT) (envelope-from david) Date: Sun, 11 Jun 2017 11:08:56 -0700 From: David Wolfskill To: Michael Butler Cc: stable@freebsd.org Subject: Re: post ino64: lockd no runs? Message-ID: <20170611172022.GA3184@albert.catwhisker.org> Reply-To: stable@freebsd.org Mail-Followup-To: stable@freebsd.org, Michael Butler MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 22:54:09 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > of my systems after a full rebuild of src and ports. No log entries > offer any insight as to why :-( >=20 > imb I don't tend to use NFS on my systems that are running head, so I haven't had occasion to test this as stated. However, I just completed my weekly update of the "prooduction" systems here at home, running stable/11. And I find that lockd seems to be ... claiming that all is well, but declining to run (for long). To the best of my knowledge, that was not the case until this last update, which was from: FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 to FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/= 319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.= org:/common/S1/obj/usr/src/sys/ALBERT amd64 The "glaringly obvious" symptom in my case is that I am now unable to (directly) save an email message from within mutt(1) by appending it to an NFS-resident file. (Saving it to a local file, then using cat(1) to append that to the NFS- resident file & removing the local copy works....) After a few variations on a theme of: albert(11.1)[5] sudo service lockd restart lockd not running? Starting lockd. albert(11.1)[6] echo $? 0 albert(11.1)[7] service lockd status lockd is not running. I finally(!) thought to ask ktrace what's going on (as tailing /var/log/messages was completely unproductive, even after enabling rc_debug). So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of the output of kdump(1), I see that the trace ends with: ... 2811 rpc.lockd NAMI "/var/run/logpriv" 2786 sh CALL read(0xa,0x627fc0,0x400) 2786 sh GIO fd 10 read 0 bytes "" 2811 rpc.lockd RET connect 0 2786 sh RET read 0 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) 2786 sh CALL exit(0) 2811 rpc.lockd GIO fd 3 wrote 39 bytes "<30>Jun 11 15:43:10 rpc.lockd: Starting" 2811 rpc.lockd RET sendto 39/0x27 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) 2811 rpc.lockd RET sigaction 0 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffea40) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_BLOCK,0x800830c78,0x7fffffffe5b0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL sigprocmask(SIG_SETMASK,0x800830c8c,0) 2811 rpc.lockd RET sigprocmask 0 2811 rpc.lockd CALL exit(0x1) Then, when I tried to send this message, I started getting more whines =66rom mutt(1). I finall gave up and rebooted from the previous environment: FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 = r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.c= atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 and lockd is running: albert(11.1-P)[2] service lockd status lockd is running as pid 629. albert(11.1-P)[3]=20 so mutt(1) is not pitchng a hisssy-fit every time I try to save or send a message. In light of the above, I have Bcced: this message to current@ (where the thread originated) and sent it (and set replies) to stable@. I have a test system, last updated to stable/11 as of mid-October last year; lockd was running on it, as well (which is why I tried going back to last week's image). I'm happy to update it to points where lockd may be broken, if it might help figure out what's broken and how to fix it. Peace, david --=20 David H. Wolfskill david@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZPYc3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XN3oIAM28Fz1XHx5Y8ZOj3XFVh3Ik 7a54Z972WwfLwSCuYuk+U7lDurBMuBklQHVTOy7+rcghZMLAbuvXRUwkjF7lxErj nbwtxzy/z2xXKdAAxuTxq4OXZvwH/eVD1Pcywu9tA4EKjJeoivFEOmFbVJ7qSyJH W9hQLdZBp9jcGxZyuoGPRkW8EbDLKbybO4VjxsYhf/nkaNrNJoG0BOHLjSlnD2kB rgfjH4PSlHeHEb4IsKHsusLEgRDMxgHIKmw1FkgIQBkfNouV4jUhmUqMUSHk7+dd oCEo2Z6cS5xCU+h1R1ztZvNIJNMJYNvnYhrjwYo3O2RUlwnxO8x1K4u7OK5JEpE= =eWJh -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-stable@freebsd.org Mon Jun 12 04:43:19 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BF13BF3AF4 for ; Mon, 12 Jun 2017 04:43:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3177F81B01 for ; Mon, 12 Jun 2017 04:43:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id m47so4992429iti.1 for ; Sun, 11 Jun 2017 21:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1p++8mjJ4bMLQB2oobkHKOTG7Si6vetEfALGIXaF96E=; b=01RFD0dEDBiGAC68YVh0mOFp1Qyo5n7W0k4vAT7C7EfxoXzltv7JlUwnKD6+eYSI8c E+wvehLY1CnWBNJH7eBCYo/aPOquq4jCZKBl6dovB4rIa7u0RKafaxwT2zK+c3EqARjo 9Q4ao+620+BbMl2b1rPWesD7y7WOWj+5TFPEHDeuIifAP/1miC1dC0Ee+YvP4Df17TO7 Tp9m0fxz2sM93CA1gXKHjBHkRZcLS29lGB3CQys7kJgn0m7XjH+YjEru8Y2LKKMMuoy9 3kSQVBemm2M6YMgpOJQP97dV8qztnsHmd/hM22QGO1k2OGq3y2y5ZX+5EYIBrbfnA2WM OS5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1p++8mjJ4bMLQB2oobkHKOTG7Si6vetEfALGIXaF96E=; b=uYW6CyBKdU8GA89i3SSFP/nbRnyJPidCePSkIz2xHFdRLvNoPOzK97muu8TZceHTJr GOy360eCzh7Z2rYtRreTKljSXaD0setqUM+hgjTh4lstk/Md0DE/py/TYy/UEPrrUgyX LrczNK7429KWeOsgvDxYgiHhn7naf4WGj5Pt4RHhr+itmTbzHfxxqTlgvxnMJyRfh8de OxpgeIrbFA9FUAM1zWIj8tLcGHzRM6ldKQN8yBbZ7xAYyxIKAJsTBiS6uwChEVCvCKaB AUHTS/kQc7vde9Y7C7FAspkPuvYpzaMjOrV3r5pux3Ywi41Tlhr3n4Gb8W09GQQO1g6q mD1g== X-Gm-Message-State: AODbwcD3hjEHKTCrP2z8y6J5XQ9JGU2qXoTjXClNEjI78dDMlg4fPiXx FSMmvsXqfVmG2x2R8fbjmRA4Rek9fA/D X-Received: by 10.36.181.4 with SMTP id v4mr10667932ite.103.1497242598103; Sun, 11 Jun 2017 21:43:18 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Sun, 11 Jun 2017 21:43:17 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: References: <20170610123435.GB69235@FreeBSD.org> From: Warner Losh Date: Sun, 11 Jun 2017 22:43:17 -0600 X-Google-Sender-Auth: ZXClk_GfZiWPDBVmevON4PAW12w Message-ID: Subject: Re: FreeBSD 11.1-BETA1 Now Available To: Jonathan Chen Cc: Glen Barber , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 04:43:19 -0000 On Sun, Jun 11, 2017 at 5:04 PM, Jonathan Chen wrote: > On 11 June 2017 at 00:34, Glen Barber wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > The first BETA build of the 11.1-RELEASE release cycle is now available. > > > > Installation images are available for: > > > > o 11.1-BETA1 amd64 GENERIC > > o 11.1-BETA1 i386 GENERIC > > o 11.1-BETA1 powerpc GENERIC > > o 11.1-BETA1 powerpc64 GENERIC64 > > o 11.1-BETA1 sparc64 GENERIC > > o 11.1-BETA1 armv6 BANANAPI > > o 11.1-BETA1 armv6 BEAGLEBONE > > o 11.1-BETA1 armv6 CUBIEBOARD > > o 11.1-BETA1 armv6 CUBIEBOARD2 > > o 11.1-BETA1 armv6 CUBOX-HUMMINGBOARD > > o 11.1-BETA1 armv6 GUMSTIX > > o 11.1-BETA1 armv6 RPI-B > > o 11.1-BETA1 armv6 RPI2 > > o 11.1-BETA1 armv6 PANDABOARD > > o 11.1-BETA1 armv6 WANDBOARD > > o 11.1-BETA1 aarch64 GENERIC > > > > Note regarding arm/armv6 images: For convenience for those without > > console access to the system, a freebsd user with a password of > > freebsd is available by default for ssh(1) access. Additionally, > > the root user password is set to root. It is strongly recommended > > to change the password for both users after gaining access to the > > system. > [...] > > I was hoping for an aarch64 RPI3 image for SD cards to try out FreeBSD > 11.1. There's a memstick image, but I don't think that will work for > the RPI3? > aarch64 support isn't completely integrated into FreeBSD 11 yet. Warner From owner-freebsd-stable@freebsd.org Mon Jun 12 07:25:04 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BCEDBF5B18 for ; Mon, 12 Jun 2017 07:25:04 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 15F6D641 for ; Mon, 12 Jun 2017 07:25:04 +0000 (UTC) (envelope-from delphij@delphij.net) Received: by mailman.ysv.freebsd.org (Postfix) id 121D9BF5B17; Mon, 12 Jun 2017 07:25:04 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FC61BF5B16 for ; Mon, 12 Jun 2017 07:25:04 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3597640 for ; Mon, 12 Jun 2017 07:25:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:37a:7080:8f78:b5de:7843]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 200B41726B; Mon, 12 Jun 2017 00:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1497252303; x=1497266703; bh=tObyj6gYo3idUxjVomYDYS5e0FrCvyq7rFXVFyzb+0s=; h=Cc:Subject:To:References:From:Date:In-Reply-To; b=iBeE3z72ShkYefRsvX0prWQHHFMX83wvgw8nsssCIA83nJBs1dbm0F/iew7NCklOh tuNQ/yaA/DO9F7h4m4ovrQ2qG9PcAlWhJOFUujDmdnZTakcEYsrk2mmbVnlXWJBb47 H/Pukh0xMqJq0qcgT8SbW4zZANX9JS27ykW3xcRI= Cc: d@delphij.net Subject: Re: post ino64: lockd no runs? To: David Wolfskill , Konstantin Belousov , stable@freebsd.org References: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> <20170611172022.GA3184@albert.catwhisker.org> <20170611185830.GS2088@kib.kiev.ua> <20170611205124.GD1284@albert.catwhisker.org> From: Xin Li Message-ID: <85c966e1-f719-5d4a-d6c3-b0da7c0f6dda@delphij.net> Date: Mon, 12 Jun 2017 00:24:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170611205124.GD1284@albert.catwhisker.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jGpQtonmPe0GU9d6rCTbficmv8sTQk3FT" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 07:25:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jGpQtonmPe0GU9d6rCTbficmv8sTQk3FT Content-Type: multipart/mixed; boundary="wSuAt2EHsAUle86xemt1CPfnnUhf6NgCE"; protected-headers="v1" From: Xin Li To: David Wolfskill , Konstantin Belousov , stable@freebsd.org Cc: d@delphij.net Message-ID: <85c966e1-f719-5d4a-d6c3-b0da7c0f6dda@delphij.net> Subject: Re: post ino64: lockd no runs? References: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> <20170611172022.GA3184@albert.catwhisker.org> <20170611185830.GS2088@kib.kiev.ua> <20170611205124.GD1284@albert.catwhisker.org> In-Reply-To: <20170611205124.GD1284@albert.catwhisker.org> --wSuAt2EHsAUle86xemt1CPfnnUhf6NgCE Content-Type: multipart/mixed; boundary="------------A4444EA85EE961FFE6C1B005" Content-Language: en-US This is a multi-part message in MIME format. --------------A4444EA85EE961FFE6C1B005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for Kostantin's hints, this is indeed related to my change (which exposed an old bug with rpc.lockd). Please try attached fix. Cheers, --------------A4444EA85EE961FFE6C1B005 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="rpc.lockd.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rpc.lockd.diff" Index: usr.sbin/rpc.lockd/lockd.c =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 --- usr.sbin/rpc.lockd/lockd.c (revision 319826) +++ usr.sbin/rpc.lockd/lockd.c (working copy) @@ -902,8 +902,7 @@ lookup_addresses(struct netconfig *nconf) sin->sin_port =3D htons(0); sin->sin_addr.s_addr =3D htonl(INADDR_ANY); res->ai_addr =3D (struct sockaddr*) sin; - res->ai_addrlen =3D (socklen_t) - sizeof(res->ai_addr); + res->ai_addrlen =3D sizeof(struct sockaddr_in); break; case AF_INET6: sin6 =3D malloc(sizeof(struct sockaddr_in6)); @@ -913,7 +912,7 @@ lookup_addresses(struct netconfig *nconf) sin6->sin6_port =3D htons(0); sin6->sin6_addr =3D in6addr_any; res->ai_addr =3D (struct sockaddr*) sin6; - res->ai_addrlen =3D (socklen_t) sizeof(res->ai_addr); + res->ai_addrlen =3D sizeof(struct sockaddr_in6); break; default: break; @@ -938,7 +937,7 @@ lookup_addresses(struct netconfig *nconf) } } =20 - servaddr.len =3D servaddr.maxlen =3D res->ai_addr->sa_len; + servaddr.len =3D servaddr.maxlen =3D res->ai_addrlen; servaddr.buf =3D res->ai_addr; uaddr =3D taddr2uaddr(nconf, &servaddr); =20 --------------A4444EA85EE961FFE6C1B005-- --wSuAt2EHsAUle86xemt1CPfnnUhf6NgCE-- --jGpQtonmPe0GU9d6rCTbficmv8sTQk3FT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZPkHNAAoJEJW2GBstM+nsDmEP/21BPug6gITEQlldTB853dMf fwicA//qmON2KOebrISlqnP+ZbOv8qkbf4hL39wB8a6XUORf3Efz9sVUr7b/7yS1 OhHjkzsNzTNm+ZjM2D5YqgYslTsx9Gwi8s7l6JVjr55aWMKbhEk0bobSEceqfaIr 5p7WOOPxn97ZCmuocLR6U0luD5g6zXY9wyUbDuxmgpwfVo9A6yuTlhMnZTlzQMN4 QWTc6783R7E8em18kHH8LhfG2b/9lchLCM0QZe/DS/bDd3Pa++DtPEILEnLrzYfy VfcGyp99e/Rc/KidkLN3RZ0NYj7yWtNmxGtGstBSAdUj5WntAtMc0e3TyNyi+e68 gWdJUnxANexW/T4PowPKhzkMEl1o7EwXEoqfPBNr71Y4pVBsY5fu83nETnNZpyGy ap+6E8mPJ8acxncxMe6JCKre7nqAvNuYRkAPBAmh9itXb7iYIQpWeE6pj0yY4Uqx WtBBjPNyeIIEWOQ21dqfI6ay4qafWU8vLDGuKaS4PNdS3tRcBu/72GA4Pdd1wwxJ IfLzwnr9H47kRSn3zc3FnujY0E1us1okKtRnxMs/fAkvz5caIzBGojv7q+xTBZjA 3QLuJMNH/zIP+6laCHH4srBtd99ZTTRU+NEAK8iOTGjG6ceLNJIRZVEk89zemflP VREaW7ye97dhkwU1Vqn7 =DMs9 -----END PGP SIGNATURE----- --jGpQtonmPe0GU9d6rCTbficmv8sTQk3FT-- From owner-freebsd-stable@freebsd.org Mon Jun 12 12:14:45 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3527DBFBA3E for ; Mon, 12 Jun 2017 12:14:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1AAF76A8FC for ; Mon, 12 Jun 2017 12:14:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 16B0BBFBA3D; Mon, 12 Jun 2017 12:14:45 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16439BFBA3C for ; Mon, 12 Jun 2017 12:14:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 ACE796A8FB for ; Mon, 12 Jun 2017 12:14:44 +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 v5CCEbhv012530; Mon, 12 Jun 2017 12:14:37 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v5CCEbL9012529; Mon, 12 Jun 2017 05:14:37 -0700 (PDT) (envelope-from david) Date: Mon, 12 Jun 2017 05:14:37 -0700 From: David Wolfskill To: Xin Li Cc: Konstantin Belousov , stable@freebsd.org, d@delphij.net Subject: Re: post ino64: lockd no runs? Message-ID: <20170612121437.GR1284@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Xin Li , Konstantin Belousov , stable@freebsd.org, d@delphij.net References: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> <20170611172022.GA3184@albert.catwhisker.org> <20170611185830.GS2088@kib.kiev.ua> <20170611205124.GD1284@albert.catwhisker.org> <85c966e1-f719-5d4a-d6c3-b0da7c0f6dda@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EjUKZjov3T4fFoFJ" Content-Disposition: inline In-Reply-To: <85c966e1-f719-5d4a-d6c3-b0da7c0f6dda@delphij.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 12:14:45 -0000 --EjUKZjov3T4fFoFJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 12, 2017 at 12:24:58AM -0700, Xin Li wrote: > Thanks for Kostantin's hints, this is indeed related to my change (which > exposed an old bug with rpc.lockd). >=20 > Please try attached fix. > .... Aye; that appears to do the job: freebeast(11.1)[1] uname -a && service lockd status FreeBSD freebeast.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #367 r31982= 3M/319852:1100514: Mon Jun 12 04:58:48 PDT 2017 root@freebeast.catwhisk= er.org:/co mmon/S3/obj/usr/src/sys/GENERIC amd64 lockd is running as pid 602. freebeast(11.1)[2]=20 Thanks! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump (et al.): Hiding information doesn't prove its falsity. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --EjUKZjov3T4fFoFJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZPoWtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XHjsIAIVN/fCgQnu7rxYbmCMcBAat aVesUmYmFi0mCpw30QcTlqJFq6Ff6Ii5dQurvd5fRzKCDo3flaZkaWJ+PErAyXSy AhI/lbpR7OwxyUghd1isoBYUg9YmfxSKGINzALdRS1bK6W5gxtjyF0wbmp+plplb Qed+h4kBmAGGrzhAIQl5deZcTyyN80KOoW2KxeN+wgeGnZgFIhioOAXxZcR04qU0 mRzxor788bReZSE4Q16Qk4Jaoy6NDuKhIaHGs6p2hDFLuFJ1QTXtvcAE1cIkJlSc 4qNy8gVBnICrWZK8ISK7V8hSswt6Co6TmCHNI+ymQU6GpauBnw+2+TQ4oAlujCs= =GgcR -----END PGP SIGNATURE----- --EjUKZjov3T4fFoFJ-- From owner-freebsd-stable@freebsd.org Mon Jun 12 18:48:17 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86288C0A12D for ; Mon, 12 Jun 2017 18:48:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 71CEE796A1 for ; Mon, 12 Jun 2017 18:48:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6E0C0C0A12B; Mon, 12 Jun 2017 18:48:17 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69D68C0A12A; Mon, 12 Jun 2017 18:48:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 202E5796A0; Mon, 12 Jun 2017 18:48:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 0EAAE10AF09; Mon, 12 Jun 2017 14:47:59 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, stable@freebsd.org Subject: Re: post ino64: lockd no runs? Date: Mon, 12 Jun 2017 10:14:27 -0700 Message-ID: <2474735.4VjKMe5DLv@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <20170611172022.GA3184@albert.catwhisker.org> References: <20170611172022.GA3184@albert.catwhisker.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 12 Jun 2017 14:47:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:48:17 -0000 On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote: > On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > > of my systems after a full rebuild of src and ports. No log entries > > offer any insight as to why :-( > > > > imb > > I don't tend to use NFS on my systems that are running head, so I > haven't had occasion to test this as stated. > > However, I just completed my weekly update of the "prooduction" systems > here at home, running stable/11. And I find that lockd seems to be ... > claiming that all is well, but declining to run (for long). > > To the best of my knowledge, that was not the case until this last > update, which was from: > > FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > > to > > FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > > The "glaringly obvious" symptom in my case is that I am now unable > to (directly) save an email message from within mutt(1) by appending > it to an NFS-resident file. (Saving it to a local file, then using > cat(1) to append that to the NFS- resident file & removing the local > copy works....) > > After a few variations on a theme of: > > albert(11.1)[5] sudo service lockd restart > lockd not running? > Starting lockd. > albert(11.1)[6] echo $? > 0 > albert(11.1)[7] service lockd status > lockd is not running. > > I finally(!) thought to ask ktrace what's going on (as tailing > /var/log/messages was completely unproductive, even after enabling > rc_debug). > > So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of > the output of kdump(1), I see that the trace ends with: > > ... > 2811 rpc.lockd NAMI "/var/run/logpriv" > 2786 sh CALL read(0xa,0x627fc0,0x400) > 2786 sh GIO fd 10 read 0 bytes > "" > 2811 rpc.lockd RET connect 0 > 2786 sh RET read 0 > 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) > 2786 sh CALL exit(0) > 2811 rpc.lockd GIO fd 3 wrote 39 bytes > "<30>Jun 11 15:43:10 rpc.lockd: Starting" > 2811 rpc.lockd RET sendto 39/0x27 > 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) > 2811 rpc.lockd RET sigaction 0 > 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) > 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address This is a really good clue. nlm_syscall is dying with EFAULT. The last argument is a pointer to an array of char * pointers, and the only way I can see it dying is if it fails to copyin() one of the strings pointed to by those pointers. You could try running rpc.lockd under gdb from ports and setting a breakpoint on 'nlm_syscall' and then printing out 'addr_count' and 'p addrs@(addr_count * 2)'. Unfortunately I'm not able to reproduce the failure on a test machine I have running head post-ino64. -- John Baldwin From owner-freebsd-stable@freebsd.org Mon Jun 12 19:28:57 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B92BBC0AD69 for ; Mon, 12 Jun 2017 19:28:57 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 981877ADF3 for ; Mon, 12 Jun 2017 19:28:57 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9753CC0AD67; Mon, 12 Jun 2017 19:28:57 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94CC4C0AD66; Mon, 12 Jun 2017 19:28:57 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E5C37ADF2; Mon, 12 Jun 2017 19:28:57 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id m47so28648448iti.1; Mon, 12 Jun 2017 12:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cmM24RUV1w6UMVKTm5mewV7c4IX4CYv9ueJxMFkD5Ig=; b=hr8H+E0WUcwMFgae7syB87jd0bYxnREnur7yPYphOGQjL03OLN+1/DQG8EQAaD7foH q8AZhmvVf12/Ak6yIjg1ii7Xr1+FYZ+8htXJwFDDPnQ5TpH5YJdKlQIrQjGlPIbaenK1 UgoQXdfil/dPQ7ixd++v+7LK7WLXLwJFM5X4uB42RqQlY+ifncMgWYc8E6+LJiq6EKIJ 93fAQoPr6/VRR9K8rt6XI4ZC9ChFGD49ACLz3PtKzWCOsMvqTTvTnkEx9NI9Wa424wtz nZN2/0uV9IsmOmCbVECbIaPEdgN/sMl6VTp8VszPdJEo2eFc5WaUoJJLsvRN4y004Fs5 FqAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cmM24RUV1w6UMVKTm5mewV7c4IX4CYv9ueJxMFkD5Ig=; b=sximuJ9+YDEa/D4tx5AAG6xG2hugZdso5ACiliq80qaB3P8MGCaGP2uzgHdA9CY+v0 TakIzSa9ZlGgpXrdKOSRHhLruQqHoNMnDwB2E+rxKDQrSXLvWU28dD3Mg6WV93lhslsw oWPI2r/nTTzVOcMTXWCLOPAUXinQYYDklbjD8VOKvxIPG/rBlb7TLRrB6COIGEetMYkI J6dDeMiR6BI2/DdyxjJBdJJhUX6RdSMtWNSEOQyY/1EFMOIKWJYSoEXL5vGYwJPcJb1o q1uKWJ8lJ/8zLgljb/Bt4aMsiq2d+oFLTa9XsTQftabdtYHaok0K/kjAqV3/bnEUPwJg OuIQ== X-Gm-Message-State: AODbwcCG5GjOyVewTZ4kGUpvhEsQt/8G5kmSFl7rGi0HHLUoM+5c5j2/ ehyc/vJofy6hJN4zRYGJ5AXvcRHGk1rbeU8= X-Received: by 10.36.29.150 with SMTP id 144mr13071745itj.71.1497295736455; Mon, 12 Jun 2017 12:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.33.199 with HTTP; Mon, 12 Jun 2017 12:28:55 -0700 (PDT) In-Reply-To: <2474735.4VjKMe5DLv@ralph.baldwin.cx> References: <20170611172022.GA3184@albert.catwhisker.org> <2474735.4VjKMe5DLv@ralph.baldwin.cx> From: Xin LI Date: Mon, 12 Jun 2017 12:28:55 -0700 Message-ID: Subject: Re: post ino64: lockd no runs? To: John Baldwin Cc: FreeBSD Current , stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 19:28:57 -0000 On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin wrote: > On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote: >> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: >> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any >> > of my systems after a full rebuild of src and ports. No log entries >> > offer any insight as to why :-( >> > >> > imb >> >> I don't tend to use NFS on my systems that are running head, so I >> haven't had occasion to test this as stated. >> >> However, I just completed my weekly update of the "prooduction" systems >> here at home, running stable/11. And I find that lockd seems to be ... >> claiming that all is well, but declining to run (for long). >> >> To the best of my knowledge, that was not the case until this last >> update, which was from: >> >> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 >> >> to >> >> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 >> >> The "glaringly obvious" symptom in my case is that I am now unable >> to (directly) save an email message from within mutt(1) by appending >> it to an NFS-resident file. (Saving it to a local file, then using >> cat(1) to append that to the NFS- resident file & removing the local >> copy works....) >> >> After a few variations on a theme of: >> >> albert(11.1)[5] sudo service lockd restart >> lockd not running? >> Starting lockd. >> albert(11.1)[6] echo $? >> 0 >> albert(11.1)[7] service lockd status >> lockd is not running. >> >> I finally(!) thought to ask ktrace what's going on (as tailing >> /var/log/messages was completely unproductive, even after enabling >> rc_debug). >> >> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of >> the output of kdump(1), I see that the trace ends with: >> >> ... >> 2811 rpc.lockd NAMI "/var/run/logpriv" >> 2786 sh CALL read(0xa,0x627fc0,0x400) >> 2786 sh GIO fd 10 read 0 bytes >> "" >> 2811 rpc.lockd RET connect 0 >> 2786 sh RET read 0 >> 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) >> 2786 sh CALL exit(0) >> 2811 rpc.lockd GIO fd 3 wrote 39 bytes >> "<30>Jun 11 15:43:10 rpc.lockd: Starting" >> 2811 rpc.lockd RET sendto 39/0x27 >> 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) >> 2811 rpc.lockd RET sigaction 0 >> 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) >> 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address > > This is a really good clue. nlm_syscall is dying with EFAULT. The last > argument is a pointer to an array of char * pointers, and the only way > I can see it dying is if it fails to copyin() one of the strings pointed > to by those pointers. You could try running rpc.lockd under gdb from > ports and setting a breakpoint on 'nlm_syscall' and then printing out > 'addr_count' and 'p addrs@(addr_count * 2)'. Yes, I found that the kernel was trying to copyin() from NULL, and then found that corresponds to 'uaddr'. After some tracing I found that the tightened condition for taddr2uaddr have enforced (correctly) buffer length passed from caller, which was not set correctly since ~9 years ago (r177633, which sets the size to sizeof(pointer)) but never gets noticed because there is no check on that, so the solution seems to be to correctly set the length values to (allocated size), and that have fixed the issue for me. The code could use some cleanups and I plan to do it at some later time. > Unfortunately I'm not able to reproduce the failure on a test machine > I have running head post-ino64. This should have been fixed by r319852 in -HEAD ( https://svnweb.freebsd.org/base?view=revision&revision=319852 ), and I'll MFC the change after 3 days' settle assuming there is no objections, as this is a regression. Cheers, From owner-freebsd-stable@freebsd.org Mon Jun 12 21:03:11 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC07DC78349 for ; Mon, 12 Jun 2017 21:03:11 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A31C57F2A8; Mon, 12 Jun 2017 21:03:11 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x232.google.com with SMTP id x129so28636ite.0; Mon, 12 Jun 2017 14:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6jhdllhsUuwZa3hFZAjAixUEPJ7Dd9iPHVjcuwl0tn8=; b=HGp6yKQwhpiUUMF+Fp0j0/5Ygx05wy/+A45DGRuwob7zIpbjBNwiL313IStpMPj8ix ttclEFwZyeZMXXnZJSPSlTyRgMwWFGX7ZgVmEj3bwLK633V/+H8VoIdt7MkzJcZM8oJ+ yv/u5qB1xUTEVhWDN3f/uEYK3CtWFWSrC2XkiktPKmfQI52vn0hvP+E3vN64FFaPFGY7 o+BQeQRYQvI+N5uCOC1kzkO+akBFVKLgnHeBlDGA0VlG20UZAkjocPCR7DoWS3WKrmfA JuaMoaSSt1OyfCWiB7SgYSj7vaqFCmGG0Xw0g/eOkYdYeWWh8pbh7lmjU6QOTi5/5KLQ 6arw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6jhdllhsUuwZa3hFZAjAixUEPJ7Dd9iPHVjcuwl0tn8=; b=XAp20rc9kLAOdrnuipETRJuZWT5OizwIzSML1cAvC/ICDNyOVDAOU5gZq1Tnx+kNdn 06PmgkrlDE+4tNQifPsC7EzL8pl4vz3juGi55eRBKym6WMxkgbXKVDAnZDZIdNY2SfXL AxqPWoqA5zLJm/Iggsvhl9g2FUH8lY2MkobUgbpWw+nq51HdDIVRaiJDjdQq9vNOeqTt xccPjneZ4wiMenpLNCAG3hXIKc//ytJCBLcBJNVZns4wDP9lWu7O+4AMnPaxoQirlyj+ a78zyVUe0j9FDige0fJwrYUZ1u7rIKKWCojgQ1l9+O0jWrjLlEX0HvVG13dwNCRtg1TK cVVg== X-Gm-Message-State: AODbwcAEJnCnr0srtViFo7hlLD0dFyK5hhATSjkxXmcwBHnKoWRCefwI E8+QQkKy1bWLJYGVhPa6AYtVrLT7nj0Z X-Received: by 10.36.118.11 with SMTP id z11mr14151497itb.88.1497301391142; Mon, 12 Jun 2017 14:03:11 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.10.86 with HTTP; Mon, 12 Jun 2017 14:02:50 -0700 (PDT) In-Reply-To: References: <20170610123435.GB69235@FreeBSD.org> From: Ed Maste Date: Mon, 12 Jun 2017 17:02:50 -0400 X-Google-Sender-Auth: nKODkEktx8UXKXM15nEkzlW3-Ow Message-ID: Subject: Re: FreeBSD 11.1-BETA1 Now Available To: Warner Losh Cc: Jonathan Chen , Glen Barber , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:03:12 -0000 On 12 June 2017 at 00:43, Warner Losh wrote: > > aarch64 support isn't completely integrated into FreeBSD 11 yet. A clarification: arm64/aarch64 support has been available as of FreeBSD 11.0 for Cavium ThunderX, and the SoftIron arm64 hardware is also supported now. What we don't have yet is a project-produced SD card image for Raspberry Pi 3; until that happens you can use an image from raspbsd.org. From owner-freebsd-stable@freebsd.org Mon Jun 12 21:26:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71FCBC78A6B for ; Mon, 12 Jun 2017 21:26:13 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15EC78019A for ; Mon, 12 Jun 2017 21:26:12 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v5CLQBMU014313 for ; Mon, 12 Jun 2017 23:26:11 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3AFA46DC; Mon, 12 Jun 2017 23:26:11 +0200 (CEST) Message-ID: <593F06E5.9030608@omnilan.de> Date: Mon, 12 Jun 2017 23:25:57 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: [LOR] 11.1-BETA1 dev/md/md.c <-> vm/vm_pager.c - lost begnin matchlist Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 12 Jun 2017 23:26:11 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:26:13 -0000 Dear hackers, I couldn't find a up to date list for begning LOR reports. Since ffs/vfs.. LORs, which I don't understand, diffused my attention over the time, I'm not aware about the actual importance of them these days (without panic). Here's is one, happening on 11.1-BETA1. which I haven't found a previous report about: lock order reversal: 1st 0xfffffe03bca22c10 bufwait (bufwait) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_pager.c:370 2nd 0xfffff8001f9ff068 ufs (ufs) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/md/md.c:942 stack backtrace: #0 0xffffffff805e79b0 at witness_debugger+0x70 #1 0xffffffff805e78a3 at witness_checkorder+0xe23 #2 0xffffffff805621d5 at __lockmgr_args+0x875 #3 0xffffffff8081c215 at ffs_lock+0xa5 #4 0xffffffff808d78d0 at VOP_LOCK1_APV+0xe0 #5 0xffffffff8065531a at _vn_lock+0x6a #6 0xffffffff803fb948 at mdstart_vnode+0x438 #7 0xffffffff803f9f4d at md_kthread+0x19d #8 0xffffffff8054ea34 at fork_exit+0x84 #9 0xffffffff80864c0e at fork_trampoline+0xe -harry From owner-freebsd-stable@freebsd.org Tue Jun 13 00:45:14 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6983D87C3D for ; Tue, 13 Jun 2017 00:45:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 904B61C7F for ; Tue, 13 Jun 2017 00:45:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 8C7FCD87C3C; Tue, 13 Jun 2017 00:45:14 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BF76D87C3B; Tue, 13 Jun 2017 00:45:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 67A0E1C7E; Tue, 13 Jun 2017 00:45:13 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v5D0jCVH053880; Mon, 12 Jun 2017 17:45:12 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v5D0jC4a053879; Mon, 12 Jun 2017 17:45:12 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201706130045.v5D0jC4a053879@pdx.rh.CN85.dnsmgr.net> Subject: Re: post ino64: lockd no runs? In-Reply-To: To: Xin LI Date: Mon, 12 Jun 2017 17:45:12 -0700 (PDT) CC: John Baldwin , FreeBSD Current , stable@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-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 00:45:14 -0000 > On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin wrote: > > On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote: > >> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote: > >> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any > >> > of my systems after a full rebuild of src and ports. No log entries > >> > offer any insight as to why :-( > >> > > >> > imb > >> > >> I don't tend to use NFS on my systems that are running head, so I > >> haven't had occasion to test this as stated. > >> > >> However, I just completed my weekly update of the "prooduction" systems > >> here at home, running stable/11. And I find that lockd seems to be ... > >> claiming that all is well, but declining to run (for long). > >> > >> To the best of my knowledge, that was not the case until this last > >> update, which was from: > >> > >> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 r319566M/319569:1100514: Sun Jun 4 03:54:41 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > >> > >> to > >> > >> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322 r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT amd64 > >> > >> The "glaringly obvious" symptom in my case is that I am now unable > >> to (directly) save an email message from within mutt(1) by appending > >> it to an NFS-resident file. (Saving it to a local file, then using > >> cat(1) to append that to the NFS- resident file & removing the local > >> copy works....) > >> > >> After a few variations on a theme of: > >> > >> albert(11.1)[5] sudo service lockd restart > >> lockd not running? > >> Starting lockd. > >> albert(11.1)[6] echo $? > >> 0 > >> albert(11.1)[7] service lockd status > >> lockd is not running. > >> > >> I finally(!) thought to ask ktrace what's going on (as tailing > >> /var/log/messages was completely unproductive, even after enabling > >> rc_debug). > >> > >> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of > >> the output of kdump(1), I see that the trace ends with: > >> > >> ... > >> 2811 rpc.lockd NAMI "/var/run/logpriv" > >> 2786 sh CALL read(0xa,0x627fc0,0x400) > >> 2786 sh GIO fd 10 read 0 bytes > >> "" > >> 2811 rpc.lockd RET connect 0 > >> 2786 sh RET read 0 > >> 2811 rpc.lockd CALL sendto(0x3,0x7fffffffe2c0,0x27,0,0,0) > >> 2786 sh CALL exit(0) > >> 2811 rpc.lockd GIO fd 3 wrote 39 bytes > >> "<30>Jun 11 15:43:10 rpc.lockd: Starting" > >> 2811 rpc.lockd RET sendto 39/0x27 > >> 2811 rpc.lockd CALL sigaction(SIGALRM,0x7fffffffec20,0) > >> 2811 rpc.lockd RET sigaction 0 > >> 2811 rpc.lockd CALL nlm_syscall(0,0x1e,0x4,0x801015040) > >> 2811 rpc.lockd RET nlm_syscall -1 errno 14 Bad address > > > > This is a really good clue. nlm_syscall is dying with EFAULT. The last > > argument is a pointer to an array of char * pointers, and the only way > > I can see it dying is if it fails to copyin() one of the strings pointed > > to by those pointers. You could try running rpc.lockd under gdb from > > ports and setting a breakpoint on 'nlm_syscall' and then printing out > > 'addr_count' and 'p addrs@(addr_count * 2)'. > > Yes, I found that the kernel was trying to copyin() from NULL, and > then found that corresponds to 'uaddr'. After some tracing I found > that the tightened condition for taddr2uaddr have enforced (correctly) > buffer length passed from caller, which was not set correctly since ~9 > years ago (r177633, which sets the size to sizeof(pointer)) but never > gets noticed because there is no check on that, so the solution seems > to be to correctly set the length values to (allocated size), and that > have fixed the issue for me. > > The code could use some cleanups and I plan to do it at some later time. > > > Unfortunately I'm not able to reproduce the failure on a test machine > > I have running head post-ino64. > > This should have been fixed by r319852 in -HEAD ( > https://svnweb.freebsd.org/base?view=revision&revision=319852 ), and > I'll MFC the change after 3 days' settle assuming there is no > objections, as this is a regression. (RE hat on) The next 11.1 release builds start on the 16th, please try to make your RFa to RE and complete the merge before that date, I would really hate to have 11.1 go out without this fixed. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Tue Jun 13 08:14:50 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A4FBB955B8 for ; Tue, 13 Jun 2017 08:14:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 71BD5726AF for ; Tue, 13 Jun 2017 08:14:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 70A6EB955B7; Tue, 13 Jun 2017 08:14:50 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FC2CB955B6 for ; Tue, 13 Jun 2017 08:14:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 1EFE372693 for ; Tue, 13 Jun 2017 08:14:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1dKgyB-000Ocn-NO for stable@freebsd.org; Tue, 13 Jun 2017 11:14:35 +0300 From: Daniel Braniss Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 11.1-Beta panics as vmware guest Message-Id: <34B7DC9D-BB16-4AC5-8E62-E2108A377CFD@cs.huji.ac.il> Date: Tue, 13 Jun 2017 11:14:35 +0300 To: stable@freebsd.org X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Tue, 13 Jun 2017 11:22:51 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:14:50 -0000 hi, this only happens sometimes, and on boot: sorry, at the moment I don=E2=80=99t have a serial console, so: From owner-freebsd-stable@freebsd.org Tue Jun 13 11:30:33 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2D50BF13F5 for ; Tue, 13 Jun 2017 11:30:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8E58377C4A for ; Tue, 13 Jun 2017 11:30:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 8AB2DBF13F4; Tue, 13 Jun 2017 11:30:33 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8832EBF13F3 for ; Tue, 13 Jun 2017 11:30:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4540577C49 for ; Tue, 13 Jun 2017 11:30:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1dKk1g-0009p4-SQ for stable@freebsd.org; Tue, 13 Jun 2017 14:30:24 +0300 From: Daniel Braniss Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: 11.1-Beta panics as vmware guest Date: Tue, 13 Jun 2017 14:30:24 +0300 References: <34B7DC9D-BB16-4AC5-8E62-E2108A377CFD@cs.huji.ac.il> To: stable@freebsd.org In-Reply-To: <34B7DC9D-BB16-4AC5-8E62-E2108A377CFD@cs.huji.ac.il> Message-Id: <6BB7D9E5-8325-4A35-A67C-D729C6EF4E7D@cs.huji.ac.il> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:30:33 -0000 > On 13 Jun 2017, at 11:14, Daniel Braniss wrote: >=20 > hi, > this only happens sometimes, and on boot: > sorry, at the moment I don=E2=80=99t have a serial console, so: hrumph, I guess it was cut out, so here is the url: = http://www.cs.huji.ac.il/~danny/Screen%20Shot%202017-06-13%20at%2011= .09.21.png = From owner-freebsd-stable@freebsd.org Tue Jun 13 12:03:16 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48728BF275D for ; Tue, 13 Jun 2017 12:03:16 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq6.tb.mail.iss.as9143.net (smtpq6.tb.mail.iss.as9143.net [212.54.42.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01A8B78DE5; Tue, 13 Jun 2017 12:03:15 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.34.117] (helo=smtp9.mnd.mail.iss.as9143.net) by smtpq6.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dKkG4-0001DC-UJ; Tue, 13 Jun 2017 13:45:16 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp9.mnd.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dKkG4-0008EV-SK; Tue, 13 Jun 2017 13:45:16 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 883EDA62; Tue, 13 Jun 2017 13:45:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTVHL7hC1KQJ; Tue, 13 Jun 2017 13:45:14 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id D72DEA58; Tue, 13 Jun 2017 13:45:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FreeBSD 11.1-BETA1 Now Available From: peter.blok@bsd4all.org In-Reply-To: Date: Tue, 13 Jun 2017 13:45:14 +0200 Cc: Warner Losh , Glen Barber , Jonathan Chen Content-Transfer-Encoding: quoted-printable Message-Id: <6B47BBF3-D6A0-48AD-92FA-B54F51418331@bsd4all.org> References: <20170610123435.GB69235@FreeBSD.org> To: Ed Maste , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=ZpSdE5zG c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=IkcTkHD0fZMA:10 a=LWSFodeU3zMA:10 a=6I5d2MoRAAAA:8 a=7Qk2ozbKAAAA:8 a=HdxzEQxaAAAA:8 a=FFVccJOOJx4NYI2uhlEA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=1lyxoWkJIXJV6VJUPhuM:22 a=jieHaypiTVdaWWeO-ZD-:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 12:03:16 -0000 Hi, For a while now, I=E2=80=99m not able to build a RPI1-B image from = -stable. I have narrowed it dow to fix 318394, which adds a refresh = option to geom_label. If I undo this fix in today=E2=80=99s stable it = works ok. If I don=E2=80=99t I=E2=80=99m getting continuously: vm_fault: pager read error, pid 1 (init) vnode_pager_generic_getpages_done: I/O read error 5 I have looked at the fix and I can=E2=80=99t figure out why it breaks = the code. And yes I have tried various other SD cards - they all have the same = issue. Peter > On 12 Jun 2017, at 23:02, Ed Maste wrote: >=20 > On 12 June 2017 at 00:43, Warner Losh wrote: >>=20 >> aarch64 support isn't completely integrated into FreeBSD 11 yet. >=20 > A clarification: arm64/aarch64 support has been available as of > FreeBSD 11.0 for Cavium ThunderX, and the SoftIron arm64 hardware is > also supported now. >=20 > What we don't have yet is a project-produced SD card image for > Raspberry Pi 3; until that happens you can use an image from > raspbsd.org. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Tue Jun 13 12:04:53 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58C29BF2844 for ; Tue, 13 Jun 2017 12:04:53 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from smtpq5.tb.mail.iss.as9143.net (smtpq5.tb.mail.iss.as9143.net [212.54.42.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1210A78F9B; Tue, 13 Jun 2017 12:04:52 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from [212.54.42.132] (helo=smtp8.tb.mail.iss.as9143.net) by smtpq5.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dKkFW-0001Uu-Fu; Tue, 13 Jun 2017 13:44:42 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp8.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dKkFW-0001gX-Di; Tue, 13 Jun 2017 13:44:42 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id BC63BA56; Tue, 13 Jun 2017 13:44:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLIl_l15U3fp; Tue, 13 Jun 2017 13:44:40 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id DD4C2A4D; Tue, 13 Jun 2017 13:44:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FreeBSD 11.1-BETA1 Now Available From: Peter Blok In-Reply-To: Date: Tue, 13 Jun 2017 13:44:39 +0200 Cc: Warner Losh , Glen Barber , Jonathan Chen Content-Transfer-Encoding: quoted-printable Message-Id: <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> References: <20170610123435.GB69235@FreeBSD.org> To: Ed Maste , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=WsJbCZXv c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=IkcTkHD0fZMA:10 a=LWSFodeU3zMA:10 a=6I5d2MoRAAAA:8 a=7Qk2ozbKAAAA:8 a=HdxzEQxaAAAA:8 a=FFVccJOOJx4NYI2uhlEA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=1lyxoWkJIXJV6VJUPhuM:22 a=jieHaypiTVdaWWeO-ZD-:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 12:04:53 -0000 Hi, For a while now, I=E2=80=99m not able to build a RPI1-B image from = -stable. I have narrowed it dow to fix 318394, which adds a refresh = option to geom_label. If I undo this fix in today=E2=80=99s stable it = works ok. If I don=E2=80=99t I=E2=80=99m getting continuously: vm_fault: pager read error, pid 1 (init) vnode_pager_generic_getpages_done: I/O read error 5 I have looked at the fix and I can=E2=80=99t figure out why it breaks = the code. And yes I have tried various other SD cards - they all have the same = issue. Peter > On 12 Jun 2017, at 23:02, Ed Maste wrote: >=20 > On 12 June 2017 at 00:43, Warner Losh wrote: >>=20 >> aarch64 support isn't completely integrated into FreeBSD 11 yet. >=20 > A clarification: arm64/aarch64 support has been available as of > FreeBSD 11.0 for Cavium ThunderX, and the SoftIron arm64 hardware is > also supported now. >=20 > What we don't have yet is a project-produced SD card image for > Raspberry Pi 3; until that happens you can use an image from > raspbsd.org. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Wed Jun 14 13:13:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B84C5D8D916 for ; Wed, 14 Jun 2017 13:13:13 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 249D72957 for ; Wed, 14 Jun 2017 13:13:09 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id v5EDD46A082115 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 14 Jun 2017 15:13:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id v5EDD4LW082114 for freebsd-stable@FreeBSD.ORG; Wed, 14 Jun 2017 15:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id v5ECH2nE082416 for ; Wed, 14 Jun 2017 14:17:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id v5ECE2BY081772 for ; Wed, 14 Jun 2017 14:14:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id v5ECE2ul081769 for freebsd-stable@FreeBSD.ORG; Wed, 14 Jun 2017 14:14:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: 11.1-BETA1: lsof build failure Date: Wed, 14 Jun 2017 14:03:12 +0200 Organization: even some more stinky socks Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 14 Jun 2017 12:03:47 +0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="79712"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 X-Mozilla-News-Host: news://localhost:119 Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 14 Jun 2017 15:13:05 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:13:13 -0000 FYI, please check if reproducible and/or issue: Installed this from SVN & local build: 11.1-BETA1 FreeBSD 11.1-BETA1 #0 r319858:319867M ... amd64 Then tried to update lsof-4.90.f,8 and got this error: cc -pipe -DNEEDS_BOOL_TYPEDEF -DHASTASKS -DHAS_PAUSE_SBT -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHAS_FILEDESCENT -DHAS_TMPFS -DHASWCTYPE_H -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_VM_MEMATTR_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHASFUSEFS -DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T -DHAS_SB_CCC -DHAS_FDESCENTTBL -DFREEBSDV=11000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR="11.1-BETA1" -I/usr/src/sys -O2 -c dvch.c -o dvch.o --- dnode.o --- dnode.c:906:13: error: no member named 'i_dev' in 'struct inode' if (i->i_dev ~ ^ dnode.c:916:27: error: no member named 'i_dev' in 'struct inode' dev = Dev2Udev((KA_T)i->i_dev); ~ ^ 2 errors generated. *** [dnode.o] Error code 1 From owner-freebsd-stable@freebsd.org Wed Jun 14 13:37:24 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 364D2D8E07E for ; Wed, 14 Jun 2017 13:37:24 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15D1B3563 for ; Wed, 14 Jun 2017 13:37:24 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5GUeHUoGO9qIJfbBya50u8cVRRzp817ZOOkRYmkVF+8=; b=ErWKD3QMmEmTEYc6FW72XciSRJ JlP6byslSFT3p6imY/OOWsjkaqfX/5Xq2VEF6vibSqHb2wavMZyTVXe1g6ZquY1P0H5oJW1LNq4Dg lPvA5bwTXfAlFGOkAcMJnqlM1CcPbXgR/SRg0fp67rsi5VilSkY8ErFqOVfbdoWV/RYI=; Received: from [74.203.163.58] (port=55283 helo=[10.106.10.45]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dL8U5-000PC3-GA; Wed, 14 Jun 2017 08:37:21 -0500 User-Agent: Microsoft-MacOutlook/f.24.0.170608 Date: Wed, 14 Jun 2017 08:36:50 -0500 Subject: Re: 11.1-BETA1: lsof build failure From: Larry Rosenman To: Peter , Message-ID: <68B8DDC0-7DE5-43D4-A904-CFB613CE2145@lerctr.org> Thread-Topic: 11.1-BETA1: lsof build failure References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:37:24 -0000 Current lsof is 4.90M. Larry Sysutils/lsof maintainer On 6/14/17, 8:13 AM, "Peter" wrote: FYI, please check if reproducible and/or issue: Installed this from SVN & local build: 11.1-BETA1 FreeBSD 11.1-BETA1 #0 r319858:319867M ... amd64 Then tried to update lsof-4.90.f,8 and got this error: cc -pipe -DNEEDS_BOOL_TYPEDEF -DHASTASKS -DHAS_PAUSE_SBT -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHAS_FILEDESCENT -DHAS_TMPFS -DHASWCTYPE_H -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_VM_MEMATTR_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHASFUSEFS -DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T -DHAS_SB_CCC -DHAS_FDESCENTTBL -DFREEBSDV=11000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR="11.1-BETA1" -I/usr/src/sys -O2 -c dvch.c -o dvch.o --- dnode.o --- dnode.c:906:13: error: no member named 'i_dev' in 'struct inode' if (i->i_dev ~ ^ dnode.c:916:27: error: no member named 'i_dev' in 'struct inode' dev = Dev2Udev((KA_T)i->i_dev); ~ ^ 2 errors generated. *** [dnode.o] Error code 1 _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Wed Jun 14 13:49:47 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36FA8D8E371 for ; Wed, 14 Jun 2017 13:49:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C290E3B8B; Wed, 14 Jun 2017 13:49:46 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v5EDne0a089082 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 15:49:41 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-stable@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id v5EDnaVa093171; Wed, 14 Jun 2017 20:49:36 +0700 (+07) (envelope-from eugen@grosbein.net) To: FreeBSD Stable From: Eugene Grosbein Subject: syslog() thread unsafety X-Enigmail-Draft-Status: N1110 Cc: Gleb Smirnoff , Konstantin Belousov Message-ID: <59413EF0.20608@grosbein.net> Date: Wed, 14 Jun 2017 20:49:36 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 2.8 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: *** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:49:47 -0000 Hi! Our [v]syslog() implementation in src/lib/libc/gen/syslog.c tries to be thread-safe and uses "syslog_mutex". It may lock this mutex then call blocking system calls like sendto(). If a thread owning this mutex is pthread_cancel()'d in process, the mutex stays UMUTEX_CONTESTED and every other thread calling [v]syslog() deadlocks. I can reproduce this with net/mpd5 daemon reliably within some seconds from the beginning of my stress test involving RADIUS so mpd5 runs multi-threaded. I've tried to wrap every mpd5's [v]syslog() call around with pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate) and pthread_setcancelstate(oldstate, NULL) statements and this eliminates the problem but that's not a solution in any way. This problem seems to be root cause of multiple complaints about mpd5 being unstable under FreeBSD 9.x+ version (PR: 186114, 214482). Please take a look. Eugene Grosbein From owner-freebsd-stable@freebsd.org Wed Jun 14 14:12:44 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55881D8EAFE for ; Wed, 14 Jun 2017 14:12:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 EA92464DA8; Wed, 14 Jun 2017 14:12:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5EECcn9072462 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Jun 2017 17:12:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5EECcn9072462 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5EECc5F072461; Wed, 14 Jun 2017 17:12:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Jun 2017 17:12:38 +0300 From: Konstantin Belousov To: Eugene Grosbein Cc: FreeBSD Stable , Gleb Smirnoff Subject: Re: syslog() thread unsafety Message-ID: <20170614141238.GM2088@kib.kiev.ua> References: <59413EF0.20608@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59413EF0.20608@grosbein.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 14:12:44 -0000 On Wed, Jun 14, 2017 at 08:49:36PM +0700, Eugene Grosbein wrote: > Hi! > > Our [v]syslog() implementation in src/lib/libc/gen/syslog.c > tries to be thread-safe and uses "syslog_mutex". > > It may lock this mutex then call blocking system calls like sendto(). > If a thread owning this mutex is pthread_cancel()'d in process, > the mutex stays UMUTEX_CONTESTED and every other thread calling [v]syslog() deadlocks. > > I can reproduce this with net/mpd5 daemon reliably within some seconds > from the beginning of my stress test involving RADIUS so mpd5 runs multi-threaded. > > I've tried to wrap every mpd5's [v]syslog() call around with > pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate) and > pthread_setcancelstate(oldstate, NULL) statements and this eliminates the problem > but that's not a solution in any way. > > This problem seems to be root cause of multiple complaints > about mpd5 being unstable under FreeBSD 9.x+ version (PR: 186114, 214482). If the issue is that mpd5 cancels logging thread, and this leaves the mutex in the locked state, the right solution is to establish a cleanup handler around the locked region. Note that this can only work if the cancellation is in deferred mode, async mode is unsafe by definition. Try something like this, untested even a minimal bit. diff --git a/lib/libc/gen/syslog.c b/lib/libc/gen/syslog.c index dfca67360fa..2c390efe95e 100644 --- a/lib/libc/gen/syslog.c +++ b/lib/libc/gen/syslog.c @@ -129,8 +129,8 @@ syslog(int pri, const char *fmt, ...) va_end(ap); } -void -vsyslog(int pri, const char *fmt, va_list ap) +static void +vsyslog1(int pri, const char *fmt, va_list ap) { int cnt; char ch, *p; @@ -151,13 +151,9 @@ vsyslog(int pri, const char *fmt, va_list ap) saved_errno = errno; - THREAD_LOCK(); - /* Check priority against setlogmask values. */ - if (!(LOG_MASK(LOG_PRI(pri)) & LogMask)) { - THREAD_UNLOCK(); + if (!(LOG_MASK(LOG_PRI(pri)) & LogMask)) return; - } /* Set default facility if none specified. */ if ((pri & LOG_FACMASK) == 0) @@ -167,10 +163,8 @@ vsyslog(int pri, const char *fmt, va_list ap) tbuf_cookie.base = tbuf; tbuf_cookie.left = sizeof(tbuf); fp = fwopen(&tbuf_cookie, writehook); - if (fp == NULL) { - THREAD_UNLOCK(); + if (fp == NULL) return; - } /* Build the message. */ (void)time(&now); @@ -200,7 +194,6 @@ vsyslog(int pri, const char *fmt, va_list ap) fmt_fp = fwopen(&fmt_cookie, writehook); if (fmt_fp == NULL) { fclose(fp); - THREAD_UNLOCK(); return; } @@ -285,10 +278,8 @@ vsyslog(int pri, const char *fmt, va_list ap) */ disconnectlog(); connectlog(); - if (send(LogFile, tbuf, cnt, 0) >= 0) { - THREAD_UNLOCK(); + if (send(LogFile, tbuf, cnt, 0) >= 0) return; - } /* * if the resend failed, fall through to * possible scenario 2 @@ -303,15 +294,11 @@ vsyslog(int pri, const char *fmt, va_list ap) if (status == CONNPRIV) break; _usleep(1); - if (send(LogFile, tbuf, cnt, 0) >= 0) { - THREAD_UNLOCK(); + if (send(LogFile, tbuf, cnt, 0) >= 0) return; - } } - } else { - THREAD_UNLOCK(); + } else return; - } /* * Output the message to the console; try not to block @@ -333,10 +320,25 @@ vsyslog(int pri, const char *fmt, va_list ap) (void)_writev(fd, iov, 2); (void)_close(fd); } +} + +static void +syslog_cancel_cleanup(void *arg __unused) +{ THREAD_UNLOCK(); } +void +vsyslog(int pri, const char *fmt, va_list ap) +{ + + THREAD_LOCK(); + pthread_cleanup_push(syslog_cancel_cleanup, NULL); + vsyslog1(pri, fmt, ap); + pthread_cleanup_pop(1); +} + /* Should be called with mutex acquired */ static void disconnectlog(void) @@ -423,9 +425,11 @@ openlog_unlocked(const char *ident, int logstat, int logfac) void openlog(const char *ident, int logstat, int logfac) { + THREAD_LOCK(); + pthread_cleanup_push(syslog_cancel_cleanup, NULL); openlog_unlocked(ident, logstat, logfac); - THREAD_UNLOCK(); + pthread_cleanup_pop(1); } From owner-freebsd-stable@freebsd.org Wed Jun 14 16:40:03 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C194FBEED6C for ; Wed, 14 Jun 2017 16:40:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 57CFC701EF; Wed, 14 Jun 2017 16:40:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v5EGdlHD090495 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 18:39:47 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kostikbel@gmail.com Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id v5EGddoZ084349 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Jun 2017 23:39:39 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: syslog() thread unsafety To: Konstantin Belousov References: <59413EF0.20608@grosbein.net> <20170614141238.GM2088@kib.kiev.ua> Cc: FreeBSD Stable , Gleb Smirnoff From: Eugene Grosbein Message-ID: <594166CB.60709@grosbein.net> Date: Wed, 14 Jun 2017 23:39:39 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20170614141238.GM2088@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 2.8 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: *** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:40:03 -0000 14.06.2017 21:12, Konstantin Belousov wrote: > If the issue is that mpd5 cancels logging thread, and this leaves the > mutex in the locked state, the right solution is to establish a cleanup > handler around the locked region. Note that this can only work if the > cancellation is in deferred mode, async mode is unsafe by definition. > > Try something like this, untested even a minimal bit. [skip] I've given it a spin with unpatched mpd5 and it seems to work just fine now. I'm curious, should these two lines be swapped? + THREAD_LOCK(); + pthread_cleanup_push(syslog_cancel_cleanup, NULL); It seems it could be a race between another thread's pthread_cancel() and pthread_cleanup_push() here. Anyway, we have several other places in the lib/ with similar code possibly missing pthread_cleanup_push(): lib/libc/gen: popen.c, getlogin.c lib/libc/stdio: findfp.c, fclose.c Please consider committing the fix at least for syslog.c From owner-freebsd-stable@freebsd.org Wed Jun 14 17:09:09 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FE07BEFA8C for ; Wed, 14 Jun 2017 17:09:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 376D471982; Wed, 14 Jun 2017 17:09:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5EH94BL011855 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Jun 2017 20:09:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5EH94BL011855 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5EH94GS011854; Wed, 14 Jun 2017 20:09:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Jun 2017 20:09:04 +0300 From: Konstantin Belousov To: Eugene Grosbein Cc: FreeBSD Stable , Gleb Smirnoff Subject: Re: syslog() thread unsafety Message-ID: <20170614170904.GR2088@kib.kiev.ua> References: <59413EF0.20608@grosbein.net> <20170614141238.GM2088@kib.kiev.ua> <594166CB.60709@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <594166CB.60709@grosbein.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:09:09 -0000 On Wed, Jun 14, 2017 at 11:39:39PM +0700, Eugene Grosbein wrote: > 14.06.2017 21:12, Konstantin Belousov wrote: > > > If the issue is that mpd5 cancels logging thread, and this leaves the > > mutex in the locked state, the right solution is to establish a cleanup > > handler around the locked region. Note that this can only work if the > > cancellation is in deferred mode, async mode is unsafe by definition. > > > > Try something like this, untested even a minimal bit. > > [skip] > > I've given it a spin with unpatched mpd5 and it seems to work just fine now. > I'm curious, should these two lines be swapped? > > + THREAD_LOCK(); > + pthread_cleanup_push(syslog_cancel_cleanup, NULL); > > It seems it could be a race between another thread's pthread_cancel() > and pthread_cleanup_push() here. As I mentioned in my previous reply, you can only rely on some guarantees for the deferred cancellation mode. In this mode, only some calls are allowed to become cancellation points. In particular, the cancellation cannot happen between THREAD_LOCK() and push(). OTOH, if you configured the thread for async cancellation mode, then cancellation can happen anywhere. If you called any non-signal-safe function, any invariant can be broken. That is, the cancellation cleanup is not supposed to be useful with async cancellation. And you are not supposed to call into stdio or syslog() while in async. > > Anyway, we have several other places in the lib/ with similar code > possibly missing pthread_cleanup_push(): > > lib/libc/gen: popen.c, I doubt that popen() needs the cancellation protection. The _close() calls there are explicitely not the cancellation points, they are direct syscall invocations, and are not subject to cancellation testing. The only potentially problematic case could be the fclose() call in the locked region. But again, fclose(3) only potential cancellation point is the fp->_close() call. For fdopen()-ed FILEs, _close is set to the __sclose() wrapper which only calls _close(). That is, popen() looks safe. > getlogin.c > lib/libc/stdio: findfp.c, fclose.c I already wrote about fclose() above, might be it indeed should grow the cleanup handler for the general case. I do not see any code which would need cancellation protection in findfp, what exactly do you mean there ? Same for getlogin(). > > Please consider committing the fix at least for syslog.c Confirm that it fixed your case, then I will commit the change. From owner-freebsd-stable@freebsd.org Wed Jun 14 20:13:27 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55D0EBF3073 for ; Wed, 14 Jun 2017 20:13:27 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8D7277395 for ; Wed, 14 Jun 2017 20:13:26 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id v5EKD5pb000139 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 14 Jun 2017 22:13:06 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id v5EKD5TJ000138 for freebsd-stable@FreeBSD.ORG; Wed, 14 Jun 2017 22:13:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id v5EK536L068605 for ; Wed, 14 Jun 2017 22:05:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id v5EK42ii068356 for ; Wed, 14 Jun 2017 22:04:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id v5EK42Do068355 for freebsd-stable@FreeBSD.ORG; Wed, 14 Jun 2017 22:04:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: 11.1-BETA1: lsof build failure Date: Wed, 14 Jun 2017 21:54:49 +0200 Organization: even some more stinky socks Message-ID: <59419489.90405@citylink.dinoex.sub.org> References: <68B8DDC0-7DE5-43D4-A904-CFB613CE2145@lerctr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: oper.dinoex.de; logging-data="66524"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 In-Reply-To: <68B8DDC0-7DE5-43D4-A904-CFB613CE2145@lerctr.org> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 14 Jun 2017 22:13:06 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 20:13:27 -0000 Larry Rosenman wrote: > Current lsof is 4.90M. Ack, that does. > Larry > Sysutils/lsof maintainer > > On 6/14/17, 8:13 AM, "Peter" wrote: > > FYI, please check if reproducible and/or issue: > > > Installed this from SVN & local build: > > 11.1-BETA1 FreeBSD 11.1-BETA1 #0 r319858:319867M ... amd64 > > Then tried to update lsof-4.90.f,8 and got this error: > > cc -pipe -DNEEDS_BOOL_TYPEDEF -DHASTASKS -DHAS_PAUSE_SBT > -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHAS_FILEDESCENT -DHAS_TMPFS > -DHASWCTYPE_H -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 > -DHAS_VM_MEMATTR_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H > -DHASFUSEFS -DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT > -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T -DHAS_SB_CCC -DHAS_FDESCENTTBL > -DFREEBSDV=11000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 > -DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR="11.1-BETA1" -I/usr/src/sys -O2 -c > dvch.c -o dvch.o > --- dnode.o --- > dnode.c:906:13: error: no member named 'i_dev' in 'struct inode' > if (i->i_dev > ~ ^ > dnode.c:916:27: error: no member named 'i_dev' in 'struct inode' > dev = Dev2Udev((KA_T)i->i_dev); > ~ ^ > 2 errors generated. > *** [dnode.o] Error code 1 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Thu Jun 15 03:38:06 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27FB1BFF417 for ; Thu, 15 Jun 2017 03:38:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC7B109C; Thu, 15 Jun 2017 03:38:05 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v5F3bxvW095814 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2017 05:38:00 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kostikbel@gmail.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id v5F3bt1W058015 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Jun 2017 10:37:55 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: syslog() thread unsafety To: Konstantin Belousov References: <59413EF0.20608@grosbein.net> <20170614141238.GM2088@kib.kiev.ua> <594166CB.60709@grosbein.net> <20170614170904.GR2088@kib.kiev.ua> Cc: FreeBSD Stable , Gleb Smirnoff From: Eugene Grosbein Message-ID: <5942010E.40907@grosbein.net> Date: Thu, 15 Jun 2017 10:37:50 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20170614170904.GR2088@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 03:38:06 -0000 15.06.2017 0:09, Konstantin Belousov wrote: > On Wed, Jun 14, 2017 at 11:39:39PM +0700, Eugene Grosbein wrote: >> 14.06.2017 21:12, Konstantin Belousov wrote: >> >>> If the issue is that mpd5 cancels logging thread, and this leaves the >>> mutex in the locked state, the right solution is to establish a cleanup >>> handler around the locked region. Note that this can only work if the >>> cancellation is in deferred mode, async mode is unsafe by definition. >>> >>> Try something like this, untested even a minimal bit. >> >> [skip] >> >> I've given it a spin with unpatched mpd5 and it seems to work just fine now. >> I'm curious, should these two lines be swapped? >> >> + THREAD_LOCK(); >> + pthread_cleanup_push(syslog_cancel_cleanup, NULL); >> >> It seems it could be a race between another thread's pthread_cancel() >> and pthread_cleanup_push() here. > As I mentioned in my previous reply, you can only rely on some > guarantees for the deferred cancellation mode. In this mode, only some > calls are allowed to become cancellation points. In particular, the > cancellation cannot happen between THREAD_LOCK() and push(). Forgot to mention that mpd5 does not change the mode to PTHREAD_CANCEL_ASYNCHRONOUS from the default deferred. > That is, popen() looks safe. >> getlogin.c >> lib/libc/stdio: findfp.c, fclose.c > I already wrote about fclose() above, might be it indeed should grow the > cleanup handler for the general case. I do not see any code which would > need cancellation protection in findfp, what exactly do you mean there ? > Same for getlogin(). That was just quick scan for THREAD_LOCK() :-) I'm new to these details of pthreads. >> Please consider committing the fix at least for syslog.c > Confirm that it fixed your case, then I will commit the change. Well, my stress test for mpd5 has been running for several hours and no hang still. Without your patch, it locked in a minute, so it seems the case is fixed, thanks! Eugene Grosbein From owner-freebsd-stable@freebsd.org Fri Jun 16 08:26:43 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00CC1BFA1C1 for ; Fri, 16 Jun 2017 08:26:43 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout07.t-online.de (mailout07.t-online.de [194.25.134.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA62075D4D for ; Fri, 16 Jun 2017 08:26:42 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd09.aul.t-online.de (fwd09.aul.t-online.de [172.20.27.151]) by mailout07.t-online.de (Postfix) with SMTP id CC9274215944 for ; Fri, 16 Jun 2017 10:26:33 +0200 (CEST) Received: from Stefans-MBP-2.fritz.box (XHnDmEZAghXRyoCPGH-Ld8fvGbdL0pcPPG1az1oHZdmu1KAwufB9L8NREkjb+2wQLm@[84.154.108.252]) by fwd09.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1dLmaO-1ypuXQ0; Fri, 16 Jun 2017 10:26:32 +0200 To: FreeBSD Stable From: Stefan Esser Subject: GELI: Regression between STABLE-10 and STABLE-11? Message-ID: Date: Fri, 16 Jun 2017 10:26:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ID: XHnDmEZAghXRyoCPGH-Ld8fvGbdL0pcPPG1az1oHZdmu1KAwufB9L8NREkjb+2wQLm X-TOI-MSGID: dbc9940d-dd6d-4388-a6ea-decf8aa09529 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 08:26:43 -0000 Hi all, I'm administrating an SVN server for a small company, which is used to archive work results, but also customer contracts and information received under NDA. The system uses pure ZFS (root on ZFS) and part of the "data" pool is a ZVOL that is used as a GELI provider to hold the confidential data. I just tried to upgrade this system to STABLE-11 (or rather 11-BETA1) and found, that I could not attach the GELI protected partition with: # geli attach -d -k /root/MY_GELI_KEYFILE /dev/zvol/data/geli.vol The command failed with "invalid password" (or along that line, sorry for not writing the exact text down). The system was running with consistent STABLE-11 kernel and world, and there was no sign of any other problem. I performed a roll-back to STABLE-10 and could attach the GELI partition without any problem with the key-file and password that had failed under STABLE-11. This problem is not critical for me (I can create an encrypted backup of the encrypted data and restore that into a GELI partition created under STABLE-11), but it might be a general problem - that's why I'm reporting this failure ... Some more details: $ uname -a FreeBSD XXX.com 10.3-STABLE FreeBSD 10.3-STABLE #0 r318284: Mon May 15 11:58:47 CEST 2017 root@s... amd64 The (abridged) ZFS pool status is: $ zpool status pool: sys config: NAME STATE READ WRITE CKSUM sys ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/System-1 ONLINE 0 0 0 gpt/System-2 ONLINE 0 0 0 pool: data config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/Data-1 ONLINE 0 0 0 gpt/Data-2 ONLINE 0 0 0 pool: crypto config: NAME STATE READ WRITE CKSUM crypto ONLINE 0 0 0 zvol/data/geli.vol.eli ONLINE 0 0 0 $ zfs list -t volume NAME USED AVAIL REFER MOUNTPOINT data/geli.vol 94.5G 78.5G 37.9G - I know about the problem of ZFS on ZFS and this will be fixed (I'm going to convert the file-system in the ZVOL to UFS), but it was a valid setup when the server was installed a number of years ago. (And I use "vfs.zfs.vol.recursive=1" as a work-around to disable the safe-guard that has been implemented to prevent ZFS on ZPOOL.) I'm able to work around the problem, since the amount of data in the encrypted partition is small and I wanted to transfer it into an UFS file-system on a GELI partition, anyway. Since I had only reserved a short maintenance window for the attempted upgrade, I could not perform many tests and I lost all logs during the rollback to STABLE-10. (I had not considered, this could be a problem that might affect others, at that time.) Regards, STefan From owner-freebsd-stable@freebsd.org Fri Jun 16 12:25:41 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D504BFF6ED for ; Fri, 16 Jun 2017 12:25:41 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 167557D3D6 for ; Fri, 16 Jun 2017 12:25:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 4D83327461 for ; Fri, 16 Jun 2017 08:25:35 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 9003237DE for ; Fri, 16 Jun 2017 07:25:33 -0500 (CDT) To: FreeBSD-STABLE Mailing List From: Karl Denninger Subject: Interesting permissions difference on NanoBSD build Message-ID: Date: Fri, 16 Jun 2017 07:25:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010201070904060803030303" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:25:41 -0000 This is a cryptographically signed message in MIME format. --------------ms010201070904060803030303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've recently started playing with the "base" NanoBSD scripts and have run into an interesting issue. Specifically, this is what winds up in the "_.w" (world) directory base when the build completes: root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al total 112 drwxr-x--- 18 root wheel 24 Jun 15 17:10 . drwxr-xr-x 5 root wheel 24 Jun 15 17:11 .. -rw-r--r-- 2 root wheel 955 Jun 15 17:09 .cshrc -rw-r--r-- 2 root wheel 247 Jun 15 17:09 .profile -r--r--r-- 1 root wheel 6197 Jun 15 17:09 COPYRIGHT drwxr-xr-x 2 root wheel 47 Jun 15 17:08 bin drwxr-xr-x 8 root wheel 51 Jun 15 17:09 boot -rw-r--r-- 1 root wheel 12 Jun 15 17:09 boot.config drwxr-xr-x 2 root wheel 2 Jun 15 17:09 cfg drwxr-xr-x 4 root wheel 4 Jun 15 17:10 conf dr-xr-xr-x 2 root wheel 3 Jun 15 17:09 dev drwxr-x--x 28 root wheel 110 Jun 15 17:10 etc drwxr-xr-x 4 root wheel 56 Jun 15 17:08 lib drwxr-xr-x 3 root wheel 5 Jun 15 17:09 libexec drwxr-xr-x 2 root wheel 2 Jun 15 17:07 media drwxr-xr-x 2 root wheel 2 Jun 15 17:07 mnt dr-xr-xr-x 2 root wheel 2 Jun 15 17:07 proc drwxr-xr-x 2 root wheel 146 Jun 15 17:08 rescue drwxr-xr-x 2 root wheel 12 Jun 15 17:10 root drwxr-xr-x 2 root wheel 137 Jun 15 17:08 sbin lrwxr-xr-x 1 root wheel 11 Jun 15 17:07 sys -> usr/src/sys lrwxr-xr-x 1 root wheel 7 Jun 15 17:10 tmp -> var/tmp drwxr-x--x 12 root wheel 12 Jun 15 17:10 usr drwxr-xr-x 25 root wheel 25 Jun 15 17:10 var root@NewFS:/pics/Crochet-work-AMD/obj/_.w # Note the missing "r" bit for "other" in usr and etc directories -- and the missing "x" bit (at minimum) for the root! The same is carried down to "local" under usr: root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al usr total 134 drwxr-x--x 12 root wheel 12 Jun 15 17:10 . drwxr-x--- 18 root wheel 24 Jun 15 17:10 .. drwxr-xr-x 2 root wheel 497 Jun 15 17:09 bin drwxr-xr-x 52 root wheel 327 Jun 15 17:10 include drwxr-xr-x 8 root wheel 655 Jun 15 17:10 lib drwxr-xr-x 4 root wheel 670 Jun 15 17:09 lib32 drwxr-xr-x 5 root wheel 5 Jun 15 17:10 libdata drwxr-xr-x 7 root wheel 70 Jun 15 17:10 libexec drwxr-x--x 10 root wheel 11 Jun 15 17:10 local drwxr-xr-x 2 root wheel 294 Jun 15 17:08 sbin drwxr-xr-x 31 root wheel 31 Jun 15 17:10 share drwxr-xr-x 14 root wheel 17 Jun 15 17:10 tests root@NewFS:/pics/Crochet-work-AMD/obj/_.w # I do not know if this is intentional, but it certainly was not expected. It does carry through to the disk image that is created as well and then there's this, which if you mount the image leads me to wonder what's going on: root@NewFS:/pics/Crochet-work-AMD/obj # mount -o ro /dev/md0s1a /mnt root@NewFS:/pics/Crochet-work-AMD/obj # cd /mnt root@NewFS:/mnt # ls -al total 34 drwxr-x--- 19 root wheel 512 Jun 15 17:10 . drwxr-xr-x 45 root wheel 55 Jun 1 10:58 .. -rw-r--r-- 2 root wheel 955 Jun 15 17:09 .cshrc -rw-r--r-- 2 root wheel 247 Jun 15 17:09 .profile drwxrwxr-x 2 root operator 512 Jun 15 17:10 .snap -r--r--r-- 1 root wheel 6197 Jun 15 17:09 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Jun 15 17:08 bin drwxr-xr-x 8 root wheel 1024 Jun 15 17:09 boot -rw-r--r-- 1 root wheel 12 Jun 15 17:09 boot.config drwxr-xr-x 2 root wheel 512 Jun 15 17:09 cfg drwxr-xr-x 4 root wheel 512 Jun 15 17:10 conf dr-xr-xr-x 2 root wheel 512 Jun 15 17:09 dev drwxr-x--x 28 root wheel 2048 Jun 15 17:10 etc drwxr-xr-x 4 root wheel 1536 Jun 15 17:08 lib drwxr-xr-x 3 root wheel 512 Jun 15 17:09 libexec drwxr-xr-x 2 root wheel 512 Jun 15 17:07 media drwxr-xr-x 2 root wheel 512 Jun 15 17:07 mnt dr-xr-xr-x 2 root wheel 512 Jun 15 17:07 proc drwxr-xr-x 2 root wheel 2560 Jun 15 17:08 rescue drwxr-xr-x 2 root wheel 512 Jun 15 17:10 root drwxr-xr-x 2 root wheel 2560 Jun 15 17:08 sbin lrwxr-xr-x 1 root wheel 11 Jun 15 17:07 sys -> usr/src/sys lrwxr-xr-x 1 root wheel 7 Jun 15 17:10 tmp -> var/tmp drwxr-x--x 12 root wheel 512 Jun 15 17:10 usr drwxr-xr-x 25 root wheel 512 Jun 15 17:10 var Note the permissions at the root -- that denies *search* for others.... it is an exact copy of the "_.w" permission list of course, but if you create a non-root user as a part of the NanoBSD build you wind up with some "interesting" behavior when that user logs in! I'm assuming this is unintentional but wondering where it comes from (and whether it needs / should be fixed); it's easy to fix it, of course, once the embedded system boots but you need to (obviously) mount read/write long enough to update it.... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010201070904060803030303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MTYxMjI1MzFaME8GCSqGSIb3DQEJBDFCBEDi4bIR E3uyWDFQKkKBo0Cb1ymneZpPtI3l1tmjgYBhepizaFYtBUUhtM1Fro9lT5mEHIbo9Wvv9Eom 8gJNAp4hMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIALPGtPdaxFmfy 4QlaT/nvoAPoYvaBwEAMqywHv71yx6fRxSePAbZ0jd3OvNLTOyRQ75tA/Lo4Tk5Ov8J/WIoR vACbeIp336eN9SuYNsfe/qiHlUq7RNXW6HoJj2gROTtNtlxHaQ4j+5FqPHT7ZS8m0Pvrm+Jd ruryR+6FyjiTaPK/YfLH0fOLrqvxgvxTjetuZ5T8OaoWtwMW/plPWBQjX9GcLTj/V8nt8rQH HuHjZI4M/ypq4mxxstVCK2jLipxjJPA7T36PXpYRym2mijGSITjXSkiQ4FCk1eqBGjORzihh ziJ3tWA8MRBSeuyQXGbf2cNwwCcRjPtBDS1uMVRzIFSrDBVyJ5qBPB4nDnMdcmyYryM+ZQbt MNErM2KwFD3zRRNspO+G9JAYDhRaOOK3in2fSEirq7x6sxWkr5zJvENYj3YOekS6Df/UWybE 0XL6g79gV3yLDX+31FObd281wfIfPd0URpCORunuOusvMjCMy+34YnuUZv3efLWUGpRqDRc6 psuccLIzUpqU+Rkf5/Kzj4IZH8qEMNLI8giRpiNmbola5f94QMAP6ai4MbbIBP07ZcHxChC3 tY85gYJ45hW1ALCLUThTetpUetgDumAocIsHhhNjCoS9etKSKdiLznvKkwdkVHLw7IFtUNRT 0hnUY2waAkRgNPtM65wiB5oAAAAAAAA= --------------ms010201070904060803030303-- From owner-freebsd-stable@freebsd.org Fri Jun 16 12:53:04 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FD14BFFF9B for ; Fri, 16 Jun 2017 12:53:04 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 EA2D07E079 for ; Fri, 16 Jun 2017 12:53:03 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3wq0dz2cXwzZqg; Fri, 16 Jun 2017 14:52:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=mail; t=1497617573; x=1499431974; bh=W6RrXZVUAAA35T RWOrBcLI5TCJCfXn5VEKG8Idaf6t8=; b=gTAFtiV//M8/jDKhArAdZgdyx5o0Oj hQKvPxePmK0jn6FqY/877nM7xqms8oWbRzLmoPH4IZKk+UCeC9fvALB1ToztsXm3 1Jg16mR7iiVWN8bgURx6DBB0CdUZYq5PKPUVB5AYiV6bzd/8ICl7wdZTwYA5BQda VQOfR4o0yC0Uw= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id kLWmupGxBapg; Fri, 16 Jun 2017 14:52:53 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 16 Jun 2017 14:52:53 +0200 (CEST) Subject: Re: Interesting permissions difference on NanoBSD build To: Karl Denninger , FreeBSD-STABLE Mailing List References: From: Guido Falsi Message-ID: <1387791f-fe22-08d7-2048-26bd95eab451@madpilot.net> Date: Fri, 16 Jun 2017 14:52:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:53:04 -0000 On 06/16/17 14:25, Karl Denninger wrote: > I've recently started playing with the "base" NanoBSD scripts and have > run into an interesting issue. [...] > Note the missing "r" bit for "other" in usr and etc directories -- and > the missing "x" bit (at minimum) for the root! The same is carried down > to "local" under usr: > > root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al usr > total 134 > drwxr-x--x 12 root wheel 12 Jun 15 17:10 . > drwxr-x--- 18 root wheel 24 Jun 15 17:10 .. > drwxr-xr-x 2 root wheel 497 Jun 15 17:09 bin > drwxr-xr-x 52 root wheel 327 Jun 15 17:10 include > drwxr-xr-x 8 root wheel 655 Jun 15 17:10 lib > drwxr-xr-x 4 root wheel 670 Jun 15 17:09 lib32 > drwxr-xr-x 5 root wheel 5 Jun 15 17:10 libdata > drwxr-xr-x 7 root wheel 70 Jun 15 17:10 libexec > drwxr-x--x 10 root wheel 11 Jun 15 17:10 local > drwxr-xr-x 2 root wheel 294 Jun 15 17:08 sbin > drwxr-xr-x 31 root wheel 31 Jun 15 17:10 share > drwxr-xr-x 14 root wheel 17 Jun 15 17:10 tests > root@NewFS:/pics/Crochet-work-AMD/obj/_.w # I have no idea why this is happening on your system but I'm not observing it here: > ls -al usr total 85 drwxr-xr-x 9 root wheel 9 Jun 15 13:32 . drwxr-xr-x 22 root wheel 29 Jun 15 13:32 .. drwxr-xr-x 2 root wheel 359 Jun 15 13:32 bin drwxr-xr-x 4 root wheel 446 Jun 15 13:32 lib drwxr-xr-x 3 root wheel 3 Jun 15 13:32 libdata drwxr-xr-x 5 root wheel 47 Jun 15 13:32 libexec drwxr-xr-x 12 root wheel 13 Jun 15 13:32 local drwxr-xr-x 2 root wheel 218 Jun 15 13:32 sbin drwxr-xr-x 17 root wheel 17 Jun 15 13:32 share and I get (almost) the same on the installed nanobsd system: > ls -al usr total 24 drwxr-xr-x 9 root wheel 512 Jun 15 13:32 . drwxr-xr-x 23 root wheel 512 Jun 15 13:34 .. drwxr-xr-x 2 root wheel 6144 Jun 15 13:32 bin drwxr-xr-x 4 root wheel 10752 Jun 15 13:32 lib drwxr-xr-x 3 root wheel 512 Jun 15 13:32 libdata drwxr-xr-x 5 root wheel 1024 Jun 15 13:32 libexec drwxr-xr-x 12 root wheel 512 Jun 15 13:32 local drwxr-xr-x 2 root wheel 4096 Jun 15 13:32 sbin drwxr-xr-x 17 root wheel 512 Jun 15 13:32 share The machine I'm building the NanoBSD image on is running head r318959, and is running ZFS, while the NanoBSD system I've built is tracking 11-STABLE and is at r319971 at present, so a BETA1. Could you report version information too? maybe it's a problem present on head NanoBSD scripts? -- Guido Falsi From owner-freebsd-stable@freebsd.org Fri Jun 16 13:22:30 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36949C08ACD for ; Fri, 16 Jun 2017 13:22:30 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB817ED91 for ; Fri, 16 Jun 2017 13:22:29 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 66AB927336 for ; Fri, 16 Jun 2017 09:22:00 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 865CA3935 for ; Fri, 16 Jun 2017 08:21:58 -0500 (CDT) Subject: Re: Interesting permissions difference on NanoBSD build To: freebsd-stable@freebsd.org References: <1387791f-fe22-08d7-2048-26bd95eab451@madpilot.net> From: Karl Denninger Message-ID: <0561597d-4b24-f68e-33a8-d0902e7696da@denninger.net> Date: Fri, 16 Jun 2017 08:21:56 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1387791f-fe22-08d7-2048-26bd95eab451@madpilot.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020903020300030706080704" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 13:22:30 -0000 This is a cryptographically signed message in MIME format. --------------ms020903020300030706080704 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/16/2017 07:52, Guido Falsi wrote: > On 06/16/17 14:25, Karl Denninger wrote: >> I've recently started playing with the "base" NanoBSD scripts and have= >> run into an interesting issue. > [...] >> Note the missing "r" bit for "other" in usr and etc directories -- and= >> the missing "x" bit (at minimum) for the root! The same is carried do= wn >> to "local" under usr: >> >> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al usr >> total 134 >> drwxr-x--x 12 root wheel 12 Jun 15 17:10 . >> drwxr-x--- 18 root wheel 24 Jun 15 17:10 .. >> drwxr-xr-x 2 root wheel 497 Jun 15 17:09 bin >> drwxr-xr-x 52 root wheel 327 Jun 15 17:10 include >> drwxr-xr-x 8 root wheel 655 Jun 15 17:10 lib >> drwxr-xr-x 4 root wheel 670 Jun 15 17:09 lib32 >> drwxr-xr-x 5 root wheel 5 Jun 15 17:10 libdata >> drwxr-xr-x 7 root wheel 70 Jun 15 17:10 libexec >> drwxr-x--x 10 root wheel 11 Jun 15 17:10 local >> drwxr-xr-x 2 root wheel 294 Jun 15 17:08 sbin >> drwxr-xr-x 31 root wheel 31 Jun 15 17:10 share >> drwxr-xr-x 14 root wheel 17 Jun 15 17:10 tests >> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # > I have no idea why this is happening on your system but I'm not > observing it here: > >> ls -al usr > total 85 > drwxr-xr-x 9 root wheel 9 Jun 15 13:32 . > drwxr-xr-x 22 root wheel 29 Jun 15 13:32 .. > drwxr-xr-x 2 root wheel 359 Jun 15 13:32 bin > drwxr-xr-x 4 root wheel 446 Jun 15 13:32 lib > drwxr-xr-x 3 root wheel 3 Jun 15 13:32 libdata > drwxr-xr-x 5 root wheel 47 Jun 15 13:32 libexec > drwxr-xr-x 12 root wheel 13 Jun 15 13:32 local > drwxr-xr-x 2 root wheel 218 Jun 15 13:32 sbin > drwxr-xr-x 17 root wheel 17 Jun 15 13:32 share > > > and I get (almost) the same on the installed nanobsd system: >> ls -al usr > total 24 > drwxr-xr-x 9 root wheel 512 Jun 15 13:32 . > drwxr-xr-x 23 root wheel 512 Jun 15 13:34 .. > drwxr-xr-x 2 root wheel 6144 Jun 15 13:32 bin > drwxr-xr-x 4 root wheel 10752 Jun 15 13:32 lib > drwxr-xr-x 3 root wheel 512 Jun 15 13:32 libdata > drwxr-xr-x 5 root wheel 1024 Jun 15 13:32 libexec > drwxr-xr-x 12 root wheel 512 Jun 15 13:32 local > drwxr-xr-x 2 root wheel 4096 Jun 15 13:32 sbin > drwxr-xr-x 17 root wheel 512 Jun 15 13:32 share > > The machine I'm building the NanoBSD image on is running head r318959, > and is running ZFS, while the NanoBSD system I've built is tracking > 11-STABLE and is at r319971 at present, so a BETA1. > > Could you report version information too? maybe it's a problem present > on head NanoBSD scripts? FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP I also build using Crochet against both /usr/src (my "primary" source repo, which is on the rev noted here) and against a second one (-HEAD), which I need to use for the RPI3. Neither winds up with this sort of permission issue. The obj directory is on /pics/Crochet-Work-AMD, which is a zfs filesystem mounted off a "scratch" SSD. The problem appears to stem from the creation of "_.w" and since directory permissions are "normally" inherited it promulgates from there unless an explicit permission set occurs. Yet I see nothing that would create the world directory with anything other than the umask at the time it runs. I *am* running this from "batch" -- perhaps that's where the problem is coming from? I'll try adding a "umask 022" to the nanobsd.sh script at the top and see what that does. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020903020300030706080704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MTYxMzIxNTZaME8GCSqGSIb3DQEJBDFCBEBridWr ZWPoHfmEqYZzeNMmROI7v5bgbqoX7ypSy3CsizJMpPUGjlS+Pa80ROnUeujoY9hKtKdmzqjB GyL6s+X3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAiEvY5knWoB4q BGe6crK4AaDWRvbIbLunWZ6LiG5BDiYGQl8qKej43K9GIJptfp0xnkwjudkDeROimcIFh/BV EYTAOd/q2JTGrXPfKkiJOM83V/tO47+CWBRY+wfddnChcy13zOKj2HHAZxM32+5I92eqwAVT kueih/XKGJyA+nL6TVJW/zkTBQIMqaLpORkbLb6W6U9u+fu7Dm0ET0p+idepGeiW8JxLAzM8 FmH68qJEWipuu+sbcKo4APsWaI5sF7YEaitssPSoZmFuNhC1IzIr23cp0zviaboTb6DQvXim mXC3JsdKDQLMuzbll0UIa0K/Up/8X62oNQiLJmPZ1ttH58Dlb7R2qBCDD4ZbGvEJYbDW3l3h J+otFUBueT0hdyy2rM2j/o5XGuhv9sqIHYzwrCUPD6gesCMHrIzHbQyOB4+2Y+BkY+FkMnhK cqMRESbNWijyHG967gh9nUz9OFzb7IkSmj/AmhatumDUmEWFGAgGhXnPlVRnQbXfK+4Kb13D bHAP/l3yjhaJMpqCIsLn//tGDxlfWamclJU2LUbCzf/jaS79Olqhp2H+uKecvgFZpBAYubK+ ZPORNvfwZECb13Zwq49cXovnmQ8dt3nTFwECG7AItdlJhL6RIlIVPSVCy4dO+7T3+vKuRH/Q cDqVJ3I/TKpOG3tD3GciovAAAAAAAAA= --------------ms020903020300030706080704-- From owner-freebsd-stable@freebsd.org Fri Jun 16 14:55:40 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BDB9C0ADE1 for ; Fri, 16 Jun 2017 14:55:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6BC82FE7 for ; Fri, 16 Jun 2017 14:55:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 289E527336 for ; Fri, 16 Jun 2017 10:55:39 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 016E33C84 for ; Fri, 16 Jun 2017 09:55:37 -0500 (CDT) Subject: Re: Interesting permissions difference on NanoBSD build To: freebsd-stable@freebsd.org References: <1387791f-fe22-08d7-2048-26bd95eab451@madpilot.net> <0561597d-4b24-f68e-33a8-d0902e7696da@denninger.net> From: Karl Denninger Message-ID: <129b610a-0f2b-4831-ea5f-9aa4c323cfa8@denninger.net> Date: Fri, 16 Jun 2017 09:55:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <0561597d-4b24-f68e-33a8-d0902e7696da@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030809040209060705000707" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 14:55:40 -0000 This is a cryptographically signed message in MIME format. --------------ms030809040209060705000707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/16/2017 08:21, Karl Denninger wrote: > On 6/16/2017 07:52, Guido Falsi wrote: >> On 06/16/17 14:25, Karl Denninger wrote: >>> I've recently started playing with the "base" NanoBSD scripts and hav= e >>> run into an interesting issue. >> [...] >>> Note the missing "r" bit for "other" in usr and etc directories -- an= d >>> the missing "x" bit (at minimum) for the root! The same is carried d= own >>> to "local" under usr: >>> >>> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al usr >>> total 134 >>> drwxr-x--x 12 root wheel 12 Jun 15 17:10 . >>> drwxr-x--- 18 root wheel 24 Jun 15 17:10 .. >>> drwxr-xr-x 2 root wheel 497 Jun 15 17:09 bin >>> drwxr-xr-x 52 root wheel 327 Jun 15 17:10 include >>> drwxr-xr-x 8 root wheel 655 Jun 15 17:10 lib >>> drwxr-xr-x 4 root wheel 670 Jun 15 17:09 lib32 >>> drwxr-xr-x 5 root wheel 5 Jun 15 17:10 libdata >>> drwxr-xr-x 7 root wheel 70 Jun 15 17:10 libexec >>> drwxr-x--x 10 root wheel 11 Jun 15 17:10 local >>> drwxr-xr-x 2 root wheel 294 Jun 15 17:08 sbin >>> drwxr-xr-x 31 root wheel 31 Jun 15 17:10 share >>> drwxr-xr-x 14 root wheel 17 Jun 15 17:10 tests >>> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # >> I have no idea why this is happening on your system but I'm not >> observing it here: >> >>> ls -al usr >> total 85 >> drwxr-xr-x 9 root wheel 9 Jun 15 13:32 . >> drwxr-xr-x 22 root wheel 29 Jun 15 13:32 .. >> drwxr-xr-x 2 root wheel 359 Jun 15 13:32 bin >> drwxr-xr-x 4 root wheel 446 Jun 15 13:32 lib >> drwxr-xr-x 3 root wheel 3 Jun 15 13:32 libdata >> drwxr-xr-x 5 root wheel 47 Jun 15 13:32 libexec >> drwxr-xr-x 12 root wheel 13 Jun 15 13:32 local >> drwxr-xr-x 2 root wheel 218 Jun 15 13:32 sbin >> drwxr-xr-x 17 root wheel 17 Jun 15 13:32 share >> >> >> and I get (almost) the same on the installed nanobsd system: >>> ls -al usr >> total 24 >> drwxr-xr-x 9 root wheel 512 Jun 15 13:32 . >> drwxr-xr-x 23 root wheel 512 Jun 15 13:34 .. >> drwxr-xr-x 2 root wheel 6144 Jun 15 13:32 bin >> drwxr-xr-x 4 root wheel 10752 Jun 15 13:32 lib >> drwxr-xr-x 3 root wheel 512 Jun 15 13:32 libdata >> drwxr-xr-x 5 root wheel 1024 Jun 15 13:32 libexec >> drwxr-xr-x 12 root wheel 512 Jun 15 13:32 local >> drwxr-xr-x 2 root wheel 4096 Jun 15 13:32 sbin >> drwxr-xr-x 17 root wheel 512 Jun 15 13:32 share >> >> The machine I'm building the NanoBSD image on is running head r318959,= >> and is running ZFS, while the NanoBSD system I've built is tracking >> 11-STABLE and is at r319971 at present, so a BETA1. >> >> Could you report version information too? maybe it's a problem present= >> on head NanoBSD scripts? > FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 > karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP > > I also build using Crochet against both /usr/src (my "primary" source > repo, which is on the rev noted here) and against a second one (-HEAD),= > which I need to use for the RPI3. Neither winds up with this sort of > permission issue. > > The obj directory is on /pics/Crochet-Work-AMD, which is a zfs > filesystem mounted off a "scratch" SSD. > > The problem appears to stem from the creation of "_.w" and since > directory permissions are "normally" inherited it promulgates from ther= e > unless an explicit permission set occurs. Yet I see nothing that would= > create the world directory with anything other than the umask at the > time it runs. > > I *am* running this from "batch" -- perhaps that's where the problem is= > coming from? I'll try adding a "umask 022" to the nanobsd.sh script at= > the top and see what that does. Nope. It's something in the installworld subset; I put a stop in after the clean/create world directory and I have a 0755 permission mask on the (empty) directory. Hmmm... I do not know where this is coming from now but this test implies that it's the "installworld" action that causes it. root@NewFS:/pics/Crochet-work-AMD/obj # ls -al total 2176760 drwxr-xr-x 5 root wheel 24 Jun 16 09:41 . drwxr-xr-x 3 root wheel 3 Jun 16 08:25 .. -rw-r--r-- 1 root wheel 7658918 Jun 16 09:22 _.bk -rw-r--r-- 1 root wheel 53768368 Jun 16 09:15 _.bw -rw-r--r-- 1 root wheel 200 Jun 16 09:25 _.cust.cust_comconsole= -rw-r--r-- 1 root wheel 733 Jun 16 09:25 _.cust.cust_freebsd -rw-r--r-- 1 root wheel 550 Jun 16 09:25 _.cust.cust_install_fi= les -rw-r--r-- 1 root wheel 16958 Jun 16 09:25 _.cust.cust_pkgng -rw-r--r-- 1 root wheel 2566610 Jun 16 09:26 _.di -rw-r--r-- 1 root wheel 6000000000 Jun 16 09:26 _.disk.full -rw-r--r-- 1 root wheel 2711020032 Jun 16 09:26 _.disk.image -rw-r--r-- 1 root wheel 59 Jun 16 09:25 _.dl -rw-r--r-- 1 root wheel 59521 Jun 16 09:25 _.du -rw-r--r-- 1 root wheel 2041 Jun 16 08:25 _.env -rw-r--r-- 1 root wheel 75783 Jun 16 09:24 _.etc -rw-r--r-- 1 root wheel 148 Jun 16 09:25 _.fdisk -rw-r--r-- 1 root wheel 215692 Jun 16 09:25 _.ik -rw-r--r-- 1 root wheel 4085907 Jun 16 09:24 _.iw drwxr-xr-x 2 root wheel 2 Jun 16 09:25 _.mnt -rw-r--r-- 1 root wheel 2676015 Jun 16 09:25 _.mtree drwxr-xr-x 2 root wheel 2 Jun 16 09:41 _.w -rw-r--r-- 1 root wheel 22 Jun 16 08:25 make.conf.build -rw-r--r-- 1 root wheel 22 Jun 16 09:22 make.conf.install drwxr-xr-x 3 root wheel 3 Jun 16 08:25 usr root@NewFS:/usr/src/tools/tools/nanobsd # sh nanobsd.sh -b -n -c PCEngines.conf 00:00:00 ### Exporting NanoBSD variables 00:00:00 ### Setting variable: MAKEOBJDIRPREFIX=3D"/pics/Crochet-work-AMD= /obj" 00:00:00 ### Setting variable: NANO_ARCH=3D"amd64" 00:00:00 ### Setting variable: NANO_CODESIZE=3D"0" 00:00:00 ### Setting variable: NANO_CONFSIZE=3D"125000" 00:00:00 ### Setting variable: NANO_CUSTOMIZE=3D" cust_comconsole cust_pkgng cust_install_files cust_freebsd" 00:00:00 ### Setting variable: NANO_DATASIZE=3D"1000000" 00:00:00 ### Setting variable: NANO_DRIVE=3D"mmcsd0" 00:00:00 ### Setting variable: NANO_HEADS=3D"16" 00:00:00 ### Setting variable: NANO_IMAGES=3D"2" 00:00:00 ### Setting variable: NANO_IMGNAME=3D"_.disk.full" 00:00:00 ### Setting variable: NANO_MAKE=3D"make" 00:00:00 ### Setting variable: NANO_MAKE_CONF_BUILD=3D"/pics/Crochet-work-AMD/obj/make.conf.build" 00:00:00 ### Setting variable: NANO_MAKE_CONF_INSTALL=3D"/pics/Crochet-work-AMD/obj/make.conf.install" 00:00:00 ### Setting variable: NANO_MEDIASIZE=3D"11718750" 00:00:00 ### Setting variable: NANO_NAME=3D"pcengines" 00:00:00 ### Setting variable: NANO_NEWFS=3D"-b 4096 -f 512 -i 8192 -U" 00:00:00 ### Setting variable: NANO_OBJ=3D"/pics/Crochet-work-AMD/obj" 00:00:00 ### Setting variable: NANO_PMAKE=3D"make -j 8" 00:00:00 ### Setting variable: NANO_SECTS=3D"63" 00:00:00 ### Setting variable: NANO_SRC=3D"/usr/src" 00:00:00 ### Setting variable: NANO_TOOLS=3D"/usr/src/tools/tools/nanobsd= " 00:00:00 ### Setting variable: NANO_WORLDDIR=3D"/pics/Crochet-work-AMD/obj/_.w" 00:00:00 ### Setting variable: NANO_BOOT0CFG=3D"-o packet -s 1 -m 3" 00:00:00 ### Setting variable: NANO_BOOTLOADER=3D"boot/boot0sio" 00:00:00 ### Setting variable: NANO_LABEL=3D"" 00:00:00 ### Setting variable: NANO_MODULES=3D"default" 00:00:00 ### Setting variable: NANO_NOPRIV_BUILD=3D"" 00:00:00 ### Setting variable: NANO_METALOG=3D"" 00:00:00 ### Setting variable: NANO_LOG=3D"/pics/Crochet-work-AMD/obj" 00:00:00 ### Setting variable: SRCCONF=3D"/dev/null" 00:00:00 ### Setting variable: SRC_ENV_CONF=3D"/dev/null" 00:00:00 # NanoBSD image pcengines build starting 00:00:00 ## run early customize scripts 00:00:00 ## Skipping buildworld (as instructed) 00:00:00 ## Skipping buildkernel (as instructed) 00:00:00 ## Clean and create world directory (/pics/Crochet-work-AMD/obj/_.w) STOP STOP STOP --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030809040209060705000707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MTYxNDU1MzVaME8GCSqGSIb3DQEJBDFCBEBZ443e xHnSzHymR1i0oDqom63UdAt45ZdlR5Hr2kekDBkP9IJZnflPCY9MqSY5v9tOR4PjEPN+7H1q 55F4slruMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAstQrSuh7le4I OIllldpGpIbxK855K1S3+Rkt3GD8FSWyyvPcVkieGAKZqKrGdAmTJNOqFnFBY6EL1HZY/hpz Y0nXLBJvi9IT9/JnJLdo1e0Fder6hciDyvApuSLUlDWsI4hoppBU3ZIcSAgaqndJmiWaweW2 fs/zOVS5ldApmPVi2Ki9F/EK4wNxI3A9ddF/pfBc1tQQxPa2rjrQSf2ErphLJxp/cUUlWRVg 0Vs2yNX+J4S6Fgg9/D5I14et6lRLhRro+K8ZWTzff1t/RdBYWFGDGqVBbSnw9ErcOt+xYw37 XvPBtthrDv/dbr4y8WCz0OyGDrflHrAEf84g2ygtV9p3rEwPKGbKhtqESFgx4LSRNWfbfWXq gEBqUW9JqzyDJRu29qerrI7cb+uUG0FcAz+dP0qzUSLXWMIi4EusOvgrdd2MfhEDFRbBj8m1 sa0FeT5mQSW8TnGTF58SRnQnXoPFKdj5pCynifUhKrcobp1euttwARsDsNzoklGmXEa0R7Wb teiquTcWjGz/Ec+IBS8HArQ8idz9tIVQ/t4ZqVM6cRjW0q7GIjfRGTKTRAjz+cieaTACp9/u PjZqr8q2U8LnFk8ek3VKWlEG9Vb/69gOY7zwDr1M3Su6yjtXP3qrQCt/wQVtYy3ZgeOoNkQS i/eJK9uWOgky/WUzk60NlvgAAAAAAAA= --------------ms030809040209060705000707-- From owner-freebsd-stable@freebsd.org Fri Jun 16 15:53:01 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53A01C77092 for ; Fri, 16 Jun 2017 15:53:01 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9137E0 for ; Fri, 16 Jun 2017 15:53:00 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 10FBB27336 for ; Fri, 16 Jun 2017 11:53:00 -0400 (EDT) Received: from [192.168.10.20] (D10.Denninger.Net [192.168.10.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 3F59FB92A6 for ; Fri, 16 Jun 2017 10:52:59 -0500 (CDT) Subject: Re: Interesting permissions difference on NanoBSD build To: freebsd-stable@freebsd.org References: <1387791f-fe22-08d7-2048-26bd95eab451@madpilot.net> <0561597d-4b24-f68e-33a8-d0902e7696da@denninger.net> <129b610a-0f2b-4831-ea5f-9aa4c323cfa8@denninger.net> From: Karl Denninger Message-ID: <51250937-eb64-bd50-b63c-0725439bb20b@denninger.net> Date: Fri, 16 Jun 2017 10:52:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <129b610a-0f2b-4831-ea5f-9aa4c323cfa8@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050107090003080600020208" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 15:53:01 -0000 This is a cryptographically signed message in MIME format. --------------ms050107090003080600020208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/16/2017 09:55, Karl Denninger wrote: > On 6/16/2017 08:21, Karl Denninger wrote: >> On 6/16/2017 07:52, Guido Falsi wrote: >>> On 06/16/17 14:25, Karl Denninger wrote: >>>> I've recently started playing with the "base" NanoBSD scripts and ha= ve >>>> run into an interesting issue. >>> [...] >>>> Note the missing "r" bit for "other" in usr and etc directories -- a= nd >>>> the missing "x" bit (at minimum) for the root! The same is carried = down >>>> to "local" under usr: >>>> >>>> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # ls -al usr >>>> total 134 >>>> drwxr-x--x 12 root wheel 12 Jun 15 17:10 . >>>> drwxr-x--- 18 root wheel 24 Jun 15 17:10 .. >>>> drwxr-xr-x 2 root wheel 497 Jun 15 17:09 bin >>>> drwxr-xr-x 52 root wheel 327 Jun 15 17:10 include >>>> drwxr-xr-x 8 root wheel 655 Jun 15 17:10 lib >>>> drwxr-xr-x 4 root wheel 670 Jun 15 17:09 lib32 >>>> drwxr-xr-x 5 root wheel 5 Jun 15 17:10 libdata >>>> drwxr-xr-x 7 root wheel 70 Jun 15 17:10 libexec >>>> drwxr-x--x 10 root wheel 11 Jun 15 17:10 local >>>> drwxr-xr-x 2 root wheel 294 Jun 15 17:08 sbin >>>> drwxr-xr-x 31 root wheel 31 Jun 15 17:10 share >>>> drwxr-xr-x 14 root wheel 17 Jun 15 17:10 tests >>>> root@NewFS:/pics/Crochet-work-AMD/obj/_.w # >>> I have no idea why this is happening on your system but I'm not >>> observing it here: >>> >>>> ls -al usr >>> total 85 >>> drwxr-xr-x 9 root wheel 9 Jun 15 13:32 . >>> drwxr-xr-x 22 root wheel 29 Jun 15 13:32 .. >>> drwxr-xr-x 2 root wheel 359 Jun 15 13:32 bin >>> drwxr-xr-x 4 root wheel 446 Jun 15 13:32 lib >>> drwxr-xr-x 3 root wheel 3 Jun 15 13:32 libdata >>> drwxr-xr-x 5 root wheel 47 Jun 15 13:32 libexec >>> drwxr-xr-x 12 root wheel 13 Jun 15 13:32 local >>> drwxr-xr-x 2 root wheel 218 Jun 15 13:32 sbin >>> drwxr-xr-x 17 root wheel 17 Jun 15 13:32 share >>> >>> >>> and I get (almost) the same on the installed nanobsd system: >>>> ls -al usr >>> total 24 >>> drwxr-xr-x 9 root wheel 512 Jun 15 13:32 . >>> drwxr-xr-x 23 root wheel 512 Jun 15 13:34 .. >>> drwxr-xr-x 2 root wheel 6144 Jun 15 13:32 bin >>> drwxr-xr-x 4 root wheel 10752 Jun 15 13:32 lib >>> drwxr-xr-x 3 root wheel 512 Jun 15 13:32 libdata >>> drwxr-xr-x 5 root wheel 1024 Jun 15 13:32 libexec >>> drwxr-xr-x 12 root wheel 512 Jun 15 13:32 local >>> drwxr-xr-x 2 root wheel 4096 Jun 15 13:32 sbin >>> drwxr-xr-x 17 root wheel 512 Jun 15 13:32 share >>> >>> The machine I'm building the NanoBSD image on is running head r318959= , >>> and is running ZFS, while the NanoBSD system I've built is tracking >>> 11-STABLE and is at r319971 at present, so a BETA1. >>> >>> Could you report version information too? maybe it's a problem presen= t >>> on head NanoBSD scripts? >> FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 >> karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP >> >> I also build using Crochet against both /usr/src (my "primary" source >> repo, which is on the rev noted here) and against a second one (-HEAD)= , >> which I need to use for the RPI3. Neither winds up with this sort of >> permission issue. >> >> The obj directory is on /pics/Crochet-Work-AMD, which is a zfs >> filesystem mounted off a "scratch" SSD. >> >> The problem appears to stem from the creation of "_.w" and since >> directory permissions are "normally" inherited it promulgates from the= re >> unless an explicit permission set occurs. Yet I see nothing that woul= d >> create the world directory with anything other than the umask at the >> time it runs. >> >> I *am* running this from "batch" -- perhaps that's where the problem i= s >> coming from? I'll try adding a "umask 022" to the nanobsd.sh script a= t >> the top and see what that does. > Nope. > > It's something in the installworld subset; I put a stop in after the > clean/create world directory and I have a 0755 permission mask on the > (empty) directory. > > Hmmm... > > I do not know where this is coming from now but this test implies that > it's the "installworld" action that causes it. > > root@NewFS:/pics/Crochet-work-AMD/obj # ls -al > > total 2176760 > drwxr-xr-x 5 root wheel 24 Jun 16 09:41 . > drwxr-xr-x 3 root wheel 3 Jun 16 08:25 .. > -rw-r--r-- 1 root wheel 7658918 Jun 16 09:22 _.bk > -rw-r--r-- 1 root wheel 53768368 Jun 16 09:15 _.bw > -rw-r--r-- 1 root wheel 200 Jun 16 09:25 _.cust.cust_comconso= le > -rw-r--r-- 1 root wheel 733 Jun 16 09:25 _.cust.cust_freebsd > -rw-r--r-- 1 root wheel 550 Jun 16 09:25 _.cust.cust_install_= files > -rw-r--r-- 1 root wheel 16958 Jun 16 09:25 _.cust.cust_pkgng > -rw-r--r-- 1 root wheel 2566610 Jun 16 09:26 _.di > -rw-r--r-- 1 root wheel 6000000000 Jun 16 09:26 _.disk.full > -rw-r--r-- 1 root wheel 2711020032 Jun 16 09:26 _.disk.image > -rw-r--r-- 1 root wheel 59 Jun 16 09:25 _.dl > -rw-r--r-- 1 root wheel 59521 Jun 16 09:25 _.du > -rw-r--r-- 1 root wheel 2041 Jun 16 08:25 _.env > -rw-r--r-- 1 root wheel 75783 Jun 16 09:24 _.etc > -rw-r--r-- 1 root wheel 148 Jun 16 09:25 _.fdisk > -rw-r--r-- 1 root wheel 215692 Jun 16 09:25 _.ik > -rw-r--r-- 1 root wheel 4085907 Jun 16 09:24 _.iw > drwxr-xr-x 2 root wheel 2 Jun 16 09:25 _.mnt > -rw-r--r-- 1 root wheel 2676015 Jun 16 09:25 _.mtree > drwxr-xr-x 2 root wheel 2 Jun 16 09:41 _.w > -rw-r--r-- 1 root wheel 22 Jun 16 08:25 make.conf.build > -rw-r--r-- 1 root wheel 22 Jun 16 09:22 make.conf.install > drwxr-xr-x 3 root wheel 3 Jun 16 08:25 usr > > root@NewFS:/usr/src/tools/tools/nanobsd # sh nanobsd.sh -b -n -c > PCEngines.conf > 00:00:00 ### Exporting NanoBSD variables > 00:00:00 ### Setting variable: MAKEOBJDIRPREFIX=3D"/pics/Crochet-work-A= MD/obj" > 00:00:00 ### Setting variable: NANO_ARCH=3D"amd64" > 00:00:00 ### Setting variable: NANO_CODESIZE=3D"0" > 00:00:00 ### Setting variable: NANO_CONFSIZE=3D"125000" > 00:00:00 ### Setting variable: NANO_CUSTOMIZE=3D" cust_comconsole > cust_pkgng cust_install_files cust_freebsd" > 00:00:00 ### Setting variable: NANO_DATASIZE=3D"1000000" > 00:00:00 ### Setting variable: NANO_DRIVE=3D"mmcsd0" > 00:00:00 ### Setting variable: NANO_HEADS=3D"16" > 00:00:00 ### Setting variable: NANO_IMAGES=3D"2" > 00:00:00 ### Setting variable: NANO_IMGNAME=3D"_.disk.full" > 00:00:00 ### Setting variable: NANO_MAKE=3D"make" > 00:00:00 ### Setting variable: > NANO_MAKE_CONF_BUILD=3D"/pics/Crochet-work-AMD/obj/make.conf.build" > 00:00:00 ### Setting variable: > NANO_MAKE_CONF_INSTALL=3D"/pics/Crochet-work-AMD/obj/make.conf.install"= > 00:00:00 ### Setting variable: NANO_MEDIASIZE=3D"11718750" > 00:00:00 ### Setting variable: NANO_NAME=3D"pcengines" > 00:00:00 ### Setting variable: NANO_NEWFS=3D"-b 4096 -f 512 -i 8192 -U"= > 00:00:00 ### Setting variable: NANO_OBJ=3D"/pics/Crochet-work-AMD/obj" > 00:00:00 ### Setting variable: NANO_PMAKE=3D"make -j 8" > 00:00:00 ### Setting variable: NANO_SECTS=3D"63" > 00:00:00 ### Setting variable: NANO_SRC=3D"/usr/src" > 00:00:00 ### Setting variable: NANO_TOOLS=3D"/usr/src/tools/tools/nanob= sd" > 00:00:00 ### Setting variable: > NANO_WORLDDIR=3D"/pics/Crochet-work-AMD/obj/_.w" > 00:00:00 ### Setting variable: NANO_BOOT0CFG=3D"-o packet -s 1 -m 3" > 00:00:00 ### Setting variable: NANO_BOOTLOADER=3D"boot/boot0sio" > 00:00:00 ### Setting variable: NANO_LABEL=3D"" > 00:00:00 ### Setting variable: NANO_MODULES=3D"default" > 00:00:00 ### Setting variable: NANO_NOPRIV_BUILD=3D"" > 00:00:00 ### Setting variable: NANO_METALOG=3D"" > 00:00:00 ### Setting variable: NANO_LOG=3D"/pics/Crochet-work-AMD/obj" > 00:00:00 ### Setting variable: SRCCONF=3D"/dev/null" > 00:00:00 ### Setting variable: SRC_ENV_CONF=3D"/dev/null" > 00:00:00 # NanoBSD image pcengines build starting > 00:00:00 ## run early customize scripts > 00:00:00 ## Skipping buildworld (as instructed) > 00:00:00 ## Skipping buildkernel (as instructed) > 00:00:00 ## Clean and create world directory > (/pics/Crochet-work-AMD/obj/_.w) > STOP STOP STOP I found the problem -- the customize file function that I was using was picking up the directory tree permissions in the source and applying it across the board; the error was in there. Disregard; the script is ok; this is a potential mine field in its use, but it's one that falls under "user error" in terms of category :-) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050107090003080600020208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MTYxNTUyNTdaME8GCSqGSIb3DQEJBDFCBEAJn+wr QcJgp6beKqoZ/bnuWaUHFMjEv0KgdwMeiqx8VSlKjIoEbMPpfnoBBepxzVSttXlwEhbYzLWv 1TET3t1mMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAU34z9gp29Fau NhnFgo0nNbKCSkBYa3MS5TvCt9j1TE9DcGz/JP/fbnema72fzyZwUd9CKPk00oc8CEY23whp JR4tDcInLbFENAQxuoHNwyEjHhWPNDkucYdsdpKsEPy96TP9LXY0enTkMPZSdWjPjCP8w5kn RzwWxGRdQD6JMUy3fyEcGmLOXbZsxqv6LTw3r3PmGtk+7mofwfPX1pzJKWxyY6xPhaMyUHPp yKpo3VeoQgfrWj1to1A53CJZF0lsjIPgIWcQ2tJa5l9UcoF+YkpPcixP878tWW66RktYn46z QxNZMlg2SFtcrsLNLjGCwBc8BmPLyC612FUvATH9q8qv0uxJpE8AGXEnOF7n03LFkD7Rr0je W7Ai7oddz049p14GZMibZ3xdSchzx+MxOzoYcfIzVJ3ZrR65R9NlpXoA8vjKVt4cAzaT006p IPtv9dtXdGVlQPb+3hPcygj1pHVjw3zOaKExPcYU98ks8M5AhxJhrHvQ91xq11TwkL74904i k2Oh3Bl8szsznfPKwkBU6TpdYCDG1/EoHmkVNzYwKL49yUXzcOQgqi6onxzYLe7eYHpscm+d 6VoxsbHLTuJJLGndprqr1iK8MGmEWyhnFQIcXHdwBi5eK2MdCSyXWxcSn9WkCm3Dg+2OTNSF VQVOT6QCRoquS3SLanS88JoAAAAAAAA= --------------ms050107090003080600020208-- From owner-freebsd-stable@freebsd.org Sat Jun 17 17:11:16 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0D50BFE0FB for ; Sat, 17 Jun 2017 17:11:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BA667266A; Sat, 17 Jun 2017 17:11:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id C43AE5DB8; Sat, 17 Jun 2017 17:11:06 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sat, 17 Jun 2017 17:11:04 +0000 From: Glen Barber To: freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 11.1-BETA2 Now Available Message-ID: <20170617171104.GZ67367@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-STABLE amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer X-Spidey-Sense: Uh oh, Peter logged in User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 17:11:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The second BETA build of the 11.1-RELEASE release cycle is now available. Installation images are available for: o 11.1-BETA2 amd64 GENERIC o 11.1-BETA2 i386 GENERIC o 11.1-BETA2 powerpc GENERIC o 11.1-BETA2 powerpc64 GENERIC64 o 11.1-BETA2 sparc64 GENERIC o 11.1-BETA2 armv6 BANANAPI o 11.1-BETA2 armv6 BEAGLEBONE o 11.1-BETA2 armv6 CUBIEBOARD o 11.1-BETA2 armv6 CUBIEBOARD2 o 11.1-BETA2 armv6 CUBOX-HUMMINGBOARD o 11.1-BETA2 armv6 GUMSTIX o 11.1-BETA2 armv6 RPI-B o 11.1-BETA2 armv6 RPI2 o 11.1-BETA2 armv6 PANDABOARD o 11.1-BETA2 armv6 WANDBOARD o 11.1-BETA2 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.1/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/11" branch. A summary of changes since 11.1-BETA1 includes: o The cpuset_getaffinity(2) and cpuset_setaffinity(2) sytem calls are now allowed in capabilities mode. o The bmake utility has been updated to version 20170510. o The 'locate all off' sesutil(8) command now correctly deactivates LEDs on empty ses(4) slots. o The msk(4) driver has been updated to properly use message signalled interrupts on the Softiron Overdrive 1000 system. o The pcib(4) driver has been updated for Hyper-V virtual machines to use device serial numbers instead of the GUID for persistent devices. o A possible null pointer reference has been corrected. o A buffer length issue in RPC code has been corrected. o SMBFS has been fixed with saved passwords longer than 18 characters. o Various swap pager fixes. o top(1) has been updated to change the way the ZFS ARC compression ratio is calculated, and remove overhead statistics, already included in other counters. o bsdinstall(8) has been updated to make ZFS min_auto_ashift adjustment persistent, as well as support Auto ZFS mode for ARM64. o Possible transmission breakage of files longer than 4 GB on 32-bit architectures has been fixed. A list of changes since 11.0-RELEASE are available in the stable/11 release notes: https://www.freebsd.org/relnotes/11-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 11.1-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64, i386, and aarch64 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/11.1-BETA2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-11.1-BETA2 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 11.1-BETA2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 10.x. Alternatively, the user can install misc/compat10x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 11.1-BETA2 amd64 GENERIC: SHA512 (FreeBSD-11.1-BETA2-amd64-bootonly.iso) = 9e949a17803da5135b2d6485def66a5a2e89119fbb656b36385c92b0501bbb8e74f31e8205460a5198309df9f60b177b696dd0c45a9cbbcf6a4e13daeb9b76f5 SHA512 (FreeBSD-11.1-BETA2-amd64-bootonly.iso.xz) = 1bba1e7149d13f1528286455ec6e2aea29d607ac50590b5382100704f4e0f92b7994fa21ccf1388bd487ef050c0701986653f35aeaed6c848d027eb6f3ffbf85 SHA512 (FreeBSD-11.1-BETA2-amd64-disc1.iso) = 83174db162cd1a657b6c19344c936c3cb3db38a941245a0b4bc89aaabe1831b3d51bd2359e6d7f477414994ec462ad3c6dc93d6c254934f762b73513d3950068 SHA512 (FreeBSD-11.1-BETA2-amd64-disc1.iso.xz) = 15f454bf808dc2dc5d0203bb349f86e197d519d00a2177b3f6bd42dca67e66d88768de58cccda7d894f6daf29c7db02e397a22deb4a063d08e23232fc010485d SHA512 (FreeBSD-11.1-BETA2-amd64-dvd1.iso) = 4a45b490dcebc76cde5f74bbe6bd1cb9a760d52a3d039f57a119f451d2b86e7db2061355ad6986f9ac24e4ed584e8202d6a81cb6176dd0e2e3a7f85f9310324c SHA512 (FreeBSD-11.1-BETA2-amd64-dvd1.iso.xz) = 6ba49f0c64da9c79cf6a220d9b81c2e55c34745a7b1e52442e3ade510f2f38611f604a1af3b6d10f9cdc46359133cf9e98cfa0e477e2a6a2ba0d05da2a80dfda SHA512 (FreeBSD-11.1-BETA2-amd64-memstick.img) = cf15f152158c9eef8b7257c08932de805d234ce43c3b712095454b7e4d89001a7fd77f070dba4533bce7ffafd5f3bedbef7048a73a2a889ffdda93fe145a1341 SHA512 (FreeBSD-11.1-BETA2-amd64-memstick.img.xz) = 505445fdcca54f11a85ca60f49caeed6f367e75cb0e82f90d3396159767d71b69126d10ec1fe16cc2e96225da3174ecb395d40cd89def3b600436e03aba9e302 SHA512 (FreeBSD-11.1-BETA2-amd64-mini-memstick.img) = 9824f08fa31e4b693bbf77b3a8c384ea716dc70363e1a85b84843901c063ff89c6517e113b2af7b97148243908e1141bde83be752764f95d9a0da31ca15d1d46 SHA512 (FreeBSD-11.1-BETA2-amd64-mini-memstick.img.xz) = 00edab1ab6254626f87af80d22c77a332583b163034dbf8ffcf293882fdd2fcfe0c7f7efce1d94851bbf8ba2a7e2fb221053bd619003d804b4835130ffb061a1 SHA256 (FreeBSD-11.1-BETA2-amd64-bootonly.iso) = 24b21a49d39c361d96d32ac84479191d6f79f9ddafc50cdacc048fdc0de38bd4 SHA256 (FreeBSD-11.1-BETA2-amd64-bootonly.iso.xz) = 3088f8e42d061cc3f88e312b76fcee624f0e5b3c1a8b2d66888a9901e1e04486 SHA256 (FreeBSD-11.1-BETA2-amd64-disc1.iso) = 8de2464992717e3991150848e9c427d1eab90aaab68d656d5861dc71dbcd657a SHA256 (FreeBSD-11.1-BETA2-amd64-disc1.iso.xz) = 367b7468274d5953414423a8bf5b89dbef675c7e723c44deb83f536ce1dd134e SHA256 (FreeBSD-11.1-BETA2-amd64-dvd1.iso) = 891742dfa9abbff850a90bfbfa67651287eb0c2b9d0c0712259c3f8e31b409f4 SHA256 (FreeBSD-11.1-BETA2-amd64-dvd1.iso.xz) = 96c3bf6d53cb1c888037d57266d75a901d3134de87290cbdde3324fba9e990c6 SHA256 (FreeBSD-11.1-BETA2-amd64-memstick.img) = fb15cac67078ae2871213bdb55795c0dc7fa1249678a2757cb76e5cc6105e6be SHA256 (FreeBSD-11.1-BETA2-amd64-memstick.img.xz) = 1e9bce75b274131a08ef8d56209ce4b9a2b63b7ed25372d0602ee6d3dd821ecc SHA256 (FreeBSD-11.1-BETA2-amd64-mini-memstick.img) = e23dd4d1b8adb76d429c598ac04b8555f1489e947ba516e235908abbdeaa6695 SHA256 (FreeBSD-11.1-BETA2-amd64-mini-memstick.img.xz) = 52a33a8d44f065e7d9bdd1d6af8f5623ce081c7f6b5736f02910633d39687d92 o 11.1-BETA2 i386 GENERIC: SHA512 (FreeBSD-11.1-BETA2-i386-bootonly.iso) = 6e89031bc2d388deff0be42efee64a12608a325b78c300bd6dc7e2d5014c334c10be8aa7639ac9884959d16cf8043951b9fb8ac086e6545d0e950d930ee0a35c SHA512 (FreeBSD-11.1-BETA2-i386-bootonly.iso.xz) = 446cce07ffbf3f02d770a27b1f4089ad927dff0826592b3d0b87d542dadf474ded1cde1ea990f638aabc3d910bfb3a2ddf0b4db90f84ee84e8b655037d93355e SHA512 (FreeBSD-11.1-BETA2-i386-disc1.iso) = cd37e982f7bd2b926b77d4818f60a2a89332d4d443c279881b5d91da294b16321929591d7843749c29199ba57267dad9ab60300d1190b044ba417076fbfc8c66 SHA512 (FreeBSD-11.1-BETA2-i386-disc1.iso.xz) = 01a25d669ba3554430c47bbb183f0b184f7c2abaec660dc73efe54f8381f97ed1f999d056bf8e9202316429a5c8433e7e9e089ab944a8c62e5b7240f89b3af48 SHA512 (FreeBSD-11.1-BETA2-i386-dvd1.iso) = 48ff888da5f8bc30dcdc6993a5a2e54c9f6b9673d5cc346797f3f9a62e35117e8230bc460b13ac3b22461f37d8554c52c0ba8578556f3406d4d51e303043fec5 SHA512 (FreeBSD-11.1-BETA2-i386-dvd1.iso.xz) = 054c508bf9386cd4cd0323b047d473343053aae1c893afef50848a287a6c0f4de5f4aa70c55bf0a6287f36c68a52dde916249a1fda9199b1598e261f9e9df00e SHA512 (FreeBSD-11.1-BETA2-i386-memstick.img) = d15ce715ef6d9d1e19661264bb029ad622c87c15c030cc04b6d28cafa790023bba492aecfa588512b3eb8c5733949da0597280755e3e89bba43f89cf6a25369d SHA512 (FreeBSD-11.1-BETA2-i386-memstick.img.xz) = 0307e61a7debb71164a5630a7b9f7be675946bdfb7ad6ae0a76b43826353083faa1e5e65df4fefd03749d22c9f8bfc6b3786bf3a68ce923e96d69f384fee8263 SHA512 (FreeBSD-11.1-BETA2-i386-mini-memstick.img) = 51ec5357a82e8d69e0e541f35e3700d7ae36ac33a6283f973cd7b19e33e305d80141f2dfdc500e45cca2d581093a1136bffaac3eed2454492cbf62c5f4a9856e SHA512 (FreeBSD-11.1-BETA2-i386-mini-memstick.img.xz) = 0844a7ce1eb54380bc7d74b89dc8fd5ed673e19b3dd88408afb2d12f60ec71a63e83f73354ba509f6be7192b2545076c4e02b9abecee7fdab083058576b2a1c1 SHA256 (FreeBSD-11.1-BETA2-i386-bootonly.iso) = a460601bcd0b8b686df91a2e55e9a436630a317d1a017c2e38c6c6c3c72cd0bd SHA256 (FreeBSD-11.1-BETA2-i386-bootonly.iso.xz) = 1763be73443c8de3aa13bfb2178648119a43f8d79de49dcce9b7d9d44361e503 SHA256 (FreeBSD-11.1-BETA2-i386-disc1.iso) = bfabc656acc67a5691783ccbefdf0fe31db71f638a4d7b84e197d3d31bf1d665 SHA256 (FreeBSD-11.1-BETA2-i386-disc1.iso.xz) = 87cb1eeb05b38964114fa61780ad7d0fe737ee762cd636b520cc9060b34f3a4d SHA256 (FreeBSD-11.1-BETA2-i386-dvd1.iso) = 615291e8c39e167a5872ca53b4491e372e99d40342014b92ada2bc439aa18a89 SHA256 (FreeBSD-11.1-BETA2-i386-dvd1.iso.xz) = 77fdad0c4b7d5470c2e2b0c68c6095bab59d18bb5779f660ffa98715a322d2e3 SHA256 (FreeBSD-11.1-BETA2-i386-memstick.img) = 533a08fa10af29c4813559abc5b361a558149f8e0c0aa5ed43ace083547d3639 SHA256 (FreeBSD-11.1-BETA2-i386-memstick.img.xz) = fd0acc08090462f45eb1cbff508d1f69dce0f2f85f3e0b4ee4b2f43816cd3848 SHA256 (FreeBSD-11.1-BETA2-i386-mini-memstick.img) = 80ebe05f019c40e603f9529052825d411a5e800f84713e26ddba333a735b1f0c SHA256 (FreeBSD-11.1-BETA2-i386-mini-memstick.img.xz) = c8b86f4e2e8b6d4a6cc17baca1bc4e59ee03f283fe0cc4e0ff4eb497265d02c4 o 11.1-BETA2 powerpc GENERIC: SHA512 (FreeBSD-11.1-BETA2-powerpc-bootonly.iso) = f09e60d616648f390de0c1621271e449458135f0446284a73d6c61716e9b97cb79fe82ba2b81e1a5fd9cc14b5cb4674dad06a8b612f3e6e7dc65e15dc09f3201 SHA512 (FreeBSD-11.1-BETA2-powerpc-bootonly.iso.xz) = e6d5461c3df6f36badc45a552583deed4811556fec78f0fb40b18dbe27023ad4b9a237316d088676add383cb9f9942a7b6058376e57aea9932a74ac880301e7a SHA512 (FreeBSD-11.1-BETA2-powerpc-disc1.iso) = e34bee4108d596f2e5a7c862c2cec91fa9749ca937e24639701b8e3abe4361fcac4322f429ec086ccb9ce69f09b48fecc40e71543d6f37743378dd090de2483f SHA512 (FreeBSD-11.1-BETA2-powerpc-disc1.iso.xz) = 7b4734dab542ee3aaa1b1872c369aedb39f04208250c1dddaca2751d7321e49e02bacd64da344483546db2c9f53b9b005583dae31326d7a21f8c025f67d7045e SHA512 (FreeBSD-11.1-BETA2-powerpc-dvd1.iso) = 9f2908b10af4b5507a15f889d7279df1fa5459a6bfda375a9fb5c3b5cd532e90a033478d99b2894262d467187bdc1368f51905d407f980a89dc3fd1ce96f3b89 SHA512 (FreeBSD-11.1-BETA2-powerpc-dvd1.iso.xz) = 516692f3b04b0bd5ac66cdf286d1b89be893b48e2469dcfcb4dff8d09402fe8c28532c541baeb348929df54559e300f2aeb526004f3f8c83b810f2089ef53b30 SHA512 (FreeBSD-11.1-BETA2-powerpc-memstick.img) = c9640fa47808e0244f43c9e7fed52e41c15c90d0c8b0b67ed0e543ffb79cd8d6623efef54042abc0cd3b819b410dd95ba4c825990f344a153ae73991b952e55c SHA512 (FreeBSD-11.1-BETA2-powerpc-memstick.img.xz) = 43843615b40df4bb3b6f92b29055b51a14e3cce1fc367be322815d9e4e2c75e17e77e4fd1cf0688853c607e6250d02ad3844b092465a333cc1330f5c97de7d02 SHA512 (FreeBSD-11.1-BETA2-powerpc-mini-memstick.img) = 7934d73ecead22bfa97d1eedf09063a0d2c0c43d2f29a13fe14e79b6bd5c9a8c5556cec5bdf3b83ae33b10d90cfae718197abd0343914d305c914b07de193e18 SHA512 (FreeBSD-11.1-BETA2-powerpc-mini-memstick.img.xz) = 567d947a3b4a98b8fd8fcb544343cd6ea23276e4ab2b3de112c411179653abcd5304797d1c071d74c9d185b14cab4089b8c127648b905909f76a94fffeeca21b SHA256 (FreeBSD-11.1-BETA2-powerpc-bootonly.iso) = 5b6dcad86206ad31d8fd945913fab3f90b3e816934715149facfc72b6e0a7d71 SHA256 (FreeBSD-11.1-BETA2-powerpc-bootonly.iso.xz) = c6fb65684f504cd7d3f61b378b7b62492952331660a03540dd1ab74e19892919 SHA256 (FreeBSD-11.1-BETA2-powerpc-disc1.iso) = f640911e4bf4eceb51742d16a56cef3cb9e2bb71bdcfc94301b08297a7596eb7 SHA256 (FreeBSD-11.1-BETA2-powerpc-disc1.iso.xz) = bebb88c57f59a5a402d9a9bfb3aaa95d9a1c13552fa4568d2fd48c34222d5f40 SHA256 (FreeBSD-11.1-BETA2-powerpc-dvd1.iso) = afb5cbdb79c0d5e19bb16b439e5943a69011f3ea49eac3175d9a4cb49dbe9187 SHA256 (FreeBSD-11.1-BETA2-powerpc-dvd1.iso.xz) = 2b18192f76c6bbf5326df081e1e4ea1fc4250a64a7278919798a201d8648e905 SHA256 (FreeBSD-11.1-BETA2-powerpc-memstick.img) = cbe31070b54692bb5b77b9ead41731f462d517db211a9f2b86df6c0fce803e95 SHA256 (FreeBSD-11.1-BETA2-powerpc-memstick.img.xz) = 1e3dc4a051a64cccc86ae067e6d2a7a0477ed2196686b0a39e5abda65c0168cf SHA256 (FreeBSD-11.1-BETA2-powerpc-mini-memstick.img) = 03f37c9161c1b3f78bb46421b186f6f258524e58f08cdb2697f870cfc5d4f6a7 SHA256 (FreeBSD-11.1-BETA2-powerpc-mini-memstick.img.xz) = d45b2a769daf39034a4d0d46d567668d68df1f9a888c184f6a9807b3f5590d7b o 11.1-BETA2 powerpc64 GENERIC64: SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-bootonly.iso) = 60a9ce4c82428d06449d30f3cc1f2a1457f1b89075933d93ae83cc4701b49e779363549ffdaf5bfc07d6566ca1f48db8e2c852976180f9aa5a12575c2119568f SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-bootonly.iso.xz) = 8e9a0450250413e67c1422ec4e07f69ed6cdac770379c3d7c984f1dd2877d227d050286fb4530ebcb5305ac8b09c568888b94173292734e49161e60cd54b2646 SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-disc1.iso) = 991c0d99ae042888f74e947c0c8ca2450a594b22d87ec862b2db91611e792dd9c0579fa426e90c3284511dfbb7400280794e0eef7782495c7fe5c1331695cd32 SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-disc1.iso.xz) = 161d57520fea022864e52366102e235053f2a8b578086032076daab967efe6a2e546e0245e7b347c84a411f3a6a2f1dc487eec6540cf4bc8eafbccdf7aa511ff SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-dvd1.iso) = 93bc0a3e4a867c5cae22e7fbaf1bda97f59ce8b0d1c68a79b08e271445462c704330a907246e0129f41423ac6f0b85ff6697e494cbbbba2536f99da027e40a8a SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-dvd1.iso.xz) = cebbc798fd5c7d190182192e31aa8b53df21082bad4b1b3faf1092f1059c430414d059536b36fe2dcef1d2504f130f60181bcc8b67adc3f9fd4c9d27318627a2 SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-memstick.img) = d5c1fafd9f795c317bf7882990d1fee1de230252d2a54766fdfcb11a204c2fb14c2c3dbfddfaeed92f578e6e550c4feb7b52807b20087a42a041d56726388de6 SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-memstick.img.xz) = c0a11c2d17debe084b74ffba26e15447ad303b70f0647a912ea8f602289492211c7174daf66401c302fcee5be2e1d9de735b19186c75992d7a430b69a4cda262 SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-mini-memstick.img) = 0da78fd9f08dc471a75bac8463d03d3226f68eb28af1e1d377fd5123b80ce31ebd9443a6dd347e86beb445da4af2e5add5cd70c163edb3397f6def39477c3397 SHA512 (FreeBSD-11.1-BETA2-powerpc-powerpc64-mini-memstick.img.xz) = d1da42fe7b17ca9fd13746f8d76342aee0ea4a5687982abe487a2a046578afb9b8a539fe1623f1082c7090aea0665c0e6fdf6b9ff5c6dcb4aa596167c4a191ad SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-bootonly.iso) = ef3e6bc71e16833b0dc2e9fe6c7c8878e2cc92ac0c6f8a45f9fb3ffc9e7182e4 SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-bootonly.iso.xz) = 54af5b39dcd2078109b74702b4fb7c7209f8d3f7a845fcc0257a901019738725 SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-disc1.iso) = 8bd640d06f01667300b1aba20d90cd504d89ee946641921f1665db68e706dfe8 SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-disc1.iso.xz) = 9e6709ab537275c2bb319a4aee1df198bce80bec4e40d4474a873a6d728f55ba SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-dvd1.iso) = e654904f1efde68329f15e42ef4ffaffe0cfb9c9e7706d27eb94f91a2994a7bf SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-dvd1.iso.xz) = 1c2b5512747c4d1166b55915ff0548511906a65c9913484288daf0250afef677 SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-memstick.img) = ebd8da168907e77784e7724e900110da3e9ceb4faad0accbaefe560efe6d8aca SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-memstick.img.xz) = a4a145ed62adbd8346f43bbd32aa9be6cf1ab98963c3918f3d6866c875b57a03 SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-mini-memstick.img) = 39625d64f597355fcadf168b1faf59373619c8646924799eb52d6d0e8dc27290 SHA256 (FreeBSD-11.1-BETA2-powerpc-powerpc64-mini-memstick.img.xz) = 2c529bf21bcb6806e9dbb7a1bf9b17d1d846a9e079cb37759999793329a14ce1 o 11.1-BETA2 sparc64 GENERIC: SHA512 (FreeBSD-11.1-BETA2-sparc64-bootonly.iso) = 3c9606544cd328597a1a26a2b358bebae7727fcd759feb3ac6807939fc2f81cc2ff046d807f11af7143fc699b364176ae15f6e84924b779f0d9e523221ce72de SHA512 (FreeBSD-11.1-BETA2-sparc64-bootonly.iso.xz) = c865ad8b2fc986a214738ea79fc1597c5ab945cea5f7024a2dae1b02aa90ff5285b9ae927559f3716aab40468818d2c855e32f30d240db4f2a31da4d02255b41 SHA512 (FreeBSD-11.1-BETA2-sparc64-disc1.iso) = c2f9c7a80526bf4cda94e0aaf1289b2630aa09bf51fe3809058b759ff196cfa20328771cd2c3a2cf4bc4af4d62f4af29c7a26cbb0905819bbfe709ddd0882ba1 SHA512 (FreeBSD-11.1-BETA2-sparc64-disc1.iso.xz) = 230d41831598ca8e614d97cd1ff37e2471c97079bff9bb7e470ea126ceeb1ecf78650ec042c38eedd59d140702b7958a9ba9fd523b63c10963e2250bcc1caeb6 SHA512 (FreeBSD-11.1-BETA2-sparc64-dvd1.iso) = b593f0778edd6befa393a29622bb386b20d1e71df4dbaf8078e88ed092bc62acd298bc0003cd64f1fc86bc27b7ef76bfd82b3d9c6891dfa781154a8bbb49a1f0 SHA512 (FreeBSD-11.1-BETA2-sparc64-dvd1.iso.xz) = 5692a326576e24d7204603876799067772b6881bac76bae8041e2a209ebf0c9a83ee39091582a18cc60e6b45c9db8939e1da83db5e03b3b16ef44df1f1113e92 SHA256 (FreeBSD-11.1-BETA2-sparc64-bootonly.iso) = 6555c9d21d493beaa3f58f364e8718e2030939fad62d64fa817b8a6b0546f6d8 SHA256 (FreeBSD-11.1-BETA2-sparc64-bootonly.iso.xz) = 66d9a12e5b8db05811112a60e945477481f563faae6ce9213c2b7f9dcbb2bf72 SHA256 (FreeBSD-11.1-BETA2-sparc64-disc1.iso) = 6090aa7279306174429e4e6f8e0c87daeb4d3379bc6caf1169e978355fadb2d1 SHA256 (FreeBSD-11.1-BETA2-sparc64-disc1.iso.xz) = 9f884d4c47c065fdb5c85086d87e3144c96082214168fa4b8c0cb8bd49b89ed8 SHA256 (FreeBSD-11.1-BETA2-sparc64-dvd1.iso) = 99d45ae7f8a125bb876b9a4a7d5363164ed7fd139bc4d16f31eea371cbbe4d04 SHA256 (FreeBSD-11.1-BETA2-sparc64-dvd1.iso.xz) = 68fb16491f063309ddaf2750a84edca4ebafbf96737a9a2e585695fd2ec79274 o 11.1-BETA2 armv6 BANANAPI: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-BANANAPI.img.xz) = a2b825b058b211e34ba5792abd6bb05129ca398c6be8ea653a9284db4313ca98a64a505930bbbd3faaa8aada790b2dee003b4b04d6ab2f4bbed95123abe32197 SHA256 (FreeBSD-11.1-BETA2-arm-armv6-BANANAPI.img.xz) = 95566b8ce773cc8809c45002afad5732bb63309a280613268ede9f9e9fdcdeec o 11.1-BETA2 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-BEAGLEBONE.img.xz) = 1d6b2f0abb7e6001d1760d8cab565ebf57c79f4de93296ed2f4d717c1fe8a6353f33128deacedb8e749d4a7aa65632396ee4f7f76c2cab3eb9807d650254b273 SHA256 (FreeBSD-11.1-BETA2-arm-armv6-BEAGLEBONE.img.xz) = bcbcb913ef47e17a41773feb34518d0f3799aa382b7dd4cc237e98832f2c605f o 11.1-BETA2 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-CUBIEBOARD.img.xz) = 019d5638214259a741fe8f6056d5c3491f7a536cd0eaea8d29b289669d7fe18fc1ceb485ca58be83ec3d3ec46f19ac6fb4850390e0e17fb81fd345e893ba2fd9 SHA256 (FreeBSD-11.1-BETA2-arm-armv6-CUBIEBOARD.img.xz) = 0c207c31f5b28137b40aa6d989f1db1c2c40afb93764b2333da1afd7c517435c o 11.1-BETA2 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-CUBIEBOARD2.img.xz) = d2c1bb54a3cf374007bb4332d71bca72b0d79153788d170a13e01c832197fc3b188f50ea6cdd5846eff222567c71d48266252c27b948b01abce8dcd223fd4894 SHA256 (FreeBSD-11.1-BETA2-arm-armv6-CUBIEBOARD2.img.xz) = c716d6a36955a2a1c41c6f866fa9e02f97375ee30862dd4dc14bfb07df66b650 o 11.1-BETA2 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 5a3f26fe2c01a70072327fb72b063d1a6fa8f1549ad100296bc4f8e922ec8cc53a802b2029561c1b8d63df8a62f2646949b6033263a8860f985ca2edfa391654 SHA256 (FreeBSD-11.1-BETA2-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 05d017f7d39418210b41e2a3d5a3beeb3245e22991b09bc22a6121366a029541 o 11.1-BETA2 armv6 GUMSTIX: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-GUMSTIX.img.xz) = a6c3e988c398306bbef3834c789b87eeb952d3a3bb93ec497b31045cc1f3a7cc1c39566de6e396010fbc9540a70682e4741e1c7a7fb83d81b2036775c925dc65 SHA256 (FreeBSD-11.1-BETA2-arm-armv6-GUMSTIX.img.xz) = afb7453d137414f9ee54b1d28cbe011e85b1eecb0eb9142c56295be596174016 o 11.1-BETA2 armv6 RPI-B: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-RPI-B.img.xz) = 46836b9873865cbf7271104347666ef3c86cbc8ef434a99fe050dc3845db1fd8a28e0829b1d6d03ce5d2ceda2834a8afeb0222eafc96c8c2e86e98d69d9aff8a SHA256 (FreeBSD-11.1-BETA2-arm-armv6-RPI-B.img.xz) = 3a80a917c9fbdf413be1133d6cda4fbfbab647c751671da3bfae5c06187fed13 o 11.1-BETA2 armv6 RPI2: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-RPI2.img.xz) = bb6cf38b4bb2390bd6581c68f39431f025ed689129e0960012c0c8d29b5b5a778ce42a0f10f685a50623d98967aba9bcdf73c9bc007984b4e2661c6e7979ceeb SHA256 (FreeBSD-11.1-BETA2-arm-armv6-RPI2.img.xz) = d56dd060bbccae0a5a134edafd80b7257fabc55effc3ed64c5bf3c8883f54352 o 11.1-BETA2 armv6 PANDABOARD: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-PANDABOARD.img.xz) = 490c3a79a4e3d1d79a03abd9f700308c7a93b175ae0d18c0db731716afaa082a720acacbb2d238465ca78d276749811a47918e5cb20363a57c0dded2fc846321 SHA256 (FreeBSD-11.1-BETA2-arm-armv6-PANDABOARD.img.xz) = acae3cfbaf539af7628e3eb414486dec9d68b0053979c95243473eda7954c427 o 11.1-BETA2 armv6 WANDBOARD: SHA512 (FreeBSD-11.1-BETA2-arm-armv6-WANDBOARD.img.xz) = 7abd32f783b114c7aeec51e565b3136020d02471f8ad7af4706f8396339f91d7951aec4f9f87f845dce16062769d87ef0ff7400b4cede3463a4d2a03efb670dc SHA256 (FreeBSD-11.1-BETA2-arm-armv6-WANDBOARD.img.xz) = 9a3fc584ffeae7e6ece4abbe82dbf8aa2f681b5c1b10df8df87b1ad236009349 o 11.1-BETA2 aarch64 GENERIC: SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64-memstick.img) = fd1012f5b970106d8ab86fa5d7be500e0f69d756dffbab108f5286a689bad0c100b41f3503579e25b19c572fcaf64908d8726feade26c01b20f979e0c2f4cc51 SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64-memstick.img.xz) = 2e17cad16f40cbe80595e207af280a9230c5869c574faf4b9cddfed4333ba1aaf1a8071ae102b637d28a198be5d0403826b8124ae5dea7f3912b90c90e554cae SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64-mini-memstick.img) = 3f13b822c25d28b5b8c0fe5ca0b629e9e6abf01945ccc9d035c2349939b123e1c62d642c7fa83410ac2bd3802c2794794384808871b7ee33b3a04b55e283ca81 SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64-mini-memstick.img.xz) = 6e8d28cab2c79296ece55a17626567e6798b058d10ada10e72a0f03426b26c11cb0fbdf5e0c7f18fc495dbcb7ea28f374ee308bbf2f9756b4e9daccf93585a0d SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64-memstick.img) = b34a121fd43a8d40fb33f09f04248654c4d7eaf367f7208100325c1e32d022df SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64-memstick.img.xz) = 3b9a3bf72b2020997bcde7e098856c77bb18eabd10ef6c96ac126aac954c7d39 SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64-mini-memstick.img) = 074d1ad7811f504fda4b41f0625d6f2eacb3c853cb4759e485b19d2079eda2b0 SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64-mini-memstick.img.xz) = 6db651b4f423aab9a74af2012a207802d2f7344ca2cae9e11c4e1cb5b70b8d62 == VM IMAGE CHECKSUMS == o 11.1-BETA2 amd64: SHA512 (FreeBSD-11.1-BETA2-amd64.qcow2.xz) = 4e1fe8166cab8d1f7884bd1aba39af8a3ad33c21645c25bf0b9f855fd8734db0bbaa9866a434b77c38e7994c502ee9e1e692101800b52367ed125ddc0b864111 SHA512 (FreeBSD-11.1-BETA2-amd64.raw.xz) = 4b658e23b0f66ccc42ca63575708b9bd34deaf14c76c866931fb416f1b95d90734c33e1d8b6cdf4e43955dd03e92ef831c06571f7c96695b6eecc9e4160ca2e5 SHA512 (FreeBSD-11.1-BETA2-amd64.vhd.xz) = d62bce2f0b5c0833095d2a500a765838a10c7671a6353d02d9f645628a13bfa94ad1457b1e48d6688323b745f5faf859575df1529f8c7ba84acdacc3762fcc34 SHA512 (FreeBSD-11.1-BETA2-amd64.vmdk.xz) = 64f7298daf91fa27ca5bf9f1d2d1e2b1a21fcc82e6be25b9381cc6fd4c55fe3b43b2d4040d60e90e894f1ece4d530ac9bfd8345c39d0bf28b9a3ab436b7daf19 SHA256 (FreeBSD-11.1-BETA2-amd64.qcow2.xz) = eadf0a2c91feb50231a1070cab2d279111bd7129d1980ed14849850ce6120f5d SHA256 (FreeBSD-11.1-BETA2-amd64.raw.xz) = 47cce5e6edee8978ba071be295407b779bdc4f9ea87242cf7f98ae5eaa7ec242 SHA256 (FreeBSD-11.1-BETA2-amd64.vhd.xz) = b14f4ff24de620cbb33be6f62b75fb589d63c1296e8c3b048e303e0d85044948 SHA256 (FreeBSD-11.1-BETA2-amd64.vmdk.xz) = ff10b5c09da125b5820d95c53ce7d1aeeb64d602ca7d92f017c141fcf0d34082 o 11.1-BETA2 i386: SHA512 (FreeBSD-11.1-BETA2-i386.qcow2.xz) = 8934efc9206773f8ab661036bede0016bd710d356787c6223c9400ea0f1d689a8cc6c8bcc8b85a59eeb13ab5bbb6b32e4081df471292daf716ae0a69315a14dc SHA512 (FreeBSD-11.1-BETA2-i386.raw.xz) = 780d0e9da57a6dc0b1098b0b8d6725c5acee8865b192348ec935d8292e3f06f9bbcfee823233d24dc1499adf0dd92618e04739b82f5da96d634817d28fc5a960 SHA512 (FreeBSD-11.1-BETA2-i386.vhd.xz) = e2d192290e1d6a0157b6d8b4cfb98ffc45bd8a5bee03d49d35665c825911520c642cdbdbb5a3c312f0706858c83c227577fcf5bbb02aebb27bde00ba199b8acf SHA512 (FreeBSD-11.1-BETA2-i386.vmdk.xz) = 457f46cc0b8d7248e246b2133960c59a5e35b44ae3e6c4259918200356fa8a21ac1a970cb4997ac862903253b7815dfd2e7b6ec455245ab92dc9758d3ebe5cf3 SHA256 (FreeBSD-11.1-BETA2-i386.qcow2.xz) = 6fa2248ce50e6f257c338334a03200cd4bd3576cc94bd17616711561061d569a SHA256 (FreeBSD-11.1-BETA2-i386.raw.xz) = 40c194e5a86ecf87081deb700c2442b577a9c66f108f3ac0c813f1f9b9fdc6e0 SHA256 (FreeBSD-11.1-BETA2-i386.vhd.xz) = e04843065db409a1e288cc1e662bc2140cfd2490daa3541e3888a6cd468f870d SHA256 (FreeBSD-11.1-BETA2-i386.vmdk.xz) = e219da1751f5a5cb0cb7f0fab509ea042b7e7fcec7e430b0fd8250c1899acdbb o 11.1-BETA2 aarch64: SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64.qcow2.xz) = 834d679f268d235e9c4e586ce67f46b82b769fea3e09519ad67089db786e038004cf0875b0c3e0ff61eaee308da8fff8acaf3c685a7cccc11f52bd4e7dcf5456 SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64.raw.xz) = d07ca78bd4aa343730b9cf0d19671f96f3c8bf46ed46252d059e9f71e79db6dba1e4d1c0f85d097d4325f5795950997b80922538bbcd15630aac139625904716 SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64.vhd.xz) = 762372bcdc5f6a5090d56c504934ef09f76fc0ce9b1c2e0edee8cd3e33baa419ec1992fe9534ce817f3e77f1f2ec96d5f56b86ddbf0b02cab57f94dcdd7e3add SHA512 (FreeBSD-11.1-BETA2-arm64-aarch64.vmdk.xz) = 368782a9be547749c748443db9e3aa775d7c861b105ce8ffb00b9db4456f8e22ea3c1f3402627bfe754712a1217dd952d0a8747adcc7c003105abde9d26a1db3 SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64.qcow2.xz) = 2d6af1f2b988b13da1d2a478b8c1f65d0d2d687684419e3ab79e213bf3fbb86e SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64.raw.xz) = a12890fa8d3de5d1a9aca4ec5bec651a21cb0937186757cbbdc63e970be75272 SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64.vhd.xz) = d4d8177e4a99e5f79ebb12c459df978661e4064780f031099e1eebed26b56235 SHA256 (FreeBSD-11.1-BETA2-arm64-aarch64.vmdk.xz) = db254c88ae5409be549aa70e85f9d11e4d8463e8d766b9636daddd73a49bbd66 Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAllFYqgACgkQAxRYpUeP 4pPUog//ZV5MKhDtH8DI5Dz+FZo9KHgtWrNfNsshhqjLkzkPOI7JhGPsgt95VAOF x9s7/dSSi23X1JxlaC2i1RMO8cGUGIt8t7PrQ+pO60FsZPbKSHeVw+cNJj6L55Do khp+FPMoj1NKHBkUzDkj5c7yNQ54R6Hs5q1n8wRhJg7uREJUk4Pq2/sXAmO3Vu2b dKN56zng3Rlf36V06zNWKZkkJ3Z/jH7TAhweUNOyz4ZQ348vEv6kpMbyw/it15ka 8EfXPZk0LDwLR+Bu8/UkwbV1zRQsTar1WWjhkLLxRVOKzTnpYmda5vAeoK8Y70OA F9MLCBDx7HMzxKZGI6X+pfDe7sgyIM2CrXWZA63Npw+dkjp7erXk9YfvjwULRpny f+EFmxK1T7gWpDYtO3UQ6JFe7P/xI8RYFvpwKuQT3ESsMClufUYKwWtVKlyeMbFC RNNvFnKb4wP8+s3CnRgswSC04120vOrY6ulc0pBWNVrRjPKIybJFIzqgb+yw81Hz B6JlGBzhKIEZu3i1dUxIriU149tEx6b6RngFZaT5DBCcovU3Ux9NC24qWrQPGoPr oViYjASctAXQm19dXICZaB07evylbFFe7Y2hKW99qPfexJVanu7Jvpf8izdUnxMW DOjNuLPslgGO+ZhwMfOkmd92zUqOnAemgZ1m+2GHmWG6+dL3Q0s= =tsAf -----END PGP SIGNATURE-----