f190c36b5d45 buildworld failure

[Graham Perrin]

From :

clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

*** [dma.full] Error code 1

make[5]: stopped in /usr/src/libexec/dma/dmagent
.ERROR_TARGET='dma.full'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/libexec/dma/dmagent/dma.full.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'






OpenPGP_signature
Description: OpenPGP digital signature

Freeze with mount of a UFS volume, main-n263630-ab3e6234ab6e-dirty

[Graham Perrin]

Froze at 06:40, when I used Plasma to mount and open the volume.

Photographs: 
. 
The freeze occurred a split-second after a click; the option to mount 
and open was replaced by the option to safely remove.


Probed not long after the event 
 but NB it's truly SDDM and 
Plasma (not LightDM and Budgie).


As far as I can tell: nothing useful logged, unfortunately. The freeze 
was hard (no ssh, and no shutdown in response to the power button).


No freeze with subsequent mount of the (cleaned) volume.



OpenPGP_signature
Description: OpenPGP digital signature

debug.verbose_sysinit=1

[Graham Perrin]

When debug.verbose_sysinit=1 is set in loader.conf(5), is normal to 
_not_ have BOOT and copyright messages?


Boot began with:

Jun 25 06:49:31 mowa219-gjp4-8570p-freebsd syslogd: kernel boot file is 
/boot/kernel/kernel


– then (timestamps etc. trimmed):

DEP)... done.
   malloc_init(&M_JADDREF)... done.
   malloc_init(&M_JREMREF)... done.
   malloc_init(&M_JMVREF)... done.
   malloc_init(&M_JNEWBLK)... done.
   malloc_init(&M_JFREEBLK)... done.
   malloc_init(&M_JFREEFRAG)... done.
   malloc_init(&M_JSEG)... done.
   malloc_init(&M_JSEGDEP)... done.
   malloc_init(&M_SBDEP)... done.
   malloc_init(&M_JTRUNC)... done.
   malloc_init(&M_JFSYNC)... done.
   malloc_init(&M_SENTINEL)... done.
   malloc_init(&M_SAVEDINO)... done.
   malloc_init(&M_JBLOCKS)... done.
   malloc_init(&M_MOUNTDATA)... done.
   malloc_init(&M_DIRHASH)... done.
   malloc_init(&M_DQUOT)... done.
   malloc_init(&M_UFSMNT)... done.
   malloc_init(&M_VMPGDATA)... done.
   malloc_init(&M_DEVFS2)... done.
   malloc_init(&M_DEVFS3)... done.
   malloc_init(&M_UMAHASH)... done.
   malloc_init(&M_UMA)... done.
   malloc_init(&M_CDEVP)... done.
   malloc_init(&M_DEVFS4)... done.
   malloc_init(&M_DEVFSRULE)... done.
   malloc_init(&M_DEVFS)... done.
   malloc_init(&M_CDEVPDATA)... done.
   malloc_init(&M_MSDOSFSNODE)... done.
   malloc_init(&M_MSDOSFSMNT)... done.
   malloc_init(&M_MSDOSFSFAT)... done.
   malloc_init(&M_NEWNFSRVCACHE)... done.
   malloc_init(&M_NEWNFSDCLIENT)... done.
   malloc_init(&M_NEWNFSDSTATE)... done.
   malloc_init(&M_FICT_PAGES)... done.
   malloc_init(&M_NEWNFSDLOCK)... done.
   malloc_init(&M_NEWNFSDLOCKFILE)... done.
   malloc_init(&M_NEWNFSSTRING)... done.
   malloc_init(&M_XENBUS)... done.
   malloc_init(&M_RPC)... done.
   malloc_init(&M_AESNI)... done.
   malloc_init(&M_PCI_LINK)... done.
   malloc_init(&M_NEWNFSUSERGROUP)... done.
   malloc_init(&M_ATKBDDEV)... done.
   malloc_init(&M_BXE_ILT)... done.
   malloc_init(&M_HVSOCK)... done.
   malloc_init(&M_IOMMU_DMAMAP)... done.
   malloc_init(&M_ISCI)... done.
   malloc_init(&M_APMDEV)... done.
   malloc_init(&M_NEWNFSDREQ)... done.
   malloc_init(&M_NEWNFSFH)... done.
   malloc_init(&M_NEWNFSCLOWNER)... done.
   malloc_init(&M_DMAR_CTX)... done.
   malloc_init(&M_DMAR_DOMAIN)... done.
   malloc_init(&M_DMAR_IDPGTBL)... done.
   malloc_init(&M_NEWNFSCLOPEN)... done.
   malloc_init(&M_NEWNFSCLDELEG)... done.
   malloc_init(&M_QPI)... done.
   malloc_init(&M_BUSDMA)... done.
   malloc_init(&M_BOUNCE)... done.
   malloc_init(&M_INTR)... done.
   malloc_init(&M_LEGACYDEV)... done.
   malloc_init(&M_MCA)... done.
   malloc_init(&M_CPUS)... done.
   malloc_init(&M_NEXUSDEV)... done.
   malloc_init(&M_XENHVM)... done.
   malloc_init(&M_NEWNFSCLCLIENT)... done.
   malloc_init(&M_NEWNFSCLLOCKOWNER)... done.
   malloc_init(&M_XENINTR)... done.
   malloc_init(&M_NEWNFSCLLOCK)... done.
   malloc_init(&M_FPUKERN_CTX)... done.
   malloc_init(&M_MEMDESC)... done.
   malloc_init(&M_NEWNFSV4NODE)... done.
   malloc_init(&M_NEWNFSDIRECTIO)... done.
   malloc_init(&M_NEWNFSDIROFF)... done.
   malloc_init(&M_NEWNFSDROLLBACK)... done.
   malloc_init(&M_NEWNFSLAYOUT)... done.
   malloc_init(&M_NEWNFSFLAYOUT)... done.
   malloc_init(&M_NEWNFSDEVINFO)... done.
   malloc_init(&M_NEWNFSSOCKREQ)... done.
   malloc_init(&M_NEWNFSCLDS)... done.
   malloc_init(&M_AXGBE)... done.
   malloc_init(&M_IAVF)... done.
   malloc_init(&M_ICE)... done.
   malloc_init(&M_ICE_OSDEP)... done.
   malloc_init(&M_ICE_RESMGR)... done.
   malloc_init(&M_NEWNFSLAYRECALL)... done.
   malloc_init(&M_NEWNFSDSESSION)... done.
   malloc_init(&M_NEWNFSREQ)... done.
   malloc_init(&M_NEWNFSMNT)... done.
   malloc_init(&M_NFS_FHA)... done.
   malloc_init(&M_PFSNODES)... done.
   malloc_init(&M_PFSVNCACHE)... done.
   malloc_init(&M_IXL)... done.
   malloc_init(&M_TMPFSEA)... done.
   malloc_init(&M_TMPFSMNT)... done.
   malloc_init(&M_TMPFSNAME)... done.
   malloc_init(&M_SMARTPQI)... done.
   malloc_init(&M_MADT)... done.
   malloc_init(&M_TMPFSDIR)... done.
   malloc_init(&M_IOAPIC)... done.
   malloc_init(&M_LAPIC)... done.
   malloc_init(&M_FLASHMAP)... done.
   malloc_init(&M_MSI)... done.
   tunable_mbinit(0)... done.
   kstack_cache_init(0)... done.
   pmap_bootstrap_la57(0)... done.
   authtls_init(0)... done.
   vt_update_static(&vt_consdev)... VT(efifb): resolution 1600x900
done.
   sleepinit(0)... done.
   vt_init_font(&vt_consdev)... done.
   vid_malloc_init(0)... done.
   scmeminit(0)... done.
   authnone_init(0)... done.
   authunix_init(0)... done.
subsystem 180
   init_dynamic_kenv(0)... done.
   static_hints_to_env(0)... done.
subsystem 181
   xen_hvm_sysinit(0)... done.
   hyperv_init(0)... done.
subsystem 1a4
   mtx_pool_setup_dynamic(0)... done.
subsystem 1ac
   usb_quirk_init(0)... done.
   filelistinit(0)... done.
   lf_init(0)... done.
   usb_linux_init(0)... done.
   nlm_client_init(0)... done.
   hidquirk_init(0)... done.
   linux_ww_init(0)... done.
   mtx_sysinit(&to_kill_g

debug.verbose_sysinit=1 and kern.msgbufsize=196608

[Graham Perrin]

On 25/06/2023 21:32, David Wolfskill wrote:

On Sun, Jun 25, 2023 at 09:20:40PM +0100, Graham Perrin wrote:

When debug.verbose_sysinit=1 is set in loader.conf(5), is normal to _not_
have BOOT and copyright messages?

It's normal (in that situation) to require a higher value in
kern.msgbufsize if you want the entire dmesg output saved in
/var/run/dmesg.boot, yes.

I use a shell script to modify that (in /boot/loader.conf.d/) in
conjunction with requesting a "verbose" (or not) boot.

E.g., on my laptop, the default value is 98304, which is fine for a
"normal" boot; for a "verbose" boot, I set it to 196608 (which works in
this case).

…

Thanks. 196608 was enough for me.


OpenPGP_signature
Description: OpenPGP digital signature

f190c36b5d45 buildworld failure: ld: error: undefined symbol: SSL_get_peer_certificate

[Graham Perrin]

On 25/06/2023 20:57, Graham Perrin wrote:

From <https://reviews.freebsd.org/P590$177>:

clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

*** [dma.full] Error code 1

make[5]: stopped in /usr/src/libexec/dma/dmagent
.ERROR_TARGET='dma.full'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/libexec/dma/dmagent/dma.full.meta' 


.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'


<https://cgit.freebsd.org/src/log/?qt=range&q=f190c36b5d45>


Thanks to a hint from David H. Wolfskill:

# Meta data file 
/usr/obj/usr/src/amd64.amd64/libexec/dma/dmagent/dma.full.meta
CMD cc -target x86_64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -O3 -pipe 
-march=native -mtune=native -fno-common -DOPENSSL_API_COMPAT=0x1010L 
-I/usr/src/contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME 
-DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' 
-DDMA_VERSION='"v0.13+"' -DDMA_ROOT_USER='"mailnull"' 
-DDMA_GROUP='"mail"' -fPIE -g -gz=zlib -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition 
-Wno-pointer-sign -Wdate-time -Wformat=2 -Wno-format-extra-args -Werror 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter 
-Qunused-arguments -Wl,-zrelro -pie   -o dma.full aliases_parse.o 
aliases_scan.o base64.o conf.o crypto.o dma.o dns.o local.o mail.o net.o 
spool.o util.o   -lssl  -lcrypto

CWD /usr/obj/usr/src/amd64.amd64/libexec/dma/dmagent
TARGET dma.full
OODATE aliases_parse.o aliases_scan.o base64.o conf.o crypto.o dma.o 
dns.o local.o mail.o net.o spool.o util.o

-- command output --
ld: error: undefined symbol: SSL_get_peer_certificate
>>> referenced by crypto.c:198 (/usr/src/contrib/dma/crypto.c:198)
>>>   crypto.o:(smtp_init_crypto)
>>> did you mean: SSL_get0_peer_certificate
>>> defined in: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libssl.so
__cxa_thread_call_dtors: dtr 0xc439c0 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0xc440f0 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0xc44400 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0xbc9870 from unloaded dso, skipping
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 1582
# Start 1687753164.054683
V 5
E 1710 /bin/sh
R 1710 /etc/libmap.conf
R 1710 /usr/local/etc/libmap.d
R 1710 /usr/local/etc/libmap.d/mesa.conf
R 1710 /var/run/ld-elf.so.hints
R 1710 /lib/libedit.so.8
R 1710 /lib/libc.so.7
R 1710 /lib/libtinfow.so.9
R 1710 /usr/share/locale/en_GB.UTF-8/LC_COLLATE
R 1710 /usr/share/locale/en_GB.UTF-8/LC_CTYPE
R 1710 /usr/share/locale/en_GB.UTF-8/LC_MONETARY
R 1710 /usr/share/locale/en_GB.UTF-8/LC_NUMERIC
R 1710 /usr/share/locale/en_GB.UTF-8/LC_TIME
R 1710 /usr/share/locale/en_GB.UTF-8/LC_MESSAGES
F 1710 1713
E 1713 /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/cc
F 1713 1718
E 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/Scrt1.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crti.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crtbeginS.o
R 1718 aliases_parse.o
R 1718 aliases_scan.o
R 1718 base64.o
R 1718 conf.o
R 1718 crypto.o
R 1718 dma.o
R 1718 dns.o
R 1718 local.o
R 1718 mail.o
R 1718 net.o
R 1718 spool.o
R 1718 util.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libssl.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libcrypto.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc.a
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc_s.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/lib/libc.so.7
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc_nonshared.a
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc.a
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc_s.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crtendS.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crtn.o
R 1718 dma.full.tmpf410f8d
W 1718 dma.full.tmpf410f8d
D 1718 dma.full.tmpf410f8d
X 1718 1 0
X 1713 1 0
X 1710 1 0
# Stop 1687753166.044683
# Bye bye



OpenPGP_signature
Description: OpenPGP digital signature

Re: f190c36b5d45 buildworld failure: ld: error: undefined symbol: SSL_get_peer_certificate

[Graham Perrin]

On 26/06/2023 05:31, Graham Perrin wrote:

On 25/06/2023 20:57, Graham Perrin wrote:

From <https://reviews.freebsd.org/P590$177>:

clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

*** [dma.full] Error code 1

make[5]: stopped in /usr/src/libexec/dma/dmagent
.ERROR_TARGET='dma.full'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/libexec/dma/dmagent/dma.full.meta' 


.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes 
verbose'



<https://cgit.freebsd.org/src/log/?qt=range&q=f190c36b5d45>


Thanks to a hint from David H. Wolfskill:

# Meta data file 
/usr/obj/usr/src/amd64.amd64/libexec/dma/dmagent/dma.full.meta
CMD cc -target x86_64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -O3 -pipe 
-march=native -mtune=native -fno-common 
-DOPENSSL_API_COMPAT=0x1010L -I/usr/src/contrib/dma 
-DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME 
-DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' 
-DDMA_VERSION='"v0.13+"' -DDMA_ROOT_USER='"mailnull"' 
-DDMA_GROUP='"mail"' -fPIE -g -gz=zlib -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition 
-Wno-pointer-sign -Wdate-time -Wformat=2 -Wno-format-extra-args 
-Werror -Wmissing-variable-declarations -Wthread-safety 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter 
-Qunused-arguments -Wl,-zrelro -pie   -o dma.full aliases_parse.o 
aliases_scan.o base64.o conf.o crypto.o dma.o dns.o local.o mail.o 
net.o spool.o util.o   -lssl -lcrypto

CWD /usr/obj/usr/src/amd64.amd64/libexec/dma/dmagent
TARGET dma.full
OODATE aliases_parse.o aliases_scan.o base64.o conf.o crypto.o dma.o 
dns.o local.o mail.o net.o spool.o util.o

-- command output --
ld: error: undefined symbol: SSL_get_peer_certificate
>>> referenced by crypto.c:198 (/usr/src/contrib/dma/crypto.c:198)
>>>   crypto.o:(smtp_init_crypto)
>>> did you mean: SSL_get0_peer_certificate
>>> defined in: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libssl.so
__cxa_thread_call_dtors: dtr 0xc439c0 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0xc440f0 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0xc44400 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0xbc9870 from unloaded dso, skipping
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


*** Error code 1

-- filemon acquired metadata --
# filemon version 5
# Target pid 1582
# Start 1687753164.054683
V 5
E 1710 /bin/sh
R 1710 /etc/libmap.conf
R 1710 /usr/local/etc/libmap.d
R 1710 /usr/local/etc/libmap.d/mesa.conf
R 1710 /var/run/ld-elf.so.hints
R 1710 /lib/libedit.so.8
R 1710 /lib/libc.so.7
R 1710 /lib/libtinfow.so.9
R 1710 /usr/share/locale/en_GB.UTF-8/LC_COLLATE
R 1710 /usr/share/locale/en_GB.UTF-8/LC_CTYPE
R 1710 /usr/share/locale/en_GB.UTF-8/LC_MONETARY
R 1710 /usr/share/locale/en_GB.UTF-8/LC_NUMERIC
R 1710 /usr/share/locale/en_GB.UTF-8/LC_TIME
R 1710 /usr/share/locale/en_GB.UTF-8/LC_MESSAGES
F 1710 1713
E 1713 /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/cc
F 1713 1718
E 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/Scrt1.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crti.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crtbeginS.o
R 1718 aliases_parse.o
R 1718 aliases_scan.o
R 1718 base64.o
R 1718 conf.o
R 1718 crypto.o
R 1718 dma.o
R 1718 dns.o
R 1718 local.o
R 1718 mail.o
R 1718 net.o
R 1718 spool.o
R 1718 util.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libssl.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libcrypto.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc.a
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc_s.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/lib/libc.so.7
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc_nonshared.a
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc.a
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libgcc_s.so
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crtendS.o
R 1718 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crtn.o
R 1718 dma.full.tmpf410f8d
W 1718 dma.full.tmpf410f8d
D 1718 dma.full.tmpf410f8d
X 1718 1 0
X 1713 1 0
X 1710 1 0
# Stop 1687753166.044683
# Bye bye

I removed /usr/obj/usr/src/amd64.amd64 (or maybe, more bluntly, the 
contents of /usr/obj/).


Updated src to f81be7a8318b, built world OK.

-

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Graham Perrin]

On 28/06/2023 17:54, Naman Sood wrote:

After doing a system update to the newest CURRENT, dhclient is not able to 
obtain an IP address for itself over an eduroam WPA2-Enterprise PEAP network. …


No problem with eduroam here,

% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n263799-f81be7a8318b-dirty: Mon Jun 26 22:09:58 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1400092 1400090

%


I'm using the rtwn network driver. …


iwn(4) here.



… makes me think the change might be related to the recent OpenSSL migration? …


I wonder.

I just realised my discrepancy above, 1400092 1400090. It's unlike me to 
forget an installworld, oops.


 
was the OpenSSL 3.0 update bump from 1400091 to 1400092.


I'll installworld then review.



OpenPGP_signature
Description: OpenPGP digital signature

f81be7a8318b installworld failed

[Graham Perrin]

…
===> stand/efi/loader_4th (install)
installing DIRS BINDIR
install  -d -m 0755 -o root  -g wheel  /boot
/usr/local/bin/ccache cc -target x86_64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -O3 -pipe 
-march=native -mtune=native -fno-common   -Wformat -fshort-wchar 
-mno-red-zone -nostdinc -I/usr/obj/usr/src/amd64.amd64/stand/libsa 
-I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys 
-Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface 
-ffunction-sections -fdata-sections -DLOADER_GELI_SUPPORT 
-I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -ffreestanding 
-mno-mmx -mno-sse -mno-avx -mno-avx2 -msoft-float -fPIC -mno-red-zone 
-mno-relax -I. -Iinclude -I/usr/src/stand/efi/loader_4th/../loader 
-I/usr/src/stand/libsa/zfs -I/usr/src/sys/contrib/openzfs/include 
-I/usr/src/sys/contrib/openzfs/include/os/freebsd/zfs -DEFI_ZFS_BOOT 
-fPIC -I/usr/src/stand/efi/loader_4th 
-I/usr/src/stand/efi/loader_4th/arch/amd64 -I/usr/src/stand/efi/include 
-I/usr/src/stand/efi/include/amd64 
-I/usr/src/sys/contrib/dev/acpica/include -I/usr/src/stand/i386/libi386 
-DEFI -I/usr/src/stand/common -fPIC -I/usr/src/stand/ficl 
-I/usr/src/stand/ficl/amd64 -I/usr/src/stand/common -DBF_DICTSIZE=3 
-DLOADER_MSDOS_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_NET_SUPPORT 
-DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -DLOADER_ZFS_SUPPORT 
-I/usr/src/stand/libsa/zfs -I/usr/src/sys/cddl/boot/zfs 
-I/usr/src/sys/cddl/contrib/opensolaris/uts/common 
-DHELP_FILENAME=\"loader.help.efi\" -g -gz=zlib  -std=gnu99 
-Wno-format-zero-length -Wsystem-headers -Werror -Wno-pointer-sign 
-Wdate-time -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses  -Oz -Qunused-arguments 
-I/usr/src/sys/teken -I/usr/src/contrib/pnglite 
ERROR-tried-to-rebuild-during-make-install -c 
/usr/src/stand/efi/loader_4th/../loader/bootinfo.c -o bootinfo.o
clang: error: no such file or directory: 
'ERROR-tried-to-rebuild-during-make-install'

*** [bootinfo.o] Error code 1

make[6]: stopped in /usr/src/stand/efi/loader_4th
1 error

make[6]: stopped in /usr/src/stand/efi/loader_4th

make[5]: stopped in /usr/src/stand/efi

make[4]: stopped in /usr/src/stand

make[3]: stopped in /usr/src

make[2]: stopped in /usr/src
  187.16 real    52.07 user   109.04 sys
*** [installworld] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src

make: stopped in /usr/src
% uname -KU
1400092 1400090
% uname -a
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n263799-f81be7a8318b-dirty: Mon Jun 26 22:09:58 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

%



OpenPGP_signature
Description: OpenPGP digital signature

651d1efd96a6 buildworld failed

[Graham Perrin]

% uname -KU
1400092 1400090
% uname -a
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n263799-f81be7a8318b-dirty: Mon Jun 26 22:09:58 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

% bectl list -c creation | tail -n 2
n263630-ab3e6234ab6e-c -  -  644M  2023-06-24 11:42
n263799-f81be7a8318b-a NR /  429G  2023-06-27 03:14
%



…
In file included from 
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3.c:13:
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3_impl.h:53:10: 
fatal error: 'immintrin.h' file not found

#include 
 ^
1 error generated.
*** [Support/BLAKE3/blake3.o] Error code 1

make[4]: stopped in /usr/src/lib/clang/libllvm
.ERROR_TARGET='Support/BLAKE3/blake3.o'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/Support_BLAKE3_blake3.o.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='/usr/local/bin/ccache cc  -O2 -pipe -O3 -pipe -march=native 
-mtune=native -fno-common 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/sys/contrib/zstd/lib 
-I/usr/src/contrib/llvm-project/llvm/lib/Target/X86 
-I/usr/src/contrib/llvm-project/llvm/lib/ObjCopy -DBLAKE3_USE_NEON=0 
-I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC 
-DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd14.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd14.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" 
-DLLVM_TARGET_ENABLE_X86 
-DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -gline-tables-only -std=gnu99 -Wno-format-zero-length 
-Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-parameter 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c 
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3.c -o 
Support/BLAKE3/blake3.o; ;'

.CURDIR='/usr/src/lib/clang/libllvm'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm'
.TARGETS='all'
CPUTYPE=''
…


# Meta data file 
/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/Support_BLAKE3_blake3.o.meta
CMD /usr/local/bin/ccache cc  -O2 -pipe -O3 -pipe -march=native -mtune=native 
-fno-common  -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/sys/contrib/zstd/lib 
-I/usr/src/contrib/llvm-project/llvm/lib/Target/X86 
-I/usr/src/contrib/llvm-project/llvm/lib/ObjCopy -DBLAKE3_USE_NEON=0 
-I/usr/src/lib/clang/include -I/usr/src/contrib/llvm-project/llvm/include 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-DHAVE_VCS_VERSION_INC -DNDEBUG 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd14.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd14.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 
-DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -gline-tables-only -std=gnu99 -Wno-format-zero-length 
-Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-parameter 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c 
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3.c -o 
Support/BLAKE3/blake3.o
CMD 
CWD /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
TARGET Support/BLAKE3/blake3.o
-- command output --
In file included from 
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3.c:13:
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3_impl.h:53:10: 
fatal error: 'immintrin.h' file not found
#include 
 ^
1 error generated.

*** Error code 1

-- file

Re: dhclient unable to negotiate on WPA2-Enterprise network (eduroam)

[Graham Perrin]

On 29/06/2023 09:07, Graham Perrin wrote:


… I just realised my discrepancy above, 1400092 1400090.




… I'll installworld then review.


Sorry, review is delayed.

(I remembered and repeated the cause of the discrepancy, an installworld 
failure 
<https://lists.freebsd.org/archives/freebsd-current/2023-June/003944.html>; 
and I can not yet build the most recent src.)




OpenPGP_signature
Description: OpenPGP digital signature

651d1efd96a6 buildworld failed, cd9da8d072e4 succeeded

[Graham Perrin]

On 29/06/2023 19:16, Graham Perrin wrote:

% uname -KU
1400092 1400090
% uname -a
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT 
#0 main-n263799-f81be7a8318b-dirty: Mon Jun 26 22:09:58 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

% bectl list -c creation | tail -n 2
n263630-ab3e6234ab6e-c -  -  644M  2023-06-24 11:42
n263799-f81be7a8318b-a NR /  429G  2023-06-27 03:14
%


For the record: I booted the earlier ab3e6234ab6e, which had no version 
mismatch (between kernel and user environment), then built and installed 
cd9da8d072e4 without difficulty.


(I guess, I should be unsurprised by failures whilst there was a mismatch.)





…
In file included from 
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3.c:13:
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3_impl.h:53:10: 
fatal error: 'immintrin.h' file not found

#include 
 ^
1 error generated.
*** [Support/BLAKE3/blake3.o] Error code 1

make[4]: stopped in /usr/src/lib/clang/libllvm
.ERROR_TARGET='Support/BLAKE3/blake3.o'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/Support_BLAKE3_blake3.o.meta' 


.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='/usr/local/bin/ccache cc  -O2 -pipe -O3 -pipe 
-march=native -mtune=native -fno-common 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/sys/contrib/zstd/lib 
-I/usr/src/contrib/llvm-project/llvm/lib/Target/X86 
-I/usr/src/contrib/llvm-project/llvm/lib/ObjCopy -DBLAKE3_USE_NEON=0 
-I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC 
-DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd14.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd14.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" 
-DLLVM_TARGET_ENABLE_X86 
-DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections -gline-tables-only -std=gnu99 -Wno-format-zero-length 
-Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-parameter 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c 
/usr/src/contrib/llvm-project/llvm/lib/Support/BLAKE3/blake3.c -o 
Support/BLAKE3/blake3.o; ;'

.CURDIR='/usr/src/lib/clang/libllvm'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm'
.TARGETS='all'
CPUTYPE=''
…






OpenPGP_signature
Description: OpenPGP digital signature

Re: f81be7a8318b installworld failed

[Graham Perrin]

On 29/06/2023 19:12, Kyle Evans wrote:

…

This error indicates that for some reason we're trying to build during 
the install phase; either tree was updated since last build, messed up 
timestamps on build artifacts, messed up clock, etc. Whatever the case 
may be, make(1) sees the build output of this as out-of-date. 



Thanks.

I'm past the failure now, happy to assume that the version mismatch 
(1400092, 1400090), prior to build, was an aggravating factor.




OpenPGP_signature
Description: OpenPGP digital signature

Re: System lockups on 14-current with Plasma 5

[Graham Perrin]

Plasma here, packages upgraded a few hours ago.

% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n263900-cd9da8d072e4-dirty: Sat Jul  1 23:55:17 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64 1400092 1400092

%


On 03/07/2023 22:20, Patrick McMunn wrote:

everything except the mouse cursor becomes completely unresponsive.


If you key Alt-Tab, then does KWin walk through windows?

If you key Control+Alt+F2, then is there a switch away (from the 
unresponsive desktop environment at ttyv8) to ttyv1?


Generally: to minimise the possibility of requiring a non-graceful stop 
of the system, you can configure the power button as outlined at 
. 



What's your graphics hardware?



OpenPGP_signature
Description: OpenPGP digital signature

Re: Possible PEBKAC bug for fwget(8)?

[Graham Perrin]

On 07/07/2023 00:58, Kenneth Raplee wrote:

… `fwget -vn pci`, it only prints out the following usage info: …


I made what might have been the same mistake, 
.


PCI pictured at 
, 
somehow I don't imagine finding that type of slot inside the HP 
EliteBook where I ran the command ;-)




OpenPGP_signature
Description: OpenPGP digital signature

Re: kernel: sonewconn: pcb 0xfffff8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (60 occurrences), ?

[Graham Perrin]

On 21/06/2023 01:29, Graham Perrin wrote:


… Thanks, people.

A few hours ago I took a hint from one of the pages linked from 
<https://dan.langille.org/2020/01/01/listen-queue-overflow/>, added a 
line to my sysctl.conf(5).


…
% grep ipc /etc/sysctl.conf
kern.ipc.soacceptqueue=256
%


I found no improvement from that. IIRC I also tried 512.



OpenPGP_signature
Description: OpenPGP digital signature

Unreliability with DHCP

[Graham Perrin]

1. Sleep (suspend) whilst connected to one network

2. connect to a network elsewhere

3. wake (resume).

Result:

/etc/resolv.conf frequently contains outdated information. In some 
(maybe all) such cases, the IPv4 inet address is outdated; and so on.


Which /etc/rc.d/ file(s) should I attempt to fix?

I imagine using the resume keyword, which is currently used by only one 
script:


% rcorder -k resume /etc/rc.d/*
/etc/rc.d/ntpd
%


I routinely run the command below to work around the bug (and observe 
the states of things) – run _after_ the bug bites. I'd prefer a fix, to 
prevent the bites.


ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig 
wlan0 down && ifconfig em0 down && sleep 5 ; ls 
/var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15
; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c 2 
-4 freshports.org




OpenPGP_signature
Description: OpenPGP digital signature

Fwd: Unreliability with DHCP

[Graham Perrin]

Can anyone from freebsd-net@ help?


 Forwarded Message 
Subject:Unreliability with DHCP
Date:   Sun, 30 Jul 2023 16:17:43 +0100
From:   Graham Perrin 
Organisation:   FreeBSD
To: FreeBSD CURRENT 



1. Sleep (suspend) whilst connected to one network

2. connect to a network elsewhere

3. wake (resume).

Result:

/etc/resolv.conf frequently contains outdated information. In some 
(maybe all) such cases, the IPv4 inet address is outdated; and so on.


Which /etc/rc.d/ file(s) should I attempt to fix?

I imagine using the resume keyword, which is currently used by only one 
script:


% rcorder -k resume /etc/rc.d/*
/etc/rc.d/ntpd
%


I routinely run the command below to work around the bug (and observe 
the states of things) – run _after_ the bug bites. I'd prefer a fix, to 
prevent the bites.


ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig 
wlan0 down && ifconfig em0 down && sleep 5 ; ls 
/var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15
; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c 2 
-4 freshports.org




OpenPGP_signature
Description: OpenPGP digital signature

Re: Fwd: Unreliability with DHCP

[Graham Perrin]

On 05/08/2023 12:39, Oleksandr Kryvulia wrote:

04.08.23 19:07, Graham Perrin пише:


Can anyone from freebsd-net@ help?


 Forwarded Message 
Subject: Unreliability with DHCP
Date: Sun, 30 Jul 2023 16:17:43 +0100
From: Graham Perrin 
Organisation: FreeBSD
To: FreeBSD CURRENT 



1. Sleep (suspend) whilst connected to one network

2. connect to a network elsewhere

3. wake (resume).

Result:

/etc/resolv.conf frequently contains outdated information. In some 
(maybe all) such cases, the IPv4 inet address is outdated; and so on.


Which /etc/rc.d/ file(s) should I attempt to fix?

I imagine using the resume keyword, which is currently used by only 
one script:


% rcorder -k resume /etc/rc.d/*
/etc/rc.d/ntpd
%


I routinely run the command below to work around the bug (and observe 
the states of things) – run _after_ the bug bites. I'd prefer a fix, 
to prevent the bites.


ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig 
wlan0 down && ifconfig em0 down && sleep 5 ; ls 
/var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15
; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c 
2 -4 freshports.org





As dirty workaround I have in my /etc/rc.resume

service netif restart
service routing restart



Thanks, I'll try when I'm next on campus.

I do know that 'service routing restart' can be problematic. Please, 
see, for example, <https://pastebin.com/raw/mXmVPruq>; I had something 
similar a few minutes ago.

service routing restart (was: Unreliability with DHCP)

[Graham Perrin]

On 05/08/2023 23:16, Graham Perrin wrote:

On 05/08/2023 12:39, Oleksandr Kryvulia wrote:

04.08.23 19:07, Graham Perrin пише:


…



As dirty workaround I have in my /etc/rc.resume

service netif restart
service routing restart


 … 'service routing restart' can be problematic. Please, see, for 
example, <https://pastebin.com/raw/mXmVPruq>; I had something similar 
a few minutes ago.


After 'service routing restart' (alone), should 'route show default' 
find a route?


<https://reviews.freebsd.org/P599$29>

route: route has not been found: No error: 0



OpenPGP_signature
Description: OpenPGP digital signature

service routing restart, service dhclient restart (was: Unreliability with DHCP)

[Graham Perrin]

Thanks,

On 06/08/2023 08:36, Oleksandr Kryvulia wrote:
… In my case default route is assigned by dhclient, so 'service 
routing restart' must be run quickly after 'service netif restart' - 
before we receive dhcp offer. 


Is this documented and explained somewhere, or did you learn through 
trial and error?



Another option is to run 'service dhclient restart wlan0' after 
routing restart. …


Is there, similarly, a need to rush the two commands?

 no route;
 /etc/rc.d/dhclient: WARNING: 
failed to start dhclient

Re: Has the update procedure changed?

[Graham Perrin]

On 08/08/2023 03:50, Robert Huff wrote:


…

1) It would be really nice is someone would take a look and make
sure these 100% non-contradictory.

…


Looks by people should, ideally, include:


209744 – Move installation instructions from UPDATING to new file


256830 – the COMMON ITEMS: section in /usr/src/UPDATING makes no mention 
of etcupdate


… plus the discussion, which I can't find (I thought it was a BR), about 
disorderly numbering; and so on.




OpenPGP_signature
Description: OpenPGP digital signature

Re: Has the update procedure changed?

[Graham Perrin]

On 06/08/2023 09:20, Mark Millard wrote:


… https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
section 26.6.1 lists:

# git pull /usr/src
check /usr/src/UPDATING
# cd /usr/src
# make -j4 buildworld
# make -j4 kernel
# shutdown -r now
# etcupdate -p
# cd /usr/src
# make installworld
# etcupdate -B
# shutdown -r now

The material in 26.6.5 does not repeat all that, it is
more of a summary that is presented. …


IMHO a summary should not omit any step that is _essential_.

etcupdate -B is non-optional.




OpenPGP_signature
Description: OpenPGP digital signature

Re: ZFS deadlock in 14

[Graham Perrin]

 maybe.


OpenPGP_signature
Description: OpenPGP digital signature

Re: 14.0 boot failure

[Graham Perrin]

On 05/08/2023 00:45, Kevin Oberman wrote:
A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails 
to boot. …


I refrained from updating after reading this.

Any news?

TIA



OpenPGP_signature
Description: OpenPGP digital signature

Re: 14.0 boot failure

[Graham Perrin]

On 09/08/2023 07:10, Kevin Oberman wrote:
I closed the ticket. 


I wasn't aware of a ticket, thanks for the update.

Yesterday's 09c20a293280 boots fine for me.

Re: ZFS deadlock in 14

[Graham Perrin]

On 11/08/2023 04:32, Kevin Bowling wrote:

Spoke too soon still seeing zfs lockups 


Kevin, do you have a log device? (ZIL)


under heavy poudriere workload …


Can you tell what was building when the problem occurred? For example,

qutebrowser 
/usr/local/poudriere/data/logs/bulk/main-default/latest/index.html


– where main is my main jail, and qutebrowser is readily compatible 
(browsers such as Chromium and Firefox are not).

Re: Speed improvements in ZFS

[Graham Perrin]

On 15/08/2023 13:05, Alexander Leidinger wrote:

… periodic runs …


Here, I get a sense that these benefit greatly from L2ARC.

… So whatever was done inside ZFS or VFS or nullfs between 2023-06-19 
and 2023-07-20 has given a huge speed improvement. …


 not within the time 
frame, the most recent commit was 2023-06-16.


 
the two most recent commits might be of interest. Related: 
, 
. 

Re: Fwd: Unreliability with DHCP

[Graham Perrin]

On 06/08/2023 17:05, Warner Losh wrote:


On Sun, Aug 6, 2023 at 12:38 AM Kevin Oberman  wrote:

On Sat, Aug 5, 2023 at 3:16 PM Graham Perrin
 wrote:

On 05/08/2023 12:39, Oleksandr Kryvulia wrote:

> …
>
> As dirty workaround I have in my /etc/rc.resume
>
> service netif restart
> service routing restart

Thanks, I'll try when I'm next on campus.

I do know that 'service routing restart' can be problematic.
Please,
see, for example, <https://pastebin.com/raw/mXmVPruq>; I had
something
similar a few minutes ago.


My usual solution is "service netif restart wlan0" (or the
interface you are using). It should restart the interface, if
rc.conf calls for it, dhcpclient and wpa_supplicant (if appropriate).


I'll have to remember that. I've been removing and reinsterting my usb 
dongle when when dhclient fails.
I'd like to move to the internal wlan card, but the driver support has 
some show-stopper issues with
suspend/resume for me more basic than dhclient... However, once those 
are resolved, I'd need a way to

workaround the dhclient bug.

Anybody have a clue why this is needed?

Warner



I have no clue, however if such needs are commonplace then maybe someone 
who's network-savvy can make a bug report. There's been tumbleweed, over 
the years, whenever I've tried to make things reliable for myself.


Warner, I'll be interested to know whether what's below (also) works 
around things for you. Assuming ue0.


route delete default ; ifconfig ue0 down && sleep 5 ; ifconfig ue0 up && 
sleep 15 ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; 
ping -c 2 -4 freshports.org

etcupdate -B, /.cshrc and /.profile

[Graham Perrin]

If I recall correctly, a few hours ago etcupdate -B resulted in removal 
of two files:


/.cshrc
/.profile

Is this degree of checking/removal a novelty?

(I can't recall the files' contents, or when I created them. I guess 
that I carelessly created them as dot files months ago without realising 
that I wasn't at ~, I don't mourn their loss.)


Re: the manual pages below, I'm reminded of where files _should_ be.

Boot failures with 14.0-ALPHA1

[Graham Perrin]

I'll update to ALPHA2.

In the meantime, briefly: 

– no visible progress beyond the four lines of EFI framebuffer information.

In each case, I worked around by removing a USB flash drive that's used 
for L2ARC.


The most recent incident was preceded by a power button shutdown, in 
response to a drm-510-kmod blackout (GPU lockup etc.) whilst typing in 
Firefox (comparable to  
for drm-515-kmod 5.15.25).


The prior incident was also preceded by a power button shutdown (in 
response to a blackout at Plasma log out time). This was remarkable in 
that there was an unexpected restart, when I expected the computer to 
power off.

ZFS deadlock in 14: without ZIL

[Graham Perrin]

On 19/08/2023 00:03, Mark Millard wrote:

I believe the below quoted messages were reports of deadlocks
based on after the following 2 MFV being in place in their
environments:

Thu, 10 Aug 2023
. . .
 • git: cd25b0f740f8 - main - zfs: cherry-pick fix from openzfs Martin 
Matuska
 • git: 28d2e3b5dedf - main - zfs: cherry-pick fix from openzfs Martin 
Matuska


…


Both were ZIL-related.

 no ZIL; I 
never used the feature.

ZFS deadlock in 14: with ZIL :-)

[Graham Perrin]

On 19/08/2023 11:31, Dimitry Andric wrote:


On 19 Aug 2023, at 09:36, Graham Perrin  wrote:

…

<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271945#c0> no ZIL; I never 
used the feature.

The ZIL always exists, but it can be stored on a separate device for
performance reasons. See zpoolconcepts(7), the Intent Log section:

  By default, the intent log is allocated from blocks within the main pool.
  However, it might be possible to get better performance using separate
  intent log devices such as NVRAM or a dedicated disk.  For example:
# zpool create pool sda sdb log sdc

-Dimitry

Thanks!

I looked at the page umpteen times, that part never sunk in. Now I know.

<https://openzfs.github.io/openzfs-docs/man/master/7/zpoolconcepts.7.html#Intent_Log>

Boot failures with 14.0-ALPHA1 and 14.0-ALPHA2

[Graham Perrin]

On 18/08/2023 13:21, Graham Perrin wrote:

I'll update to ALPHA2.


Another failure.

In this case, removal of a USB device was unnecessary; the next start 
succeeded.


% bectl list -c creation | grep edacf4b4824a
n264868-edacf4b4824a-a NR /  460G  2023-08-19 03:54
n264868-edacf4b4824a-b -  -  52.1M 2023-08-20 20:20
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-ALPHA2 FreeBSD 14.0-ALPHA2 amd64 
1400094 #4 main-n264868-edacf4b4824a-dirty: Fri Aug 18 23:46:09 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.a

md64/sys/GENERIC amd64 1400094 1400094
%


In the meantime, briefly: <https://photos.app.goo.gl/jcXxDuxWPyXTa59Z8>

– no visible progress beyond the four lines of EFI framebuffer 
information.


In each case, I worked around by removing a USB flash drive that's 
used for L2ARC.


The most recent incident was preceded by a power button shutdown, in 
response to a drm-510-kmod blackout (GPU lockup etc.) whilst typing in 
Firefox (comparable to 
<https://github.com/freebsd/drm-kmod/issues/239> for drm-515-kmod 
5.15.25).


The prior incident was also preceded by a power button shutdown (in 
response to a blackout at Plasma log out time). This was remarkable in 
that there was an unexpected restart, when I expected the computer to 
power off.

GPU firmware: could not load firmware image, error 2

[Graham Perrin]

Some relevant messages at.

Should I be concerned by error 2 in these contexts?

% pkg iinfo drm-510-kmod
drm-510-kmod-5.10.163_7
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-ALPHA2 FreeBSD 14.0-ALPHA2 amd64 
1400094 #4 main-n264868-edacf4b4824a-dirty: Fri Aug 18 23:46:09 BST 
2023grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
  amd64 1400094 1400094

GPU firmware: could not load firmware image, error 2

[Graham Perrin]

On 20/08/2023 23:06, Graham Perrin wrote:


Some relevant messages at<https://pastebin.com/raw/wxWi8YS7>.

Should I be concerned by error 2 in these contexts?

% pkg iinfo drm-510-kmod
drm-510-kmod-5.10.163_7
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-ALPHA2 FreeBSD 14.0-ALPHA2 amd64 
1400094 #4 main-n264868-edacf4b4824a-dirty: Fri Aug 18 23:46:09 BST 
2023grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
  amd64 1400094 1400094


Off-list, someone wrote:


I believe you have to install drm-515-kmod


It's not a requirement.

I did try it (and encountered the errors) before reverting to drm-510-kmod.

OT: These errors aside, drm-515-kmod is, for me, so unreliable that I 
can't use it; the bugs are in GitHub.

src.conf(5) to specify multiple flavours of a port

[Graham Perrin]

In a thread elsewhere, as an example that did /not/ involve src.conf, 
Mark Johnston wrote:



$ cd /usr/ports/graphics/gpu-firmware-intel-kmod
$ sudo make reinstall FLAVOR=kabylake


How might I use /etc/src.conf to achieve much the same, with a different 
port?


A recent edition of my file included these four lines, the third of 
which causes an error:


PORTS_MODULES= graphics/drm-510-kmod
# PORTS_MODULES= graphics/drm-515-kmod
PORTS_MODULES+= graphics/gpu-firmware-radeon-kmod@btc 
graphics/gpu-firmware-radeon-kmod@sumo 
graphics/gpu-firmware-radeon-kmod@turks

# PORTS_MODULES+= graphics/gpu-firmware-radeon-kmod

This morning: I use the fourth line, instead.

In future: I'd prefer to be without the build time that's associated 
with so many flavours, when only three are required.





More than doubly time-consuming, because:

KERNCONF=GENERIC GENERIC-NODEBUG
# KERNCONF=GENERIC
# KERNCONF=GENERIC-NODEBUG

NO_INSTALLEXTRAKERNELS=no

TIA

ports-mgmt/portconf – not src.conf(5) – to specify multiple flavours of a port for buildkernel purposes

[Graham Perrin]

On 22/08/2023 05:34, Warner Losh wrote:


How might I use /etc/src.conf to achieve much the same, with a
different port?



I thought stuff like this went in ports.conf...

…


Warner solves another mystery. Thanks!

Honestly, I was oblivious to the possibility:

% man -P cat 5 ports.conf
No manual entry for ports.conf
% apropos ports.conf
apropos: nothing appropriate
% rg -i -e 'ports\.conf' /usr/doc/website/content/en
% rg -i -e 'ports\.conf' /usr/doc/documentation/content/en
%

– and so on. As far as I can tell, it's not documented in the usual places.

Eventually, Google helped to remind me of a 2021 comment 
, 
where part of the previous person's comment had never sunk in. I wrote:



(I never used ports-mgmt/portconf, and so on.)



So:


% gh repo sync grahamperrin/freebsd-ports && git -C /usr/ports pull 
--ff-only --quiet && git -C /usr/ports pull --ff-only freebsd main

✓Synced the "grahamperrin:main" branch from "freebsd:main"
Updating files: 100% (35/35), done.
From https://git.freebsd.org/ports
* branch  main   -> FETCH_HEAD
  15a5c70847f1..355374a1f6be  main   -> freebsd/main
Already up to date.
% sudo pkg install ports-mgmt/portconf
grahamperrin's password:
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
Fetching packagesite.pkg: 100%    2 KiB   2.2kB/s    00:01
The provides database is up-to-date.
Processing entries: 100%
poudriere repository update completed. 7 packages processed.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
   portconf: 1.6_1 [FreeBSD]

Number of packages to be installed: 1

2 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching portconf-1.6_1.pkg: 100%    2 KiB   2.3kB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Installing portconf-1.6_1...
[1/1] Extracting portconf-1.6_1: 100%
Spamming /etc/make.conf... Done.
=
Message from portconf-1.6_1:

--
To set port-specific make variables, create the
/usr/local/etc/ports.conf configuration file
with the following syntax:


# this is a comment
*: NOPORTDOCS
editors/openoffice-3: WITH_CCACHE|LOCALIZED_LANG=it
print/ghostscript-* print/lpr-wrapper: A4
sysutils/fusefs-kmod*: !KERNCONF | !NOPORTDOCS
www/firefox-i18n: WITHOUT_SWITCHER | FIREFOX_I18N=fr it
x11/fakeport: CONFIGURE_ARGS=--with-modules="aaa bbb ccc"


Global port directory patterns and blanks around the
pipe "|" symbol are allowed.
Values shouldn't be quoted even if they contain spaces.
Lines beginning with a '#' are comments.
% apropos ports.conf
apropos: nothing appropriate
% rg --count -e 'ports\.conf' /usr/ports
/usr/ports/net-mgmt/ocsinventory-ocsreports/files/pkg-message.in:1
/usr/ports/ports-mgmt/portconf/files/pkg-message.in:1
/usr/ports/ports-mgmt/portconf/files/portconf.sh.in:1
^C
% sudo nano /usr/local/etc/ports.conf
grahamperrin's password:
% cat /usr/local/etc/ports.conf
graphics/gpu-firmware-radeon-kmod: FLAVORS=btc sumo turks
%


Still, there's guesswork. I have /no/ idea whether the FLAVORS part of 
that last line is valid :-)


Time will tell.

Re: ports-mgmt/portconf – not src.conf(5) – to specify multiple flavours of a port for buildkernel purposes

[Graham Perrin]

On 22/08/2023 06:42, Graham Perrin wrote:


…
% cat /usr/local/etc/ports.conf
graphics/gpu-firmware-radeon-kmod: FLAVORS=btc sumo turks
%


Still, there's guesswork. I have /no/ idea whether the FLAVORS part of 
that last line is valid :-)


Time will tell.

/me tails /var/log/buildkernel.log, rocks with laughter at innumerable 
warnings, cancels,


…
make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5393: warning: duplicate 
script for target "sumo" ignored
make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using 
previous script for "sumo" defined here
make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5402: warning: duplicate 
script for target 
"/usr/obj/usr/src/amd64.amd64/sys/GENERIC/usr/ports/graphics/gpu-firmware-radeon-kmod/work-"btc" 
ignored
make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using 
previous script for 
"/usr/obj/usr/src/amd64.amd64/sys/GENERIC/usr/ports/graphics/gpu-firmware-radeon-kmod/work-"btc" 
defined here
make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5402: warning: duplicate 
script for target "sumo" ignored
make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using 
previous script for "sumo" defined here

env: sumo: No such file or directory
^C
%


, begins a new build that excludes GPU firmware whilst ignoring the 
relevance of 
<https://github.com/freebsd/freebsd-src/commit/cedc82c0466a>, intends to 
build the modules with poudriere-devel after the OS is updated, 
rebelliously  begins a paragraph with a comma and makes a whitespace 
error that should be barely visible in the HTML version of this email 
that will not be seen in an archive :-)

7addfafe73e0 early boot kernel panics

[Graham Perrin]

I could not get 7addfafe73e0 to boot.

 (2023-08-21, 
21 hours ago).


I reverted to a edacf4b4824a boot environment, which is fine.

Should I simply update to ? 
Assuming a known issue with 7addfafe73e0

273297 – BOOT time panic after preloading TSLOG data (was: 7addfafe73e0 early boot kernel panics)

[Graham Perrin]

Thanks, people.

I couldn't attach a photograph to the opening post (entire emails, not 
just attachments, disappear in the ether).


Instead, a photo here:

etcupdate -p, and other uses of etcupdate(8) (was: Has the update procedure changed?)

[Graham Perrin]

On 07/08/2023 16:51, Kevin Oberman wrote:
UPDATING seems to match the Makefile except that Makefile is far less 
detailed. The Makefile even says "See src/UPDATING `COMMON ITEMS' for 
more complete information."


…  "etcupdate -p". …


 prompted me to 
look at 
. 



Is this fortune-provided tip outdated?

etcupdate -p, and other uses of etcupdate(8)

[Graham Perrin]

On 28/08/2023 09:53, Tomoaki AOKI wrote:

On Sun, 27 Aug 2023 18:16:35 +0100
Graham Perrin  wrote:


On 07/08/2023 16:51, Kevin Oberman wrote:

…

…  "etcupdate -p". …

<https://mastodon.bsd.cafe/@fbfortune/110960171470986602>  …


Is this fortune-provided tip outdated?

… for src updates, no [3].



[3]
https://lists.freebsd.org/archives/freebsd-current/2023-August/004210.html



This, in particular:


run "etcupdate" after every upgrade



I mean, I never ran the command without an option, just once at an 
indeterminate stage after an upgrade.


I learnt to run it first with option -p _before_ installworld (i.e. 
during an upgrade), then a run with option -B after installworld.

(264305, 268393, 272878) 14-ALPHA2 panic on cold boot

[Graham Perrin]

On 29/08/2023 09:09, cglogic wrote:

… I found two related bug reports:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264305
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268393

My backtrace is the same as in reported issues. So I did not write it 
from a screen to a paper.


As I understand, this bug affects all AMD Zen2, Zen3 and Zen4 
computers and laptops.
We are near FreeBSD 14.0 release now, maybe it will be possible to fix 
it before release.
; I'll 
discuss with the Bugzilla triage team.

Re: pkg problems with v15

[Graham Perrin]

On 31/08/2023 02:59, brian whalen wrote:

…
pkg: 
http://pkgmir.geo.freebsd.org/FreeBSD:15:amd64/quarterly/meta.txz: Not 
Found

…



For 15.0-CURRENT you should use latest; don't expect quarterly.

Also, it's probably too soon for latest.

1. 

2. seek (filter) main-amd64

3. click the 'Started (UTC)' column heading until you get reverse 
chronological order.


Whilst 
 
is 'stopped:done:', I can't guess whether the end result was suitable 
for general end use.

Re: user problems when upgrading to v15

[Graham Perrin]

On 31/08/2023 03:00, brian whalen wrote:

… I ran etcupdate resolve accepting the remote option and saw 2 issues.

The root user's password was deleted.

The non root user no longer existed.
Logically, remote does not include things such as your root user's 
password.

Re: user problems when upgrading to v15

[Graham Perrin]

On 31/08/2023 03:31, brian whalen wrote:

Understood. I guess I was expecting the update process of etcupdate -p 
&& make installworld && etcupdate -B to not whack existing users or 
delete an existing root user's password. I accepted the remote and 
then recreated users and reset passwords and am retrying this.


BW


Thanks.

For clarity: did the routine /not/ prompt you to edit the file (in 
which, you would have seen conflict markers etc.)?



On 8/30/2023 7:21 PM, Graham Perrin wrote:

On 31/08/2023 03:00, brian whalen wrote:

… I ran etcupdate resolve accepting the remote option and saw 2 issues.

The root user's password was deleted.

The non root user no longer existed.
Logically, remote does not include things such as your root user's 
password.

Occasional supend/sleep failure

[Graham Perrin]

I have a suspend.sh script that aims to take three cache devices offline 
before sleep of the computer:


% grep -v -e '# ' /etc/rc.suspend | uniq | grep -B 3 -A 2 suspend.sh
#!/bin/sh
#

/usr/local/sbin/suspend.sh

    echo "Usage: $0 [apm|acpi] [standby,suspend|1-4]"
% grep -v -e '# ' /usr/local/sbin/suspend.sh | uniq
#!/bin/sh

while mount | grep Transcend 2>&1; do
   zpool export Transcend
   sleep 5
done

zpool offline august gpt/cache1-august
zpool offline august gpt/cache2-august
zpool offline august gpt/cache3-august

sync

killall pulseaudio

while fstat | grep -e dsp -e mixer 2>&1; do
   fstat | grep -e dsp -e mixer | cut -w -f 3 | while read pid;
  do kill -15 "$pid"
   done
done

sysctl hw.snd.default_unit=1

%


Below, it seems that sleep fails if a device is not detached. (Possibly 
if the offlining does not succeed, although I did check pool status 
shortly before suspend.)


How can I more reliably ensure detachment before /etc/rc.suspend proceeds?

Alternatively (ideally) is it possible for /etc/rc.suspend to _not_ 
proceed if detachment does not occur?



Final lines in /var/log/messages before a forced stop of the computer:

Aug 31 17:37:01 mowa219-gjp4-8570p-freebsd kernel: ugen1.8:  
at usbus1 (disconnected)
Aug 31 17:38:46 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_close_locked:352[1]: Closing access to gpt/cache1-august.
Aug 31 17:38:46 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:315[1]: Detaching from gpt/cache1-august.
Aug 31 17:38:46 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:326[1]: Destroying consumer for gpt/cache1-august.
Aug 31 17:38:53 mowa219-gjp4-8570p-freebsd kernel: acpi0: suspend 
request timed out, forcing sleep now
Aug 31 17:38:56 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_close_locked:352[1]: Closing access to gpt/cache2-august.
Aug 31 17:38:56 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:315[1]: Detaching from gpt/cache2-august.
Aug 31 17:38:56 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:326[1]: Destroying consumer for gpt/cache2-august.



Extract from /var/log/console.log after the next start:

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: Enter full pathname 
of shell or RETURN for /bin/sh:

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: # mount -uw /
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: # zfs mount -a
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: # zpool status -x
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:   pool: august
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  state: ONLINE
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: status: One or more 
devices has been taken offline by the administrator.
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  Sufficient 
replicas exist for the pool to continue functioning in a

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  degraded state.
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: action: Online the 
device using 'zpool online' or replace the device with

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  'zpool replace'.
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:   scan: scrub 
repaired 0B in 11:06:38 with 0 errors on Mon Jun 12 01:56:37 2023

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: config:
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: NAME 
STATE READ WRITE CKSUM
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: august   
ONLINE   0 0 0
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: ada0p3.eli 
ONLINE   0 0 0

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  cache
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: gpt/cache2-august  
OFFLINE  0 0 0
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: gpt/cache3-august  
ONLINE   0 0 0
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: gpt/cache1-august  
OFFLINE  0 0 0

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: errors: No known data 
errors

Unicode input regression

[Graham Perrin]

Following my first pkg upgrade with 15.0-CURRENT, I no longer get the 
required character after input.


In applications such as Dolphin, Konsole, Firefox, and Thunderbird: the 
visible input (e.g. code 2013 for an en dash) is followed by disappearance.


In Code - OSS (editors/vscode): input is followed by visibility of the 
code (e.g. 2013), as if I typed it normally.


The version of IBus did not change.

Does anyone else have this regression?

kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

[Graham Perrin]

Some inspections are extraordinarily time-consuming. Others complete 
very quickly, as they should.


One recent inspection took more than half an hour.

Anyone else?

A screenshot: 

% pkg iinfo poudriere-devel
poudriere-devel-3.3.99.20220831
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT 
amd64 150 #10 main-n265053-315ee00fa961-dirty: Mon Aug 28 06:22:31 
BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
amd64 150 150

%

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

[Graham Perrin]

On 02/09/2023 10:17, Mateusz Guzik wrote:

On 9/2/23, Graham Perrin  wrote:

Some inspections are extraordinarily time-consuming. Others complete
very quickly, as they should.

One recent inspection took more than half an hour.

Anyone else?

A screenshot: <https://i.imgur.com/SK9qvfw.png>

% pkg iinfo poudriere-devel
poudriere-devel-3.3.99.20220831
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT
amd64 150 #10 main-n265053-315ee00fa961-dirty: Mon Aug 28 06:22:31
BST 2023
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

amd64 150 150
%




get a flamegraph with dtrace

https://github.com/brendangregg/FlameGraph


Thanks!

See <https://bz-attachments.freebsd.org/attachment.cgi?id=244586> for a 
PDF of a reply that probably did not reach the list.

Re: kernel 100% CPU …

[Graham Perrin]

On 02/09/2023 18:31, Mateusz Guzik wrote:


… upload it to freefall …


Sorry, that's no longer possible.

Do people have a preferred FreeBSD-oriented location/service for 
FreeBSD-specific files?


TIA

In the meantime: I find the symptom reproducible, quite frequently, 
without using poudriere. Currently:


% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT 
amd64 150 #11 main-n265135-07bc20e4740d-dirty: Sat Sep  2 19:40:08 
BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
amd64 150 150

%

Re: kernel 100% CPU

[Graham Perrin]

On 02/09/2023 18:31, Mateusz Guzik wrote:


Looks like you have a lot of unrelated traffic in there.

Run this script:
#pragma D option dynvarsize=32m

profile:::profile-997
/execname == "find"/
{
 @oncpu[stack(), "oncpu"] = count();
}

/*
  * The p_flag & 0x4 test filters out kernel threads.
  */

sched:::off-cpu
/execname == "find"/
{
 self->ts = timestamp;
}

sched:::on-cpu
/self->ts/
{
 @offcpu[stack(30), "offcpu"] = sum(timestamp - self->ts);
 self->ts = 0;
}

dtrace:::END
{
 normalize(@offcpu, 100);
 printa("%k\n%s\n%@d\n\n", @offcpu);
 printa("%k\n%s\n%@d\n\n", @oncpu);
}

dtrace -s script.d -o out



# pwd
/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu
# ./2023-09-02-18-31.sh
./2023-09-02-18-31.sh: profile:::profile-997: not found
./2023-09-02-18-31.sh: /execname: not found
./2023-09-02-18-31.sh: 6: Syntax error: "(" unexpected (expecting "}")
# whoami
root
# echo $
$
# echo $0
sh
# echo $SHELL
/bin/csh
# exit
root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
#

Re: kernel 100% CPU

[Graham Perrin]

On 03/09/2023 09:01, Juraj Lutter wrote:

… The script mjg@ provided is not a shell script.

The script filename is “script.d” where you should put the
above-mentioned DTrace script (without the "dtrace -s script.d -o out” line).



Thanks, I guess that I'm still doing something wrong:


root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
# time dtrace -s script.d -o /tmp/out

dtrace: script 'script.d' matched 4 probes
^C0.246u 4.049s 27:25.70 0.2%   14+91k 261+0io 274pf+0w
root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
# cat /tmp/out


CPU ID    FUNCTION:NAME
  3  2 :END

root@mowa219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu 
#

Re: kernel 100% CPU

[Graham Perrin]

On 03/09/2023 15:02, Mateusz Guzik wrote:

On 9/3/23, Graham Perrin  wrote:

…

The script is intended to run when you have git executing for a long time.


Ah, sorry for my poor understanding.

Re: 
<https://lists.freebsd.org/archives/freebsd-current/2023-September/004539.html>, 
I ran it at a time when the symptom (kernel 100% CPU) was observable 
without a recent run of poudriere-bulk(8).

Re: kernel 100% CPU

[Graham Perrin]

On 02/09/2023 18:31, Mateusz Guzik wrote:

On 9/2/23, Graham Perrin wrote:

… I began the trace /after/ the issue became observable.
Will it be more meaningful to begin a trace and then reproduce the issue
(before the trace ends)?

…

Looks like you have a lot of unrelated traffic in there.

…


Instead, <https://mega.nz/folder/dQdgXK4K#Eb-uC02fT63eweQWWwD8TA> the 
two files from 09:21 this morning. Are these useful?


Before this run of DTrace, I quit Firefox and other applications that 
might be causing noise (and the OS has been restarted since my last run 
of poudriere-bulk(8)).


dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count(); 
} tick-60s { exit(0); }' -o out.kern_stacks

Re: kernel 100% CPU

[Graham Perrin]

On 03/09/2023 17:55, Mateusz Guzik wrote:

On 9/3/23, Graham Perrin  wrote:

On 02/09/2023 18:31, Mateusz Guzik wrote:

On 9/2/23, Graham Perrin wrote:

… I began the trace /after/ the issue became observable.
Will it be more meaningful to begin a trace and then reproduce the issue
(before the trace ends)?

…

Looks like you have a lot of unrelated traffic in there.

…

Instead, <https://mega.nz/folder/dQdgXK4K#Eb-uC02fT63eweQWWwD8TA> the
two files from 09:21 this morning. Are these useful?

Before this run of DTrace, I quit Firefox and other applications that
might be causing noise (and the OS has been restarted since my last run
of poudriere-bulk(8)).

dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count();
} tick-60s { exit(0); }' -o out.kern_stacks


Post your "sysctl -a" somewhere.

sysctl-a-2023-09-03-18-22.txt added to the MEGA folder is complete, 
including TSLOG-related lines.


Alternatively, tslog under 
<https://bsd-hardware.info/?probe=d240fba8b7#Logs> is automatically 
pruned to exclude such lines. Hopefully not excessively pruned.


TSLOG is one of three things in a Git stash that I apply before most 
builds, <https://reviews.freebsd.org/P601>.

sysutils/panicmail and boot environments

[Graham Perrin]

For the penultimate panic: panicmail was received (in my Gmail Inbox).

For the most recent panic: no panicmail in the same Inbox. Might this 
be, because the kernel panicked in a different boot environment? If so: 
will a temporary boot of the environment be enough for delivery of the mail?



From :


Before the panic: with n265135-07bc20e4740d-b running, I created then 
mounted n265135-07bc20e4740d-c, upgraded its packages, unmounted then 
activated the environment, then restarted the OS.


If I recall correctly: the panic occurred very close to the end of the 
shutdown routine.

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

[Graham Perrin]

On 03/09/2023 10:26, Michael Gmelin wrote:


On Sat, 2 Sep 2023 09:53:38 +0100
Graham Perrin  wrote:


Some inspections are extraordinarily time-consuming. Others complete
very quickly, as they should.

One recent inspection took more than half an hour.

Anyone else?


Does `git clone https://git.freebsd.org/ports.git` work for you?
(currently it's not working from where I am). Maybe related.

Best
Michael


Today, yes.

Sorry for not replying sooner, Gmail sent your 2nd September email to spam.

% pwd
/tmp
% time git clone https://git.freebsd.org/ports.git && rm -r ports
Cloning into 'ports'...
remote: Enumerating objects: 5943170, done.
remote: Counting objects: 100% (943/943), done.
remote: Compressing objects: 100% (127/127), done.
remote: Total 5943170 (delta 923), reused 816 (delta 816), pack-reused 
5942227

Receiving objects: 100% (5943170/5943170), 1.11 GiB | 6.29 MiB/s, done.
Resolving deltas: 100% (3586216/3586216), done.
Updating files: 100% (156931/156931), done.
941.630u 59.980s 10:11.66 163.7%    +442k 14+0io 58pf+16w
override r--r--r-- grahamperrin/wheel for 
ports/.git/objects/pack/pack-d72c55d78249720bb87ae380c69ecb3c6dc5fe94.idx? 
^C

% sudo rm -r /tmp/ports
grahamperrin's password:
%

/var/db/etcupdate/ in hier(7) (was: user problems when upgrading to v15)

[Graham Perrin]

On 09/09/2023 17:02, John Baldwin wrote:

On 9/2/23 7:11 AM, Dimitry Andric wrote:

…


… /var/db/etcupdate/conflicts, …



Shall I make a simple (non-contentious) pull request for hier(7) to 
include /var/db/etcupdate/ and the conflicts/ subdirectory?


/var/db/etcupdate/ is present by default with a clean installation of 
15.0-CURRENT.


I guess that conflicts/ appears (and remains after resolution) only 
after the first conflict is found. True?

Re: ZFS Panics Still

[Graham Perrin]

On 12/09/2023 00:17, Cy Schubert wrote:


… poudriere …



panic: vm_page_dequeue_deferred: page 0xfe000b7e9748 has unexpected queue 
state
…
 is for arm64. 
Should we broaden the hardware field, there?

Continually count the number of open files

[Graham Perrin]

Can anything like systat(1) present a count, continually?

I'd like to monitor, after log in to Plasma (X11), in connection with 
.

Re: Continually count the number of open files

[Graham Perrin]

On 12/09/2023 17:19, Bakul Shah wrote:

On Sep 11, 2023, at 11:38 PM, Graham Perrin  wrote:

Can anything like systat(1) present a count, continually?

How about

while sleep 0.1; do sysctl -n kern.openfiles; done



That's ideal, thanks. I knew about the sysctl, but not how to form a 
command like the one above.


(I'm a tcsh user, I can easily 'sh' before running the command.)



Or you can write a small program using sysctl(3).


I'd like to monitor, after log in to Plasma (X11), in connection with 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273669>.

Not sure checking how many files are open will help you.
Looks like "baloo" is using inotify to watch changes on
every file & directory or something. Simulating inotify
with kqueue under FreeBSD doesn't scale well. FreeBSD
should add inotify.


baloo is not used in 273669.

I'm beginning to investigate something unrelated to KDE that has bugged 
me, on FreeBSD, for a very long time.


Thanks

vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)

[Graham Perrin]

On 16/09/2023 01:28, Glen Barber wrote:

o A fix for the ZFS block_cloning feature has been implemented.


Thanks

I see 
, 
with 
 
in stable/14.


As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT 
n265350-72d97e1dd9cc): should we assume that additional fixes, not 
necessarily in time for 14.0-RELEASE, will be required before 
vfs.zfs.bclone_enabled can default to 1?

buildkernel: Cleaning for nvidia-driver-470-470.161.03: [all] Stopped -- signal 22

[Graham Perrin]

The tail of a log:

…
Building /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel.full
--- kernel.full ---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...
  text  data    bss    dec hex   filename
  20670038   1677321   19288064   41635423   0x27b4e5f kernel.full
Building /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel.debug
Building /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel
--- all ---
===> Ports module x11/nvidia-driver-470 (all)
cd /usr/ports/x11/nvidia-driver-470; env  -u CC  -u CXX  -u CPP -u 
MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR  MAKEFLAGS="-j 32 -J 15,16 -j 
32 -J 15,16 -D NO_MODULES_OBJ DISABLE_VULNERABILITIES=yes KERNEL=kernel 
TARGET=amd64 TARGET_ARCH=amd64" SYSDIR=/usr/src/sys 
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin 
SRC_BASE=/usr/src  OSVERSION=150 
WRKDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC make -B clean build

===>  Cleaning for nvidia-driver-470-470.161.03
*** [all] Stopped -- signal 22



Why might a stop occur, with that signal?

My src.conf included:

PORTS_MODULES+=x11/nvidia-driver-470

uname -KU 1500001 1500000

[Graham Perrin]

User environment (150) inferior to kernel (151).

Is this type of discrepancy ever normal/acceptable?

Below, builds and installations were orderly.


% grep -C 2 completed\ on /var/log/buildworld.log
 267.66 real   176.81 user    81.72 sys
--
>>> World build completed on Tue Sep 26 14:20:05 BST 2023
>>> World built in 1253 seconds, ncpu: 8, make -j8
--
% grep -C 2 completed\ on /var/log/buildkernel.log
2162.64 real  3921.60 user  1299.64 sys
--
>>> Kernel build for GENERIC completed on Tue Sep 26 14:56:11 BST 2023
--
--
--
3319.78 real  3736.60 user  1354.83 sys
--
>>> Kernel build for GENERIC-NODEBUG completed on Tue Sep 26 15:51:31 
BST 2023

--
>>> Kernel(s)  GENERIC GENERIC-NODEBUG built in 5485 seconds, ncpu: 8, 
make -j16

% grep -C 1 completed\ on /var/log/installkernel.log
--
>>> Installing kernel GENERIC completed on Tue Sep 26 17:38:25 BST 2023
--
--
--
>>> Installing kernel GENERIC-NODEBUG completed on Tue Sep 26 17:39:46 
BST 2023

--
% grep -C 2 everything\ completed\ on /var/log/installworld.log
  46.47 real    15.04 user    13.94 sys
--
>>> Installing everything completed on Tue Sep 26 18:04:11 BST 2023
--
 684.99 real   110.22 user   171.06 sys
% uname -KU
151 150
% uname -a
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT #13 
main-n265538-915af883221a: Tue Sep 26 15:28:56 BST 2023 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-

NODEBUG amd64
%

Re: uname -KU 1500001 1500000

[Graham Perrin]

On 01/10/2023 23:41, Mark Millard wrote:
That indicates that __FreeBSD_version was 150 when the uname that 
was run was built but the running kernel was built when 
__FreeBSD_version was 151 . (Presumes a lack of use of OSVERSION 
to override the getosreldate result for the kernel case.)


What does "file /usr/bin/uname" report? Which does it list for:

FreeBSD 15.0 (150)
vs.
FreeBSD 15.0 (151)

?



% file /usr/bin/uname
/usr/bin/uname: ELF 64-bit LSB pie executable, x86-64, version 1 
(FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for 
FreeBSD 15.0 (151), FreeBSD-style, stripped

%



…

Occasional supend/sleep failures: race? USB, HP dock, ZFS, three L2ARC devices.

[Graham Perrin]

On 31/08/2023 19:42, Graham Perrin wrote (to freebsd-current alone, 
<https://lists.freebsd.org/archives/freebsd-current/2023-August/004509.html>):


I have a suspend.sh script that aims to take three cache devices 
offline before sleep of the computer:


% grep -v -e '# ' /etc/rc.suspend | uniq | grep -B 3 -A 2 suspend.sh
#!/bin/sh
#

/usr/local/sbin/suspend.sh

    echo "Usage: $0 [apm|acpi] [standby,suspend|1-4]"
% grep -v -e '# ' /usr/local/sbin/suspend.sh | uniq
#!/bin/sh

while mount | grep Transcend 2>&1; do
   zpool export Transcend
   sleep 5
done

zpool offline august gpt/cache1-august
zpool offline august gpt/cache2-august
zpool offline august gpt/cache3-august

sync

killall pulseaudio

while fstat | grep -e dsp -e mixer 2>&1; do
   fstat | grep -e dsp -e mixer | cut -w -f 3 | while read pid;
  do kill -15 "$pid"
   done
done

sysctl hw.snd.default_unit=1

%


…



On the morning of Tuesday 26th September, I predicted a failure 
(internal HDD ada1 was busy with a buildworld), so I took a screenshot 
before attempting to sleep the notebook (HP ZBook 17 G2).


The album at <https://photos.app.goo.gl/wg2Ab5Huod1ToEMn8> begins with 
cropped and non-cropped versions of this shot (08:07:51).


08:10: the failure to suspend, photographed. L2ARC device 
gpt/cache1-august at the foot of the screen.


08:11: the HP dock. Two of four USB ports at the side occupied by flash 
drives, both Kingston DataTraveler 3.0. gpt/cache1-august above, 
gpt/cache2-august below.


08:12: the screen, after physically disconnecting various peripherals 
but not the dock. At the foot of the screen: a Kingston DataTraveler 
2.0, which provides gpt/cache3-august. This drive was at the side of the 
notebook (was not docked).


08:13: the screen, after removing the HP ZBook from the HP dock.

REMARKABLE: neither of the DataTraveler 3.0 devices (in the side of the 
dock) appears in any photograph.



Is this a race condition? As if the OS, or ZFS, prematurely lost the 
ability to handle the docked storage devices on USB.


Can I do anything to make the sleep-related script (above) stronger, to 
reduce the risk of failure?


Might things be more reliable _without_ acpi_hp(4)?


FreeBSD 15.0-CURRENT on the morning of 26th September would have been 
n265350-72d97e1dd9cc:


% bectl list -c creation | tail -n 5
n265350-72d97e1dd9cc-c -  -  882M  2023-09-19 12:45
n265350-72d97e1dd9cc-d -  -  775M  2023-09-23 12:09
n265538-915af883221a-a -  -  256M  2023-09-26 16:30
n265538-915af883221a-b -  -  257M  2023-09-28 09:05
n265538-915af883221a-c NR /  503G  2023-09-29 23:34
%

% grep acpi_hp /boot/loader.conf
acpi_hp_load="YES"
# dev.acpi_hp.0.verbose=1
% man 4 acpi_hp
%

<https://man.freebsd.org/cgi/man.cgi?query=acpi_hp&sektion=4&manpath=freebsd-release#BUGS> 
experimental, etc.

Occasional suspend/sleep failures: race? USB, HP dock, ZFS, three L2ARC devices.

[Graham Perrin]

On 31/08/2023 19:42, Graham Perrin wrote (to freebsd-current alone, 
<https://lists.freebsd.org/archives/freebsd-current/2023-August/004509.html>):


I have a suspend.sh script that aims to take three cache devices 
offline before sleep of the computer:


% grep -v -e '# ' /etc/rc.suspend | uniq | grep -B 3 -A 2 suspend.sh
#!/bin/sh
#

/usr/local/sbin/suspend.sh

    echo "Usage: $0 [apm|acpi] [standby,suspend|1-4]"
% grep -v -e '# ' /usr/local/sbin/suspend.sh | uniq
#!/bin/sh

while mount | grep Transcend 2>&1; do
   zpool export Transcend
   sleep 5
done

zpool offline august gpt/cache1-august
zpool offline august gpt/cache2-august
zpool offline august gpt/cache3-august

sync

killall pulseaudio

while fstat | grep -e dsp -e mixer 2>&1; do
   fstat | grep -e dsp -e mixer | cut -w -f 3 | while read pid;
  do kill -15 "$pid"
   done
done

sysctl hw.snd.default_unit=1

%


…



On the morning of Tuesday 26th September, I predicted a failure 
(internal HDD ada1 was busy with a buildworld), so I took a screenshot 
before attempting to sleep the notebook (HP ZBook 17 G2).


The album at <https://photos.app.goo.gl/wg2Ab5Huod1ToEMn8> begins with 
cropped and non-cropped versions of this shot (08:07:51).


08:10: the failure to suspend, photographed. L2ARC device 
gpt/cache1-august at the foot of the screen.


08:11: the HP dock. Two of four USB ports at the side occupied by flash 
drives, both Kingston DataTraveler 3.0. gpt/cache1-august above, 
gpt/cache2-august below.


08:12: the screen, after physically disconnecting various peripherals 
but not the dock. At the foot of the screen: a Kingston DataTraveler 
2.0, which provides gpt/cache3-august. This drive was at the side of the 
notebook (was not docked).


08:13: the screen, after removing the HP ZBook from the HP dock.

REMARKABLE: neither of the DataTraveler 3.0 devices (in the side of the 
dock) appears in any photograph.



Is this a race condition? As if the OS, or ZFS, prematurely lost the 
ability to handle the docked storage devices on USB.


Can I do anything to make the sleep-related script (above) stronger, to 
reduce the risk of failure?


Might things be more reliable _without_ acpi_hp(4)?


FreeBSD 15.0-CURRENT on the morning of 26th September would have been 
n265350-72d97e1dd9cc:


% bectl list -c creation | tail -n 5
n265350-72d97e1dd9cc-c -  -  882M  2023-09-19 12:45
n265350-72d97e1dd9cc-d -  -  775M  2023-09-23 12:09
n265538-915af883221a-a -  -  256M  2023-09-26 16:30
n265538-915af883221a-b -  -  257M  2023-09-28 09:05
n265538-915af883221a-c NR /  503G  2023-09-29 23:34
%

% grep acpi_hp /boot/loader.conf
acpi_hp_load="YES"
# dev.acpi_hp.0.verbose=1
% man 4 acpi_hp
%

<https://man.freebsd.org/cgi/man.cgi?query=acpi_hp&sektion=4&manpath=freebsd-release#BUGS> 
experimental, etc.

vfs.zfs.arc.min (was: how to set vfs.zfs.arc.max in 15-current ?)

[Graham Perrin]

On 13/10/2023 07:46, Toomas Soome wrote:



On 13. Oct 2023, at 09:35, void  wrote:

On Fri, Oct 13, 2023 at 08:12:47AM +0200, Juraj Lutter wrote:


Set also vfs.zfs.arc.min to some value higher than zero.

aha! that worked!!! :D

root@beer:/root# sysctl vfs.zfs.arc.min=1073741824
vfs.zfs.arc.min: 0 -> 1073741824
root@beer:/root# sysctl vfs.zfs.arc.max=8589934592
vfs.zfs.arc.max: 0 -> 8589934592
root@beer:/root#
thank you!
--


That is a bit odd, arc min used to be 64MB as lowest value - that is, it should 
never be 0.

rgds,
toomas


0 here, when not set.

 
describes the effect of 0, 
 
on the same page does not.


A gap in documentation upstream?

Re: kernel 100% CPU

[Graham Perrin]

On 03/09/2023 20:25, Mateusz Guzik wrote:


…

Sorry mate, neglected to specify: collect sysctl -a once you run into 
the problem.


Once I look at that I'm probably going to ship some debug patches to 
narrow it down. 



I had what might be the same issue this afternoon, for the first time in 
weeks. With the slowdown, it took a few minutes for me to find your 
email, unfortunately the symptoms subsided moments before finding it.


So, I collected the information, but it's probably another missed 
opportunity (the information collected too late).


The busy period lasted for around six minutes:

root@mowa219-gjp4-8570p-freebsd:~ # poudriere bulk -j main -J 3 -Ctv 
devel/pkgconf

[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for main-default
[00:00:02] Warning: Using packages from previously failed, or 
uncommitted, build: 
/usr/local/poudriere/data/packages/main-default/.building

[00:00:02] Mounting ccache from: /usr/.ccache
[00:00:02] Mounting ports from: /usr/local/poudriere/ports/default
[00:00:02] Mounting packages from: 
/usr/local/poudriere/data/packages/main-default

[00:00:02] Mounting distfiles from: /usr/ports/distfiles
[00:00:02] Copying /var/db/ports from: 
/usr/local/etc/poudriere.d/main-options

[00:00:02] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf -> 
/usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf

[00:00:02] Starting jail main-default
[00:00:02] Will build as nobody:nobody (65534:65534)
[00:00:05] Logs: 
/usr/local/poudriere/data/logs/bulk/main-default/2023-10-14_16h16m30s
[00:00:05] Loading MOVED for 
/usr/local/poudriere/data/.m/main-default/ref/usr/ports

[00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:06] Inspecting ports tree for modifications to git checkout... yes
[00:06:39] Ports top-level git hash: e843b8293c (dirty)
…

Re: uname -KU 1500001 1500000

[Graham Perrin]

On Mon, 2 Oct 2023 at 08:33, Mark Millard  wrote:

> Or file and ls results for the amd64.amd64/usr.bin/uname/uname.o ?
> (Just checking for if there are surprises.)

Please, where would I find that file? I'm lost

FreeBSD user environment repeatedly inferior to kernel (was: uname -KU 1500001 1500000)

[Graham Perrin]

On Sun, 1 Oct 2023 at 20:28, Graham Perrin  wrote:

> User environment (150) inferior to kernel (151).
>
> …

I discovered a comparable mismatch from build and installation on 9th
November. Any ideas?

I use devel/ccache4 4.8, if that's relevant.

Copied from :

% uname -KU
153 151
% uname -a
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT
#3 main-n266317-f5b3e686292b-dirty: Thu Nov  9 12:49:29 GMT 2023
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
amd64
% grep -C 2 completed\ on /var/log/buildworld.log

--
>>> World build completed on Thu Nov  9 10:31:19 GMT 2023
>>> World built in 3208 seconds, ncpu: 8, make -j4
--
% grep -C 2 completed\ on /var/log/buildkernel.log
 4356.16 real  2766.18 user   363.33 sys
--
>>> Kernel build for GENERIC completed on Thu Nov  9 11:43:59 GMT 2023
--
--
--
 4002.48 real  2817.89 user   367.08 sys
--
>>> Kernel build for GENERIC-NODEBUG completed on Thu Nov  9 12:50:48 GMT 2023
--
>>> Kernel(s)  GENERIC GENERIC-NODEBUG built in 8369 seconds, ncpu: 8, make -j4
% grep -C 1 completed\ on /var/log/installkernel.log
--
>>> Installing kernel GENERIC completed on Thu Nov  9 20:22:06 GMT 2023
--
--
--
>>> Installing kernel GENERIC-NODEBUG completed on Thu Nov  9 20:23:48 GMT 2023
--
% grep -C 2 everything\ completed\ on /var/log/installworld.log
   28.98 real16.25 user12.06 sys
--
>>> Installing everything completed on Fri Nov 10 00:36:46 GMT 2023
--
  287.91 real   111.51 user   171.26 sys
%

99132daf6f70 rc.d/ldconfig: Prepend rtld stdlib paths to ldconfig(32)_paths

[Graham Perrin]

On Mon, 20 Nov 2023 at 08:48, Dima Panov  wrote:

> On 20.11.2023 06:48, Graham Perrin wrote:
>
>> …
>>   ldconfig: warning: /lib32: No such file or directory
>>
>
> It is related to 
> https://cgit.freebsd.org/src/commit/?id=99132daf6f70cb0cc969c555d3612547fa3cf1db

Thanks.

Also noted, at the weekend, from beefy18 and ampere2:

<https://lists.freebsd.org/archives/freebsd-pkg-fallout/2023-November/515853.html>

<https://lists.freebsd.org/archives/freebsd-pkg-fallout/2023-November/516898.html>

Boot failure, amd64 (HP EliteBook 650 G10)

[Graham Perrin]

amd64.

AFAICT the EliteBook 650 G10 was introduced around May 2023.

Does anything in the three photographs tally with a report in Bugzilla?

Any overlap with 
 
for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))?

CURRENT 220ee18f1964 memstick kernel panic, MacBookPro8,3

[Graham Perrin]

Originally posted to 



Photograph: 



USB flash drive written from 
FreeBSD-15.0-CURRENT-amd64-20240314-220ee18f1964-268793-memstick.img.xz


Broadcom Wi-Fi-related, maybe? 





Reproducible in safe mode.

Chromium with Widevine: kernel panic: condition vp->v_type == VDIR || VN_IS_DOOMED(vp) not met ⋯vfs_cache.c:3452 (vn_fullpath_dir)

[Graham Perrin]

Reproducible at .

Re: CURRENT kernel crash beyond git: 02d15215cef2

[Graham Perrin]

On 26/05/2024 13:45, Herbert J. Skuhra wrote:

… No, idea why the fix hasn't been committed yet: …


A few hours earlier:

uma: Fix improper uses of UMA_MD_SMALL_ALLOC · freebsd/freebsd-src@d25ed65


HTH

Unexpected results with 'mergemaster -Ui'

[Graham Perrin]

 line 133 onwards, for example.

I never before found any potential change to
/etc/group

Please, is it unusual?

Lack of experience here. I have updated the system only a few times (maybe less 
than a dozen), the result of mergemaster on this occasion took me by surprise.

Results on all previous occasions were relatively terse, much less to 
consider/merge.



Also today, with an earlier run of mergemaster, when I _did_ choose to install 
a temporary file, the installation failed. I didn't keep a note of the 
specifics but a file mode was mentioned.
___
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: Unexpected results with 'mergemaster -Ui'

[Graham Perrin]

On 11/08/2018 09:02, Graham Perrin wrote:
> … Also today, with an earlier run of mergemaster, when I _did_ choose to 
> install a temporary file, the installation failed. I didn't keep a note of 
> the specifics but a file mode was mentioned.

For reference only

I built a slightly more recent world and kernel,
installed the kernel,
could not reproduce the installation failure with mergemaster.

(Side note: could not installworld, bugged as outlined at 
<https://www.mail-archive.com/svn-src-all@freebsd.org/msg167891.html>. I guess 
that the breakage will be fixed in due course.)

___
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"

npviewer.bin exited on signal 6 (core dumped) with www/linux-flashplayer

[Graham Perrin]

I don't know whether it's specific to www/linux-flashplayer, but whenever the 
plug-in loads (in Waterfox or Firefox) there's a dump.

This morning, for example (from dmesg, after a few visits to 
):

pid 34576 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 35395 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36304 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36316 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36359 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36371 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36401 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36414 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36446 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)
pid 36459 (npviewer.bin), uid 1004: exited on signal 6 (core dumped)

Should I raise a bug against www/linux-flashplayer, or against something else?



For one of the exits, with Firefox run in safe mode at the command line:

*** NSPlugin Viewer  *** WARNING: grmpf, despite much effort, I could not 
determine the actual plugin area size...
Fontconfig warning: "/usr/local/etc/fonts/local.conf", line 1093: saw number, 
expected matrix
*** glibc detected *** /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin: 
free(): invalid next size (fast): 0x08104998 ***
=== Backtrace: =
/lib/libc.so.6(+0x70bb1)[0x289afbb1]
/lib/libc.so.6(+0x73611)[0x289b2611]
/lib/libstdc++.so.6(_ZdlPv+0x22)[0x2a346df2]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x5951a4)[0x297951a4]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x55e75b)[0x2975e75b]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x55e59c)[0x2975e59c]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x389698)[0x29589698]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x4d499f)[0x296d499f]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x548ab1)[0x29748ab1]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x38448a)[0x2958448a]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x54914c)[0x2974914c]
/usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so(+0x54fcba)[0x2974fcba]
/usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin[0x8051a1d]
/usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin[0x805a335]
/usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin[0x805ab90]
/usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin[0x8050e32]
/lib/libc.so.6(__libc_start_main+0xe6)[0x28955d26]
/usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin[0x804b311]
=== Memory map: 
08048000-0806c000 r-xp 00026000 00:00 306218 
/usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin
0806c000-080f7000 rw-p 0008b000 00:00 0
080f7000-08127000 rw-p 0003 00:00 0
2806c000-2808b000 r-xp 00024000 00:00 1874517 
/compat/linux/usr/lib/ld-2.12.so
2808b000-2808c000 r--p 00024000 00:00 1874517 
/compat/linux/usr/lib/ld-2.12.so
2808c000-2808e000 rw-p 2000 00:00 0
2808e000-2808f000 r--p 05e98000 00:00 1874710 
/compat/linux/usr/lib/locale/locale-archive
2808f000-2809 r--p 1000 00:00 1876252 
/compat/linux/usr/share/locale/en_GB/LC_MESSAGES/libc.mo
2809-28095000 r--p 5000 00:00 499790 
/compat/linux/usr/share/locale/en_GB/LC_MESSAGES/gdk-pixbuf.mo
28095000-28096000 rw-p 1000 00:00 0
28096000-2814e000 r-xp 000bb000 00:00 709315 
/compat/linux/usr/lib/libgdk-x11-2.0.so.0.2400.23
2814e000-28151000 rw-p 000bb000 00:00 709315 
/compat/linux/usr/lib/libgdk-x11-2.0.so.0.2400.23
28151000-2819c000 r-xp 0004c000 00:00 1874593 
/compat/linux/usr/lib/libgobject-2.0.so.0.2800.8
2819c000-2819d000 rw-p 0004c000 00:00 1874593 
/compat/linux/usr/lib/libgobject-2.0.so.0.2800.8
2819d000-2819e000 rw-p 1000 00:00 0
2819e000-281a2000 r-xp 4000 00:00 1874601 
/compat/linux/usr/lib/libgthread-2.0.so.0.2800.8
281a2000-281a3000 rw-p 4000 00:00 1874601 
/compat/linux/usr/lib/libgthread-2.0.so.0.2800.8
281a3000-281a4000 rw-p 1000 00:00 0
281a4000-281fc000 r-xp 0005b000 00:00 6748 
/compat/linux/usr/lib/libXt.so.6.0.0
281fc000-2820 rw-p 0005b000 00:00 6748 
/compat/linux/usr/lib/libXt.so.6.0.0
2820-286a2000 r-xp 004a8000 00:00 709317 
/compat/linux/usr/lib/libgtk-x11-2.0.so.0.2400.23
286a2000-286a8000 rw-p 004a8000 00:00 709317 
/compat/linux/usr/lib/libgtk-x11-2.0.so.0.2400.23
286a8000-286a9000 rw-p 1000 00:00 0
286a9000-287c5000 r-xp 0011d000 00:00 1874583 
/compat/linux/usr/lib/libglib-2.0.so.0.2800.8
287c5000-287c6000 rw-p 0011d000 00:00 187*** NSPlugin Wrapper *** ERROR: 
NPP_Destroy() wait for reply: Connection closed
*** NSPlugin Wrapper *** ERROR: NPObject proxy 0x80a204860 is no longer valid!
JavaScript error: https://d9.flashtalking.com/d9core, line 

Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M

[Graham Perrin]

HP EliteBook 8570p with AMD 'Thames' Radeon HD 7570M.

If neither drm-stable-kmod nor drm-next-kmod is used – commenting out
# kld_list="/boot/modules/radeonkms.ko"
in /etc/rc.conf
and if boot is pure UEFI, without CSM,
then the notebook can reliably resume from suspend. There's a
distinctive single amber pulse of the (normally blue) radio button
before suspend occurs. However:

- without CSM, most of the startup routine is illegible, 'torn'

– for example, I can't see what's typed when I boot to single user mode.



If either drm-stable-kmod or drm-next-kmod is used
and if boot is pure UEFI,
then the notebook can not suspend. No amber pulse of the radio button.

With and without drm-next-kmod:
if boot is hybrid UEFI with CSM,
then suspend occurs, but resume fails. No beep, the computer restarts.

debug.acpi.resume_beep=1
in /boot/loader.conf for an audible beep.



Please: might graphics/drm-devel-kmod be better for either the tearing (without 
CSM) or for suspend?



$ date ; uname -v
Wed 22 Aug 2018 09:51:39 BST
FreeBSD 12.0-ALPHA2 #2 r337986: Fri Aug 17 22:01:23 BST 2018 
root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
$ pkg info graphics/drm-stable-kmod
drm-stable-kmod-g20180802
Name   : drm-stable-kmod
Version    : g20180802
Installed on   : Wed Aug 22 06:43:35 2018 BST
Origin : graphics/drm-stable-kmod
Architecture   : FreeBSD:12:amd64
Prefix : /usr/local
Categories : graphics kld
Licenses   : BSD2CLAUSE, MIT, GPLv2
Maintainer : j...@freebsd.org
WWW    : https://github.com/FreeBSDDesktop/kms-drm
Comment    : DRM modules for the linuxkpi-based KMS components
Options    :
    DEBUG  : off
Annotations    :
    FreeBSD_version: 1200078
    repo_type  : binary
    repository : FreeBSD
Flat size  : 7.51MiB
Description    :
amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components.
Currently corresponding to Linux 4.9 DRM. More stable state. amdgpu and
radeonkms are known to fail with EFI boot.

WWW: https://github.com/FreeBSDDesktop/kms-drm
$ pciconf -lv | grep -A 4 vga
vgapci0@pci0:1:0:0: class=0x03 card=0x17a9103c chip=0x68411002 rev=0x00 
hdr=0x00
    vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device = 'Thames [Radeon HD 7550M/7570M/7650M]'
    class  = display
    subclass   = VGA
$

___
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, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M

[Graham Perrin]

On 22/08/2018 17:50, Pete Wright wrote:
> not sure this will address this specific issue - but have you tested setting 
> this sysctl knob and seeing if that fixes your resume issues:
> hw.acpi.reset_video=1

Thanks, I'll be away for around three weeks, I'll test some time in September.

___
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"

Firefox: recommendations – Pocket

[Graham Perrin]

For a few months I got recommendations from Pocket.

No longer.

Is the code removed? Or has Mozilla become stricter about enforcing 
regional restrictions?


(I'm in the UK.)
___
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: r355097 make buildkernel: ports module graphics/gpu-firmware-kmod (all): could not find bsd.sysdir.mk

[Graham Perrin]

On 26/11/2019 08:15, Hans Petter Selasky wrote:

On 2019-11-26 05:54, Warner Losh wrote:

So when I committed the sysdir stuff I forgot to add it to the install
list. I've fixed it now. Either upgrade, or just copy src/share/mk/
bsd.sysdir.mk to /usr/share/mk

Warner


Or:

make -m /usr/src/share/mk

--HPS


I updated source to r355121, still getting an error (below).

Did I misunderstand the advice?




root@momh167-gjp4-8570p:/usr/src # make -m /usr/src/share/mk -j2 
buildkernel KERNCONF=GENERIC-NODEBUG


…

===> Ports module graphics/gpu-firmware-kmod (all)
cd ${PORTSDIR:-/usr/ports}/graphics/gpu-firmware-kmod; env  -u CC -u 
CXX  -u CPP  -u MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR MAKEFLAGS="-j 
2 -J 15,16 -j 2 -J 15,16 -D NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL 
KERNCONF=GENERIC-NODEBUG KERNEL=kernel TARGET=amd64 TARGET_ARCH=amd64"  
SYSDIR=/usr/src/sys 
PATH=/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin 
SRC_BASE=/usr/src  OSVERSION=1300060 
WRKDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B 
clean build

===>  Cleaning for gpu-firmware-kmod-g20191015
===>  License AMD INTEL accepted by the user
===>   gpu-firmware-kmod-g20191015 depends on file: /usr/local/sbin/pkg 
- found
===> Fetching all distfiles required by gpu-firmware-kmod-g20191015 for 
building

===>  Extracting for gpu-firmware-kmod-g20191015
=> SHA256 Checksum OK for 
FreeBSDDesktop-kms-firmware-g20191015-81315fa_GH0.tar.gz.

===>  Patching for gpu-firmware-kmod-g20191015
===>  Configuring for gpu-firmware-kmod-g20191015
===>  Building for gpu-firmware-kmod-g20191015
===> i915kmsfw (all)
===> i915kmsfw/bxtdmc (all)
make[6]: "/usr/src/sys/conf/kmod.mk" line 77: Could not find bsd.sysdir.mk
make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/usr/ports/graphics/gpu-firmware-kmod/work/kms-firmware-81315fa/i915kmsfw/bxtdmc

*** Error code 1

Stop.
make[5]: stopped in 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/usr/ports/graphics/gpu-firmware-kmod/work/kms-firmware-81315fa/i915kmsfw

*** Error code 1

Stop.
make[4]: stopped in 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/usr/ports/graphics/gpu-firmware-kmod/work/kms-firmware-81315fa

===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/graphics/gpu-firmware-kmod
*** [all] Error code 1

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
1 error

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
*** [buildkernel] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src
*** [buildkernel] Error code 2

make: stopped in /usr/src
1 error

make: stopped in /usr/src
root@momh167-gjp4-8570p:/usr/src # date ; uname -v
Wed Nov 27 09:08:01 GMT 2019
FreeBSD 13.0-CURRENT #37 r354945: Thu Nov 21 19:11:47 GMT 2019 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

root@momh167-gjp4-8570p:/usr/src # bectl list
BE   Active Mountpoint Space Created
r350684  -  -  1.66M 2019-08-07 19:01
r354082b -  -  108G  2019-10-27 14:08
r354616b -  -  1.37M 2019-11-16 17:35
r354945  -  -  1.29M 2019-11-21 13:06
r354945a -  -  1.39M 2019-11-22 02:26
r354945b -  -  1.61M 2019-11-25 06:04
r355107  -  -  1.32M 2019-11-26 07:59
r355121  NR /  30.8G 2019-11-27 00:35
root@momh167-gjp4-8570p:/usr/src #



___
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"

r355494 buildworld [libprocstat.o] Error code 1 [lib/libprocstat__L] Error code 2

[Graham Perrin]

--- _libinstall ---
sh /usr/src/tools/install.sh  -C -o root -g wheel -m 444 libmlx5.a 
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/
sh /usr/src/tools/install.sh  -s -o root -g wheel -m 444   -S 
libmlx5.so.1 /usr/obj/usr/src/amd64.amd64/tmp/lib/
sh /usr/src/tools/install.sh  -o root -g wheel -m 444 libmlx5.so.1.debug 
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/
sh /usr/src/tools/install.sh -l rs -o root -g wheel -m 755 
/usr/obj/usr/src/amd64.amd64/tmp/lib/libmlx5.so.1 
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libmlx5.so

--- lib/libprocstat__L ---
===> lib/libprocstat (obj,all,install)
--- .depend ---
echo libprocstat.so.1.full: 
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libelf.a 
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libkvm.a 
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libutil.a >> .depend

--- zfs/zfs.o ---
--- secure/lib/libcrypto__L ---
--- ct_sct_ctx.o ---
cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
-I/usr/src/crypto/openssl -I/usr/src/crypto/openssl/crypto/include 
-I/usr/src/crypto/openssl/include -DL_ENDIAN -DOPENSSL_CPUID_OBJ 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/etc/ssl\"" -DENGINESDIR="\"/usr/lib/engines\"" -DNDEBUG 
-I/usr/src/crypto/openssl/crypto 
-I/usr/src/crypto/openssl/crypto/ec/curve448 
-I/usr/src/crypto/openssl/crypto/ec/curve448/arch_32 
-I/usr/src/crypto/openssl/crypto/modes 
-I/usr/obj/usr/src/amd64.amd64/secure/lib/libcrypto -g -MD 
-MF.depend.ct_sct_ctx.o -MTct_sct_ctx.o -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments    -c 
/usr/src/crypto/openssl/crypto/ct/ct_sct_ctx.c -o ct_sct_ctx.o

--- lib/libprocstat__L ---
--- zfs.o ---
cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
-I/usr/src/sys/cddl/compat/opensolaris 
-I/usr/src/cddl/compat/opensolaris/include 
-I/usr/src/cddl/compat/opensolaris/lib/libumem 
-I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common 
-I/usr/src/sys/cddl/contrib/opensolaris/common/zfs 
-I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/usr/src/sys/cddl/contrib/opensolaris/uts/common 
-I/usr/src/cddl/contrib/opensolaris/head -I/usr/src/lib/libprocstat 
-DNEED_SOLARIS_BOOLEAN   -g -MD -MF.depend.zfs.o -MTzfs.o -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
-Qunused-arguments    -c /usr/src/lib/libprocstat/zfs.c -o zfs.o

--- secure/lib/libcrypto__L ---
--- ct_vfy.o ---
cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe 
-I/usr/src/crypto/openssl -I/usr/src/crypto/openssl/crypto/include 
-I/usr/src/crypto/openssl/include -DL_ENDIAN -DOPENSSL_CPUID_OBJ 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DVPAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/etc/ssl\"" -DENGINESDIR="\"/usr/lib/engines\"" -DNDEBUG 
-I/usr/src/crypto/openssl/crypto 
-I/usr/src/crypto/openssl/crypto/ec/curve448 
-I/usr/src/crypto/openssl/crypto/ec/curve448/arch_32 
-I/usr/src/crypto/openssl/crypto/modes 
-I/usr/obj/usr/src/amd64.amd64/secure/lib/libcrypto -g -MD 
-MF.depend.ct_vfy.o -MTct_vfy.o -std=gnu99 -Wno-format-zero-length 
-fstack-protector-strong -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments    -c 
/usr/src/crypto/openssl/crypto/ct/ct_vfy.c -o ct_vfy.o

--- lib/libprocstat__L ---
--- cd9660.o ---
cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -I. 
-I/usr/src/lib/libprocstat -D_KVM_VNODE -DLIBPROCSTAT_ZF

Re: r355494 buildworld [libprocstat.o] Error code 1 [lib/libprocstat__L] Error code 2

[Graham Perrin]

Ignore my previous e-mail.

I just saw, the 'SVN r355491 breaks libprocstat' thread.

(Forgot to check my 'current' e-mail folder, to which I recently began 
filtering e-mail. Apologies for the noise.)


___
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: SVN r355732 breaks DRM

[Graham Perrin]

On 14/12/2019 01:30, Warner Losh wrote:

> A fix is in progress.

Thank you.

r355860 drm-legacy-kmod  lines 70–81: the 
same issue, yes?

___
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"

r355978 OK (was: SVN r355732 breaks DRM)

[Graham Perrin]

On 18/12/2019 10:21, Evilham wrote:


On dc., des. 18 2019, Graham Perrin wrote:


On 14/12/2019 01:30, Warner Losh wrote:

 > A fix is in progress.

Thank you.

r355860 drm-legacy-kmod <https://pastebin.com/NcrA9iLe> lines 70–81: the
same issue, yes?


FWIW: https://github.com/FreeBSDDesktop/kms-drm/issues/198

I've been using a locally built drm-kmod without patches (off commit 
ee53eae) for a couple days with the latest HEAD.

Maybe the port just hasn't been rebuilt on FreeBSD infra yet?

In any case, and at your own risk you can give that a go.
--
Evilham


Thank you. All good with what's above and r355978.

___
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"

VirtualBox segmentation fault, 5.2.34_1 on FreeBSD-CURRENT r359249

[Graham Perrin]

On 20/03/2020 01:24, Kyle Evans wrote:

On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin  wrote:

Is this maybe related to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I
make a separate bug report?


Please throw a tentative "Me too" on that PR; I'm investigating it,
then we'll see if they're related or requires yet another PR.


Locally built 5.2.34_1 not working on -CURRENT. Should I open a new bug?


grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Tue 24 Mar 2020 10:49:01 GMT
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % virtualbox
Segmentation fault
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' virtualbox-ose 
virtualbox-ose-kmod

emulators/virtualbox-ose 5.2.34_1 poudriere
emulators/virtualbox-ose-kmod 5.2.34 poudriere
grahamperrin@momh167-gjp4-8570p:~ % grep virtualbox /var/log/messages
Mar 22 21:22:40 momh167-gjp4-8570p pkg[26037]: virtualbox-ose-kmod 
reinstalled: 5.2.34 -> 5.2.34
Mar 22 21:23:05 momh167-gjp4-8570p pkg[26037]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 23 01:38:52 momh167-gjp4-8570p pkg[77976]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 23 05:03:36 momh167-gjp4-8570p pkg[52378]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 23 15:44:12 momh167-gjp4-8570p pkg[27169]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
Mar 24 08:19:51 momh167-gjp4-8570p pkg[49646]: virtualbox-ose 
reinstalled: 5.2.34_1 -> 5.2.34_1
grahamperrin@momh167-gjp4-8570p:~ % grep -v \# 
/usr/local/etc/poudriere.d/make.conf

WITHOUT_LLVM_TARGET_ALL=
MESA_LLVM_VER=${LLVM_DEFAULT}
grahamperrin@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"

USB microphones with FreeBSD-CURRENT

[Graham Perrin]

I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

From :

grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Sun 22 Mar 2020 08:49:07 GMT
FreeBSD 13.0-CURRENT #0 r359068: Wed Mar 18 21:14:12 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % cat /dev/sndstat
Installed devices:
pcm0:  (play)
pcm1:  (play/rec)
pcm2:  (play/rec)
pcm3:  (play/rec) default
pcm4:  (rec)
No devices installed from userspace.
grahamperrin@momh167-gjp4-8570p:~ % sysctl hw.snd.default_unit
hw.snd.default_unit: 3
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' firefox
www/firefox 74.0_5,1 FreeBSD
grahamperrin@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"

OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

[Graham Perrin]

This occurs when I enable OpenZFS:

OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD?

From :

grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max
sysctl: unknown oid 'vfs.zfs.arc_max'
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Wed 25 Mar 2020 04:52:22 GMT
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

grahamperrin@momh167-gjp4-8570p:~ % kldstat | grep zfs
 2    1 0x82108000   58ac58 openzfs.ko
grahamperrin@momh167-gjp4-8570p:~ % grep zfs /boot/loader.conf
# zfs_load="YES"
openzfs_load="YES"
grahamperrin@momh167-gjp4-8570p:~ % grep zfs /etc/sysctl.conf
vfs.zfs.min_auto_ashift=12
# HP EliteBook 8570p 16 GB memory vfs.zfs.arc_max defaults to 15523106816
# vfs.zfs.arc_max="7761553408"
vfs.zfs.arc_max="2147483648"
grahamperrin@momh167-gjp4-8570p:~ % zfs-stats -a

…
___
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"

ZFS: destroying snapshots without compromising boot environments

[Graham Perrin]

I imagine that some of the 2019 snapshots below are redundant.

Can I safely destroy any of them?

$ zfs list -t snapshot
NAME USED AVAIL  
REFER  MOUNTPOINT

copperbowl/ROOT/Waterfox@2020-03-20-06:19:45    67.0M -  59.2G  -
copperbowl/ROOT/r359249b@2019-08-18-04:04:53    5.82G -  40.9G  -
copperbowl/ROOT/r359249b@2019-08-18-11:28:31    4.32G -  40.7G  -
copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0  9.43G -  43.4G  -
copperbowl/ROOT/r359249b@2019-09-19-20:03:26    5.13G -  43.3G  -
copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0  7.67G -  44.6G  -
copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0  7.66G -  55.2G  -
copperbowl/ROOT/r359249b@2020-01-11-14:15:47    7.41G -  56.2G  -
copperbowl/ROOT/r359249b@2020-03-17-21:57:17    12.0G -  59.2G  -
copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K -  1.24G  -
copperbowl/poudriere/jails/head@clean    328K -  1.89G  -
$ beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -   12.2G 2020-03-10 18:24
r357746f -  -    1.3G 2020-03-20 06:19
r359249b NR /  148.9G 2020-03-28 01:19
$ beadm list -aDs
BE/Dataset/Snapshot  Active Mountpoint  
Space Created


Waterfox
  copperbowl/ROOT/Waterfox   -  - 137.0M 
2020-03-10 18:24
    r359249b@2020-03-17-21:57:17 - -   59.2G 
2020-03-17 21:57
  copperbowl/ROOT/Waterfox@2020-03-20-06:19:45   - -   67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f   - -    1.2G 
2020-03-20 06:19
    Waterfox@2020-03-20-06:19:45 - -   59.2G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b@2019-08-18-04:04:53   - -    5.8G 
2019-08-18 04:04
  copperbowl/ROOT/r359249b@2019-08-18-11:28:31   - -    4.3G 
2019-08-18 11:28
  copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - -    9.4G 
2019-09-13 18:45
  copperbowl/ROOT/r359249b@2019-09-19-20:03:26   - -    5.1G 
2019-09-19 20:03
  copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - -    7.7G 
2019-09-24 20:45
  copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - -    7.7G 
2020-01-09 17:05
  copperbowl/ROOT/r359249b@2020-01-11-14:15:47   - -    7.4G 
2020-01-11 14:15
  copperbowl/ROOT/r359249b@2020-03-17-21:57:17   - -   12.0G 
2020-03-17 21:57
  copperbowl/ROOT/r359249b   NR /   59.0G 
2020-03-28 01:19

$

___
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: ZFS: destroying snapshots without compromising boot environments

[Graham Perrin]

On 28/03/2020 15:19, Allan Jude wrote:

> You can try to destroy the snapshot, if it is the basis of a clone, then
> you will get an error, that you'd need to destroy the BE first, so you
> might decide to keep that snapshot. As long as you don't use the -R flag
> to zfs destroy dataset@snapshot, it will not destroy the clones.
>
> You can also use 'zfs promote' to make the clone into the parent, making
> the original parent into the clone. This allows you to destroy that
> original and the snapshot while keeping the clone.

Perfect, thank you. I was nervous about destruction without warning.

Below, are the differences (in measurement) between beadm and bectl to 
be expected?




root@momh167-gjp4-8570p:~ # beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -   15.9G 2020-03-10 18:24
r357746f -  -    1.3G 2020-03-20 06:19
r359249b NR /   74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # beadm list -aDs
BE/Dataset/Snapshot    Active Mountpoint Space 
Created


Waterfox
  copperbowl/ROOT/Waterfox -  - 137.0M 
2020-03-10 18:24
    r359249b@2020-03-17-21:57:17   -  - 59.2G 
2020-03-17 21:57
  copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f -  - 1.2G 2020-03-20 
06:19
    Waterfox@2020-03-20-06:19:45   -  - 59.2G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b@2020-03-17-21:57:17 -  - 15.7G 
2020-03-17 21:57
  copperbowl/ROOT/r359249b NR / 59.0G 
2020-03-28 01:19

root@momh167-gjp4-8570p:~ # bectl list
BE   Active Mountpoint Space Created
Waterfox -  -  204M  2020-03-10 18:24
r357746f -  -  1.21G 2020-03-20 06:19
r359249b NR /  74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # bectl list -aDs
BE/Dataset/Snapshot  Active Mountpoint Space 
Created


Waterfox
  copperbowl/ROOT/Waterfox   -  - 204M  
2020-03-10 18:24
  Waterfox@2020-03-20-06:19:45   -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f   -  - 1.21G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b   NR / 74.7G 
2020-03-28 01:19
  r359249b@2020-03-17-21:57:17   -  - 15.7G 
2020-03-17 21:57

root@momh167-gjp4-8570p:~ # zfs list -t snapshot
NAME USED AVAIL  
REFER  MOUNTPOINT

copperbowl/ROOT/Waterfox@2020-03-20-06:19:45    67.0M -  59.2G  -
copperbowl/ROOT/r359249b@2020-03-17-21:57:17    15.7G -  59.2G  -
copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K -  1.24G  -
copperbowl/poudriere/jails/head@clean    328K -  1.89G  -
root@momh167-gjp4-8570p:~ # zfs destroy 
copperbowl/ROOT/r359249b@2020-03-17-21:57:17
cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17': snapshot 
has dependent clones

use '-R' to destroy the following datasets:
copperbowl/ROOT/r357746f
copperbowl/ROOT/Waterfox@2020-03-20-06:19:45
copperbowl/ROOT/Waterfox
root@momh167-gjp4-8570p:~ # date ; uname -v
Sat Mar 28 15:30:57 GMT 2020
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

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"

ZFS: lost the ability to boot a BE

[Graham Perrin]

I lost the ability to boot the environment named 'r357746', I suspect 
this occurred after I set it to use OpenZFS in lieu of ZFS.


I would like to edit its /boot/loader.conf (revert to zfs_load="YES") 
but re: https://github.com/openzfs/zfs/issues/4553 I can not think of a 
way to mount the dataset.


Please, how can I proceed?



Re: ZFS: destroying snapshots without compromising boot environments

On 28/03/2020 15:36, Graham Perrin wrote:

On 28/03/2020 15:19, Allan Jude wrote:

> You can try to destroy the snapshot, if it is the basis of a clone, 
then

> you will get an error, that you'd need to destroy the BE first, so you
> might decide to keep that snapshot. As long as you don't use the -R 
flag

> to zfs destroy dataset@snapshot, it will not destroy the clones.
>
> You can also use 'zfs promote' to make the clone into the parent, 
making

> the original parent into the clone. This allows you to destroy that
> original and the snapshot while keeping the clone.

Perfect, thank you. I was nervous about destruction without warning.

Below, are the differences (in measurement) between beadm and bectl to 
be expected?




root@momh167-gjp4-8570p:~ # beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -   15.9G 2020-03-10 18:24
r357746f -  -    1.3G 2020-03-20 06:19
r359249b NR /   74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # beadm list -aDs
BE/Dataset/Snapshot    Active Mountpoint Space 
Created


Waterfox
  copperbowl/ROOT/Waterfox -  - 137.0M 
2020-03-10 18:24
    r359249b@2020-03-17-21:57:17   -  - 59.2G 
2020-03-17 21:57
  copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f -  - 1.2G 
2020-03-20 06:19
    Waterfox@2020-03-20-06:19:45   -  - 59.2G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b@2020-03-17-21:57:17 -  - 15.7G 
2020-03-17 21:57
  copperbowl/ROOT/r359249b NR / 59.0G 
2020-03-28 01:19

root@momh167-gjp4-8570p:~ # bectl list
BE   Active Mountpoint Space Created
Waterfox -  -  204M  2020-03-10 18:24
r357746f -  -  1.21G 2020-03-20 06:19
r359249b NR /  74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # bectl list -aDs
BE/Dataset/Snapshot  Active Mountpoint 
Space Created


Waterfox
  copperbowl/ROOT/Waterfox   -  - 204M 
2020-03-10 18:24
  Waterfox@2020-03-20-06:19:45   -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f   -  - 1.21G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b   NR / 74.7G 
2020-03-28 01:19
  r359249b@2020-03-17-21:57:17   -  - 15.7G 
2020-03-17 21:57

root@momh167-gjp4-8570p:~ # zfs list -t snapshot
NAME USED AVAIL  
REFER  MOUNTPOINT

copperbowl/ROOT/Waterfox@2020-03-20-06:19:45    67.0M - 59.2G  -
copperbowl/ROOT/r359249b@2020-03-17-21:57:17    15.7G - 59.2G  -
copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G  -
copperbowl/poudriere/jails/head@clean    328K - 1.89G  -
root@momh167-gjp4-8570p:~ # zfs destroy 
copperbowl/ROOT/r359249b@2020-03-17-21:57:17
cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17': 
snapshot has dependent clones

use '-R' to destroy the following datasets:
copperbowl/ROOT/r357746f
copperbowl/ROOT/Waterfox@2020-03-20-06:19:45
copperbowl/ROOT/Waterfox
root@momh167-gjp4-8570p:~ # date ; uname -v
Sat Mar 28 15:30:57 GMT 2020
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

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: USB microphones with FreeBSD-CURRENT

[Graham Perrin]

On 28/03/2020 12:45, Jan Beich wrote:

Graham Perrin  writes:


I can't get web browsers to recognise USB microphones.

USB output (e.g. to my headphones) is OK.

USB input (e.g. from the microphone part of the headphones) is not.

Any suggestions?

Firefox uses "pulse-rust" cubeb backend *by default* if "pulseaudio"
package is installed. getUserMedia is supposed to preset a dropdown menu
to select a microphone. Make sure pulseaudio actually recognizes the
desired microphone e.g., debug via "pactl list" and "parec".

I don't have a mic but, looking at the code, only pulse-rust or pulse
backends on Linux/FreeBSD support selecting non-default audio device.
It maybe possible to use other backends but if audio device used for
output and input are different that'd require routing defaults which can
be done via config file (e.g., ~/.asoundrc) or externally via virtual_oss.


pcm3:  (play/rec) default
pcm4:  (rec)

Are these distinct physical devices?


Yes.




hw.snd.default_unit: 3

Have you tried using 4?


I did, but decided that the device previously at 4 (Alctron USB700 
<https://www.alctron-audio.com/EN/microphones/USB/USB700.html>) probably 
has a hardware fault.


Worth noting: if I attempt to suspend the system whilst the device at 3 
(SteelSeries Siberia 350 headphones with integral microphone 
<https://steelseries.com/gaming-headsets/siberia-350>) is physically 
connected, suspend sometimes fails; it becomes necessary to force off 
the computer.


If I start the system with the headphones connected, then the microphone 
at 3 is usable at e.g. 
<https://www.podcastinsights.com/online-mic-test/> and 
<https://talky.io/> (see <https://i.imgur.com/Ch3SuZn.png>) but not in 
Microsoft Teams.


If I disconnect the headphones (to minimise the risk of failure to 
suspend), then reconnect, the system seems unable to reuse the 
headphones (see <https://i.imgur.com/8Of5MUK.png>); a restart is required.


In Microsoft Teams, neither 2 nor 3 is detected; there's only 1 (see 
<https://i.imgur.com/13HmxKi.png>) and after allowing use of /dev/dsp1 
it 'disappears', leaving only the camera in use (head of 
<https://i.imgur.com/k5ak2jL.png>).


___
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"

ZFS: OpenZFS: lost the ability to boot a BE

[Graham Perrin]

On 30/03/2020 19:47, Graham Perrin wrote:
I lost the ability to boot the environment named 'r357746', I suspect 
this occurred after I set it to use OpenZFS in lieu of ZFS.


I would like to edit its /boot/loader.conf (revert to zfs_load="YES") 
but re: https://github.com/openzfs/zfs/issues/4553 I can not think of 
a way to mount the dataset.


Please, how can I proceed?


Whilst booted from a different environment, I mounted the dataset whilst 
in single user mode, edited /boot/loader.conf … a little tricky, because 
after the mount I could no longer use zfs commands (ZFS library 
initialisation failed, words to that effect). Then beadm to activate the 
BE, and shutdown -r now


Success :-)

With zfs_load="YES" (in lieu of openzfs_load="YES") the BE is usable.




Re: ZFS: destroying snapshots without compromising boot environments

On 28/03/2020 15:36, Graham Perrin wrote:

On 28/03/2020 15:19, Allan Jude wrote:

> You can try to destroy the snapshot, if it is the basis of a clone, 
then

> you will get an error, that you'd need to destroy the BE first, so you
> might decide to keep that snapshot. As long as you don't use the -R 
flag

> to zfs destroy dataset@snapshot, it will not destroy the clones.
>
> You can also use 'zfs promote' to make the clone into the parent, 
making

> the original parent into the clone. This allows you to destroy that
> original and the snapshot while keeping the clone.

Perfect, thank you. I was nervous about destruction without warning.

Below, are the differences (in measurement) between beadm and bectl 
to be expected?




root@momh167-gjp4-8570p:~ # beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -   15.9G 2020-03-10 18:24
r357746f -  -    1.3G 2020-03-20 06:19
r359249b NR /   74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # beadm list -aDs
BE/Dataset/Snapshot    Active Mountpoint 
Space Created


Waterfox
  copperbowl/ROOT/Waterfox -  - 137.0M 
2020-03-10 18:24
    r359249b@2020-03-17-21:57:17   -  - 59.2G 
2020-03-17 21:57
  copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f -  - 1.2G 
2020-03-20 06:19
    Waterfox@2020-03-20-06:19:45   -  - 59.2G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b@2020-03-17-21:57:17 -  - 15.7G 
2020-03-17 21:57
  copperbowl/ROOT/r359249b NR / 59.0G 
2020-03-28 01:19

root@momh167-gjp4-8570p:~ # bectl list
BE   Active Mountpoint Space Created
Waterfox -  -  204M  2020-03-10 18:24
r357746f -  -  1.21G 2020-03-20 06:19
r359249b NR /  74.7G 2020-03-28 01:19
root@momh167-gjp4-8570p:~ # bectl list -aDs
BE/Dataset/Snapshot  Active Mountpoint 
Space Created


Waterfox
  copperbowl/ROOT/Waterfox   -  - 204M 
2020-03-10 18:24
  Waterfox@2020-03-20-06:19:45   -  - 67.0M 
2020-03-20 06:19


r357746f
  copperbowl/ROOT/r357746f   -  - 1.21G 
2020-03-20 06:19


r359249b
  copperbowl/ROOT/r359249b   NR / 74.7G 
2020-03-28 01:19
  r359249b@2020-03-17-21:57:17   -  - 15.7G 
2020-03-17 21:57

root@momh167-gjp4-8570p:~ # zfs list -t snapshot
NAME USED AVAIL  
REFER  MOUNTPOINT

copperbowl/ROOT/Waterfox@2020-03-20-06:19:45    67.0M - 59.2G  -
copperbowl/ROOT/r359249b@2020-03-17-21:57:17    15.7G - 59.2G  -
copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G  -
copperbowl/poudriere/jails/head@clean    328K - 1.89G  -
root@momh167-gjp4-8570p:~ # zfs destroy 
copperbowl/ROOT/r359249b@2020-03-17-21:57:17
cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17': 
snapshot has dependent clones

use '-R' to destroy the following datasets:
copperbowl/ROOT/r357746f
copperbowl/ROOT/Waterfox@2020-03-20-06:19:45
copperbowl/ROOT/Waterfox
root@momh167-gjp4-8570p:~ # date ; uname -v
Sat Mar 28 15:30:57 GMT 2020
FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 
root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

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"

USB microphones with FreeBSD-CURRENT: bug 194727, r358629

[Graham Perrin]

On 30/03/2020 20:36, Theron wrote:


On 2020-03-30 15:06, Graham Perrin wrote:
Worth noting: if I attempt to suspend the system whilst the device at 
3 (SteelSeries Siberia 350 headphones with integral microphone 
<https://steelseries.com/gaming-headsets/siberia-350>) is physically 
connected, suspend sometimes fails; it becomes necessary to force off 
the computer.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727

Theron, thank you! That might explain a recent sense of randomness with 
the symptoms. I've been testing in three different boot environments, 
only one of which is above the 358629 at 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c22>:


grahamperrin@momh167-gjp4-8570p:~ % beadm list
BE   Active Mountpoint  Space Created
Waterfox -  -  383.2M 2020-03-10 18:24
r357746f -  -  148.3M 2020-03-20 06:19
r359249b -  -   15.8G 2020-03-28 01:19
r357746g NR /   60.9G 2020-03-31 00:24

(In retrospect, most remarkable to me was that the bug could bite before 
logging in; taking the 'Sleep' option in sddm did not lead to a suspend 
of the system. Hopefully fixed for FreeBSD-CURRENT by r358629; I'll not 
test now, maybe later in the week.)


___
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"

mount -t zfs … and (RFC, 7452) zfs mount -o mountpoint=…

[Graham Perrin]

Re: ZFS: OpenZFS: lost the ability to boot a BE

Allan Jude wrote:


To temporarily mount a ZFS filesystem:

mount -t zfs poolname/data/set /path/here


– thanks, Allan – I have probably been given the same hint more than 
once before! (Rarely needed. I forget.)



Rodney W. Grimes wrote:


Is there anyway to get the zfs command to add mountpoint as
a temporary value like it does some of the others so that

zfs mount -o mountpoint=/mnt poolname/data/set

would just do the right thing?


RFC: Temporary property and mount handling design changes needed to 
address multiple issues. · Issue #7452 · openzfs/zfs




___
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: USB microphones with FreeBSD-CURRENT: bug 194727, r358629

[Graham Perrin]

On 31/03/2020 03:47, Theron wrote:



I don't know what would be attaching to mixer before login. …



www/plasma5-plasma-browser-integration interaction with x11/sddm maybe?

___
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"

pkg upgrade … solver: cannot find provide for requirement …

[Graham Perrin]

Re: VirtualBox segmentation fault, 5.2.34_1 on FreeBSD-CURRENT r359249

On 24/03/2020 11:36, Graham Perrin wrote:

> … Locally built 5.2.34_1 not working on -CURRENT. …

Now with r359249:

grahamperrin@momh167-gjp4-8570p:~ % pkg rquery '%o %v %R' virtualbox-ose
emulators/virtualbox-ose 5.2.34_1 FreeBSD
emulators/virtualbox-ose 5.2.34_2 poudriere

– 5.2.34_2 is built, but I can't upgrade from 5.2.34_1.

Partial record:



…
root@momh167-gjp4-8570p:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking for upgrades (15 candidates): 100%
Processing candidates (15 candidates): 100%
solver: cannot find provide for requirement libopenblas.so when 
processing package: py27-numpy
solver: cannot find provide for requirement libopenblas.so when 
processing package: suitesparse
solver: cannot find provide for requirement libdioritegtk-0.2.so when 
processing package: nuvolaplayer
solver: cannot find provide for requirement libdioriteglib-0.2.so when 
processing package: nuvolaplayer
solver: cannot find provide for requirement libopenblas.so when 
processing package: coin-or-CoinUtils

Checking integrity... done (0 conflicting)
Your packages are up to date.
root@momh167-gjp4-8570p:~ # pkg upgrade virtualbox-ose
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
solver: cannot find provide for requirement libcurl.so.4 when processing 
package: virtualbox-ose

…



Context: <https://pastebin.com/jjcTTwM9>
___
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"