From owner-svn-src-head@freebsd.org Tue Sep 3 14:06:40 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DC34CDCC38; Tue, 3 Sep 2019 14:06:35 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N7zb1zDqz4Pj6; Tue, 3 Sep 2019 14:06:35 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 49EC81A8AA; Tue, 3 Sep 2019 14:06:12 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 2588C4D38; Tue, 9 Apr 2019 21:48:02 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1A383EF3; Tue, 9 Apr 2019 21:48:01 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1F8564CCC; Tue, 9 Apr 2019 21:48:01 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id A4DF04CC5; Tue, 9 Apr 2019 21:47:58 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from ecc05.stack.nl (ws0.zlo.nu [190.2.135.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EBD683EE7; Tue, 9 Apr 2019 21:47:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mail02.stack.nl (blade.stack.nl [51.15.111.152]) by ecc05.stack.nl (Postfix) with ESMTPS id 2436F100F73; Tue, 9 Apr 2019 21:47:47 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail02.stack.nl (Postfix) with ESMTP id 024F0240FD7; Tue, 9 Apr 2019 21:47:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail02 Received: from mail02.stack.nl ([127.0.0.1]) by localhost (mail02.stack.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGXvYWEm2_mo; Tue, 9 Apr 2019 21:47:44 +0000 (UTC) Received: from blade.stack.nl (blade.stack.nl [192.168.122.130]) by mail02.stack.nl (Postfix) with ESMTP id 3A6A2240FD4; Tue, 9 Apr 2019 21:47:44 +0000 (UTC) Received: by blade.stack.nl (Postfix, from userid 1677) id 12C08211C5; Tue, 9 Apr 2019 23:47:44 +0200 (CEST) From: Jilles Tjoelker To: Chris Rees Cc: rgrimes@freebsd.org, "Rodney W. Grimes" , Chris Rees , Andriy Gapon , "O. Hartmann" , Chris Rees , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5 Message-ID: <20190409214743.GA9621@stack.nl> References: <201904092108.x39L8ZCG062247@gndrsh.dnsmgr.net> <2B336327-528C-4E16-AA5D-B3497B1941D0@bayofrum.net> <95242E98-E578-476E-AFA6-099F00AF50BC@bayofrum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95242E98-E578-476E-AFA6-099F00AF50BC@bayofrum.net> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 4B1A383EF3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-Mailman-Approved-At: Sat, 12 Oct 2019 23:41:31 +0000 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:06:41 -0000 X-Original-Date: Tue, 9 Apr 2019 23:47:44 +0200 X-List-Received-Date: Tue, 03 Sep 2019 14:06:41 -0000 On Tue, Apr 09, 2019 at 10:24:16PM +0100, Chris Rees wrote: > On 9 April 2019 22:13:29 BST, Chris Rees wrote: > >On 9 April 2019 22:08:35 BST, "Rodney W. Grimes" > > wrote: > >>> On 09/04/2019 20:59, Chris Rees wrote: > >>> > On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" > >> wrote: > >>> >>> On 09/04/2019 21:33, Rodney W. Grimes wrote: > >>> >>>> I think the trigger issue is: > >>> >>>> grep zfs /etc/rc.d/zvol > >>> >>>> rcvar="zfs_enable" > >>> >>>> required_modules="zfs" > >>> >>>> that module requires may be going south with the > >>> >>>> new code when the module is built into the kernel. > >>> >>> Maybe it's because the module's name is zfsctrl (for whatever > >>reason) > >>> >> while the > >>> >>> module file is named zfs.ko. > >>> >> I suspect that could also lead to issues with the new code. > >>> >> It seems to be failing to detect that zfs is infact functional in > >>the > >>> >> kernel, > >>> >> and blindly, or not so blindly, trying to load zfs,ko, which when > >>you > >>> >> build > >>> >> it into the kernel you usually do so without any modules built, > >so > >>> >> there is > >>> >> no /boot/kernel/zfs.ko, and even if you did build it any attempt > >>to > >>> >> load > >>> >> it would return an error. > >>> > Loading with it built in isn't a problem, as I showed earlier. > >>> > Loading when it doesn't exist *is*. > >>> > I'm torn. Either we could revert this, or add a check to the > >>required_modules function instead, which I think is the better solution. > >>> Hang on, > >>> [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes > >>> yes > >>I think your testing the return value of sudo here? > >Sudo returns the child's return value. > Turns out Oliver had also reported this to current@ with a log > https://lists.freebsd.org/pipermail/freebsd-current/2019-April/073148.html > Jilles@, mind if I revert this while I get some testing on this > scenario done? > It seems to me that zfs may not be included in the kernel, just > zfsctrl, or something like that. It seems like kldload -n does not work as expected for zfs, so reverting seems the right approach. -- Jilles Tjoelker