Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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? > [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. > > -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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. Do you have a static linked zfs in your kernel without a zfs.ko in /boot? kldstat | grep zfs > > Chris > > >> [crees@pegasus]~% find /boot -name zfsctrl\* find /boot -name zfs the module file is called zfs.ko > >> [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 -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hi again, 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. Chris -- 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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 [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. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> Hey,
>
> On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
> >On Sun, 7 Apr 2019 18:31:45 + (UTC)
> >Chris Rees wrote:
> >
> >> Author: crees (doc,ports committer)
> >> Date: Sun Apr 7 18:31:45 2019
> >> New Revision: 346017
> >> URL: https://svnweb.freebsd.org/changeset/base/346017
> >>
> >> Log:
> >> Remove now unnecessary kldstat check before attempting to load
> >modules.
> >>
> >> Since r233109, kldload has the -n option, which silently ignores
> >options
> >> that are already loaded.
> >>
> >>
> >https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
> >>
> >> Note that this script no longer reports if the module is already
> >loaded,
> >> but it could be argued this wasn't particularly useful information.
> >>
> >> PR: docs/234248
> >> Reviewed by: bcr (docs), kib, rgrimes (visual)
> >> Approved by: jilles
> >> Differential Revision: https://reviews.freebsd.org/D18670
> >>
> >> Modified:
> >> head/libexec/rc/rc.d/abi
> >> head/libexec/rc/rc.d/bthidd
> >> head/libexec/rc/rc.d/cfumass
> >> head/libexec/rc/rc.d/kld
> >> head/libexec/rc/rc.d/mdconfig
> >> head/libexec/rc/rc.d/mdconfig2
> >> head/libexec/rc/rc.d/mountcritremote
> >> head/libexec/rc/rc.d/syscons
> >> head/libexec/rc/rc.subr
> >> head/share/man/man5/rc.conf.5
> >>
> >> Modified: head/libexec/rc/rc.d/abi
> >>
> >==
>
>
> {Snip}
>
>
> >It seems this patch breaks ZFS if ZFS is built-in kernel!
> >
> >Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
> >volume
> >at boot time, rendering servers unusable.
> >Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
> >filesystems as
> >expected.
> >
>
> Are you sure it's this causing that? Please try reverting it.
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.
> Chris
--
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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. Ultimately at this time it is your decision, my personal mode of operation is when an unforseen bug comes up in something I did it is to revert, work on the issue until I am confident it is addressed, and addressed without adding any addition issue, then revert the revert and apply the fix. > Chris -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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. Chris -- 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hey,
On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
>On Sun, 7 Apr 2019 18:31:45 + (UTC)
>Chris Rees wrote:
>
>> Author: crees (doc,ports committer)
>> Date: Sun Apr 7 18:31:45 2019
>> New Revision: 346017
>> URL: https://svnweb.freebsd.org/changeset/base/346017
>>
>> Log:
>> Remove now unnecessary kldstat check before attempting to load
>modules.
>>
>> Since r233109, kldload has the -n option, which silently ignores
>options
>> that are already loaded.
>>
>>
>https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>>
>> Note that this script no longer reports if the module is already
>loaded,
>> but it could be argued this wasn't particularly useful information.
>>
>> PR:docs/234248
>> Reviewed by: bcr (docs), kib, rgrimes (visual)
>> Approved by: jilles
>> Differential Revision: https://reviews.freebsd.org/D18670
>>
>> Modified:
>> head/libexec/rc/rc.d/abi
>> head/libexec/rc/rc.d/bthidd
>> head/libexec/rc/rc.d/cfumass
>> head/libexec/rc/rc.d/kld
>> head/libexec/rc/rc.d/mdconfig
>> head/libexec/rc/rc.d/mdconfig2
>> head/libexec/rc/rc.d/mountcritremote
>> head/libexec/rc/rc.d/syscons
>> head/libexec/rc/rc.subr
>> head/share/man/man5/rc.conf.5
>>
>> Modified: head/libexec/rc/rc.d/abi
>>
>==
{Snip}
>It seems this patch breaks ZFS if ZFS is built-in kernel!
>
>Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
>volume
>at boot time, rendering servers unusable.
>Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
>filesystems as
>expected.
>
Are you sure it's this causing that? Please try reverting it.
Chris
--
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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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. > -- > Andriy Gapon -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On 09/04/2019 23:08, Chris Rees wrote: > [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes > yes > > [crees@pegasus]~% find /boot -name zfsctrl\* > [crees@pegasus]~% I am not sure what was your point, but here are some thoughts (or food for thought). 1. As I mentioned earlier, ZFS has this duality where a loadable file is called zfs.ko, but the actual module is called zfsctrl 2. 'kldload -n zfsctrl' should work if ZFS is already present (either in the kernel or because zfs.ko is loaded) because zfsctlr is the module name 3. I don't know if 'kldload -n zfsctrl' would work if ZFS is not loaded, because I am not sure if kldload is able to figure out that zfsctlrl can be found in zfs.ko. 4. In any case, /etc/rc.d/zfs has required_modules="zfs". So, the above is moot unless you replace "zfs" with "zfsctrl". And then, it may or may not work depending on #3. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
[ Charset UTF-8 unsupported, converting... ]
> Hi Rod,
>
> On 09/04/2019 19:33, Rodney W. Grimes wrote:
> >> Hey,
> >>
> >> On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
> >>> On Sun, 7 Apr 2019 18:31:45 + (UTC)
> >>> Chris Rees wrote:
> >>>
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load
> >>> modules.
> Since r233109, kldload has the -n option, which silently ignores
> >>> options
> that are already loaded.
>
>
> >>> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
> Note that this script no longer reports if the module is already
> >>> loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
> Reviewed by: bcr (docs), kib, rgrimes (visual)
> Approved by: jilles
> Differential Revision:https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
>
> >>> ==
> >>
> >> {Snip}
> >>
> >>
> >>> It seems this patch breaks ZFS if ZFS is built-in kernel!
> >>>
> >>> Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
> >>> volume
> >>> at boot time, rendering servers unusable.
> >>> Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
> >>> filesystems as
> >>> expected.
> >>>
> >> Are you sure it's this causing that? Please try reverting it.
> > 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.
>
>
> I wondered that, but I don't think so.
>
> [crees@pegasus]~% kldstat -v |head
> Id Refs Address??? Size Name
> ?1?? 30 0x8020 11df240? kernel (/boot/kernel.PEGASUS/kernel)
> ??? Contains modules:
> ??? Id Name
> ??? 227 newreno
> ??? 215 if_lo
> ??? 229 ipsec
> ??? 228 mld
> ??? 226 igmp
> ??? 201 elf32
> [crees@pegasus]~% sudo kldload ipsec
> kldload: can't load ipsec: module already loaded or in kernel
> [crees@pegasus]~% sudo kldload -n ipsec
> [crees@pegasus]~% echo $?
> 0
> [crees@pegasus]~%
>
> The required_modules code calls load_kld, which uses kldload -n. This
> always returns true... unless Oliver has removed the zfs module from
> /boot/kernel perhaps?
He explicitly stated he is running with ZFS compiled into
his kernel, in that situation there well be
no /boot/kernel/zfs.ko file.
--
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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. 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hi Rod,
On 09/04/2019 19:33, Rodney W. Grimes wrote:
Hey,
On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
On Sun, 7 Apr 2019 18:31:45 + (UTC)
Chris Rees wrote:
Author: crees (doc,ports committer)
Date: Sun Apr 7 18:31:45 2019
New Revision: 346017
URL: https://svnweb.freebsd.org/changeset/base/346017
Log:
Remove now unnecessary kldstat check before attempting to load
modules.
Since r233109, kldload has the -n option, which silently ignores
options
that are already loaded.
https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
Note that this script no longer reports if the module is already
loaded,
but it could be argued this wasn't particularly useful information.
PR: docs/234248
Reviewed by: bcr (docs), kib, rgrimes (visual)
Approved by: jilles
Differential Revision: https://reviews.freebsd.org/D18670
Modified:
head/libexec/rc/rc.d/abi
head/libexec/rc/rc.d/bthidd
head/libexec/rc/rc.d/cfumass
head/libexec/rc/rc.d/kld
head/libexec/rc/rc.d/mdconfig
head/libexec/rc/rc.d/mdconfig2
head/libexec/rc/rc.d/mountcritremote
head/libexec/rc/rc.d/syscons
head/libexec/rc/rc.subr
head/share/man/man5/rc.conf.5
Modified: head/libexec/rc/rc.d/abi
==
{Snip}
It seems this patch breaks ZFS if ZFS is built-in kernel!
Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
volume
at boot time, rendering servers unusable.
Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
filesystems as
expected.
Are you sure it's this causing that? Please try reverting it.
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.
I wondered that, but I don't think so.
[crees@pegasus]~% kldstat -v |head
Id Refs Address Size Name
1 30 0x8020 11df240 kernel (/boot/kernel.PEGASUS/kernel)
Contains modules:
Id Name
227 newreno
215 if_lo
229 ipsec
228 mld
226 igmp
201 elf32
[crees@pegasus]~% sudo kldload ipsec
kldload: can't load ipsec: module already loaded or in kernel
[crees@pegasus]~% sudo kldload -n ipsec
[crees@pegasus]~% echo $?
0
[crees@pegasus]~%
The required_modules code calls load_kld, which uses kldload -n. This
always returns true... unless Oliver has removed the zfs module from
/boot/kernel perhaps?
Chris
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hey, On 7 April 2019 22:14:56 BST, Oliver Pinter wrote: >On Sunday, April 7, 2019, Chris Rees wrote: > >> Author: crees (doc,ports committer) >> Date: Sun Apr 7 18:31:45 2019 >> New Revision: 346017 >> URL: https://svnweb.freebsd.org/changeset/base/346017 >> >> Log: >> Remove now unnecessary kldstat check before attempting to load >modules. >> >> Since r233109, kldload has the -n option, which silently ignores >options >> that are already loaded. >> >> >https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html >> >> Note that this script no longer reports if the module is already >loaded, >> but it could be argued this wasn't particularly useful information. >> >> PR: docs/234248 > > >This is why a docs PR? Followup from that PR. >> Reviewed by: bcr (docs), kib, rgrimes (visual) > > >I haven't seen kib on the reviewers list. Please refer to the conversation on freebsd-rc that I linked in the commit message. Chris -- 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On Sun, 7 Apr 2019 18:31:45 + (UTC)
Chris Rees wrote:
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load modules.
>
> Since r233109, kldload has the -n option, which silently ignores options
> that are already loaded.
>
> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>
> Note that this script no longer reports if the module is already loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
> Reviewed by:bcr (docs), kib, rgrimes (visual)
> Approved by:jilles
> Differential Revision: https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
> ==
> --- head/libexec/rc/rc.d/abi Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/abi Sun Apr 7 18:31:45 2019(r346017)
> @@ -27,10 +27,10 @@ linux_start()
> local _tmpdir
>
> echo -n ' linux'
> - load_kld -e 'linux(aout|elf)' linux
> + load_kld linux
> case `sysctl -n hw.machine_arch` in
> amd64)
> - load_kld -e 'linux64elf' linux64
> + load_kld linux64
> ;;
> esac
> if [ -x /compat/linux/sbin/ldconfigDisabled ]; then
>
> Modified: head/libexec/rc/rc.d/bthidd
> ==
> --- head/libexec/rc/rc.d/bthidd Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/bthidd Sun Apr 7 18:31:45
> 2019 (r346017) @@ -34,11 +34,11 @@ evdev_enabled()
> bthidd_prestart()
> {
> if evdev_enabled; then
> - load_kld -m uinput uinput
> + load_kld uinput
> fi
> - load_kld -m kbdmux kbdmux
> - load_kld -m vkbd vkbd
> - load_kld -m ng_btsocket ng_btsocket
> + load_kld kbdmux
> + load_kld vkbd
> + load_kld ng_btsocket
> return 0
> }
>
>
> Modified: head/libexec/rc/rc.d/cfumass
> ==
> --- head/libexec/rc/rc.d/cfumass Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/cfumassSun Apr 7 18:31:45
> 2019 (r346017) @@ -75,7 +75,7 @@ cfumass_start()
> return "${err}"
> fi
>
> - load_kld -e cfumass cfumass
> + load_kld cfumass
>
> # If the template is already switched to Mass Storage, then reset
> # it to -1 to force the host to reenumerate it; otherwise it might
>
> Modified: head/libexec/rc/rc.d/kld
> ==
> --- head/libexec/rc/rc.d/kld Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/kld Sun Apr 7 18:31:45 2019(r346017)
> @@ -46,7 +46,7 @@ kld_start()
>
> echo 'Loading kernel modules:'
> for _kld in $kld_list ; do
> - load_kld -e ${_kld}.ko $_kld
> + load_kld $_kld
> done
> }
>
>
> Modified: head/libexec/rc/rc.d/mdconfig
> ==
> --- head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:31:45
> 2019 (r346017) @@ -114,7 +114,7 @@ mdconfig_start()
> continue
> fi
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip ||
> return 3
> + load_kld geom_uzip || return 3
> # sleep a bit to allow creation
> of /dev/mdX.uzip sleep 2
> fi
>
> Modified: head/libexec/rc/rc.d/mdconfig2
> ==
> --- head/libexec/rc/rc.d/mdconfig2Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/mdconfig2 Sun Apr 7 18:31:45
> 2019 (r346017) @@ -123,7 +123,7 @@ mdconfig2_start()
> # been created.
> if [ "${_type}" = "vnode" -a "${_fs}" != "/" ]; then
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip || return 3
> + load_kld geom_uzip || return 3
> fi
> if is_readonly ${_fs}; then
>
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On Sunday, April 7, 2019, Chris Rees wrote:
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load modules.
>
> Since r233109, kldload has the -n option, which silently ignores options
> that are already loaded.
>
> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>
> Note that this script no longer reports if the module is already loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
This is why a docs PR?
> Reviewed by: bcr (docs), kib, rgrimes (visual)
I haven't seen kib on the reviewers list.
> Approved by: jilles
> Differential Revision:https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
>
> ==
> --- head/libexec/rc/rc.d/abiSun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/abiSun Apr 7 18:31:45 2019(r346017)
> @@ -27,10 +27,10 @@ linux_start()
> local _tmpdir
>
> echo -n ' linux'
> - load_kld -e 'linux(aout|elf)' linux
> + load_kld linux
> case `sysctl -n hw.machine_arch` in
> amd64)
> - load_kld -e 'linux64elf' linux64
> + load_kld linux64
> ;;
> esac
> if [ -x /compat/linux/sbin/ldconfigDisabled ]; then
>
> Modified: head/libexec/rc/rc.d/bthidd
>
> ==
> --- head/libexec/rc/rc.d/bthidd Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/bthidd Sun Apr 7 18:31:45 2019(r346017)
> @@ -34,11 +34,11 @@ evdev_enabled()
> bthidd_prestart()
> {
> if evdev_enabled; then
> - load_kld -m uinput uinput
> + load_kld uinput
> fi
> - load_kld -m kbdmux kbdmux
> - load_kld -m vkbd vkbd
> - load_kld -m ng_btsocket ng_btsocket
> + load_kld kbdmux
> + load_kld vkbd
> + load_kld ng_btsocket
> return 0
> }
>
>
> Modified: head/libexec/rc/rc.d/cfumass
>
> ==
> --- head/libexec/rc/rc.d/cfumassSun Apr 7 18:24:26 2019
> (r346016)
> +++ head/libexec/rc/rc.d/cfumassSun Apr 7 18:31:45 2019
> (r346017)
> @@ -75,7 +75,7 @@ cfumass_start()
> return "${err}"
> fi
>
> - load_kld -e cfumass cfumass
> + load_kld cfumass
>
> # If the template is already switched to Mass Storage, then reset
> # it to -1 to force the host to reenumerate it; otherwise it might
>
> Modified: head/libexec/rc/rc.d/kld
>
> ==
> --- head/libexec/rc/rc.d/kldSun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/kldSun Apr 7 18:31:45 2019(r346017)
> @@ -46,7 +46,7 @@ kld_start()
>
> echo 'Loading kernel modules:'
> for _kld in $kld_list ; do
> - load_kld -e ${_kld}.ko $_kld
> + load_kld $_kld
> done
> }
>
>
> Modified: head/libexec/rc/rc.d/mdconfig
>
> ==
> --- head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:24:26 2019
> (r346016)
> +++ head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:31:45 2019
> (r346017)
> @@ -114,7 +114,7 @@ mdconfig_start()
> continue
> fi
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip ||
> return 3
> + load_kld geom_uzip || return 3
> # sleep a bit to allow creation of
> /dev/mdX.uzip
> sleep 2
> fi
>
> Modified: head/libexec/rc/rc.d/mdconfig2
>
> ==
> --- head/libexec/rc/rc.d/mdconfig2 Sun Apr 7 18:24:26 2019
> (r346016)
> +++ head/libexec/rc/rc.d/mdconfig2 Sun Apr 7 18:31:45 2019
> (r346017)
> @@ -123,7 +123,7 @@ mdconfig2_start()
> # been created.
> if [ "${_type}" = "vnode" -a "${_fs}" != "/" ]; then
> if [ "${_file}" !=
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On 09/04/2019 23:08, Chris Rees wrote: > [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes > yes > > [crees@pegasus]~% find /boot -name zfsctrl\* > [crees@pegasus]~% I am not sure what was your point, but here are some thoughts (or food for thought). 1. As I mentioned earlier, ZFS has this duality where a loadable file is called zfs.ko, but the actual module is called zfsctrl 2. 'kldload -n zfsctrl' should work if ZFS is already present (either in the kernel or because zfs.ko is loaded) because zfsctlr is the module name 3. I don't know if 'kldload -n zfsctrl' would work if ZFS is not loaded, because I am not sure if kldload is able to figure out that zfsctlrl can be found in zfs.ko. 4. In any case, /etc/rc.d/zfs has required_modules="zfs". So, the above is moot unless you replace "zfs" with "zfsctrl". And then, it may or may not work depending on #3. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hi again, 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. Chris -- 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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. Do you have a static linked zfs in your kernel without a zfs.ko in /boot? kldstat | grep zfs > > Chris > > >> [crees@pegasus]~% find /boot -name zfsctrl\* find /boot -name zfs the module file is called zfs.ko > >> [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 -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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? > [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. > > -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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. 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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 [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. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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. Ultimately at this time it is your decision, my personal mode of operation is when an unforseen bug comes up in something I did it is to revert, work on the issue until I am confident it is addressed, and addressed without adding any addition issue, then revert the revert and apply the fix. > Chris -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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. Chris -- 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> 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. > -- > Andriy Gapon -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
[ Charset UTF-8 unsupported, converting... ]
> Hi Rod,
>
> On 09/04/2019 19:33, Rodney W. Grimes wrote:
> >> Hey,
> >>
> >> On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
> >>> On Sun, 7 Apr 2019 18:31:45 + (UTC)
> >>> Chris Rees wrote:
> >>>
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load
> >>> modules.
> Since r233109, kldload has the -n option, which silently ignores
> >>> options
> that are already loaded.
>
>
> >>> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
> Note that this script no longer reports if the module is already
> >>> loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
> Reviewed by: bcr (docs), kib, rgrimes (visual)
> Approved by: jilles
> Differential Revision:https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
>
> >>> ==
> >>
> >> {Snip}
> >>
> >>
> >>> It seems this patch breaks ZFS if ZFS is built-in kernel!
> >>>
> >>> Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
> >>> volume
> >>> at boot time, rendering servers unusable.
> >>> Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
> >>> filesystems as
> >>> expected.
> >>>
> >> Are you sure it's this causing that? Please try reverting it.
> > 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.
>
>
> I wondered that, but I don't think so.
>
> [crees@pegasus]~% kldstat -v |head
> Id Refs Address??? Size Name
> ?1?? 30 0x8020 11df240? kernel (/boot/kernel.PEGASUS/kernel)
> ??? Contains modules:
> ??? Id Name
> ??? 227 newreno
> ??? 215 if_lo
> ??? 229 ipsec
> ??? 228 mld
> ??? 226 igmp
> ??? 201 elf32
> [crees@pegasus]~% sudo kldload ipsec
> kldload: can't load ipsec: module already loaded or in kernel
> [crees@pegasus]~% sudo kldload -n ipsec
> [crees@pegasus]~% echo $?
> 0
> [crees@pegasus]~%
>
> The required_modules code calls load_kld, which uses kldload -n. This
> always returns true... unless Oliver has removed the zfs module from
> /boot/kernel perhaps?
He explicitly stated he is running with ZFS compiled into
his kernel, in that situation there well be
no /boot/kernel/zfs.ko file.
--
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
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. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hi Rod,
On 09/04/2019 19:33, Rodney W. Grimes wrote:
Hey,
On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
On Sun, 7 Apr 2019 18:31:45 + (UTC)
Chris Rees wrote:
Author: crees (doc,ports committer)
Date: Sun Apr 7 18:31:45 2019
New Revision: 346017
URL: https://svnweb.freebsd.org/changeset/base/346017
Log:
Remove now unnecessary kldstat check before attempting to load
modules.
Since r233109, kldload has the -n option, which silently ignores
options
that are already loaded.
https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
Note that this script no longer reports if the module is already
loaded,
but it could be argued this wasn't particularly useful information.
PR: docs/234248
Reviewed by: bcr (docs), kib, rgrimes (visual)
Approved by: jilles
Differential Revision: https://reviews.freebsd.org/D18670
Modified:
head/libexec/rc/rc.d/abi
head/libexec/rc/rc.d/bthidd
head/libexec/rc/rc.d/cfumass
head/libexec/rc/rc.d/kld
head/libexec/rc/rc.d/mdconfig
head/libexec/rc/rc.d/mdconfig2
head/libexec/rc/rc.d/mountcritremote
head/libexec/rc/rc.d/syscons
head/libexec/rc/rc.subr
head/share/man/man5/rc.conf.5
Modified: head/libexec/rc/rc.d/abi
==
{Snip}
It seems this patch breaks ZFS if ZFS is built-in kernel!
Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
volume
at boot time, rendering servers unusable.
Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
filesystems as
expected.
Are you sure it's this causing that? Please try reverting it.
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.
I wondered that, but I don't think so.
[crees@pegasus]~% kldstat -v |head
Id Refs Address Size Name
1 30 0x8020 11df240 kernel (/boot/kernel.PEGASUS/kernel)
Contains modules:
Id Name
227 newreno
215 if_lo
229 ipsec
228 mld
226 igmp
201 elf32
[crees@pegasus]~% sudo kldload ipsec
kldload: can't load ipsec: module already loaded or in kernel
[crees@pegasus]~% sudo kldload -n ipsec
[crees@pegasus]~% echo $?
0
[crees@pegasus]~%
The required_modules code calls load_kld, which uses kldload -n. This
always returns true... unless Oliver has removed the zfs module from
/boot/kernel perhaps?
Chris
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> Hey,
>
> On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
> >On Sun, 7 Apr 2019 18:31:45 + (UTC)
> >Chris Rees wrote:
> >
> >> Author: crees (doc,ports committer)
> >> Date: Sun Apr 7 18:31:45 2019
> >> New Revision: 346017
> >> URL: https://svnweb.freebsd.org/changeset/base/346017
> >>
> >> Log:
> >> Remove now unnecessary kldstat check before attempting to load
> >modules.
> >>
> >> Since r233109, kldload has the -n option, which silently ignores
> >options
> >> that are already loaded.
> >>
> >>
> >https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
> >>
> >> Note that this script no longer reports if the module is already
> >loaded,
> >> but it could be argued this wasn't particularly useful information.
> >>
> >> PR: docs/234248
> >> Reviewed by: bcr (docs), kib, rgrimes (visual)
> >> Approved by: jilles
> >> Differential Revision: https://reviews.freebsd.org/D18670
> >>
> >> Modified:
> >> head/libexec/rc/rc.d/abi
> >> head/libexec/rc/rc.d/bthidd
> >> head/libexec/rc/rc.d/cfumass
> >> head/libexec/rc/rc.d/kld
> >> head/libexec/rc/rc.d/mdconfig
> >> head/libexec/rc/rc.d/mdconfig2
> >> head/libexec/rc/rc.d/mountcritremote
> >> head/libexec/rc/rc.d/syscons
> >> head/libexec/rc/rc.subr
> >> head/share/man/man5/rc.conf.5
> >>
> >> Modified: head/libexec/rc/rc.d/abi
> >>
> >==
>
>
> {Snip}
>
>
> >It seems this patch breaks ZFS if ZFS is built-in kernel!
> >
> >Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
> >volume
> >at boot time, rendering servers unusable.
> >Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
> >filesystems as
> >expected.
> >
>
> Are you sure it's this causing that? Please try reverting it.
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.
> Chris
--
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hey,
On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
>On Sun, 7 Apr 2019 18:31:45 + (UTC)
>Chris Rees wrote:
>
>> Author: crees (doc,ports committer)
>> Date: Sun Apr 7 18:31:45 2019
>> New Revision: 346017
>> URL: https://svnweb.freebsd.org/changeset/base/346017
>>
>> Log:
>> Remove now unnecessary kldstat check before attempting to load
>modules.
>>
>> Since r233109, kldload has the -n option, which silently ignores
>options
>> that are already loaded.
>>
>>
>https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>>
>> Note that this script no longer reports if the module is already
>loaded,
>> but it could be argued this wasn't particularly useful information.
>>
>> PR:docs/234248
>> Reviewed by: bcr (docs), kib, rgrimes (visual)
>> Approved by: jilles
>> Differential Revision: https://reviews.freebsd.org/D18670
>>
>> Modified:
>> head/libexec/rc/rc.d/abi
>> head/libexec/rc/rc.d/bthidd
>> head/libexec/rc/rc.d/cfumass
>> head/libexec/rc/rc.d/kld
>> head/libexec/rc/rc.d/mdconfig
>> head/libexec/rc/rc.d/mdconfig2
>> head/libexec/rc/rc.d/mountcritremote
>> head/libexec/rc/rc.d/syscons
>> head/libexec/rc/rc.subr
>> head/share/man/man5/rc.conf.5
>>
>> Modified: head/libexec/rc/rc.d/abi
>>
>==
{Snip}
>It seems this patch breaks ZFS if ZFS is built-in kernel!
>
>Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
>volume
>at boot time, rendering servers unusable.
>Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
>filesystems as
>expected.
>
Are you sure it's this causing that? Please try reverting it.
Chris
--
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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On Sun, 7 Apr 2019 18:31:45 + (UTC)
Chris Rees wrote:
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load modules.
>
> Since r233109, kldload has the -n option, which silently ignores options
> that are already loaded.
>
> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>
> Note that this script no longer reports if the module is already loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
> Reviewed by:bcr (docs), kib, rgrimes (visual)
> Approved by:jilles
> Differential Revision: https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
> ==
> --- head/libexec/rc/rc.d/abi Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/abi Sun Apr 7 18:31:45 2019(r346017)
> @@ -27,10 +27,10 @@ linux_start()
> local _tmpdir
>
> echo -n ' linux'
> - load_kld -e 'linux(aout|elf)' linux
> + load_kld linux
> case `sysctl -n hw.machine_arch` in
> amd64)
> - load_kld -e 'linux64elf' linux64
> + load_kld linux64
> ;;
> esac
> if [ -x /compat/linux/sbin/ldconfigDisabled ]; then
>
> Modified: head/libexec/rc/rc.d/bthidd
> ==
> --- head/libexec/rc/rc.d/bthidd Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/bthidd Sun Apr 7 18:31:45
> 2019 (r346017) @@ -34,11 +34,11 @@ evdev_enabled()
> bthidd_prestart()
> {
> if evdev_enabled; then
> - load_kld -m uinput uinput
> + load_kld uinput
> fi
> - load_kld -m kbdmux kbdmux
> - load_kld -m vkbd vkbd
> - load_kld -m ng_btsocket ng_btsocket
> + load_kld kbdmux
> + load_kld vkbd
> + load_kld ng_btsocket
> return 0
> }
>
>
> Modified: head/libexec/rc/rc.d/cfumass
> ==
> --- head/libexec/rc/rc.d/cfumass Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/cfumassSun Apr 7 18:31:45
> 2019 (r346017) @@ -75,7 +75,7 @@ cfumass_start()
> return "${err}"
> fi
>
> - load_kld -e cfumass cfumass
> + load_kld cfumass
>
> # If the template is already switched to Mass Storage, then reset
> # it to -1 to force the host to reenumerate it; otherwise it might
>
> Modified: head/libexec/rc/rc.d/kld
> ==
> --- head/libexec/rc/rc.d/kld Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/kld Sun Apr 7 18:31:45 2019(r346017)
> @@ -46,7 +46,7 @@ kld_start()
>
> echo 'Loading kernel modules:'
> for _kld in $kld_list ; do
> - load_kld -e ${_kld}.ko $_kld
> + load_kld $_kld
> done
> }
>
>
> Modified: head/libexec/rc/rc.d/mdconfig
> ==
> --- head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:31:45
> 2019 (r346017) @@ -114,7 +114,7 @@ mdconfig_start()
> continue
> fi
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip ||
> return 3
> + load_kld geom_uzip || return 3
> # sleep a bit to allow creation
> of /dev/mdX.uzip sleep 2
> fi
>
> Modified: head/libexec/rc/rc.d/mdconfig2
> ==
> --- head/libexec/rc/rc.d/mdconfig2Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/mdconfig2 Sun Apr 7 18:31:45
> 2019 (r346017) @@ -123,7 +123,7 @@ mdconfig2_start()
> # been created.
> if [ "${_type}" = "vnode" -a "${_fs}" != "/" ]; then
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip || return 3
> + load_kld geom_uzip || return 3
> fi
> if is_readonly ${_fs}; then
>
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hey, On 7 April 2019 22:14:56 BST, Oliver Pinter wrote: >On Sunday, April 7, 2019, Chris Rees wrote: > >> Author: crees (doc,ports committer) >> Date: Sun Apr 7 18:31:45 2019 >> New Revision: 346017 >> URL: https://svnweb.freebsd.org/changeset/base/346017 >> >> Log: >> Remove now unnecessary kldstat check before attempting to load >modules. >> >> Since r233109, kldload has the -n option, which silently ignores >options >> that are already loaded. >> >> >https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html >> >> Note that this script no longer reports if the module is already >loaded, >> but it could be argued this wasn't particularly useful information. >> >> PR: docs/234248 > > >This is why a docs PR? Followup from that PR. >> Reviewed by: bcr (docs), kib, rgrimes (visual) > > >I haven't seen kib on the reviewers list. Please refer to the conversation on freebsd-rc that I linked in the commit message. Chris -- 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-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On Sunday, April 7, 2019, Chris Rees wrote:
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load modules.
>
> Since r233109, kldload has the -n option, which silently ignores options
> that are already loaded.
>
> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>
> Note that this script no longer reports if the module is already loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
This is why a docs PR?
> Reviewed by: bcr (docs), kib, rgrimes (visual)
I haven't seen kib on the reviewers list.
> Approved by: jilles
> Differential Revision:https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
>
> ==
> --- head/libexec/rc/rc.d/abiSun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/abiSun Apr 7 18:31:45 2019(r346017)
> @@ -27,10 +27,10 @@ linux_start()
> local _tmpdir
>
> echo -n ' linux'
> - load_kld -e 'linux(aout|elf)' linux
> + load_kld linux
> case `sysctl -n hw.machine_arch` in
> amd64)
> - load_kld -e 'linux64elf' linux64
> + load_kld linux64
> ;;
> esac
> if [ -x /compat/linux/sbin/ldconfigDisabled ]; then
>
> Modified: head/libexec/rc/rc.d/bthidd
>
> ==
> --- head/libexec/rc/rc.d/bthidd Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/bthidd Sun Apr 7 18:31:45 2019(r346017)
> @@ -34,11 +34,11 @@ evdev_enabled()
> bthidd_prestart()
> {
> if evdev_enabled; then
> - load_kld -m uinput uinput
> + load_kld uinput
> fi
> - load_kld -m kbdmux kbdmux
> - load_kld -m vkbd vkbd
> - load_kld -m ng_btsocket ng_btsocket
> + load_kld kbdmux
> + load_kld vkbd
> + load_kld ng_btsocket
> return 0
> }
>
>
> Modified: head/libexec/rc/rc.d/cfumass
>
> ==
> --- head/libexec/rc/rc.d/cfumassSun Apr 7 18:24:26 2019
> (r346016)
> +++ head/libexec/rc/rc.d/cfumassSun Apr 7 18:31:45 2019
> (r346017)
> @@ -75,7 +75,7 @@ cfumass_start()
> return "${err}"
> fi
>
> - load_kld -e cfumass cfumass
> + load_kld cfumass
>
> # If the template is already switched to Mass Storage, then reset
> # it to -1 to force the host to reenumerate it; otherwise it might
>
> Modified: head/libexec/rc/rc.d/kld
>
> ==
> --- head/libexec/rc/rc.d/kldSun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/kldSun Apr 7 18:31:45 2019(r346017)
> @@ -46,7 +46,7 @@ kld_start()
>
> echo 'Loading kernel modules:'
> for _kld in $kld_list ; do
> - load_kld -e ${_kld}.ko $_kld
> + load_kld $_kld
> done
> }
>
>
> Modified: head/libexec/rc/rc.d/mdconfig
>
> ==
> --- head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:24:26 2019
> (r346016)
> +++ head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:31:45 2019
> (r346017)
> @@ -114,7 +114,7 @@ mdconfig_start()
> continue
> fi
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip ||
> return 3
> + load_kld geom_uzip || return 3
> # sleep a bit to allow creation of
> /dev/mdX.uzip
> sleep 2
> fi
>
> Modified: head/libexec/rc/rc.d/mdconfig2
>
> ==
> --- head/libexec/rc/rc.d/mdconfig2 Sun Apr 7 18:24:26 2019
> (r346016)
> +++ head/libexec/rc/rc.d/mdconfig2 Sun Apr 7 18:31:45 2019
> (r346017)
> @@ -123,7 +123,7 @@ mdconfig2_start()
> # been created.
> if [ "${_type}" = "vnode" -a "${_fs}" != "/" ]; then
> if [ "${_file}" !=
