On 9 April 2019 22:08:35 BST, "Rodney W. Grimes" <free...@gndrsh.dnsmgr.net>
wrote:
>> On 09/04/2019 20:59, Chris Rees wrote:
>> > On 9 April 2019 20:55:07 BST, "Rodney W. Grimes"
><free...@gndrsh.dnsmgr.net> 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.
Chris
>> [crees@pegasus]~% find /boot -name zfsctrl\*
>> [crees@pegasus]~%
>>
>> I think that, rather than speculating, we should wait for Oliver to
>> confirm that this is actually the problem, because I still don't
>think
>> it is.
>>
>> Chris
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
