Re: Plans for git (was: Please check the current beta git conversions)

[Warner Losh]

Steve,

I was wrong to freak out so badly at your suggestion. I can give you an
explanation for why but it was wrong for me to do so.

I thought that the doc was better than it was and so I couldn't understand
and flashed to anger rather than listening.

So even so, my tone is well below the standard I try to set for myself: so
it was doubly wrong. I've been doing it a lot this year, guess I'm not
coping as well as I thought with the times. It's no excuse, though, and I'm
sorry.

I felt bad about over-reacting so I came back to things fresh today. On
fresh reading, your suggestions are good ones. Very similar to the ones I
came to after spending some quality time trying to edit the document you'd
offered the suggestion to. The content and focus isn't quite right there. I
spent a couple hours trying to fix it, only to find myself in a dead end I
couldn't puzzle my way out of before quitting for the day... I'll give it
another try over the weekend or next week.

So please accept my apology for being a jerk, yelling at you in a truly
unprofessional way and screaming when I should really have been listening.
Again, anything I say by way of explanation doesn't justify it at all.

Warner

On Wed, Sep 2, 2020 at 11:11 AM Warner Losh  wrote:

>
>
> On Wed, Sep 2, 2020 at 10:47 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
>> On Wed, Sep 02, 2020 at 12:14:08PM -0400, Ed Maste wrote:
>> > On Wed, 2 Sep 2020 at 02:31, Steve Kargl
>> >  wrote:
>> > >
>> > > > A short intro on git for svn users:
>> > > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
>> > > >
>> > >
>> > > ROTFL.  From the "short intro", 2nd sentence.
>> > >
>> > > New committers are assumed to already be familiar with the basic
>> > > operation of Git.  If not, start by reading the Git Book.
>> >
>> > This doc started as a direct translation of the Subversion primer,
>> > which has as its first sentence:
>> > > New committers are assumed to already be familiar with the basic
>> operation of Subversion. If not, start by reading the Subversion Book.
>> >
>> > As with the Subversion primer the doc is intended to provide a quick
>> > reference for day-to-day commands, but not act as a reference or
>> > introduction to the entire theory of operation of the associated VCS.
>>
>> Like GCC, which did the svn to git dance at start of the year,
>> FreeBSD is throwing away a decade+ of corporate knowledge of
>> working with svn and /usr/src.  What is needed is a succinct
>> translation of the most common svn commands translated to git.
>>
>> Checking out /usr/src as u...@freebsd.org
>>
>>   svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
>>
>>   git ...
>>
>> Checking out /usr/src without freebsd.org account
>>
>>   svn checkout https://svn.freebsd.org/base/head ${HOME}/freebsd/src
>>
>>   git ...
>>
>> Creating diff against updated head.
>>
>>   svn update
>>   svn diff > patch.diff
>>
>>   git ...
>>
>> Adding a new file
>>
>>   svn add /usr/src/libm/msun/src/_s_sinpi.c
>>
>>   git ...
>>
>> Committing a change to /usr/src
>>
>>   svn update
>>   svn diff  | more (everyone does one last check, right?)
>>   svn commit 
>>
>>   git ...
>>
>
> This is an insultingly stupid comment to make. We don't need people to say
> the obvious.
>
> This sort of comment isn't helpful. People will just ignore you if you
> make too many of them like it.
>
> Warner
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: rfc: should extant TLS connections be closed when a CRL is updated?

[Rick Macklem]

John-Mark Gurney wrote:
>Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +:
>> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
>> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
>> However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
>> (Those would only be closed if the daemon is restarted.)
>>
>> I am now thinking that, maybe, an SSL_shutdown()/close() should be done on
>> all extant TCP connections using NFS over TLS when an updated CRL is loaded,
>> since a connection might have used a revoked certificate for its handshake.
>>
>> What do others think?
>
>IMO, this should scan the existing connections, and only shut them
>down if they are using a revoked Cert.  This is the correct way to
>do things.
Yes. I agree with you and Stefan that this is the way to go.
(When I test with a single client, I sometimes forget that there might be
 1000s of connections on a production server.)

>I do realize that this is likely not possible, and in reality, the
>ssl library in use should do this automatically, but likely does not.
>As the library likely does not, we should probably make this an
>option to close all connections upon CRL reload, with it being well
>documented.
Well, I haven't looked yet, but I suspect that there are lower level OpenSSL
library functions that can be used to read each entry from the CRL.

If I can do that, it is just comparing the Issuer and Serial# with the ones
associated with the connection (captured when the handshake is done).

So long as the lower level ssl library functions are not internal ones,
I am comfortable doing that. (It might make the code a little harder
to maintain, but I suspect what is in OpenSSL3 will be around for a while,
API wise?)

>Now that option should likely be set to default on, but documented
>such that if you do regular/often CRL reloads, that a user may want
>to turn that off if it's disruptive to their server.
I think this is the fallback, if I can't easily read the entries out of the CRL.

Thanks for the good comments (Stefan too), rick

--
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: bectl: cannot promote 'zroot/ROOT/r364030-OpenZFS2': not a cloned filesystem

[Graham Perrin]

On 30/08/2020 20:37, marco wrote:

…


However the boot fails dropping me to the mountroot prompt.

Luckily activating r364030-OpenZFS again is not a problem and the system will 
happily boot from that again after attempting to boot from r364030-OpenZFS2.

So now I have only 1 working BE and it feels a bit tricky to try an upgrade in 
place.
What's the best advice here?
I could switch back to base ZFS in this active BE, see if the system will be 
able to import zroot and mount all my datasets and boot, then try to create 
another BE using base ZFS and then attempt to update.


FYI 

>> sysutils/openzfs bectl activate … cannot promote … not a cloned 
filesystem … did not successfully activate boot environment


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: rfc: should extant TLS connections be closed when a CRL is updated?

[John-Mark Gurney]

Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +:
> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
> However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
> (Those would only be closed if the daemon is restarted.)
> 
> I am now thinking that, maybe, an SSL_shutdown()/close() should be done on
> all extant TCP connections using NFS over TLS when an updated CRL is loaded,
> since a connection might have used a revoked certificate for its handshake.
> 
> What do others think?

IMO, this should scan the existing connections, and only shut them
down if they are using a revoked Cert.  This is the correct way to
do things.

I do realize that this is likely not possible, and in reality, the
ssl library in use should do this automatically, but likely does not.
As the library likely does not, we should probably make this an
option to close all connections upon CRL reload, with it being well
documented.

Now that option should likely be set to default on, but documented
such that if you do regular/often CRL reloads, that a user may want
to turn that off if it's disruptive to their server.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: openzfs related kernel install fails (r365296)

[Mark Johnston]

On Fri, Sep 04, 2020 at 09:41:56PM +0300, Ruslan Makhmatkhanov wrote:
> Mark Johnston wrote on 9/4/20 9:34 PM:
> > On Fri, Sep 04, 2020 at 09:27:54PM +0300, Ruslan Makhmatkhanov wrote:
> >> Hello,
> >>
> >> tried to make world and kernel from r365296. Kernel fails at install
> >> stage in zfs module:
> >>
> >> ===> zfs (install)
> >> install -T release -o root -g wheel -m 555   zfs.ko /boot/kernel/
> >> install -T dbg -o root -g wheel -m 555   zfs.ko.debug
> >> /usr/lib/debug/boot/kernel/
> >> install: /usr/lib/debug/boot/kernel/: No such file or directory
> >> *** Error code 71
> >>
> >> Stop.
> >> make[4]: stopped in /mnt/hdd/src/sys/modules/zfs
> >> *** Error code 1
> >> *** Error code 1
> >>
> >> Stop.
> >> make[2]: stopped in /mnt/hdd/obj/mnt/hdd/src/amd64.amd64/sys/Z1
> >> *** Error code 1
> >>
> >> Stop.
> >> make[1]: stopped in /mnt/hdd/src
> >>
> >>
> >> It seems `nomakeoptions   DEBUG' in my kernel configuration is culprit.
> >> Worked fine before. Is there options to fix that besides enabling DEBUG?
> > 
> > The zfs.ko Makefile unconditionally enables creation of a debug file.
> > Could you verify that the problem is gone with this patch?
> 
> 
> This patch indeed fixes the install. Thank you!

Committed in r365336, thanks.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: installkernel: install: /usr/lib/debug/boot/kernel/: No such file or directory *** Error code 71

[Mateusz Guzik]

On 9/4/20, O. Hartmann  wrote:
> On Tue, 1 Sep 2020 19:21:36 +0200
> Mateusz Guzik  wrote:
>
>> It's not my bug but i'll make sure it is taken care of.
>
> Oh, I'm sorry. But I grasp for every help I can get ...
>
> The problem is that I do not know whether the process "make installkernel"
> does
> silently proceed and drop the error message and everything is fine or the
> fact
> that zfs.ko is the very last kernel module in the alphabetical order makes
> it
> by accident work. So, rebooting with an inconsistent /boot/kernel folder
> has
> revealed itself as a very unpleasant situation in the past.
>

markj got to this before I could. Can you please test the patch?

Index: sys/modules/zfs/Makefile
===
--- sys/modules/zfs/Makefile(revision 365318)
+++ sys/modules/zfs/Makefile(working copy)
@@ -44,8 +44,6 @@ CFLAGS+= -DDEBUG_VFS_LOCKS
 CFLAGS+=-fprofile-arcs -ftest-coverage
 .endif

-DEBUG_FLAGS=-g
-
 .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc" || \
${MACHINE_ARCH} == "powerpcspe" || ${MACHINE_ARCH} == "arm"
 CFLAGS+= -DBITS_PER_LONG=32

>
>>
>> On 8/30/20, Hartmann, O.  wrote:
>> > On Fri, 28 Aug 2020 13:16:05 +0200
>> > Mateusz Guzik  wrote:
>> >
>> >> On 8/28/20, Hartmann, O.  wrote:
>> >> > On Fri, 28 Aug 2020 12:31:21 +0200
>> >> > Mateusz Guzik  wrote:
>> >> >
>> >> >> Can you show more of the log?
>> >> >>
>> >> >> When you installkernel you should see:
>> >> >> mkdir -p /boot/kernel
>> >> >> install -p -m 555 -o root -g wheel kernel /boot/kernel/
>> >> >
>> >> > These lines are seen right after the beginning of "make
>> >> > installkernel".
>> >> >> mkdir -p /usr/lib/debug/boot/kernel
>> >> >> install -p -m 555 -o root -g wheel kernel.debug
>> >> >> /usr/lib/debug/boot/kernel/
>> >> >
>> >> > I wouldn't expect these lines according to my /etc/src.conf, since I
>> >> > disbaled debugging and installing debugging infos.
>> >> >>
>> >> >> Did these succeed? Do these dirs exist now?
>> >> >
>> >> > It is not existent, as expected:
>> >> >
>> >> >
>> >> > # ll /usr/lib/debug/boot/kernel/
>> >> > ls: /usr/lib/debug/boot/kernel/: No such file or directory
>> >> >
>> >>
>> >> Ok. I recently made changes to the namecache, which if buggy, could
>> >> have resulted in woes like the above.
>> >>
>> >> Thus it looks like the newly imported zfs does not respect
>> >> WITHOUT_DEBUG_FILES.
>> >
>> > Even in r364973 the problem still remains.
>> > Disabling option WITHOUT_DEBUG_FILES in src.conf is exhausting the
>> > /usr/obj partition (using UFS/FFS) and no option.
>> >
>> > Got now several boxes having "make installkernel" issued with a running
>> > system but incomplete kernel installation, as buildkernel suggested a
>> > clean build. Can this be fixed, please?
>> >
>> >
>> >>
>> >> >>
>> >> >> On 8/28/20, Hartmann, O.  wrote:
>> >> >> > On CURRENT (FreeBSD 13.0-CURRENT #185 r364767: Tue Aug 25
>> >> >> > 16:10:50 CEST 2020 amd64), /usr/src at  revision 364907,
>> >> >> > installkernel fails now due to an error as shown below. For the
>> >> >> > record, "options ZFS" ist statically in the kernel config file.
>> >> >> >
>> >> >> > Also deleting /usr/obj and restarting buildworld and buildkernel
>> >> >> > from scratch doesn't solve the problem. The buildworld and
>> >> >> > buildkernel mutually finish without error (I do not see any on
>> >> >> > the console), installworld also finishes fine, but installkernel
>> >> >> > not.
>> >> >> >
>> >> >> > /etc/src.conf looks as follows:
>> >> >> >
>> >> >> > [...]
>> >> >> > CPUTYPE?=   native
>> >> >> > # World
>> >> >> > CFLAGS+=-O3
>> >> >> > #CFLAGS+=   -DNDEBUG
>> >> >> > # Kernel
>> >> >> > COPTFLAGS+= -O3
>> >> >> > #COPTFLAGS+=-DNDEBUG
>> >> >> > #CXXFLAGS+= -std=c++17
>> >> >> > WITH_CLANG_EXTRAS=  YES
>> >> >> > WITH_LLDB=  YES
>> >> >> > #WITH_BSD_GREP= YES
>> >> >> > WITH_OFED_EXTRA=YES
>> >> >> > WITH_NAND=  YES
>> >> >> > #WITH_CTF=  YES
>> >> >> > WITH_SVN=   YES
>> >> >> > WITH_BEARSSL=   YES
>> >> >> > WITH_PIE=   YES
>> >> >> > WITH_SORT_THREADS=  YES
>> >> >> > WITH_ZONEINFO_LEAPSECONDS_SUPPORT=  YES
>> >> >> > MALLOC_PRODUCTION=  YES
>> >> >> > WITHOUT_ASSERT_DEBUG=   YES
>> >> >> > WITHOUT_TESTS=  YES
>> >> >> > WITHOUT_PROFILE=YES
>> >> >> > WITHOUT_DEBUG_FILES=YES
>> >> >> > WITHOUT_REPRODUCIBLE_BUILD= YES
>> >> >> >
>> >> >> > [...]
>> >> >> >
>> >> >> > Debugging facilities are disabled as src.conf indicates.
>> >> >> >
>> >> >> > [...]
>> >> >> > install -T release -o root -g wheel -m 555   xz.ko
>> >> >> > /bo

Re: openzfs related kernel install fails (r365296)

[Ruslan Makhmatkhanov]

Mark Johnston wrote on 9/4/20 9:34 PM:

On Fri, Sep 04, 2020 at 09:27:54PM +0300, Ruslan Makhmatkhanov wrote:

Hello,

tried to make world and kernel from r365296. Kernel fails at install
stage in zfs module:

===> zfs (install)
install -T release -o root -g wheel -m 555   zfs.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   zfs.ko.debug
/usr/lib/debug/boot/kernel/
install: /usr/lib/debug/boot/kernel/: No such file or directory
*** Error code 71

Stop.
make[4]: stopped in /mnt/hdd/src/sys/modules/zfs
*** Error code 1
*** Error code 1

Stop.
make[2]: stopped in /mnt/hdd/obj/mnt/hdd/src/amd64.amd64/sys/Z1
*** Error code 1

Stop.
make[1]: stopped in /mnt/hdd/src


It seems `nomakeoptions   DEBUG' in my kernel configuration is culprit.
Worked fine before. Is there options to fix that besides enabling DEBUG?


The zfs.ko Makefile unconditionally enables creation of a debug file.
Could you verify that the problem is gone with this patch?



This patch indeed fixes the install. Thank you!




Index: sys/modules/zfs/Makefile
===
--- sys/modules/zfs/Makefile(revision 365318)
+++ sys/modules/zfs/Makefile(working copy)
@@ -44,8 +44,6 @@ CFLAGS+= -DDEBUG_VFS_LOCKS
  CFLAGS+=   -fprofile-arcs -ftest-coverage
  .endif
  
-DEBUG_FLAGS=-g

-
  .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc" || \
${MACHINE_ARCH} == "powerpcspe" || ${MACHINE_ARCH} == "arm"
  CFLAGS+= -DBITS_PER_LONG=32




--
Regards,
Ruslan

T.O.S. Of Reality
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: openzfs related kernel install fails (r365296)

[Mark Johnston]

On Fri, Sep 04, 2020 at 09:27:54PM +0300, Ruslan Makhmatkhanov wrote:
> Hello,
> 
> tried to make world and kernel from r365296. Kernel fails at install 
> stage in zfs module:
> 
> ===> zfs (install)
> install -T release -o root -g wheel -m 555   zfs.ko /boot/kernel/
> install -T dbg -o root -g wheel -m 555   zfs.ko.debug 
> /usr/lib/debug/boot/kernel/
> install: /usr/lib/debug/boot/kernel/: No such file or directory
> *** Error code 71
> 
> Stop.
> make[4]: stopped in /mnt/hdd/src/sys/modules/zfs
> *** Error code 1
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /mnt/hdd/obj/mnt/hdd/src/amd64.amd64/sys/Z1
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /mnt/hdd/src
> 
> 
> It seems `nomakeoptions   DEBUG' in my kernel configuration is culprit. 
> Worked fine before. Is there options to fix that besides enabling DEBUG?

The zfs.ko Makefile unconditionally enables creation of a debug file.
Could you verify that the problem is gone with this patch?

Index: sys/modules/zfs/Makefile
===
--- sys/modules/zfs/Makefile(revision 365318)
+++ sys/modules/zfs/Makefile(working copy)
@@ -44,8 +44,6 @@ CFLAGS+= -DDEBUG_VFS_LOCKS
 CFLAGS+=-fprofile-arcs -ftest-coverage
 .endif
 
-DEBUG_FLAGS=-g
-
 .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "powerpc" || \
${MACHINE_ARCH} == "powerpcspe" || ${MACHINE_ARCH} == "arm"
 CFLAGS+= -DBITS_PER_LONG=32
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

openzfs related kernel install fails (r365296)

[Ruslan Makhmatkhanov]

Hello,

tried to make world and kernel from r365296. Kernel fails at install 
stage in zfs module:


===> zfs (install)
install -T release -o root -g wheel -m 555   zfs.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   zfs.ko.debug 
/usr/lib/debug/boot/kernel/

install: /usr/lib/debug/boot/kernel/: No such file or directory
*** Error code 71

Stop.
make[4]: stopped in /mnt/hdd/src/sys/modules/zfs
*** Error code 1
*** Error code 1

Stop.
make[2]: stopped in /mnt/hdd/obj/mnt/hdd/src/amd64.amd64/sys/Z1
*** Error code 1

Stop.
make[1]: stopped in /mnt/hdd/src


It seems `nomakeoptions   DEBUG' in my kernel configuration is culprit. 
Worked fine before. Is there options to fix that besides enabling DEBUG?


--
Regards,
Ruslan

T.O.S. Of Reality
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: r365325: mounting ZFS within JAIL now fails: /sbin/zfs mount -a: failed

[Ryan Moeller]

On 9/4/20 6:30 AM, O. Hartmann wrote:

Running a most recent CURRENT (FreeBSD 13.0-CURRENT #1 r365325: Fri Sep 4
11:28:14 CEST 2020 amd64) with JAILS also running CURRENT of the very same
version, one specific jail which is designated to be a poudriere jail 
with ZFS

filesystems doesn't start after an update today.

The message is:

[...]
cannot mount 'POOL00/ezjail': Insufficient privileges
cannot mount 'POOL00': Insufficient privileges



I've recently committed some bug fixes in the jails <-> zones 
translations upstream after seeing a report like this. It seems to 
resolve this particular issue. Expect it to be a few days until the 
commit gets pulled in through the vendor branch.


-Ryan




Prior to the update today, everything worked fine and the jail was able to
mount its pool; "enforce_statfs= "1";" worked so far, I have no clue 
what is

going wrong here.

Can someone shed some light on this?

Addendum: As mentioned in /usr/src/UPDATING, 20200824, I did not 
upgrade the

pool.

The host has been rebuild from clean /usr/src/obj and so the jail's image
(using ezjail and /usr/src as the jail's base).

Help is appreciated,

thanks in advance,

kind regards

oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fatal trap 18 on boot after OpenZFS import

[Tomoaki AOKI]

Hi.

Encountering boot failure with fatal trap 18 on boot,
happening at (maybe) just before init() starts. Possibly on
root remount by kernel or zpool import by rc.d script.
The last revision tried is r365316 (r364788 is the last tried
clean rebuild).

The last health revision is r364744, just before actual switch
to OpenZFS. amd64 on ThinkPad P52 (Core i7-8750H) w/descrete nvidia GPU.

r364751 with diff of r364777 and r364788 (to successfully built
Without unrelated-to-OpenZFS changes) fails.

Any suggestions and fixes are appreciated.


Trap screen is something like below (text attached),
typed up from relatively clear photo, so could be some typo.

This is shown just after usual kernel startup outputs.
boot1.efi (as EFI/bootx64.efi on ESP) starts /boot/loader.efi
properly, and loader.efi seems to boot kernel properly.

As even single user shell selection doesn't appear, loader.efi
is of r364744. But they works even if I proceeded irregular
process,

  1)Update src tree
  2)Clean obj tree
  3)buildworld
  4)etcupdate -p
  5)buildkernel
  6)installkernel
  7)shutdown to single user WITHOUT reboot  <- Irregular!
  8)installworld
  9)etcupdate
 10)rebuild src/sys-dependent ports (kmods, nvidia-driver, ...)
 11)reboot

loader.efi looks doing its job and panics after kernel startup ends.
Needless to say, rolling back to r364744 state from stable/12 on nvd0
Fixes the issue.

Regards.

=

Fatal trap 18: integer divide fault while in kernel mode
cpuid = 2; apic id = 02
instruction pointer = 0x20:0x82bfa320
stack pointer   = 0x28:0xfe00e20c6900
frame pointer   = 0x28:0xfe00e20c6960
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 27 (vdev_open)
trap number = 18
panic: integer divide fault
cpuid = 2
time = 16
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00e20c6610 vpanic() at vpanic+0x182/frame fe00e20c6660
panic() at panic+0x43/frame fe00e20c66c0
trap_fatal() at trap_fatal+0x387/frame fe00e20c6720
trap() at trap+0x8e/frame fe00e20c6830
calltrap() at calltrap+0x8/frame fe00e20c6830
--- trap 0x12, rip = 0x82bfa320, rsp = 0xfe00e20c6900, rbp
= 0xfe00e20c6960 --- zio_wait() at zio_wait+0x60/frame
0xfe00e20c6960 vdev_open() at vdev_open+0x74d/frame
0xfe00e20c69c0 vdev_open_child() at vdev_open_child+0x1e/frame
0xfe00e20c69e0 taskq_run() at taskq_run+0x1f/frame
0xfe00e20c6a00 taskqueue_run_locked() at
taskqueue_run_locked+0x181/frame 0xfe00e20c6a80
taskqueue_thread_loop() at taskqueue_thread_loop+0x118/frame
0xfe00e20c6ab0 fork_exit() at fork_exit+0x7d/frame
0xfe00e20c6af0 fork_trampoline() at fork_trampoline+0xe/frame
0xfe00e20c6af0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 27 tid 100570 ]
Stopped at  kdb_enter+0x37: movq$0,0x1091556(%rip)
db> 

=

Additional info:
 *Clean build with killing CPUTYPE from command line and
  make.conf (so should be equivalent with nocona) didn't help.

 *Clean build with commenting out WITH_KERNEL_RETPOLINE line
  and WITH_RETPOLINE line in src.conf didn't help.

 *Combination of the above two didn't help, too (at r364788).

 *There are two root pools in different physical drive.
  stable/12 on nvd0 (primary) and head on ada0 (secondary).

 *GENERIC-NODEBUG based (added options CAM_IOSCHED_DYNAMIC)
  kernel.

-- 
Tomoaki AOKI


Fatal_trap_18_on_head_after_r364744.log
Description: Binary data
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fw: OpenZFS support merged: problem mounting ZFS within JAILs

[O. Hartmann]

Begin forwarded message:

Date: Fri, 4 Sep 2020 14:06:12 +0200
From: "O. Hartmann" 
To: Matthew Macy 
Cc: freebsd-current , freebsd-fs
, freebsd-hack...@freebsd.org Subject: Re: OpenZFS
support merged: problem mounting ZFS within JAILs


On Mon, 24 Aug 2020 19:38:53 -0700
Matthew Macy  wrote:

> r364746 merged OpenZFS support in to HEAD.
>
> The change should be transparent unless you want to use new features.
> I caution against 'zpool upgrade' for the next few weeks.
>
> https://svnweb.freebsd.org/base?view=revision&revision=364746
>
> If you encounter problems please report them to me, Ryan Moeller, and
> -current. ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hello.

We just upgraded several boxes running CURRENT to r365325. These systems are
running customized kernels with ZFS statically compiled in. the host's OS is
derived from "make buildworld buildkernel" in /usr/src.

Jails on that hosts are maintained vi /etc/jail.conf, but system is installed
by misusage of ezjail. So far the environemnt.

One of the jails is a dedicated poudriere jail using ZFS. This worked so far.
Every pool this specific jail or any other jail is mounting is located below

POOL/ezjail

therefore we consider

enforce_statfs= "1";

in /etc/jail.conf as sufficient. After updating all /etc/default/ and
/etc/rc.d of those poudriere-jails with ZFS everything should be inline
regarding new requests for OpenZFS .

But now enforce_statfs= "1"; isn't sufficient anymore, the jais fail to startup
with a mount error complaining about insufficient access rights. The problem
partially disappear by setting enforce_statfs= "0";, but this isn't what we
want and personally I consider it a risk. But furthermore, several ZFS datasets
prior to the upgrade successfully being exported from the hosts pools and mount
from withing the jail are now invisible within the jail.

According to /usr/src/UPDATING, tag 20200824, the features of the ZFS pools of
the main hosts have been left untouched so far, no feature upgrade has been
performed.

Some hints would be nice.

Kind regards,

oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS support merged: problem mounting ZFS within JAILs

[O. Hartmann]

On Mon, 24 Aug 2020 19:38:53 -0700
Matthew Macy  wrote:

> r364746 merged OpenZFS support in to HEAD.
>
> The change should be transparent unless you want to use new features.
> I caution against 'zpool upgrade' for the next few weeks.
>
> https://svnweb.freebsd.org/base?view=revision&revision=364746
>
> If you encounter problems please report them to me, Ryan Moeller, and
> -current. ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hello.

We just upgraded several boxes running CURRENT to r365325. These systems are
running customized kernels with ZFS statically compiled in. the host's OS is
derived from "make buildworld buildkernel" in /usr/src.

Jails on that hosts are maintained vi /etc/jail.conf, but system is installed
by misusage of ezjail. So far the environemnt.

One of the jails is a dedicated poudriere jail using ZFS. This worked so far.
Every pool this specific jail or any other jail is mounting is located below

POOL/ezjail

therefore we consider

enforce_statfs= "1";

in /etc/jail.conf as sufficient. After updating all /etc/default/ and
/etc/rc.d of those poudriere-jails with ZFS everything should be inline
regarding new requests for OpenZFS .

But now enforce_statfs= "1"; isn't sufficient anymore, the jais fail to startup
with a mount error complaining about insufficient access rights. The problem
partially disappear by setting enforce_statfs= "0";, but this isn't what we
want and personally I consider it a risk. But furthermore, several ZFS datasets
prior to the upgrade successfully being exported from the hosts pools and mount
from withing the jail are now invisible within the jail.

According to /usr/src/UPDATING, tag 20200824, the features of the ZFS pools of
the main hosts have been left untouched so far, no feature upgrade has been
performed.

Some hints would be nice.

Kind regards,

oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: installkernel: install: /usr/lib/debug/boot/kernel/: No such file or directory *** Error code 71

[O. Hartmann]

On Tue, 1 Sep 2020 19:21:36 +0200
Mateusz Guzik  wrote:

> It's not my bug but i'll make sure it is taken care of.

Oh, I'm sorry. But I grasp for every help I can get ...

The problem is that I do not know whether the process "make installkernel" does
silently proceed and drop the error message and everything is fine or the fact
that zfs.ko is the very last kernel module in the alphabetical order makes it
by accident work. So, rebooting with an inconsistent /boot/kernel folder has
revealed itself as a very unpleasant situation in the past.

Thanks anyway for your concern.

Kind regards

Oliver

>
> On 8/30/20, Hartmann, O.  wrote:
> > On Fri, 28 Aug 2020 13:16:05 +0200
> > Mateusz Guzik  wrote:
> >
> >> On 8/28/20, Hartmann, O.  wrote:
> >> > On Fri, 28 Aug 2020 12:31:21 +0200
> >> > Mateusz Guzik  wrote:
> >> >
> >> >> Can you show more of the log?
> >> >>
> >> >> When you installkernel you should see:
> >> >> mkdir -p /boot/kernel
> >> >> install -p -m 555 -o root -g wheel kernel /boot/kernel/
> >> >
> >> > These lines are seen right after the beginning of "make
> >> > installkernel".
> >> >> mkdir -p /usr/lib/debug/boot/kernel
> >> >> install -p -m 555 -o root -g wheel kernel.debug
> >> >> /usr/lib/debug/boot/kernel/
> >> >
> >> > I wouldn't expect these lines according to my /etc/src.conf, since I
> >> > disbaled debugging and installing debugging infos.
> >> >>
> >> >> Did these succeed? Do these dirs exist now?
> >> >
> >> > It is not existent, as expected:
> >> >
> >> >
> >> > # ll /usr/lib/debug/boot/kernel/
> >> > ls: /usr/lib/debug/boot/kernel/: No such file or directory
> >> >
> >>
> >> Ok. I recently made changes to the namecache, which if buggy, could
> >> have resulted in woes like the above.
> >>
> >> Thus it looks like the newly imported zfs does not respect
> >> WITHOUT_DEBUG_FILES.
> >
> > Even in r364973 the problem still remains.
> > Disabling option WITHOUT_DEBUG_FILES in src.conf is exhausting the
> > /usr/obj partition (using UFS/FFS) and no option.
> >
> > Got now several boxes having "make installkernel" issued with a running
> > system but incomplete kernel installation, as buildkernel suggested a
> > clean build. Can this be fixed, please?
> >
> >
> >>
> >> >>
> >> >> On 8/28/20, Hartmann, O.  wrote:
> >> >> > On CURRENT (FreeBSD 13.0-CURRENT #185 r364767: Tue Aug 25
> >> >> > 16:10:50 CEST 2020 amd64), /usr/src at  revision 364907,
> >> >> > installkernel fails now due to an error as shown below. For the
> >> >> > record, "options ZFS" ist statically in the kernel config file.
> >> >> >
> >> >> > Also deleting /usr/obj and restarting buildworld and buildkernel
> >> >> > from scratch doesn't solve the problem. The buildworld and
> >> >> > buildkernel mutually finish without error (I do not see any on
> >> >> > the console), installworld also finishes fine, but installkernel
> >> >> > not.
> >> >> >
> >> >> > /etc/src.conf looks as follows:
> >> >> >
> >> >> > [...]
> >> >> > CPUTYPE?=   native
> >> >> > # World
> >> >> > CFLAGS+=-O3
> >> >> > #CFLAGS+=   -DNDEBUG
> >> >> > # Kernel
> >> >> > COPTFLAGS+= -O3
> >> >> > #COPTFLAGS+=-DNDEBUG
> >> >> > #CXXFLAGS+= -std=c++17
> >> >> > WITH_CLANG_EXTRAS=  YES
> >> >> > WITH_LLDB=  YES
> >> >> > #WITH_BSD_GREP= YES
> >> >> > WITH_OFED_EXTRA=YES
> >> >> > WITH_NAND=  YES
> >> >> > #WITH_CTF=  YES
> >> >> > WITH_SVN=   YES
> >> >> > WITH_BEARSSL=   YES
> >> >> > WITH_PIE=   YES
> >> >> > WITH_SORT_THREADS=  YES
> >> >> > WITH_ZONEINFO_LEAPSECONDS_SUPPORT=  YES
> >> >> > MALLOC_PRODUCTION=  YES
> >> >> > WITHOUT_ASSERT_DEBUG=   YES
> >> >> > WITHOUT_TESTS=  YES
> >> >> > WITHOUT_PROFILE=YES
> >> >> > WITHOUT_DEBUG_FILES=YES
> >> >> > WITHOUT_REPRODUCIBLE_BUILD= YES
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> > Debugging facilities are disabled as src.conf indicates.
> >> >> >
> >> >> > [...]
> >> >> > install -T release -o root -g wheel -m 555   xz.ko
> >> >> > /boot/kernel/ ===> zfs (install)
> >> >> > install -T release -o root -g wheel -m 555   zfs.ko /boot/kernel/
> >> >> > install -T dbg -o root -g wheel -m 555   zfs.ko.debug
> >> >> >   /usr/lib/debug/boot/kernel/
> >> >> > install: /usr/lib/debug/boot/kernel/: No such file or directory
> >> >> > *** Error code 71
> >> >> >
> >> >> > Stop.
> >> >> > make[4]: stopped in /usr/src/sys/modules/zfs
> >> >> > *** Error code 1
> >> >> > *** Error code 1
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

___
freebsd-current@freebsd.org mailing list
https://lists.freebs

CURRENT: r365325: mounting ZFS within JAIL now fails: /sbin/zfs mount -a: failed

[O. Hartmann]

Running a most recent CURRENT (FreeBSD 13.0-CURRENT #1 r365325: Fri Sep  4
11:28:14 CEST 2020 amd64) with JAILS also running CURRENT of the very same
version, one specific jail which is designated to be a poudriere jail with ZFS
filesystems doesn't start after an update today.

The message is:

[...]
cannot mount 'POOL00/ezjail': Insufficient privileges
cannot mount 'POOL00': Insufficient privileges

Prior to the update today, everything worked fine and the jail was able to
mount its pool; "enforce_statfs= "1";" worked so far, I have no clue what is
going wrong here.

Can someone shed some light on this?

Addendum: As mentioned in /usr/src/UPDATING, 20200824, I did not upgrade the
pool.

The host has been rebuild from clean /usr/src/obj and so the jail's image
(using ezjail and /usr/src as the jail's base).

Help is appreciated,

thanks in advance,

kind regards

oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: /usr/src/cddl/sbin/zfs don't know how to make zfs-change-key.8

[Julian H. Stacey]

Ryan Moeller wrote:
> 
> On 9/1/20 7:42 PM, Julian H. Stacey wrote:
> > Hi curr...@freebsd.org,
> >
> > With .ctm_status src-cur 14656 .svn_revision 364986 /usr/src/cddl/sbin/zfs
> > #   bmake[4]: don't know how to make zfs-change-key.8. Stop
> 
> 
> Thanks, fixed it: https://svnweb.freebsd.org/changeset/base/365250

Thanks Ryan, src/cddl/sbin/zfs builds here on 365287

Cheers,
Julian
-- 
Julian Stacey, Consultant Sys. Engineer, BSD Linux http://berklix.com/jhs/
Crash Brexit Dec. 2020 paid by speculators. http://berklix.uk/brexit/#money
Probe Russian Brexit Referendum https://petition.parliament.uk/petitions/332293
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD CI Weekly Report 2020-08-30

[Li-Wen Hsu]

On Thu, Sep 3, 2020 at 8:57 PM Alan Somers  wrote:
>
> On Thu, Sep 3, 2020 at 4:06 AM Li-Wen Hsu  wrote:
>
> >
> > FreeBSD CI Weekly Report 2020-08-30
> > ===
> > * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
> > * Total 681 tests, 525 success, 46 failures, 110 skipped, see
> >
> > https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
> > for more details
> >
> That's 35 more failures than we used to have.  What changed?  Was this
> using the openzfs kmod?  It looks like test run 7392 was when the change
> happened.
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/7392/changes

Yes as described in the news section, the statistics are from the
build after openzfs importing.

Best,
Li-Wen
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: suspend/resume versus OpenZFS on USB

[Hans Petter Selasky]

On 2020-09-04 01:42, Graham Perrin wrote:
This week for the first time I toyed with OpenZFS on a USB device: a 
mobile hard disk drive connected to the dock of an HP EliteBook 8570p.


A light test, with the pool imported but not writing to the dataset at 
suspend time.


At resume time (22:31), the device was still physically connected but 
the pool suffered an I/O failure (and the keyboard and trackball on USB 
were unusable).


Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11239]: vdev state changed, 
pool_guid=$8076233369858608335 vdev_guid=$13893535540375859253
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11243]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11247]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11251]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11255]: pool I/O failure, 
zpool=$Transcend error=$28
Sep  3 22:31:03 momh167-gjp4-8570p ZFS[11259]: catastrophic pool I/O 
failure, zpool=$Transcend


I cleared pool errors (after which the keyboard and trackball became 
usable), exported the pool, physically disconnected the drive, restarted 
the OS, reconnected, imported and – luckily – cleared the remaining 
metadata errors through a scrub.


Please, might something be done to improve suspend/resume reliability 
with storage on USB?


Might I/O failures be less likely if I connect the drive to the notebook 
instead of its dock?


TIA



More from /var/log/messages at https://pastebin.com/CqRYbFZm

Other relevant info below.

root@momh167-gjp4-8570p:~ # date ; uptime ; uname -v
Thu Sep  3 22:45:07 BST 2020
10:45PM  up 6 mins, 6 users, load averages: 0.20, 0.27, 0.13
FreeBSD 13.0-CURRENT #63 r364768: Tue Aug 25 20:08:23 BST 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

root@momh167-gjp4-8570p:~ # zpool status -v
   pool: copperbowl
  state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
     still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
     the pool may no longer be accessible by software that does not 
support

     the features. See zpool-features(5) for details.
   scan: scrub repaired 0B in 01:39:31 with 0 errors on Thu Sep  3 
01:12:21 2020

config:

     NAME  STATE READ WRITE CKSUM
     copperbowl    ONLINE   0 0 0
   ada0p4.eli  ONLINE   0 0 0

errors: No known data errors
root@momh167-gjp4-8570p:~ # zpool import Transcend && zfs load-key 
Transcend/VirtualBox

Enter passphrase for 'Transcend/VirtualBox':
root@momh167-gjp4-8570p:~ # zpool status -v Transcend
   pool: Transcend
  state: ONLINE
status: One or more devices has experienced an error resulting in data
     corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
     entire pool from backup.
    see: https://zfsonlinux.org/msg/ZFS-8000-8A
   scan: scrub repaired 0B in 00:15:33 with 0 errors on Wed Sep  2 
22:38:56 2020

config:

     NAME    STATE READ WRITE CKSUM
     Transcend   ONLINE   0 0 0
   da0p1 ONLINE   0 0 0

errors: Permanent errors have been detected in the following files:

     :<0x0>
     :<0x3d>
root@momh167-gjp4-8570p:~ # zpool scrub Transcend
root@momh167-gjp4-8570p:~ # zfs version
zfs-0.8.0-1
zfs-kmod-0.8.0-1
root@momh167-gjp4-8570p:~ # zpool status -v Transcend
   pool: Transcend
  state: ONLINE
   scan: scrub repaired 0B in 00:17:53 with 0 errors on Thu Sep  3 
23:03:57 2020

config:

     NAME    STATE READ WRITE CKSUM
     Transcend   ONLINE   0 0 0
   da0p1 ONLINE   0 0 0

errors: No known data errors
root@momh167-gjp4-8570p:~ # zfs get 
compression,compressratio,encryption,used,referenced,mountpoint 
Transcend Transcend/VirtualBox

NAME  PROPERTY   VALUE SOURCE
Transcend compression    zstd  local
Transcend compressratio  1.70x -
Transcend encryption off default
Transcend used   76.4G -
Transcend referenced 76.4G -
Transcend mountpoint /Volumes/t500 local
Transcend/VirtualBox  compression    zstd inherited from Transcend
Transcend/VirtualBox  compressratio  1.00x -
Transcend/VirtualBox  encryption aes-256-gcm   -
Transcend/VirtualBox  used   200K  -
Transcend/VirtualBox  referenced 200K  -
Transcend/VirtualBox  mountpoint /Volumes/t500/VirtualBox inherited 
from Transcend
root@momh167-gjp4-8570p:~ # ls -hl 
/Volumes/t500/VirtualBox/Windows/Windows.vdi
-rw---  1 grahamperrin  grahamperrin    69G Sep  3 16:58 
/Volume