Re: bug in motd service / documentation
On Sat, 17 Oct 2020, Dan Mack wrote: I've been away for a while and missed the change and complexity added to /etc/motd. I figured it out but I was led astray by not knowing that it was converted into a service that only runs at boot time. If you just follow the instructions in the template file, you will nothing changes. As a suggestion, maybe change this line in the /etc/motd.template file: Edit /etc/motd.template to change this login announcement. to: Edit /etc/motd.template to change this login announcement and reboot or manually restart the motd service in /etc/rc.d/motd as in: /etc/rc.d/motd restart and also add an entry to the man page for motd. This was on: FreeBSD boxolox 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366790: Sat Oct 17 08:57:56 CDT 2020 Instead of just complaining, I've attached a diff of a proposed fix. Diff against base/head is here fwiw: https://github.com/danmack/freebsd/tree/motd-doc-fix Dan diff --git a/share/man/man5/motd.5 b/share/man/man5/motd.5 index 9feb0479b92..457c69da6b6 100644 --- a/share/man/man5/motd.5 +++ b/share/man/man5/motd.5 @@ -22,6 +22,14 @@ prepended to and the contents are written to .Pa /var/run/motd . .Pp +.Pa /var/run/motd +can be updated without a system reboot by manually restarting the +motd service after updating +.Pa /etc/motd.template: +.Bd -literal -offset -ident +service motd restart +.Ed +.Pp Individual users may suppress the display of this file by creating a file named .Dq Pa .hushlogin diff --git a/usr.bin/login/motd.template b/usr.bin/login/motd.template index 80d79095980..9973850c683 100644 --- a/usr.bin/login/motd.template +++ b/usr.bin/login/motd.template @@ -17,4 +17,5 @@ Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier -Edit /etc/motd.template to change this login announcement. +To change this login announcement, edit /etc/motd.template and either +reboot or restart the motd service in /etc/rc.d/motd. ___ 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: kernel panic and fun debugging
On Sat, Oct 17, 2020 at 1:17 PM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Sat, Oct 17, 2020 at 12:58:48PM -0600, Warner Losh wrote: > > On Sat, Oct 17, 2020, 12:00 PM Andrey V. Elsukov > wrote: > > > > > On 15.10.2020 09:56, Steve Kargl wrote: > > > > Just had a kernel panic. Best info I give you is > > > > > > > > % uname -a > > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat > Sep 26 > > > 10:35:23 PDT 2020 kargl@mobile > :/usr/obj/usr/src/i386.i386/sys/MOBILE > > > i386 > > > > > > > > % kgdb gdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 > > > > ... > > > > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug... > > > > /usr/ports/devel/gdb/work-py37/gdb-9.2/gdb/inferior.c:283: > > > internal-error: struct inferior *find_inferior_pid(int): Assertion > `pid != > > > 0' failed. > > > > A problem internal to GDB has been detected, > > > > further debugging may prove unreliable. > > > > > > Hi, > > > > > > do you have /var/crash/core.txt.1 file? > > > It may have some useful info. Also did you try an old version > > > /usr/libexec/kgdb ? > > > > > > > I got this same error, btw, when I pointed kgdb at the wrong kernel for > the > > core file. > > > > But you can 'more' the uncompressed vmcore to get at least a traceback if > > the proper kernel is gone... > > > > Warner > > > > There are only 2 kernel.debug on the system. > > % locate kernel.debug > /usr/lib/debug/boot/kernel/kernel.debug > /usr/lib/debug/boot/kernel.old/kernel.debug > > Using > > % kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 > % kgdb /usr/lib/debug/boot/kernel.old/kernel.debug vmcore.1 > > Both have the same result. In a pinch, you can use /boot/kernel/kernel if you suspect a difference... > I didn't realize the panic text > was recorded int vmcore.1. If I extracted everything correctly, > here's what happen > > WARNING !drm_modeset_is_locked(>mutex) failed at > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:621 > #0 0x2318d4b9 at linux_dump_stack+0x19 > #1 0x23219ec2 at drm_atomic_helper_check_modeset+0x92 > #2 0x23091d90 at intel_atomic_check+0x70 > #3 0x2321913e at drm_atomic_check_only+0x38e > #4 0x23219461 at drm_atomic_commit+0x11 > #5 0x23224793 at drm_client_modeset_commit_atomic+0xb3 > #6 0x2322458e at drm_client_modeset_commit_force+0x5e > #7 0x23260851 at drm_fb_helper_restore_fbdev_mode_unlocked+0x71 > #8 0x2325b092 at vt_kms_postswitch+0x132 > #9 0xa8bec5 at vt_fb_postswitch+0x15 > #10 0xa9153d at vt_window_switch+0xfd > #11 0xa8f59c at vtterm_cngrab+0x1c > #12 0xbec5bf at termcn_cngrab+0xf > #13 0xb4b6f6 at cngrab+0x16 > #14 0xb9fce2 at vpanic+0xd2 > #15 0xb9fc04 at panic+0x14 > #16 0xe2c06a at vm_fault_lookup+0x13a > #17 0xe2b8e7 at vm_fault+0x77 > WARNING !drm_modeset_is_locked(>mutex) failed at > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:621 > #0 0x2318d4b9 at linux_dump_stack+0x19 > #1 0x23219ec2 at drm_atomic_helper_check_modeset+0x92 > #2 0x23091d90 at intel_atomic_check+0x70 > #3 0x2321913e at drm_atomic_check_only+0x38e > #4 0x23219461 at drm_atomic_commit+0x11 > #5 0x23224793 at drm_client_modeset_commit_atomic+0xb3 > #6 0x2322458e at drm_client_modeset_commit_force+0x5e > #7 0x23260851 at drm_fb_helper_restore_fbdev_mode_unlocked+0x71 > #8 0x2325b092 at vt_kms_postswitch+0x132 > #9 0xa8bec5 at vt_fb_postswitch+0x15 > #10 0xa9153d at vt_window_switch+0xfd > #11 0xa8f59c at vtterm_cngrab+0x1c > #12 0xbec5bf at termcn_cngrab+0xf > #13 0xb4b6f6 at cngrab+0x16 > #14 0xb9fce2 at vpanic+0xd2 > #15 0xb9fc04 at panic+0x14 > #16 0xe2c06a at vm_fault_lookup+0x13a > #17 0xe2b8e7 at vm_fault+0x77 > WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) failed > at > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:666 > #0 0x2318d4b9 at linux_dump_stack+0x19 > #1 0x2321a005 at drm_atomic_helper_check_modeset+0x1d5 > #2 0x23091d90 at intel_atomic_check+0x70 > #3 0x2321913e at drm_atomic_check_only+0x38e > #4 0x23219461 at drm_atomic_commit+0x11 > #5 0x23224793 at drm_client_modeset_commit_atomic+0xb3 > #6 0x2322458e at drm_client_modeset_commit_force+0x5e > #7 0x23260851 at drm_fb_helper_restore_fbdev_mode_unlocked+0x71 > #8 0x2325b092 at vt_kms_postswitch+0x132 > #9 0xa8bec5 at vt_fb_postswitch+0x15 > #10 0xa9153d at vt_window_switch+0xfd > #11 0xa8f59c at vtterm_cngrab+0x1c > #12 0xbec5bf at termcn_cngrab+0xf > #13 0xb4b6f6 at cngrab+0x16 > #14 0xb9fce2 at vpanic+0xd2 > #15 0xb9fc04 at panic+0x14 > #16 0xe2c06a at vm_fault_lookup+0x13a > #17 0xe2b8e7 at vm_fault+0x77 > WARNING !drm_modeset_is_locked(>mutex) failed at > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:871 > #0 0x2318d4b9 at linux_dump_stack+0x19 > #1 0x2321adbd at drm_atomic_helper_check_planes+0x8d > #2 0x23092da7 at intel_atomic_check+0x1087 > #3 0x2321913e at
Re: kernel panic and fun debugging
On Sat, Oct 17, 2020 at 12:58:48PM -0600, Warner Losh wrote: > On Sat, Oct 17, 2020, 12:00 PM Andrey V. Elsukov wrote: > > > On 15.10.2020 09:56, Steve Kargl wrote: > > > Just had a kernel panic. Best info I give you is > > > > > > % uname -a > > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 > > 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE > > i386 > > > > > > % kgdb gdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 > > > ... > > > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug... > > > /usr/ports/devel/gdb/work-py37/gdb-9.2/gdb/inferior.c:283: > > internal-error: struct inferior *find_inferior_pid(int): Assertion `pid != > > 0' failed. > > > A problem internal to GDB has been detected, > > > further debugging may prove unreliable. > > > > Hi, > > > > do you have /var/crash/core.txt.1 file? > > It may have some useful info. Also did you try an old version > > /usr/libexec/kgdb ? > > > > I got this same error, btw, when I pointed kgdb at the wrong kernel for the > core file. > > But you can 'more' the uncompressed vmcore to get at least a traceback if > the proper kernel is gone... > > Warner > There are only 2 kernel.debug on the system. % locate kernel.debug /usr/lib/debug/boot/kernel/kernel.debug /usr/lib/debug/boot/kernel.old/kernel.debug Using % kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 % kgdb /usr/lib/debug/boot/kernel.old/kernel.debug vmcore.1 Both have the same result. I didn't realize the panic text was recorded int vmcore.1. If I extracted everything correctly, here's what happen WARNING !drm_modeset_is_locked(>mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0x2318d4b9 at linux_dump_stack+0x19 #1 0x23219ec2 at drm_atomic_helper_check_modeset+0x92 #2 0x23091d90 at intel_atomic_check+0x70 #3 0x2321913e at drm_atomic_check_only+0x38e #4 0x23219461 at drm_atomic_commit+0x11 #5 0x23224793 at drm_client_modeset_commit_atomic+0xb3 #6 0x2322458e at drm_client_modeset_commit_force+0x5e #7 0x23260851 at drm_fb_helper_restore_fbdev_mode_unlocked+0x71 #8 0x2325b092 at vt_kms_postswitch+0x132 #9 0xa8bec5 at vt_fb_postswitch+0x15 #10 0xa9153d at vt_window_switch+0xfd #11 0xa8f59c at vtterm_cngrab+0x1c #12 0xbec5bf at termcn_cngrab+0xf #13 0xb4b6f6 at cngrab+0x16 #14 0xb9fce2 at vpanic+0xd2 #15 0xb9fc04 at panic+0x14 #16 0xe2c06a at vm_fault_lookup+0x13a #17 0xe2b8e7 at vm_fault+0x77 WARNING !drm_modeset_is_locked(>mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0x2318d4b9 at linux_dump_stack+0x19 #1 0x23219ec2 at drm_atomic_helper_check_modeset+0x92 #2 0x23091d90 at intel_atomic_check+0x70 #3 0x2321913e at drm_atomic_check_only+0x38e #4 0x23219461 at drm_atomic_commit+0x11 #5 0x23224793 at drm_client_modeset_commit_atomic+0xb3 #6 0x2322458e at drm_client_modeset_commit_force+0x5e #7 0x23260851 at drm_fb_helper_restore_fbdev_mode_unlocked+0x71 #8 0x2325b092 at vt_kms_postswitch+0x132 #9 0xa8bec5 at vt_fb_postswitch+0x15 #10 0xa9153d at vt_window_switch+0xfd #11 0xa8f59c at vtterm_cngrab+0x1c #12 0xbec5bf at termcn_cngrab+0xf #13 0xb4b6f6 at cngrab+0x16 #14 0xb9fce2 at vpanic+0xd2 #15 0xb9fc04 at panic+0x14 #16 0xe2c06a at vm_fault_lookup+0x13a #17 0xe2b8e7 at vm_fault+0x77 WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:666 #0 0x2318d4b9 at linux_dump_stack+0x19 #1 0x2321a005 at drm_atomic_helper_check_modeset+0x1d5 #2 0x23091d90 at intel_atomic_check+0x70 #3 0x2321913e at drm_atomic_check_only+0x38e #4 0x23219461 at drm_atomic_commit+0x11 #5 0x23224793 at drm_client_modeset_commit_atomic+0xb3 #6 0x2322458e at drm_client_modeset_commit_force+0x5e #7 0x23260851 at drm_fb_helper_restore_fbdev_mode_unlocked+0x71 #8 0x2325b092 at vt_kms_postswitch+0x132 #9 0xa8bec5 at vt_fb_postswitch+0x15 #10 0xa9153d at vt_window_switch+0xfd #11 0xa8f59c at vtterm_cngrab+0x1c #12 0xbec5bf at termcn_cngrab+0xf #13 0xb4b6f6 at cngrab+0x16 #14 0xb9fce2 at vpanic+0xd2 #15 0xb9fc04 at panic+0x14 #16 0xe2c06a at vm_fault_lookup+0x13a #17 0xe2b8e7 at vm_fault+0x77 WARNING !drm_modeset_is_locked(>mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_1/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0x2318d4b9 at linux_dump_stack+0x19 #1 0x2321adbd at drm_atomic_helper_check_planes+0x8d #2 0x23092da7 at intel_atomic_check+0x1087 #3 0x2321913e at drm_atomic_check_only+0x38e #4 0x23219461 at drm_atomic_commit+0x11 #5 0x23224793 at drm_client_modeset_commit_atomic+0xb3 #6 0x2322458e at drm_client_modeset_commit_force+0x5e #7 0x23260851 at drm_fb_helper_restore_fbdev_mode_unlocked+0x71 #8 0x2325b092 at vt_kms_postswitch+0x132 #9 0xa8bec5 at vt_fb_postswitch+0x15 #10 0xa9153d at vt_window_switch+0xfd #11 0xa8f59c at vtterm_cngrab+0x1c #12
bug in motd service / documentation
I've been away for a while and missed the change and complexity added to /etc/motd. I figured it out but I was led astray by not knowing that it was converted into a service that only runs at boot time. If you just follow the instructions in the template file, you will nothing changes. As a suggestion, maybe change this line in the /etc/motd.template file: Edit /etc/motd.template to change this login announcement. to: Edit /etc/motd.template to change this login announcement and reboot or manually restart the motd service in /etc/rc.d/motd as in: /etc/rc.d/motd restart and also add an entry to the man page for motd. This was on: FreeBSD boxolox 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366790: Sat Oct 17 08:57:56 CDT 2020 Dan ___ 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: kernel panic and fun debugging
On Sat, Oct 17, 2020 at 08:57:31PM +0300, Andrey V. Elsukov wrote: > On 15.10.2020 09:56, Steve Kargl wrote: > > Just had a kernel panic. Best info I give you is > > > > % uname -a > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 > > 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE > > i386 > > > > % kgdb gdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 > > ... > > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug... > > /usr/ports/devel/gdb/work-py37/gdb-9.2/gdb/inferior.c:283: internal-error: > > struct inferior *find_inferior_pid(int): Assertion `pid != 0' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > > do you have /var/crash/core.txt.1 file? > It may have some useful info. Also did you try an old version > /usr/libexec/kgdb ? > The only additional info in that file is mobile dumped core - see /var/crash/vmcore.1 Wed Oct 14 23:47:49 PDT 2020 FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386 panic: vm_fault_lookup: fault on nofault entry, addr: 0 It an older laptop, so I'm not ruling out memory showing its age. I'll also note that the laptop will panic once a week or so, when the swapper decides to swap out something drm. -- Steve ___ 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: kernel panic and fun debugging
On Sat, Oct 17, 2020, 12:00 PM Andrey V. Elsukov wrote: > On 15.10.2020 09:56, Steve Kargl wrote: > > Just had a kernel panic. Best info I give you is > > > > % uname -a > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 > 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE > i386 > > > > % kgdb gdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 > > ... > > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug... > > /usr/ports/devel/gdb/work-py37/gdb-9.2/gdb/inferior.c:283: > internal-error: struct inferior *find_inferior_pid(int): Assertion `pid != > 0' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Hi, > > do you have /var/crash/core.txt.1 file? > It may have some useful info. Also did you try an old version > /usr/libexec/kgdb ? > I got this same error, btw, when I pointed kgdb at the wrong kernel for the core file. But you can 'more' the uncompressed vmcore to get at least a traceback if the proper kernel is gone... Warner -- > WBR, Andrey V. Elsukov > > ___ 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: kernel panic and fun debugging
On 15.10.2020 09:56, Steve Kargl wrote: > Just had a kernel panic. Best info I give you is > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 > 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386 > > % kgdb gdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 > ... > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug... > /usr/ports/devel/gdb/work-py37/gdb-9.2/gdb/inferior.c:283: internal-error: > struct inferior *find_inferior_pid(int): Assertion `pid != 0' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. Hi, do you have /var/crash/core.txt.1 file? It may have some useful info. Also did you try an old version /usr/libexec/kgdb ? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
OpenZFS: encrypted dataset confusion (PEBKAM)
On 17/10/2020 14:08, Ryan Moeller wrote: On 10/17/20 9:02 AM, Graham Perrin wrote: root@momh167-gjp4-8570p:~ # date ; uname -v ; uptime Sat Oct 17 14:00:10 BST 2020 FreeBSD 13.0-CURRENT #69 r366648: Tue Oct 13 05:49:05 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 2:00PM up 9 mins, 5 users, load averages: 0.29, 0.56, 0.31 root@momh167-gjp4-8570p:~ # zpool export Transcend && ls -hl /Volumes/t500/VirtualBox ; zpool import Transcend && ls -hl /Volumes/t500/VirtualBox ls: /Volumes/t500/VirtualBox: No such file or directory total 18 drwxr-xr-x 2 grahamperrin grahamperrin 2B Sep 11 19:28 CloudReady drwxr-xr-x 6 grahamperrin grahamperrin 6B May 8 09:04 FreeBSD drwxr-xr-x 4 grahamperrin grahamperrin 4B Sep 20 17:03 Linux drwxr-xr-x 4 grahamperrin grahamperrin 7B Oct 16 17:41 Windows root@momh167-gjp4-8570p:~ # zfs get all Transcend/VirtualBox | grep -e crypt -e key -e mountpoint | sort Transcend/VirtualBox encryption aes-256-gcm - Transcend/VirtualBox encryptionroot Transcend/VirtualBox - Transcend/VirtualBox keyformat passphrase - Transcend/VirtualBox keylocation prompt local Transcend/VirtualBox keystatus unavailable - Transcend/VirtualBox mountpoint /Volumes/t500/VirtualBox inherited from Transcend root@momh167-gjp4-8570p:~ # zfs --version zfs-0.8.0-1 zfs-kmod-v2020100400-zfs_79f0935fa root@momh167-gjp4-8570p:~ # This doesn't necessarily mean the encrypted filesystem is mounted though. The contents you are seeing must be in the parent filesystem. Check the output of the mount command, you should find Transcend/VirtualBox is not mounted. True! Thank you. I didn't realise that from the outset I had written to the non-encrypted parent. Fixed: root@momh167-gjp4-8570p:~ # mount | grep Transcend Transcend on /Volumes/t500 (zfs, local, nfsv4acls) root@momh167-gjp4-8570p:~ # cd /Volumes/t500/ root@momh167-gjp4-8570p:/Volumes/t500 # mv VirtualBox vbox root@momh167-gjp4-8570p:/Volumes/t500 # zfs create -o encryption=on -o keyformat=passphrase Transcend/VirtualBox cannot create 'Transcend/VirtualBox': dataset already exists root@momh167-gjp4-8570p:/Volumes/t500 # zfs destroy Transcend/VirtualBox root@momh167-gjp4-8570p:/Volumes/t500 # ls -hl vbox total 18 drwxr-xr-x 2 grahamperrin grahamperrin 2B Sep 11 19:28 CloudReady drwxr-xr-x 6 grahamperrin grahamperrin 6B May 8 09:04 FreeBSD drwxr-xr-x 4 grahamperrin grahamperrin 4B Sep 20 17:03 Linux drwxr-xr-x 4 grahamperrin grahamperrin 7B Oct 16 17:41 Windows root@momh167-gjp4-8570p:/Volumes/t500 # zfs create -o encryption=on -o keyformat=passphrase Transcend/VirtualBox Enter passphrase: Re-enter passphrase: root@momh167-gjp4-8570p:/Volumes/t500 # mount | grep Transcend Transcend on /Volumes/t500 (zfs, local, nfsv4acls) Transcend/VirtualBox on /Volumes/t500/VirtualBox (zfs, local, nfsv4acls) root@momh167-gjp4-8570p:/Volumes/t500 # zpool status -v Transcend pool: Transcend state: ONLINE scan: scrub repaired 0B in 01:11:28 with 0 errors on Sun Oct 11 12:35:27 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:/Volumes/t500 # time mv vbox/* VirtualBox/ 0.630u 1378.236s 3:16:17.32 11.7% 15+167k 0+0io 235pf+0w root@momh167-gjp4-8570p:/Volumes/t500 # ___ 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: using an encrypted dataset without a prompt for its passphrase
On 10/17/20 9:02 AM, Graham Perrin wrote: root@momh167-gjp4-8570p:~ # date ; uname -v ; uptime Sat Oct 17 14:00:10 BST 2020 FreeBSD 13.0-CURRENT #69 r366648: Tue Oct 13 05:49:05 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 2:00PM up 9 mins, 5 users, load averages: 0.29, 0.56, 0.31 root@momh167-gjp4-8570p:~ # zpool export Transcend && ls -hl /Volumes/t500/VirtualBox ; zpool import Transcend && ls -hl /Volumes/t500/VirtualBox ls: /Volumes/t500/VirtualBox: No such file or directory total 18 drwxr-xr-x 2 grahamperrin grahamperrin 2B Sep 11 19:28 CloudReady drwxr-xr-x 6 grahamperrin grahamperrin 6B May 8 09:04 FreeBSD drwxr-xr-x 4 grahamperrin grahamperrin 4B Sep 20 17:03 Linux drwxr-xr-x 4 grahamperrin grahamperrin 7B Oct 16 17:41 Windows root@momh167-gjp4-8570p:~ # zfs get all Transcend/VirtualBox | grep -e crypt -e key -e mountpoint | sort Transcend/VirtualBox encryption aes-256-gcm - Transcend/VirtualBox encryptionroot Transcend/VirtualBox - Transcend/VirtualBox keyformat passphrase - Transcend/VirtualBox keylocation prompt local Transcend/VirtualBox keystatus unavailable - Transcend/VirtualBox mountpoint /Volumes/t500/VirtualBox inherited from Transcend root@momh167-gjp4-8570p:~ # zfs --version zfs-0.8.0-1 zfs-kmod-v2020100400-zfs_79f0935fa root@momh167-gjp4-8570p:~ # This doesn't necessarily mean the encrypted filesystem is mounted though. The contents you are seeing must be in the parent filesystem. Check the output of the mount command, you should find Transcend/VirtualBox is not mounted. ___ 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: using an encrypted dataset without a prompt for its passphrase
On 17/10/2020 12:35, Ryan Moeller wrote: On 10/17/20 5:55 AM, Graham Perrin wrote: On 17/10/2020 08:40, Ryan Moeller wrote: This is intentional. The pool can be imported but the filesystem is not mounted until the key is loaded. Thanks, the file system mounts without me entering a passphrase; is this intentional? It shouldn't be possible. # zfs mount storage/crypt cannot mount 'storage/crypt': encryption key not loaded root@momh167-gjp4-8570p:~ # date ; uname -v ; uptime Sat Oct 17 14:00:10 BST 2020 FreeBSD 13.0-CURRENT #69 r366648: Tue Oct 13 05:49:05 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 2:00PM up 9 mins, 5 users, load averages: 0.29, 0.56, 0.31 root@momh167-gjp4-8570p:~ # zpool export Transcend && ls -hl /Volumes/t500/VirtualBox ; zpool import Transcend && ls -hl /Volumes/t500/VirtualBox ls: /Volumes/t500/VirtualBox: No such file or directory total 18 drwxr-xr-x 2 grahamperrin grahamperrin 2B Sep 11 19:28 CloudReady drwxr-xr-x 6 grahamperrin grahamperrin 6B May 8 09:04 FreeBSD drwxr-xr-x 4 grahamperrin grahamperrin 4B Sep 20 17:03 Linux drwxr-xr-x 4 grahamperrin grahamperrin 7B Oct 16 17:41 Windows root@momh167-gjp4-8570p:~ # zfs get all Transcend/VirtualBox | grep -e crypt -e key -e mountpoint | sort Transcend/VirtualBox encryption aes-256-gcm - Transcend/VirtualBox encryptionroot Transcend/VirtualBox - Transcend/VirtualBox keyformat passphrase - Transcend/VirtualBox keylocation prompt local Transcend/VirtualBox keystatus unavailable - Transcend/VirtualBox mountpoint /Volumes/t500/VirtualBox inherited from Transcend root@momh167-gjp4-8570p:~ # zfs --version zfs-0.8.0-1 zfs-kmod-v2020100400-zfs_79f0935fa root@momh167-gjp4-8570p:~ # ___ 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: Status of SDIO
On 17 Oct 2020, at 6:08, ykla wrote: SDIO is used in raspberry pi. Rpi WiFi network needs SDIO drivers. But WIKI that about SDIO is not update for a long time. https://wiki.freebsd.org/SDIO So what's status of SDIO development? And maybe WIFI works well in raspberry pi? SDIO went in and works with MMCCAM. The brcmfmac driver I am still working on in my free time. Apparently that is also the only driver anyone ever seems interest in so far as no others have emerged either. /bz ___ 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: using an encrypted dataset without a prompt for its passphrase
On 10/17/20 5:55 AM, Graham Perrin wrote: On 17/10/2020 08:40, Ryan Moeller wrote: This is intentional. The pool can be imported but the filesystem is not mounted until the key is loaded. Thanks, the file system mounts without me entering a passphrase; is this intentional? It shouldn't be possible. # zfs mount storage/crypt cannot mount 'storage/crypt': encryption key not loaded ___ 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: using an encrypted dataset without a prompt for its passphrase
On 17/10/2020 08:40, Ryan Moeller wrote: This is intentional. The pool can be imported but the filesystem is not mounted until the key is loaded. Thanks, the file system mounts without me entering a passphrase; is this intentional? ___ 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: using an encrypted dataset without a prompt for its passphrase
On 10/17/20 1:54 AM, Graham Perrin wrote: root@momh167-gjp4-8570p:~ # zfs get all Transcend/VirtualBox | grep -e creation -e key -e crypt Transcend/VirtualBox creation Wed Sep 2 19:02 2020 - Transcend/VirtualBox encryption aes-256-gcm - Transcend/VirtualBox keylocation prompt local Transcend/VirtualBox keyformat passphrase - Transcend/VirtualBox encryptionroot Transcend/VirtualBox - Transcend/VirtualBox keystatus unavailable - root@momh167-gjp4-8570p:~ # I was prompted in early September but since then, no prompts. I can export and import the pool (Transcend) without entering the passphrase. Is this intended behaviour and if so: how does the pool – or the computer to which I connect the device (a mobile hard disk drive) – know that entry of the phrase is unnecessary? This is intentional. The pool can be imported but the filesystem is not mounted until the key is loaded. See zfs-load-key(8) -Ryan ___ 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"
Status of SDIO
SDIO is used in raspberry pi. Rpi WiFi network needs SDIO drivers. But WIKI that about SDIO is not update for a long time. https://wiki.freebsd.org/SDIO So what's status of SDIO development? And maybe WIFI works well in raspberry pi? ___ 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"
