svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5

[Chris Rees]

On 09/04/2019 20:59, Chris Rees wrote:
> On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" <freebsd at 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 at pegasus]~% sudo kldload -n zfsctrl && echo yes
yes

[crees at pegasus]~% find /boot -name zfsctrl\*
[crees at 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.