Just a heads up : /usr/bin/time missing after install
Installed with FreeBSD-13.0-CURRENT-amd64-20190517-r347896-memstick.img and /usr/bin/time was seen to be missing. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: Just a heads up : /usr/bin/time missing after install
On 5/25/19 11:28 AM, David Wolfskill wrote: On Sat, May 25, 2019 at 10:13:45AM -0400, Dennis Clarke wrote: Installed with FreeBSD-13.0-CURRENT-amd64-20190517-r347896-memstick.img and /usr/bin/time was seen to be missing. ... I see it on my systems after source-based updates to r348231 and r348268 (on amd64). E.g.: g1-48(13.0-C)[1] uname -a && ls -lT /usr/bin/time FreeBSD g1-48.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #365 r348268M/348269: Sat May 25 08:18:27 PDT 2019 r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 -r-xr-xr-x 1 root wheel 19544 May 25 08:20:37 2019 /usr/bin/time g1-48(13.0-C)[2] Ignore my email. I see my problem. Dennis ___ 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: Someone broke USB
Life with freebsd-current. :-/ Can be fun ... just try ppc64 or for a real hoot RISC-V !! -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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"
sbin/camcontrol/camcontrol.c error breaks buildworld
In r350018 for a buildworld I am running into : . . . cc --sysroot=/usr/obj/usr/src/r350018/powerpc.powerpc64/tmp -B/usr/obj/usr/src/r350018/powerpc.powerpc64/tmp/usr/bin -O2 -pipe -I/usr/src/r350018/sbin/nvmecontrol -DWITH_NVME -DRESCUE -MD -MF.depend.camcontrol.o -MTcamcontrol.o -std=gnu99 -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 -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/r350018/sbin/camcontrol/camcontrol.c -o camcontrol.o cc1: warnings being treated as errors /usr/src/r350018/sbin/camcontrol/camcontrol.c: In function 'getdevtype': /usr/src/r350018/sbin/camcontrol/camcontrol.c:679: warning: comparison of unsigned expression < 0 is always false *** Error code 1 Stop. make[6]: stopped in /usr/src/r350018/sbin/camcontrol *** Error code 1 Stop. make[5]: stopped in /usr/obj/usr/src/r350018/powerpc.powerpc64/rescue/rescue *** Error code 1 Stop. make[4]: stopped in /usr/src/r350018/rescue/rescue *** Error code 1 Stop. make[3]: stopped in /usr/src/r350018/rescue *** Error code 1 Stop. make[2]: stopped in /usr/src/r350018 *** Error code 1 Stop. make[1]: stopped in /usr/src/r350018 *** Error code 1 Stop. make: stopped in /usr/src/r350018 # Anyone else seeing this ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: sbin/camcontrol/camcontrol.c error breaks buildworld
On 7/16/19 2:48 AM, Warner Losh wrote: On Tue, Jul 16, 2019 at 12:07 AM Dennis Clarke wrote: /usr/src/r350018/sbin/camcontrol/camcontrol.c: In function 'getdevtype': /usr/src/r350018/sbin/camcontrol/camcontrol.c:679: warning: comparison of unsigned expression < 0 is always false Anyone else seeing this ? Fixed hours ago in 350020. Hours ago. Cool. However is there no CI testing on ppc64? Maybe a jenkins type of deal would be helpful but the code base is moving so fast that it may only catch a few things here and there. Regardless the ppc64 world has bigger problems this morning : r350018 will panic on ppc64 PowerMac G5 in vm_phys_enqueue_contig https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239245 Another day another panic. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: sbin/camcontrol/camcontrol.c error breaks buildworld
On 7/16/19 6:55 AM, Dimitry Andric wrote: On 16 Jul 2019, at 12:36, Dennis Clarke wrote: On 7/16/19 2:48 AM, Warner Losh wrote: On Tue, Jul 16, 2019 at 12:07 AM Dennis Clarke wrote: /usr/src/r350018/sbin/camcontrol/camcontrol.c: In function 'getdevtype': /usr/src/r350018/sbin/camcontrol/camcontrol.c:679: warning: comparison of unsigned expression < 0 is always false Anyone else seeing this ? Fixed hours ago in 350020. Hours ago. Cool. However is there no CI testing on ppc64? There is a CI build, in any case: https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/ It showed a failure for build #11532 (r350018): https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/11532/ and also how it got fixed in build #11533 (r350020): https://ci.freebsd.org/job/FreeBSD-head-powerpc64-build/11533/ Unfortunately there is no test job which attempts to fire up a world inside e.g. qemu. Oh well, thank you for the info. Lucky me that I fell into the exact same build problem which only happens rarely. Hardly a lottery ticket win but I am happy to see the CI information. Dennis ___ 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: sbin/camcontrol/camcontrol.c error breaks buildworld
The window would have been smaller. CI detected the breakage within 10 minutes, but I was away from my email attending to some household things for an hour more... Ha! Sometimes I hear people even sleep ? I was just thinking the probability of landing in that one failed buildworld was real real small and somehow myself and a few others managed to do it. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: sbin/camcontrol/camcontrol.c error breaks buildworld
On 7/16/19 5:37 PM, Warner Losh wrote: On Tue, Jul 16, 2019 at 3:32 PM Dennis Clarke wrote: The window would have been smaller. CI detected the breakage within 10 minutes, but I was away from my email attending to some household things for an hour more... Ha! Sometimes I hear people even sleep ? I was just thinking the probability of landing in that one failed buildworld was real real small and somehow myself and a few others managed to do it. The changes survived a buildworld on amd64. I had no reason to even suspect they might be troublesome on other archs. Since I have a busy day, I took a shortcut. I don't build universe for every change, there's simply not time. So it's more complicated than you're trying to paint. I am not trying to paint anything. I know there are a few of us with limited time and limited resources and we are all just doing what we can. In spite of this we have an open source UNIX with ZFS running. On more than just x86 little boxen. So we can expect bumps in the road : a typical bump in the road for ppc64 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239245 Yep .. changes happen and things break. Such is life. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: Panic with Current 351901 ISO image
On 9/8/19 6:03 PM, Curtis Hamilton wrote: I'm encountering (randomly) the below error when trying to install 351901 from CD/DVD. On what type of system ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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 with 32-bit, non-x86 kernel
On 10/4/19 10:05 AM, Andriy Gapon wrote: Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? If you do, could you please let me know? Along with uname -rmp output. Thank you! I don't know if that has even been attempted by anyone. The ZIL and ZFS log comonents require substantial amounts of memory and I am not aware of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD current on RISC-V running fairly well with ZFS however that was a purely rv64imafdc architecture. I will watch this thread with curiosity. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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 Panic: Current: r354843: panic: solaris assert: error || lr->lr_length <= size, file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 1324
On 11/19/19 3:51 PM, Larry Rosenman wrote: Ideas? Core *IS* available, and I can give access. Unread portion of the kernel message buffer: panic: solaris assert: error || lr->lr_length <= size, file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 1324 cpuid = 20 time = 1574159903 ... #16 0x00080030d7aa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffe138 (kgdb) Looks similar to : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238076 However that assert was in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c and on RISC-V. Dennis ___ 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: breakage at usr.sbin/jail/Makefile
On 11/21/19 11:33 AM, Ed Maste wrote:
On Wed, 20 Nov 2019 at 23:19, Pete Wright wrote:
the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined.
i was contemplating suggesting updating the .if clause in the Makefile
like so:
.if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} ==
"riscv"
Yes, this is the approach I went with - Cirrus-CI started building my
proposed change last night but it wasn't finished before I was. When I
checked this morning it confirmed the fix works. In any case the best
fix here will be to resolve the underlying RISC-V binutils issue and
revert all of the workarounds.
Note that FreeBSD's CI did not catch this issue because it builds with
-DNO_CLEAN. I also build locally with -DNO_CLEAN and wouldn't have
seen it either. In my opinion we ought to just remove the not-NO_CLEAN
case from buildworld/buildkernel.
I generally look at the CI traffic to get a feel for what I *should* be
seeing and thus I was baffled when my cross compile was blowing up on
exactly this issue.
Really I want to debug :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242067
wherein printf seems to get down to _ldtoa.c and then confusion sets in
over the in memory data for fp128 little endian data but that is another
story. I can't get very far without some basic tools and at the moment
the CI builds are not very useful as they barely have anything for tools
in /bin or anywhere else. Not even ed? Really?
In any case I did look at the RISC-V projects GNU Toolchain and I did go
with a build of the latest from :
https://github.com/riscv/riscv-gnu-toolchain
and that did work well for a buildworld a few days ago. The buildkernel
fails. So I start over as if I am fishing for code in a fast flowing
stream of water where I never know what works and what doesn't the next
moment. Why? Because the CI builds were not failing. Sometimes I get
lucky. With r354874 and the new GNU Toolchain cross tools I get a clean
buildworld and then the kernel fails.
So today I will start over from scratch but I will use the GNU Toolchain
from RISC-V upstream project thus :
vesta#
vesta# uname -apKU
FreeBSD vesta 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64
amd64 1201000 1201000
vesta# /opt/rv64/tools/bin/riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
vesta#
So I will try again today and report back.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
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"
make CROSS_COMPILE=riscv64 KERNCONF=QEMU TARGET_ARCH=riscv64 buildkernel fails sys/contrib/ck/include/ck_stdbool.h:30:10: fatal error: stdbool.h: No such file or directory
I have been seeing this for days and not sure why : . . . /opt/rv64/tools/bin/riscv64-unknown-elf-gcc --sysroot=/opt/rv64/obj/usr/src/20191122121007/freebsd-riscv/riscv.riscv64/tmp -B/opt/rv64/tools/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/20191122121007/freebsd-riscv/sys -I/usr/src/20191122121007/freebsd-riscv/sys/contrib/ck/include -I/usr/src/20191122121007/freebsd-riscv/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -fno-optimize-sibling-calls -MD -MF.depend.ck_array.o -MTck_array.o -fdebug-prefix-map=./machine=/usr/src/20191122121007/freebsd-riscv/sys/riscv/include -march=rv64imafdc -mabi=lp64 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -Wno-format -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=address -Wno-error=aggressive-loop-optimizations -Wno-error=array-bounds -Wno-error=attributes -Wno-error=cast-qual -Wno-error=enum-compare -Wno-error=inline -Wno-error=maybe-uninitialized -Wno-error=overflow -Wno-error=sequence-point -Wno-unused-but-set-variable -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-overflow -Wno-error=tautological-compare -Wno-error=memset-elt-size -Wno-error=packed-not-aligned -Wno-format-zero-length -fno-common -fms-extensions -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fms-extensions -mcmodel=medany -std=iso9899:1999 -Werror /usr/src/20191122121007/freebsd-riscv/sys/contrib/ck/src/ck_array.c -I/usr/src/20191122121007/freebsd-riscv/sys/contrib/ck/include In file included from /usr/src/20191122121007/freebsd-riscv/sys/contrib/ck/include/ck_malloc.h:30, from /usr/src/20191122121007/freebsd-riscv/sys/contrib/ck/include/ck_array.h:32, from /usr/src/20191122121007/freebsd-riscv/sys/contrib/ck/src/ck_array.c:28: /usr/src/20191122121007/freebsd-riscv/sys/contrib/ck/include/ck_stdbool.h:30:10: fatal error: stdbool.h: No such file or directory 30 | #include | ^~~ compilation terminated. *** Error code 1 Stop. make[2]: stopped in /opt/rv64/obj/usr/src/20191122121007/freebsd-riscv/riscv.riscv64/sys/QEMU *** Error code 1 Stop. make[1]: stopped in /usr/src/20191122121007/freebsd-riscv *** Error code 1 Stop. make: stopped in /usr/src/20191122121007/freebsd-riscv vesta# vesta# I am using my own cross tools made from the RISC-V projects GNU Toolchain : vesta# vesta# /opt/rv64/tools/bin/riscv64-unknown-elf-gcc --version riscv64-unknown-elf-gcc (GCC) 9.2.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. vesta# Which seems to work fine for buildworld but then the kernel fails to build due to a mysterious missing header. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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"
GCC 8.x or 9.x for FreeBSD rv64imafdc ??
I will cross post this as there are very few options left. rv64imafdc folks : I will send this out to the only people and places that are likely to not simply be a black hole from which nothing ever returns. However most of my messages do just die on the mail lists with no reply from anyone ever and that is very true for the gcc maillists for anything RISC-V related. I wish I knew why. I am able to checkout and cross compile FreeBSD 13.0-CURRENT r354873 however there is no compiler. I looked. The output destination rootfs shows no signs of LLVM/Clang and certainly not gcc of any flavor. I do see wonderful things like : https://github.com/freebsd-riscv/riscv-gcc/commit/be9abee2aaa919ad8530336569d17b5a60049717 However nothing actually usable by any user out here in the more or less real world that is not inside SiFive or similar. So is there any place at all that one may attain a compiler or am I left to decipher the horrific mess that is known as the Canadian cross compiler bootstrap which has never worked for me. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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"
Has anyone tried to build QEMU from ports lately?
On : phobos# phobos# uname -apKU FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #14 main-n258340-497cdf9673e: Sun Oct 2 09:51:14 GMT 2022 root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400072 1400072 phobos# Seems to fail in a pretty consistent fashion : . . . [5633/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_mmap.c.o [5634/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/capstone -I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O0 -g -iquote . -iquote /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb -iquote /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/include -iquote /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/tcg/i386 -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -O2 -pipe -fstack-protector-strong -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H '-DCONFIG_TARGET="arm-bsd-user-config-target.h"' '-DCONFIG_DEVICES="arm-bsd-user-config-devices.h"' -MD -MQ libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -MF libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o.d -o libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -c ../bsd-user/signal.c In file included from ../bsd-user/signal.c:27: In file included from ../bsd-user/host/x86_64/host-signal.h:14: In file included from /usr/include/vm/pmap.h:92: /usr/include/machine/pmap.h:452:2: error: fields must have a constant size: 'variable length array in structure' extension will never be supported PV_CHUNK_HEADER ^ /usr/include/machine/pmap.h:448:12: note: expanded from macro 'PV_CHUNK_HEADER' uint64_tpc_map[_NPCM]; /* bitmap; 1 = free */ \ ^ /usr/include/machine/pmap.h:456:2: error: fields must have a constant size: 'variable length array in structure' extension will never be supported PV_CHUNK_HEADER ^ /usr/include/machine/pmap.h:448:12: note: expanded from macro 'PV_CHUNK_HEADER' uint64_tpc_map[_NPCM]; /* bitmap; 1 = free */ \ ^ 2 errors generated. ninja: build stopped: subcommand failed. gmake[3]: *** [Makefile:162: run-ninja] Error 1 gmake[3]: Leaving directory '/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/build' gmake[2]: *** [GNUmakefile:11: all] Error 2 gmake[2]: Leaving directory '/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb' *** Error code 2 Stop. make[1]: stopped in /usr/ports/emulators/qemu-devel *** Error code 1 Stop. make: stopped in /usr/ports/emulators/qemu-devel phobos# phobos# pwd /usr/ports/emulators/qemu-devel phobos# Possibly a problem with -linotify or who knows what ? Also see : https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg01280.html In any case, something feels wrong here. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Has anyone tried to build QEMU from ports lately?
s0 plic0: mem 0xc00-0xc5f irq 10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25 on simplebus1 timer0: Timecounter "RISC-V Timecounter" frequency 1000 Hz quality 1000 Event timer "RISC-V Eventtimer" frequency 1000 Hz quality 1000 riscv_syscon0: mem 0x10-0x100fff on simplebus1 rcons0: cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cpu4: on cpulist0 cpu5: on cpulist0 cpu6: on cpulist0 cpu7: on cpulist0 goldfish_rtc0: mem 0x101000-0x101fff irq 0 on simplebus1 goldfish_rtc0: registered as a time-of-day clock, resolution 1.00s uart0: <16550 or compatible> mem 0x1000-0x10ff irq 1 on simplebus1 uart0: console (115200,n,8,1) syscon_power0: on simplebus1 syscon_power1: on simplebus1 pcib0: mem 0x3000-0x3fff on simplebus1 pci0: on pcib0 virtio_mmio0: mem 0x10008000-0x10008fff irq 2 on simplebus1 vtblk0: on virtio_mmio0 vtblk0: 6176MB (12649600 512 byte sectors) virtio_mmio1: mem 0x10007000-0x10007fff irq 3 on simplebus1 virtio_mmio2: mem 0x10006000-0x10006fff irq 4 on simplebus1 vtnet0: on virtio_mmio2 vtnet0: Ethernet address: 52:54:00:12:34:56 Timecounters tick every 1.000 msec usb_needs_explore_all: no devclass Trying to mount root from ufs:/dev/gpt/rootfs [rw]... Release APs WARNING: WITNESS option enabled, expect reduced performance. random: unblocking device. Enter full pathname of shell or RETURN for /bin/sh: root@:/ # uname -apKU FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n258483-b05b1ecbef0: Fri Oct 7 05:52:47 UTC 2022 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC riscv riscv64 1400072 1400072 root@:/ # sysctl hw.ncpu hw.ncpu: 8 root@:/ # sysctl hw.model sysctl: unknown oid 'hw.model' root@:/ # sysctl hw.physmem hw.physmem: 34312138752 root@:/ # shutdown -p 'now' Shutdown NOW! shutdown: [pid 22] root@:/ # wall: can't open temporary file: Read-only file system 2022-10-11T04:17:08.354519+00:00 - shutdown 22 - - power-down by root: System shutdown time has arrived Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 0 0 0 0 0 0 0 0 0 0 done All buffers synced. Uptime: 56s sedna$ Sort of makes me wonder if perhaps a longer cpu ISA name string would be of any benefit? I am curious what the string was that tossed the KASSERT myself. Also funny that sysctl hw.model returns nothing useful. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Has anyone tried to build QEMU from ports lately?
On 10/11/22 04:20, Dennis Clarke wrote: On 10/10/22 17:53, Warner Losh wrote: On Mon, Oct 10, 2022 at 10:56 AM Warner Losh wrote: I know what's causing this problem. I'll resolve. tl/dr: _pv_entry.h depends on sys/param.h being included before its use. https://reviews.freebsd.org/D36927 fixes it by making sys/_pv_entry.h more self-contained and less reliant on param.h pollution. The kernel includes that everywhere it's used, but userland is more hit or miss because machine/pmap.h isn't a well defined interface, but is needed for some things sometimes. I am not sure where this is related, however, there is a change in QEMU: https://github.com/qemu/qemu/commit/a4a9a4432e2bf280a989ca344466d7375db7993f Which seems to provide a way around some really long ISA cpu name data that gets caught in sys/riscv/riscv/identcpu.c at around line 113 or so : Forgot to mention : https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c#L248 I wonder what the string is that tossed the KASSERT. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Defaulting serial communication to 115200 bps for FreeBSD 14
On 8/16/23 03:10, Tomoaki AOKI wrote: On Tue, 15 Aug 2023 21:02:57 -0700 Cy Schubert wrote: Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 message dated "Tue, 15 Aug 2023 17:18:37 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In message , Ed Maste writes: FreeBSD currently uses 9600 bps as the default for serial communication -- in the boot loader, kernel serial console, /etc/ttys, and so on. This was consistent with most equipment in the 90s, when these defaults were established. Today 115200 bps seems to be much more common, and I'm proposing that we make it the default for FreeBSD 14.0. I have a review open: https://reviews.freebsd.org/D36295. There are a few minor nits in the review to be addressed still but assuming there's general agreement I'll iterate on those and commit this in a few logical chunks. There should probably be an UPDATING entry for those who use boot0 to revert back to 9600 in that case. Not read the diff though, if the baud rate is re-initialized in boot1 or later (including btx, loader, kernel and userland) and handshake again, most of the boot process and later would run at 115200 bps. The default serial communications config on most telecom equipment that I have seen ( in the last forty years ) defaults to 9600 8n1. If people want something faster from FreeBSD then do the trivial : set comconsole_speed="115200" set console="comconsole" Is that not trivial enough? Also, merely a funny observation, if one tries a baud rate lower than 9600 then FreeBSD will panic. Jut a funny thing I have seen over and over. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Defaulting serial communication to 115200 bps for FreeBSD 14
On 8/16/23 22:28, Alexander Motin wrote: On 16.08.2023 18:14, Dennis Clarke wrote: The default serial communications config on most telecom equipment that I have seen ( in the last forty years ) defaults to 9600 8n1. If people want something faster from FreeBSD then do the trivial : set comconsole_speed="115200" set console="comconsole" Is that not trivial enough? Except it is not a telecom equipment 40 years ago. Even at 115200 that I routinely use on my development systems I feel serial console output affects verbose boot time and kernel console debugging output. I also have BIOS console redirection enabled on my systems, and I believe the default there is also 115200, and even that is pretty slow. I see no point to stay compatible if it is unusable. You seem to be missing the point. You need to make a configuration choice. You. Not the world. You. Edit your /boot/loader.conf and put in the lines above. Then be happy. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional PS: a recent CISCO ASA fireware defaults to 9600 8n1. Same as a lot of equipment.
Re: Defaulting serial communication to 115200 bps for FreeBSD 14
On 8/17/23 00:40, Warner Losh wrote: On Wed, Aug 16, 2023, 9:38 PM Dennis Clarke wrote: On 8/16/23 22:28, Alexander Motin wrote: On 16.08.2023 18:14, Dennis Clarke wrote: The default serial communications config on most telecom equipment that I have seen ( in the last forty years ) defaults to 9600 8n1. If people want something faster from FreeBSD then do the trivial : set comconsole_speed="115200" set console="comconsole" Is that not trivial enough? Except it is not a telecom equipment 40 years ago. Even at 115200 that I routinely use on my development systems I feel serial console output affects verbose boot time and kernel console debugging output. I also have BIOS console redirection enabled on my systems, and I believe the default there is also 115200, and even that is pretty slow. I see no point to stay compatible if it is unusable. You seem to be missing the point. You need to make a configuration choice. You. Not the world. You. Edit your /boot/loader.conf and put in the lines above. Then be happy. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional PS: a recent CISCO ASA fireware defaults to 9600 8n1. Same as a lot of equipment. Yes. Some tiny number of things has that as a default, an even larger number of things have a default of 115200 or even faster. And have had that default since the 90s. The whole point of defaults is that they reflect the needs of the most people. FreeBSD's defaults were already starting to be dated in 1.0... today almost everyone changes the defaults to the new value we are advocating. This is to make FreeBSD more useful out of the box to more people. To turn your argument around: people wanting the old defaults can configure their systems easily enough. If we look purely at the numbers, vastly fewer people withh be inconvenienced at 115200 than at 9600. People can still use 9600... that's likely never going away... this is just a more sensible default. Warner That makes perfect flawless sense to me. The logic of "popular" or "most valuable" to the most users for something like this. Yes I know that is a dangling elliptical sentence but it works. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
The ports quarterly tree 2023Q4 is borked for www/firefox
I do not know where else to post this. Seems that a bug report about the
problem does not mean much :
Bug 275814 - www/firefox has the wrong version in the Makefile
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814
This issue is pretty clear.
This morning I flushed out my ports tree and started over fresh :
hydra# poudriere ports -c -U ssh://anon...@git.freebsd.org/ports.git \
? -B 2023Q4 \
? -f zroot/poudriere/ports/2023Q4 \
? -m 'git+ssh' -p 2023Q4 -v
[00:00:00] Creating 2023Q4 fs at /usr/local/poudriere/ports/2023Q4... done
[00:00:01] Cloning the ports tree...Cloning into
'/usr/local/poudriere/ports/2023Q4'...
remote: Enumerating objects: 192710, done.
remote: Counting objects: 100% (192710/192710), done.
remote: Compressing objects: 100% (181019/181019), done.
remote: Total 192710 (delta 11046), reused 115681 (delta 5175),
pack-reused 0
Receiving objects: 100% (192710/192710), 83.07 MiB | 4.91 MiB/s, done.
Resolving deltas: 100% (11046/11046), done.
Updating files: 100% (155563/155563), done.
done
hydra#
hydra# poudriere ports -l
2023Q4git+ssh 2023-12-18 12:29:26 /usr/local/poudriere/ports/2023Q4
hydra#
hydra#
hydra# cat /usr/local/poudriere/ports/2023Q4/www/firefox/distinfo
TIMESTAMP = 1702328424
SHA256 (firefox-121.0.source.tar.xz) =
edc7a5159d23ff2a23e22bf5abe22231658cee2902b93b5889ee73958aa06aa4
SIZE (firefox-121.0.source.tar.xz) = 530302784
hydra#
hydra# head /usr/local/poudriere/ports/2023Q4/www/firefox/Makefile
PORTNAME= firefox
DISTVERSION=120.0.1
PORTEPOCH= 2
CATEGORIES= www wayland
MASTER_SITES=
MOZILLA/${PORTNAME}/releases/${DISTVERSION}${DISTVERSIONSUFFIX}/source \
MOZILLA/${PORTNAME}/candidates/${DISTVERSION}${DISTVERSIONSUFFIX}-candidates/build1/source
DISTFILES= ${DISTNAME}.source${EXTRACT_SUFX}
MAINTAINER= ge...@freebsd.org
COMMENT=Web browser based on the browser portion of Mozilla
hydra#
So the Makefile does not match the distfile and this borks up poudriere
over and over and over for about a week now :
hydra#
hydra# pwd
/usr/local/poudriere/ports/2023Q4
hydra# git blame www/firefox/distinfo
^17b2a0299 (Christoph Moench-Tegeder 2023-12-17 23:45:07 +0100 1)
TIMESTAMP = 1702328424
^17b2a0299 (Christoph Moench-Tegeder 2023-12-17 23:45:07 +0100 2) SHA256
(firefox-121.0.source.tar.xz) =
edc7a5159d23ff2a23e22bf5abe22231658cee2902b93b5889ee73958aa06aa4
^17b2a0299 (Christoph Moench-Tegeder 2023-12-17 23:45:07 +0100 3) SIZE
(firefox-121.0.source.tar.xz) = 530302784
hydra#
There is no way I can be the only person on the planet that likes to
have Firefox on their machine ... built from the sources.
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
Re: The ports quarterly tree 2023Q4 is borked for www/firefox
On 12/18/23 08:35, Dimitry Andric wrote: On 18 Dec 2023, at 13:59, Dennis Clarke wrote: I do not know where else to post this. Seems that a bug report about the problem does not mean much : Bug 275814 - www/firefox has the wrong version in the Makefile https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 Should be fixed by: https://cgit.freebsd.org/ports/commit/?h=2023Q4&id=ec15ee20bdd912ca31982b1be0062da5fb783ac7 -Dimitry awesome ! we have liftoff once again : hydra# hydra# poudriere ports -l 2023Q4git+ssh 2023-12-18 12:29:26 /usr/local/poudriere/ports/2023Q4 hydra# hydra# poudriere ports -p 2023Q4 -u [00:00:00] Updating portstree "2023Q4" with git+ssh... done hydra# hydra# poudriere bulk -J 6:8 -j 132_amd64 -p 2023Q4 -f pkgs_to_build.txt [00:00:00] Creating the reference jail... done [00:00:01] Mounting system devices for 132_amd64-2023Q4 [00:00:01] Mounting ports/packages/distfiles [00:00:01] Stashing existing package repository [00:00:01] Mounting packages from: /usr/local/poudriere/data/packages/132_amd64-2023Q4 /etc/resolv.conf -> /usr/local/poudriere/data/.m/132_amd64-2023Q4/ref/etc/resolv.conf [00:00:01] Starting jail 132_amd64-2023Q4 [00:00:01] Will build as nobody: (65534:65534) [00:00:01] Logs: /usr/local/poudriere/data/logs/bulk/132_amd64-2023Q4/2023-12-18_13h40m31s [00:00:01] Loading MOVED for /usr/local/poudriere/data/.m/132_amd64-2023Q4/ref/usr/ports [00:00:02] Ports supports: FLAVORS SELECTED_OPTIONS [00:00:02] Gathering ports metadata [00:00:08] Calculating ports order and dependencies [00:00:09] Sanity checking the repository [00:00:09] Checking packages for incremental rebuild needs [00:00:11] Deleting stale symlinks... done [00:00:11] Deleting empty directories... done [00:00:12] Cleaning the build queue [00:00:12] Sanity checking build queue [00:00:12] Processing PRIORITY_BOOST [00:00:12] Balancing pool [00:00:12] Recording filesystem state for prepkg... done [00:00:12] Building 1 packages using 1 builders [00:00:12] Starting/Cloning builders [00:00:14] Hit CTRL+t at any time to see build progress and stats [00:00:14] [01] [00:00:00] Building www/firefox | firefox-121.0,2 Thank you very much ! Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
ZPool on iSCSI storage not available after a reboot
This is a somewhat odd problem and may have nothing to do with iSCSI config at all. Suffice it to say that I have the following in the server /etc/rc.conf : # # the iSCSI initiator iscsid_enable="YES" iscsictl_enable="YES" iscsictl_flags="-Aa" # During boot I see this on the console : cannot import 'proteus': no suchpid 55 (zpool) is attempting to use unsafe AIO requests - not logging anymore pool or dataset Destroy and re-create the pool from a backup source. cachefile import failed, retrying no pools available to import Sure enough the machine brings up a 10Gbit link with jumboframes *after* the above messages : ix0: flags=1008843 metric 0 mtu 9000 options=4e53fbb ether 8c:dc:d4:ae:18:b8 inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 media: Ethernet autoselect (10Gbase-Twinax ) status: active nd6 options=29 Then a little later I see iscsi doing its goodness : da0 at iscsi1 bus 0 scbus8 target 0 lun 0 da0: Fixed Direct Access SPC-5 SCSI device da0: Serial Number MYSERIAL da0: 150.000MB/s transfers da0: Command Queueing enabled da0: 2097152MB (4294967296 512 byte sectors) add net ::0.0.0.0: gateway ::1 Starting iscsid. Starting iscsictl. The storage exists just fine and iSCSI seems to be doing its thing : root@titan:~ # root@titan:~ # camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (pass1,ada1) at scbus2 target 0 lun 0 (ses0,pass2) at scbus6 target 0 lun 0 (ses1,pass3) at scbus7 target 0 lun 1 (pass4,nda0) at scbus8 target 0 lun 0 (da0,pass5) root@titan:~ # root@titan:~ # gpart show da0 =>40 4294967216 da0 GPT (2.0T) 40 8 - free - (4.0K) 48 42949672001 freebsd-zfs (2.0T) 4294967248 8 - free - (4.0K) root@titan:~ # However the zpool therein is not seen : root@titan:~ # root@titan:~ # zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT iota 7.27T 597G 6.68T- - 0% 8% 1.00x ONLINE - t0 444G 40.8G 403G- - 4% 9% 1.00x ONLINE - root@titan:~ # Of course I can manually import it : root@titan:~ # zpool import pool: proteus id: 15277728307274839698 state: ONLINE status: Some supported features are not enabled on the pool. (Note that they may be intentionally disabled if the 'compatibility' property is set.) action: The pool can be imported using its name or numeric identifier, though some features will not be available without an explicit 'zpool upgrade'. config: proteus ONLINE da0p1 ONLINE root@titan:~ # It seems as if there is something out of sequence and the iSCSI processes should be happening earlier in the boot process? I really do not know and am wondering why that zpool proteus on the iSCSI storage needs to be manually import'ed after a reboot. Any insights would be wonderful. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: ZPool on iSCSI storage not available after a reboot
On 3/12/24 15:41, Alan Somers wrote: On Tue, Mar 12, 2024 at 1:28 PM Dennis Clarke wrote: . . . . Yes, this looks exactly like an ordering problem. zpools get imported early in the boot process, under the assumption that most of them are local. Networking comes up later, under the assumption that networking might require files that are mounted on ZFS. For you, I suggest setting proteus's cachefile to a non-default location and importing it from /etc/rc.local, like this: zpool set cachefile=/var/cache/iscsi-zpools.cache proteus Then in /etc/rc.local: zpool import -a -c /var/cache/iscsi-zpools.cache -o cachefile=/var/cache/iscsi-zpools.cache That seems to be perfectly reasonable. I will give that a test right now. I was messing with the previous zpool called proteus and destroyed it. Easy enough to re-create : titan# gpart add -t freebsd-zfs /dev/da0 da0p1 added titan# titan# gpart show /dev/da0 =>40 4294967216 da0 GPT (2.0T) 40 8 - free - (4.0K) 48 42949672001 freebsd-zfs (2.0T) 4294967248 8 - free - (4.0K) titan# titan# zpool create -O compress=zstd -O checksum=sha512 -O atime=off -o compatibility=openzfs-2.0-freebsd -o autoexpand=off -o autoreplace=on -o failmode=continue -o listsnaps=off -m none proteus /dev/da0p1 titan# zpool set cachefile=/var/cache/iscsi-zpools.cache proteus titan# titan# ls -lapb /etc/rc.local ls: /etc/rc.local: No such file or directory titan# ed /etc/rc.local /etc/rc.local: No such file or directory a zpool import -a -c /var/cache/iscsi-zpools.cache -o cachefile=/var/cache/iscsi-zpools.cache . f /etc/rc.local w 92 q titan# After reboot ... yes ... this seems to get the job done neatly ! root@titan:~ # root@titan:~ # zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT iota 7.27T 321G 6.95T- - 0% 4% 1.00x ONLINE - proteus 1.98T 1.03M 1.98T- - 0% 0% 1.00x ONLINE - t0444G 40.8G 403G- - 4% 9% 1.00x ONLINE - root@titan:~ # root@titan:~ # uptime 8:21PM up 3 mins, 1 user, load averages: 0.02, 0.04, 0.01 root@titan:~ # Looks good. Thank you very much :) -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
On 8/5/24 12:12, Harry Schmalzbauer wrote: Hello, two years elapsed since I last deployed a FreeBSD machine that utilizd bhyve(8), which already had bhyve_config(5) support back then. This may feel slightly off topic but I assure you that it is of great benefit. Have a look at the brilliant creation of Steve Wills that I know and love as "cirrina" : https://gitlab.com/swills/cirrina/-/releases It is very much in active development and does a neat job of handling a pile of stuff related to bhyve. Not the least of which is the creation and configuration and management of a whole slew of VMs. It is actively being tested and developed and I have been using it while testing PCI device passthru of NVidia Quadro GPUs for the purpose of CUDA dev work. I also am motivated to write up a pile of documentation related to cirrina given that it really does feel like a Swiss Army Knife which can do damn near everything I ever wanted with bhyve. Have a long hard stare at it. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
On 8/5/24 14:22, Miroslav Lachman wrote: On 05/08/2024 18:50, Dennis Clarke wrote: On 8/5/24 12:12, Harry Schmalzbauer wrote: Hello, two years elapsed since I last deployed a FreeBSD machine that utilizd bhyve(8), which already had bhyve_config(5) support back then. This may feel slightly off topic but I assure you that it is of great benefit. Have a look at the brilliant creation of Steve Wills that I know and love as "cirrina" : https://gitlab.com/swills/cirrina/-/releases It is very much in active development and does a neat job of handling a pile of stuff related to bhyve. Not the least of which is the creation and configuration and management of a whole slew of VMs. It is actively being tested and developed and I have been using it while testing PCI device passthru of NVidia Quadro GPUs for the purpose of CUDA dev work. I also am motivated to write up a pile of documentation related to cirrina given that it really does feel like a Swiss Army Knife which can do damn near everything I ever wanted with bhyve. I have seen cirrina some time ago. I was interested in GUI. A GUI with bells and whistles like VMware Workstation is a long way off. Feel free to drop a few million US dollars and I am sure a prototype would be available in six months. It may even work. Sorry but cirrina(d) is just great from the command line for now. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: git: ce4dcb97ca43 - main - zfs: merge openzfs/zfs@9c56b8ec7
On 8/10/24 22:15, Cy Schubert wrote: In message , Mark Millard write s: =E2=80=A2 [2:12 PM]Flox: getting this error in ZFS since recent = update in HEAD =E2=80=A2 [2:12 PM]Flox: sysctl_warn_reuse: can't re-use a leaf = (kstat.zfs.zroot.dataset.objset-0x204.zil_itx_metaslab_slog_alloc)! pid 58 (zpool) is attempting to use unsafe AIO requests - not logging = anymore =E2=80=A2 [2:13 PM]Flox: FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0 = main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024 = mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG = amd64 Yeah. I'm getting tons of these on all my machines as well. sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.cwsys.dataset.objset-0x2cc d.zil_itx_metaslab_slog_alloc)! Yep. Seems to be a real thing just pouring out all over the console here too : sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x4b0.zil_itx_metaslab_slog_alloc)! Just a tad uncomfortable to see. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: git: ce4dcb97ca43 - main - zfs: merge openzfs/zfs@9c56b8ec7
On 8/11/24 09:41, Cy Schubert wrote: In message <54076f5e-cd6d-40d6-b4b7-495cf8e67...@blastwave.org>, Dennis Clarke writes: On 8/10/24 22:15, Cy Schubert wrote: In message , Mark Millard write s: =E2=80=A2 [2:12 PM]Flox: getting this error in ZFS since recent = update in HEAD =E2=80=A2 [2:12 PM]Flox: sysctl_warn_reuse: can't re-use a leaf = (kstat.zfs.zroot.dataset.objset-0x204.zil_itx_metaslab_slog_alloc)! pid 58 (zpool) is attempting to use unsafe AIO requests - not logging = anymore =E2=80=A2 [2:13 PM]Flox: FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0 = main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024 = mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG = amd64 Yeah. I'm getting tons of these on all my machines as well. sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.cwsys.dataset.objset-0x2c c d.zil_itx_metaslab_slog_alloc)! Yep. Seems to be a real thing just pouring out all over the console here too : sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x4b0.zil_itx_metaslab_slog_alloc)! This only happens on import: when the system boots and when any pools are imported later on. Sadly .. nope ... that is not the case : triton# uptime 4:27PM up 11:33, 2 users, load averages: 2.76, 0.93, 0.37 triton# triton# sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)! sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)! So seems to be a thing when the machine is running and doing things like a poudriere bulk build etc etc .. I have not seen it when the machine is just twiddling its thumbs pondering an existential crisis. Yet. Just a tad uncomfortable to see. Uncomfortable but harmless. In that case let's make it go away .. mmmkay ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Anyone else seeing a stack of newline chars expressed at boot?
I have only been seeing this in the last few weeks. Perhaps ten days or so. When I see the nice beastie on the console I then get each second delay expressed with a newline thus : | | +-+ Autoboot in 10 seconds. [Space] to pause Autoboot in 9 seconds. [Space] to pause Autoboot in 8 seconds. [Space] to pause Autoboot in 7 seconds. [Space] to pause Autoboot in 6 seconds. [Space] to pause Autoboot in 5 seconds. [Space] to pause Autoboot in 4 seconds. [Space] to pause Autoboot in 3 seconds. [Space] to pause Autoboot in 2 seconds. [Space] to pause Seems odd. Curious if anyone else sees this? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: Anyone else seeing a stack of newline chars expressed at boot?
On 9/1/24 19:28, Warner Losh wrote: On Sun, Sep 1, 2024, 5:26 PM Dennis Clarke wrote: I have only been seeing this in the last few weeks. Perhaps ten days or so. When I see the nice beastie on the console I then get each second delay expressed with a newline thus : | | +-+ Autoboot in 10 seconds. [Space] to pause Autoboot in 9 seconds. [Space] to pause Autoboot in 8 seconds. [Space] to pause Autoboot in 7 seconds. [Space] to pause Autoboot in 6 seconds. [Space] to pause Autoboot in 5 seconds. [Space] to pause Autoboot in 4 seconds. [Space] to pause Autoboot in 3 seconds. [Space] to pause Autoboot in 2 seconds. [Space] to pause Seems odd. Curious if anyone else sees this? What kind of console? Serial. Nothing fancy. The machine I use to watch the serial port is running 14.1-RELEASE-p3 and nothing fancy : callisto$ callisto$ uname -a FreeBSD callisto 14.1-RELEASE-p3 FreeBSD 14.1-RELEASE-p3 GENERIC amd64 callisto$ callisto$ id uid=1001(admsys) gid=1001(admsys) groups=1001(admsys),0(wheel),68(dialer) callisto$ callisto$ echo $TERM vt100 callisto$ callisto$ cu -s 38400 -l /dev/cuau0 Connected triton# triton# uname -apKU FreeBSD triton 15.0-CURRENT FreeBSD 15.0-CURRENT #12 main-n271936-0578fe492284-dirty: Sun Sep 1 22:52:43 GMT 2024 root@triton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 amd64 1500023 1500023 triton# triton# echo $TERM vt100 triton# So there we have it. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: Anyone else seeing a stack of newline chars expressed at boot?
On 9/3/24 19:47, Warner Losh wrote: On Mon, Sep 2, 2024 at 1:07 AM Dennis Clarke wrote: On 9/1/24 19:28, Warner Losh wrote: On Sun, Sep 1, 2024, 5:26 PM Dennis Clarke wrote: I have only been seeing this in the last few weeks. Perhaps ten days or so. When I see the nice beastie on the console I then get each second delay expressed with a newline thus : | | +-+ Autoboot in 10 seconds. [Space] to pause Autoboot in 9 seconds. [Space] to pause Autoboot in 8 seconds. [Space] to pause Autoboot in 7 seconds. [Space] to pause Autoboot in 6 seconds. [Space] to pause Autoboot in 5 seconds. [Space] to pause Autoboot in 4 seconds. [Space] to pause Autoboot in 3 seconds. [Space] to pause Autoboot in 2 seconds. [Space] to pause Seems odd. Curious if anyone else sees this? What kind of console? Serial. Nothing fancy. The machine I use to watch the serial port is running 14.1-RELEASE-p3 and nothing fancy : callisto$ callisto$ uname -a FreeBSD callisto 14.1-RELEASE-p3 FreeBSD 14.1-RELEASE-p3 GENERIC amd64 callisto$ callisto$ id uid=1001(admsys) gid=1001(admsys) groups=1001(admsys),0(wheel),68(dialer) callisto$ callisto$ echo $TERM vt100 callisto$ callisto$ cu -s 38400 -l /dev/cuau0 Connected triton# triton# uname -apKU FreeBSD triton 15.0-CURRENT FreeBSD 15.0-CURRENT #12 main-n271936-0578fe492284-dirty: Sun Sep 1 22:52:43 GMT 2024 root@triton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 amd64 1500023 1500023 triton# triton# echo $TERM vt100 triton# So there we have it. stty -a? triton# echo $TERM vt100 triton# stty -a speed 38400 baud; 24 rows; 92 columns; lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk brkint -inpck -ignpar -parmrk iutf8 oflags: opost onlcr -ocrnl tab3 -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf rtsdtr cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ; eol2 = ; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; triton# triton# triton# env | sort BLOCKSIZE=K EDITOR=/usr/bin/vi ENV=/root/.shrc HOME=/root LANG=en_US.UTF-8 LC_TIME=C LESS_IS_MORE=1 LOGNAME=root MAIL=/var/mail/root MANPATH=:/opt/schily/share/man MM_CHARSET=en_US.UTF-8 OLDPWD=/usr/src PAGER=/usr/bin/more PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/opt/schily/bin PWD=/root SHELL=/bin/sh TERM=vt100 TMPDIR=/var/tmp/root TZ=GMT0 USER=root VISUAL=/usr/bin/vi XDG_RUNTIME_DIR=/var/run/xdg/root XTERM_LOCALE=en_US.UTF-8 triton# So no fancy TERMCAP stuff either. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: [sw-dev] GCC 8.x or 9.x for FreeBSD rv64imafdc ??
came pretty much 2.000 thus :
root@callisto:/home/dclarke/foo # cat pi.c
/*
* The Open Group Base Specifications Issue 6
* IEEE Std 1003.1, 2004 Edition
*/
#define _XOPEN_SOURCE 600
#include
#include
#include
int main ( int argc, char *argv[])
{
long double pi128 =
3.1415926535897932384626433832795028841971693993751L;
double pi64 = M_PI;
printf (" the sizeof(pi128) is %i\n", sizeof(pi128) );
printf (" the sizeof(pi64) is %i\n", sizeof(pi64) );
printf ("pi128 may be %44.38Lg\n", pi128 );
printf ("pi64 may be %18.16g\n", pi64 );
return ( EXIT_SUCCESS );
}
The assembly looks perfect as does the static data :
# cat pi.s
.file "pi.c"
.option nopic
.text
.section.rodata
.align 3
.LC2:
.string " the sizeof(pi128) is %i\n"
.align 3
.LC3:
.string " the sizeof(pi64) is %i\n"
.align 3
.LC4:
.string "pi128 may be %44.38Lg\n"
.align 3
.LC5:
.string "pi64 may be %44.38Lg\n"
.text
.align 1
.globl main
.type main, @function
main:
addisp,sp,-64
sd ra,56(sp)
sd s0,48(sp)
addis0,sp,64
mv a5,a0
sd a1,-64(s0)
sw a5,-52(s0)
lui a5,%hi(.LC0)
ld a4,%lo(.LC0)(a5)
sd a4,-32(s0)
ld a5,%lo(.LC0+8)(a5)
sd a5,-24(s0)
lui a5,%hi(.LC1)
fld fa5,%lo(.LC1)(a5)
fsd fa5,-40(s0)
li a1,16
lui a5,%hi(.LC2)
addia0,a5,%lo(.LC2)
callprintf
li a1,8
lui a5,%hi(.LC3)
addia0,a5,%lo(.LC3)
callprintf
ld a2,-32(s0)
ld a3,-24(s0)
lui a5,%hi(.LC4)
addia0,a5,%lo(.LC4)
callprintf
ld a1,-40(s0)
lui a5,%hi(.LC5)
addia0,a5,%lo(.LC5)
callprintf
li a5,0
mv a0,a5
ld ra,56(sp)
ld s0,48(sp)
addisp,sp,64
jr ra
.size main, .-main
.section.rodata
.align 4
.LC0:
.word 3306619320
.word 2221509004
.word 3041149649
.word 1073779231
.align 3
.LC1:
.word 1413754136
.word 1074340347
.ident "GCC: (GNU) 8.2.0"
However the output is weird :
# ./pi
the sizeof(pi128) is 16
the sizeof(pi64) is 8
pi128 may be 2.076293945362811600603241536472604
pi64 may be 3.141592653589793
However the in memory data is flawless :
# echo "16o 1074340347p 1413754136pq" | dc
400921FB
54442D18
# echo "16o 1073779231p 3041149649p 2221509004p 3306619320pq" | dc
4000921F
B54442D1
8469898C
C51701B8
I did file a bug :
Bug 242067 - libc: r354823 riscv64 has a fault in printf()
where IEEE754-2008 fp128 data is output wrong
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242067
Which seems to happen down inside _ldtoa.c under gdtoa.c and I did
single step all the way through the process on IBM PowerPC64 FreeBSD
as well as amd64. Very weird output.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
ps: currently locked in battle with this https://www.twitch.tv/lastmiles
___
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: getting rid of sys/nfs/nfs_lock.c
On 12/28/19 7:30 PM, Rick Macklem wrote: Hi, sys/nfs/nfs_lock.c uses Giant. Since it has not been used by default since March 2008, I suspect it can be removed from head without any impact. Post March 2008, the only way this code could be executed is by both building a kernel without "options NFSLOCKD" and deleting nfslockd.ko from the kernel boot directory and then running rpc.lockd on the system. I doubt anyone has been doing both of the above, but if you think it is still useful, please speak up. (I have an untested patch that replaces Giant with a regular mutex. I realized this code is not used when I trying to test it.;-) Also, if it seems appropriate, I could commit a patch that makes it print out "deprecated and going away before FreeBSD 13" message, but I doubt anyone will ever see it. Should I do such a message and wait a few months for the deletion? Such a message is a good idea. I am curious if there is any way in which we would see that message when creating an NFS share via ZFS set sharenfs='foo' ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: r356776 breaks kernel for powerpc64 users
On 2020-01-26 19:27, Mark Millard wrote: Piotr Kubaj listy at anongoth.pl wrote on Thu Jan 16 19:56:11 UTC 2020 : revision 356776 breaks booting for powerpc64 users. It reportedly works fine on POWER8, but I get kernel panic on POWER9 (Talos II) right after the usual warning: WITNESS enabled. Kernel panic is uploaded to https://pastebin.com/s8ZaUNS2. @jeff Since you commited this patch, can you fix this issue or revert this commit? Is this still a problem for powerpc64? I've not seen anything looking like a direct response or like a status update for this. I do see arm report(s) of problems that they also attributed to head -r356776 . But I've no clue how good the evidence is generally. An example message is: https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html But one part of that is for specifically for going from -r356767 to the next check-in to head: -r356776 . That problem likely has good evidence for the attribution to -r356776 . I will give current a try and report back. However I am hesitant to do so as I have a working G5 right now. For science ... I will do the experiment. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: Which AMD CPUs are supported -- temperature
On 2020-02-12 15:23, mike tancsa wrote: sysctl -a dev.cpu.0.temperature Those sort of things seem to just "not work"(tm) on older type of processors : vesta# vesta# vesta# uname -apKU FreeBSD vesta 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64 amd64 1201000 1201000 vesta# sysctl -a | grep 'cpu' kern.smp.cpus: 6 kern.smp.maxcpus: 256 kern.ccpu: 0 0, 1, 2, 3, 4, 5 0, 1 0 1 2, 3 2 3 4, 5 4 5 kern.sched.cpusetsize: 32 kern.pin_pcpu_swi: 0 kern.racct.pcpu_threshold: 1 cpu HAMMER device cpufreq kern.vt.splash_cpu_duration: 10 kern.vt.splash_cpu_style: 2 kern.vt.splash_ncpu: 0 kern.vt.splash_cpu: 0 vfs.ncpurgeminvnodes: 512 net.inet.tcp.per_cpu_timers: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.acpi.cpu_unordered: 0 hw.ncpu: 6 hw.acpi.cpu.cx_lowest: C1 hw.intrs: irq0: attimer0:3 @cpu0(domain0): 0 irq1: atkbd0:1 @cpu0(domain0): 0 irq3::5 @cpu0(domain0): 0 irq4::7 @cpu0(domain0): 0 irq5::9 @cpu0(domain0): 0 irq6::11 @cpu0(domain0): 0 irq7::13 @cpu0(domain0): 0 irq8: atrtc0:15 @cpu0(domain0): 0 irq9: acpi0:17 @cpu0(domain0): 0 irq10::19 @cpu0(domain0): 0 irq11::21 @cpu0(domain0): 0 irq12::23 @cpu0(domain0): 0 irq13::25 @cpu0(domain0): 0 irq14::27 @cpu0(domain0): 0 irq15::29 @cpu0(domain0): 0 irq16: hdac1:31 @cpu0(domain0): 37 irq17: ehci0 ehci1+:33 @cpu0(domain0): 2 irq18: ohci0 ohci1*:35 @cpu0(domain0): 22 irq19: ahci0:37 @cpu0(domain0): 4704900 irq20::39 @cpu0(domain0): 0 irq21::41 @cpu0(domain0): 0 irq22::43 @cpu0(domain0): 0 irq23::45 @cpu0(domain0): 0 irq256: hpet0:t0:53 @cpu0(domain0): 0 irq257: hpet0:t1:55 @cpu0(domain0): 0 irq258: hpet0:t2:57 @cpu0(domain0): 0 irq259: hdac0:59 @cpu0(domain0): 3 irq260: xhci0:61 @cpu0(domain0): 0 irq261: re0:63 @cpu0(domain0): 2908189 dev.cpufreq.0.%parent: cpu0 dev.cpufreq.0.%pnpinfo: dev.cpufreq.0.%location: dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc: dev.cpufreq.%parent: dev.hwpstate.0.%parent: cpu0 dev.acpi_perf.5.%parent: cpu5 dev.acpi_perf.4.%parent: cpu4 dev.acpi_perf.3.%parent: cpu3 dev.acpi_perf.2.%parent: cpu2 dev.acpi_perf.1.%parent: cpu1 dev.acpi_perf.0.%parent: cpu0 dev.cpu.5.cx_method: C1/hlt C2/io dev.cpu.5.cx_usage_counters: 12254878 0 dev.cpu.5.cx_usage: 100.00% 0.00% last 120487us dev.cpu.5.cx_lowest: C1 dev.cpu.5.cx_supported: C1/1/0 C2/2/100 dev.cpu.5.%parent: acpi0 dev.cpu.5.%pnpinfo: _HID=none _UID=0 dev.cpu.5.%location: handle=\_PR_.P006 dev.cpu.5.%driver: cpu dev.cpu.5.%desc: ACPI CPU dev.cpu.4.cx_method: C1/hlt C2/io dev.cpu.4.cx_usage_counters: 12019819 0 dev.cpu.4.cx_usage: 100.00% 0.00% last 2984us dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_supported: C1/1/0 C2/2/100 dev.cpu.4.%parent: acpi0 dev.cpu.4.%pnpinfo: _HID=none _UID=0 dev.cpu.4.%location: handle=\_PR_.P005 dev.cpu.4.%driver: cpu dev.cpu.4.%desc: ACPI CPU dev.cpu.3.cx_method: C1/hlt C2/io dev.cpu.3.cx_usage_counters: 12269169 0 dev.cpu.3.cx_usage: 100.00% 0.00% last 33499us dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_supported: C1/1/0 C2/2/100 dev.cpu.3.%parent: acpi0 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%location: handle=\_PR_.P004 dev.cpu.3.%driver: cpu dev.cpu.3.%desc: ACPI CPU dev.cpu.2.cx_method: C1/hlt C2/io dev.cpu.2.cx_usage_counters: 12058705 0 dev.cpu.2.cx_usage: 100.00% 0.00% last 8us dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_supported: C1/1/0 C2/2/100 dev.cpu.2.%parent: acpi0 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%location: handle=\_PR_.P003 dev.cpu.2.%driver: cpu dev.cpu.2.%desc: ACPI CPU dev.cpu.1.cx_method: C1/hlt C2/io dev.cpu.1.cx_usage_counters: 10797189 0 dev.cpu.1.cx_usage: 100.00% 0.00% last 1713us dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_supported: C1/1/0 C2/2/100 dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%location: handle=\_PR_.P002 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_method: C1/hlt C2/io dev.cpu.0.cx_usage_counters: 28428935 0 dev.cpu.0.cx_usage: 100.00% 0.00% last 922us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 C2/2/100 dev.cpu.0.freq_levels: 3300/13770 3000/11040 2400/7417 1800/4680 1400/3195 dev.cpu.0.freq: 1400 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.%parent: security.jail.param.cpuset.id: 0 vesta# Such is life. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: To people upgrading from before r363679
On 8/5/20 9:19 PM, Warner Losh wrote:
> If you are upgrading across r363679, you may have installworld fail, as
> documented in UPDATING.
>
> I have a fix (that requires a trip through buildworld) that's under review
> at https://reviews.freebsd.org/D25967 . The changes are likely good, but
> comments likely need updating.
>
> The short version is that we purposely use old libraries to install the
> system. We created a symbolic link to a bunch of binaries on the system and
> once installworld installs one of them, we get the error. The workaround
> works because we copy libc.so before doing the installworld, so now we're
> running with a new libc.so with new binaries, which works. My fix always
> copies and never symlinks. The symbolic link stuff is too fragile.
>
> With it, I've done one system, but I'd appreciate reports (on the code
> review if possible, to me in email if not) of people who have success
> upgrading with this. If you've already run installworld and hit the
> undefined symbol, it's too late for you to help me test (since re-running
> is the same as hitting to test is the same as the workaround and so it will
> work even if my workaround is busted).
>
> Some history: This was introduced about 2 years ago. Prior to that, we
> always copied binaries for the install.
This will fix the situation :
triton$
triton$ cat /usr/src/my.patch
--- Makefile.inc1.orig 2020-08-06 21:55:35.403116000 +
+++ Makefile.inc1 2020-08-07 04:51:05.25984 +
@@ -2296,13 +2296,12 @@
.for _tool in ${_bootstrap_tools_links}
${_bt}-link-${_tool}: .PHONY .MAKE
- @if [ ! -e "${WORLDTMP}/legacy/bin/${_tool}" ]; then \
- source_path=`which ${_tool}`; \
- if [ ! -e "$${source_path}" ] ; then \
- echo "Cannot find host tool '${_tool}'"; false; \
- fi; \
- ln -sfnv "$${source_path}"
"${WORLDTMP}/legacy/bin/${_tool}"; \
- fi
+ @rm -f "${WORLDTMP}/legacy/bin/${_tool}"; \
+ source_path=`which ${_tool}`; \
+ if [ ! -e "$${source_path}" ] ; then \
+ echo "Cannot find host tool '${_tool}'"; false; \
+ fi; \
+ cp -f "$${source_path}" "${WORLDTMP}/legacy/bin/${_tool}"
${_bt}-links: ${_bt}-link-${_tool}
.endfor
--- tools/build/Makefile.orig 2020-08-06 21:55:35.416626000 +
+++ tools/build/Makefile2020-08-07 04:49:09.064737000 +
@@ -119,26 +119,26 @@
host-symlinks:
@echo "Linking host tools into ${DESTDIR}/bin"
.for _tool in ${_host_tools_to_symlink}
- @if [ ! -e "${DESTDIR}/bin/${_tool}" ]; then \
- source_path=`which ${_tool}`; \
- if [ ! -e "$${source_path}" ] ; then \
- echo "Cannot find host tool '${_tool}'"; false; \
- fi; \
- ln -sfnv "$${source_path}" "${DESTDIR}/bin/${_tool}"; \
- fi
+ @source_path=`which ${_tool}`; \
+ if [ ! -e "$${source_path}" ] ; then \
+ echo "Cannot find host tool '${_tool}'"; false; \
+ fi; \
+ rm -f "${DESTDIR}/bin/${_tool}"; \
+ cp -f "$${source_path}" "${DESTDIR}/bin/${_tool}"
.endfor
.for _tool in ${_host_abs_tools_to_symlink}
@source_path="${_tool:S/:/ /:[1]}"; \
target_path="${DESTDIR}/bin/${_tool:S/:/ /:[2]}"; \
- if [ ! -e "$${target_path}" ] ; then \
- if [ ! -e "$${source_path}" ] ; then \
- echo "Host tool '${src_path}' is missing"; false; \
- fi; \
- ln -sfnv "$${source_path}" "$${target_path}"; \
- fi
+ if [ ! -e "$${source_path}" ] ; then \
+ echo "Host tool '${src_path}' is missing"; false; \
+ fi; \
+ rm -f "$${target_path}"; \
+ cp -f "$${source_path}" "$${target_path}"
.endfor
.if exists(/usr/libexec/flua)
ln -sf /usr/libexec/flua ${DESTDIR}/usr/libexec/flua
++ rm -f ${DESTDIR}/usr/libexec/flua
++ cp -f /usr/libexec/flua ${DESTDIR}/usr/libexec/flua
.endif
# Create all the directories that are needed during the legacy,
bootstrap-tools
triton$
triton$ uname -apKU
FreeBSD triton 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r363997: Fri Aug 7
02:48:03 GMT 2020
root@triton:/usr/obj/usr/src/head/amd64.amd64/sys/GENERIC amd64 amd64
1300105 1300105
Dennis
___
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"
service -e doesn't really sort does it? the cool tip is slightly off
Saw this pop up : rhea$ su - admsys Password: If you want to get a sorted list of all services that are started when FreeBSD boots, enter "service -e". -- Lars Engels admsys@rhea:~ $ To which I thought "sorted? really?" amalthea# cd amalthea# service -e /etc/rc.d/rctl /etc/rc.d/hostid /etc/rc.d/zpool /etc/rc.d/zvol /etc/rc.d/hostid_save /etc/rc.d/zfsbe /etc/rc.d/zfs /etc/rc.d/cleanvar /etc/rc.d/kldxref /etc/rc.d/ip6addrctl /etc/rc.d/mixer /etc/rc.d/devmatch /etc/rc.d/netif /etc/rc.d/resolv /etc/rc.d/devd /etc/rc.d/motd /etc/rc.d/newsyslog /etc/rc.d/virecover /etc/rc.d/dmesg /etc/rc.d/gptboot /etc/rc.d/syslogd /etc/rc.d/savecore /etc/rc.d/rpcbind /etc/rc.d/mountd /etc/rc.d/nfsd /etc/rc.d/ntpd /etc/rc.d/cron /etc/rc.d/sshd /etc/rc.d/sendmail /etc/rc.d/bgfsck /usr/local/etc/rc.d/smartd amalthea# Nope. That doesn't look sorted. Unless the sorted means "order in which they start" perhaps. So maybe take out the word "sorted". Either that or insert the "started order" as the manpage claims : root@rhea:/usr/src/freebsd-src # diff -u usr.bin/fortune/datfiles/freebsd-tips.orig usr.bin/fortune/datfiles/freebsd-tips --- usr.bin/fortune/datfiles/freebsd-tips.orig 2021-01-15 00:37:37.863506000 + +++ usr.bin/fortune/datfiles/freebsd-tips 2021-01-16 07:46:57.335803000 + @@ -517,7 +517,7 @@ -- Lars Engels % -If you want to get a sorted list of all services that are started when FreeBSD boots, +If you want to get a list of all services that are started when FreeBSD boots, enter "service -e". -- Lars Engels root@rhea:/usr/src/freebsd-src # Sorry for being all OCD here. Perhaps it should say sorted in the order in which they were started. Something like that. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: service -e doesn't really sort does it? the cool tip is slightly off
On 1/17/21 1:46 PM, Graham Perrin wrote: > On 16/01/2021 23:28, Dennis Clarke wrote: > >> … maybe take out the word "sorted". Either that or >> insert the "started order" as the manpage claims : >> >> root@rhea:/usr/src/freebsd-src # diff -u >> usr.bin/fortune/datfiles/freebsd-tips.orig >> usr.bin/fortune/datfiles/freebsd-tips >> --- usr.bin/fortune/datfiles/freebsd-tips.orig 2021-01-15 >> 00:37:37.863506000 + >> +++ usr.bin/fortune/datfiles/freebsd-tips 2021-01-16 >> 07:46:57.335803000 + >> @@ -517,7 +517,7 @@ >> >> -- Lars Engels >> % >> -If you want to get a sorted list of all services that are started when >> FreeBSD boots, >> +If you want to get a list of all services that are started when FreeBSD >> boots, >> enter "service -e". >> >> -- Lars Engels >> root@rhea:/usr/src/freebsd-src # >> >> Sorry for being all OCD here. Perhaps it should say sorted in the order >> in which they were started. Something like that. >> > > In lieu of 'sorted', how about 'dependency-ordered'? > Anything that makes obvious sense would be nice. When I say "obvious" here I mean "really obvious to a new user that just installed FreeBSD yesterday" and not "obvious to a twenty year expert." Dennis ___ 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"
How to fix a broken package ?
Dear Magic FreeBSD types : I have no idea what needs to be done in order for a broken package to get fixed. At the moment I can not build LXDE ( and other stuff ) on my shiney new poudriere pkg build server. There is a busted patch in a thing called "databases/sfcgal" where the version is wrong for 2024Q3 ports branch. The "main" branch seems to work just fine. Please see : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281317 So this seems to only happen in the 2024Q3 ports branch and there is a mysterious website called "FallOut?" that suggests it breaks in other place also : https://portsfallout.com/fallout?port=databases%2Fsfcgal%24 Is there anyone anywhere who can please make the 4 byte change in the 2024Q3 branch for that patch file? Thank you. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: How to fix a broken package ?
On 9/8/24 14:42, Dennis Clarke wrote: Dear Magic FreeBSD types : I have no idea what needs to be done in order . . . https://portsfallout.com/fallout?port=databases%2Fsfcgal%24 Is there anyone anywhere who can please make the 4 byte change in the 2024Q3 branch for that patch file? Thank you. The maintainer jumped on it. Neatly. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: change in /usr/bin/bc with CTRL-d no longer exit
On 9/16/24 10:13, Cy Schubert wrote: In message , void writes: On Sun, Sep 15, 2024 at 03:16:46PM -0500, Dan Mack wrote: On 14.1 and prior, a CTRL-d will exit a bc session. Today I noticed that on 3 different 15-CURRENT systems, it appears to be ignored. Works fine otherwise and I can exit the bc session with the 'quit' command okay. I re-tested this on the system console on fresh login just to rule out any terminal madness. Here's a paste of what I see: https://tpaste.us/VYya I did a fresh install of 14.1 and it works as it did previously. No biggie, just wondering if anyone else on -CURRENT can confirm/deny this change on their system. [void@vm5 ~ ] uname -KU 1400504 1400504 [void@vm5 ~ ] echo 2+2 | bc -l 4 [void@vm3 ~ ] uname -KU 1500023 1500023 [void@vm3 ~ ] echo 2+2 | bc -l 4 Of course the above works because the regression only affects tty users. Here is some paint on the bikeshed : enceladus# uname -apKU FreeBSD enceladus 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n271918-d7c87526b1c3-dirty: Mon Sep 2 09:55:54 UTC 2024 root@enceladus:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC riscv riscv64 1500023 1500023 enceladus# enceladus# bc -lq scale=36 a(1)*4 3.141592653589793238462643383279502884 ^D ^C interrupt (type "quit" to exit) ready for more input quit enceladus# Yep. That is borked. bc(1) now ignores EOF on the terminal while the above still works. You can circumvent this by putting "export BC_TTY_MODE=0" into your .profile. The side effect is that line editing will no longer work. I will have to try that. However why would bc change at all? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
main-n254654-d4e8207317c results in "no pools available to import"
Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. The rev seems to be main-n254654-d4e8207317c. I can boot single user mode and get a command prompt but nothing past that. Is there something borked in ZFS in CURRENT ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: main-n254654-d4e8207317c results in "no pools available to import"
- c3/var/tmp@2022022818005276K - - -- c3/var/tmp@2022022818154276K - - -- c3/var/tmp@2022030219410176K - - -- c3/var/tmp@2022030607084584K - - -- c3/var/tmp@2022030608050284K - - -- c3/var/tmp@2022030621585084K - - -- c3/var/tmp@2022030622043776K - - -- c3/var/tmp@2022030622124576K - - -- c3/var/tmp@2022030700364784K - - -- c3/var/tmp@2022031014452592K - - -- c3/var/tmp@2022031103004784K - - -- c3/var/tmp@2022031104420384K - - -- c3/var/tmp@2022031104464384K - - -- c3/var/tmp@2022031116330984K - - -- c3/var/tmp@2022031613405684K - - -- c3/var/tmp@2022031616000384K - - -- c3/var/tmp@2022031801290084K - - -- c3/var/tmp@2022041006361084K - - -- root@phobos:/usr/src # Not sure what else to say. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: main-n254654-d4e8207317c results in "no pools available to import"
On 4/11/22 17:50, Tomoaki AOKI wrote: On Mon, 11 Apr 2022 20:18:48 +0200 Ronald Klop wrote: On 4/11/22 17:17, Dennis Clarke wrote: Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. The rev seems to be main-n254654-d4e8207317c. I can boot single user mode and get a command prompt but nothing past that. Is there something borked in ZFS in CURRENT ? Up until now you are the only one with this error on the mailinglist today. So I doubt something is borked. You could consider to share more details about your setup to help people to think along with you. Regards, Ronald. I have main at git c79331a42c308139828c1117f49224bb83617a53 booting fine, and no commits relatd with ZFS exists within git d4e8207317c. I was just looking at that and there is one : root@phobos:/usr/src # root@phobos:/usr/src # /usr/local/bin/git --no-pager log -n 32 --pretty=oneline --abbrev-commit --graph * d4e8207317c (HEAD -> main, origin/main, origin/HEAD) vmm_instruction_emul.c: fix bhyve build * be0d16b0b05 bsdinstall: filter out disks that are unavailable from the list of options in ZFS * 5580e5bd716 nfscl: Clean up the code by removing unused arguments * 5a17f489d58 vmm: fix set but not used warning * 5241577a223 vmm: fix set but not used warning * 3587bfa797c vmm: fix set but not used warning * 5c272efaba2 vmm: fix set but not used warnings * f877977a034 vmm: fix set but not used warnings * 893a3dd697e vmm: fix set but not used warning * f3ef799f564 Only return a mapped address from efi_phys_to_kva * 57e47ae514b Include the EFI Runtime Code in the DMAP * bde57090337 UPDATING: Fix a few typos * c79331a42c3 bhyve: use linker set for ipc commands * 38c3cf6aede nfscl: Clean up the code by removing unused arguments * c45d934f6b7 nfscl: Ansify a function header * bd8701dede1 Document procstat(1) advlock command * a5229a255ea Implement procstat(1) advlocks command * e79866ddf1c procstat(1): add ability to specify subcommands not requiring pid lists * 50d3c72558f libprocstat: document procstat_getadvlock(3) * 039d1496b07 libprocstat: add procstat_getadvlock(3) * eca39864f70 Add sysctl KERN_LOCKF * 6ead1379fd4 sys/user.h: Add kinfo_lockf structure to report advisory locks * 147e4fe3f1f kern_lockf.c: remove no longer neeeded UFS headers * 59e85819be6 lockf: remove lf_inode from struct lockf_entry * 5c075d64049 ufs/acl.h: forward-declare struct inode * 8cc19b1e47d Style. * a3214fbe7ff mount: use pidfile_signal * 287451fd019 pidfile: add pidfile_signal * ecbdfbfd18d netgraph(3): Remove a double word in a source code comment * d048e8c6196 ofed: Fix a typo in a source code comment * 299fcf402dc fsck_ffs(8): Fix a typo in a source code comment * 009727ed577 routed(8): Remove a double word in a source code comment root@phobos:/usr/src # I see be0d16b0b05 bsdinstall: filter out disks that are unavailable from the list of options in ZFS Not sure what that does however. I am looking at : root@phobos:/usr/src # git pull origin main remote: Enumerating objects: 100, done. remote: Counting objects: 100% (16/16), done. remote: Compressing objects: 100% (3/3), done. remote: Total 100 (delta 13), reused 13 (delta 13), pack-reused 84 Receiving objects: 100% (100/100), 189.37 KiB | 1.38 MiB/s, done. Resolving deltas: 100% (57/57), completed with 12 local objects. From git.freebsd.org:src * branchmain -> FETCH_HEAD d4e8207317c..673bce11ced main -> origin/main Updating d4e8207317c..673bce11ced Fast-forward lib/libc/sys/getdirentries.2 | 2 ++ sbin/ifconfig/ifconfig.8 | 5 +++-- stand/man/loader_lua.8 | 47 +++ sys/compat/linprocfs/linprocfs.c | 20 sys/compat/linux/linux_socket.c | 38 +- sys/compat/linux/linux_socket.h | 1 + sys/dev/axgbe/if_axgbe_pci.c | 65 - sys/kern/vfs_subr.c | 1 + sys/kern/vfs_syscalls.c | 4 sys/netinet/ip_mroute.c | 26 -- sys/netinet/ip_output.c | 2 +- sys/netinet6/ip6_output.c| 2 ++ sys/netpfil/ipfw/ip_fw2.c| 27 --- sys/netpfil/ipfw/ip_fw_log.c | 7 +-- sys/netpfil/pf/pf_ioctl.c| 2 ++ sys/sys/vnode.h | 2 +- sys/vm/swap_pager.c | 4 ++-- 17 files changed, 180 insertions(+), 75 deletions(-) root@phobos:/usr/src # /usr/local/bin/git --no-pager log -n 32 --pretty=oneline --abbrev-commit --graph * 673bce11ced (HEAD -> main, origin/main, origin/HEAD) linux(4): Copyout actual size of addr to the user space in accept(). * bb0f644cd68 linux(4): Limit user-supplied sockaddr length in recvfrom(). * 68bfaefb3d9 linux(4): Remove unnecessary PTRIN(). * cf312f799a8 linux(4): Handle SO_DOMAIN in getsockopt syscall. * c6487446d7e g
Re: main-n254654-d4e8207317c results in "no pools available to import"
On 4/11/22 14:18, Ronald Klop wrote: On 4/11/22 17:17, Dennis Clarke wrote: Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. The rev seems to be main-n254654-d4e8207317c. I can boot single user mode and get a command prompt but nothing past that. Is there something borked in ZFS in CURRENT ? Up until now you are the only one with this error on the mailinglist today. So I doubt something is borked. You could consider to share more details about your setup to help people to think along with you. Regards, Ronald. I am officially baffled. I installed latest CURRENT snapshot on another system and then buildworld and buildkernel after checkout of d4e8207317c. At reboot, with a serial console I can get to single user mode no problem : . . . cd0 at ahcich3 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number K18C36A0237 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number S5VSNG0NB12944W ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors) ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 ses0: pass1,cd0 in 'Slot 03', SATA Slot: scbus3 target 0 GEOM: new disk ada0 Root mount waiting for: usbus0 uhub0: 26 ports with 26 removable, self powered ugen0.2: at usbus0 efirtc0: providing initial system time start_init: trying /sbin/init Enter root password, or ^D to go multi-user Password: Enter full pathname of shell or RETURN for /bin/sh: root@:/ # uname -apKU FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 d4e8207317c-n254654-d4e8207317c: Tue Apr 12 08:10:00 UTC 2022 root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400056 1400056 root@:/ # When I go to full multi-user mode I see the same message "no pools available to import" but the machine comes up just fine : root@:/ # exit Setting hostuuid: 688682c8-76df-3f6f-3af4-b06ebf2eb755. Setting hostid: 0xc646c1f3. no pools available to import Fast boot: skipping disk checks. Mounting local filesystems:. Autoloading module: acpi_wmi AuACPI: Processor \_PR_.CPU2 (ACPI ID 3) ignored ACPI: Processor \_PR_.CPU3 (ACPI ID 4) ignored ACPI: Processor \_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \_PR_.CPU7 (ACPI ID 8) ignored acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device acpi_wmi0: Embedded MOF found ACPI: \AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20220331/nsarguments-361) acpi_wmi1: on acpi0 acpi_wmi1: cannot find EC device pci0: driver added found-> vendor=0x8086, dev=0xa2ba, revid=0x00 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:0:22:0: reprobing on driver added found-> vendor=0x8086, dev=0xa2a1, revid=0x00 domain=0, bus=0, slot=31, func=2 class=05-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0:0:31:2: reprobing on driver added found-> vendor=0x8086, dev=0xa2a3, revid=0x00 domain=0, bus=0, slot=31, func=4 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 pci0:0:31:4: reprobing on driver added ichsmb0: port 0xf040-0xf05f mem 0xf712a000-0xf712a0ff irq 16 at device 31.4 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 2 vector 53 smbus0: on ichsmb0 pci1: driver added pci2: driver added toloading module: ichsmb ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.32/malo0: link state changed to UP ch/CORE 32-bit compatibility ldconfig path: /usre0: link state changed to DOWN r/lib32 Setting hostname: europa. Setting up harvesting: PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . Starting Network: lo0 re0. lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff00 groups: lo nd6 options=21 re0: flags=8843 metric 0 mtu 1500 options=8209b ether b0:6e:bf:2e:b7:55 inet 17
Re: main-n254654-d4e8207317c results in "no pools available to import"
On 4/12/22 08:29, Ronald Klop wrote: Van: Thomas Laus Datum: dinsdag, 12 april 2022 13:17 Aan: freebsd-current@freebsd.org Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to import" On 4/11/22 14:18, Ronald Klop wrote: > On 4/11/22 17:17, Dennis Clarke wrote: >> >> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot. >> >> The rev seems to be main-n254654-d4e8207317c. >> >> I can boot single user mode and get a command prompt but nothing past >> that. Is there something borked in ZFS in CURRENT ? >> > Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked. > You could consider to share more details about your setup to help people > to think along with you. > I can confirm this issue. My last update was 'main-n253996-1b3af110bc' from March 31, 2022 that worked fine. My update yesterday received the same error and refused to boot past looking for kernel modules. I did receive the "no pools available to import" message a couple of lines earlier. My hardware is a Dell Inspiron laptop with a SSD and ZFS filesystem. I have a little time today and plan on git reverting back to March 31 to further isolate the problem. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF Hi, Are you guys both using NVME or EFI? Just wondering if the common problem is in ZFS or some other component. My problem machine is definately NVME based storage. As for EFI, I don't know. Is the thing pure UEFI? Yes it is. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: main-n254654-d4e8207317c results in "no pools available to import"
On 4/12/22 18:15, Mark Millard wrote: From: Thomas Laus Date: Tue, 12 Apr 2022 15:48:32 + : On 4/12/22 08:29, Ronald Klop wrote: Are you guys both using NVME or EFI? Just wondering if the common problem is in ZFS or some other component. I will try to gather more information on the machine that actually demonstrates the problem in question. I just repeated this issue on the desktop computer that is used for my weekly builds that get distributed to the other PC's in the house. Excellent isolation test. I tried the same sort of process on a separate machine to no avail. I was not using NVME storage. I was using a brand new Samsung SSD and you can see that listed in the output : https://lists.freebsd.org/archives/freebsd-current/2022-April/001759.html * * * * the above should be considered a red herring * * * * That machine simply worked as expected. Slight surprise but then again no one else was seeing this issue. Until Thomas Laus also caught it : https://lists.freebsd.org/archives/freebsd-current/2022-April/001761.html So we have at least two examples in the wild. I will focus on the problem case I have and try to get better information. Somehow. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: main-n254654-d4e8207317c results in "no pools available to import"
On 4/13/22 07:17, Thomas Laus wrote: On 4/12/22 18:35, Dennis Clarke wrote: I will focus on the problem case I have and try to get better information. Somehow. I had an idea that maybe a GELI encrypted disk may have an issue. Both my laptop and desktop have encrypted disks. The gpart partitions have a .efi appended to the name that 'gpart list' shows. Not everyone uses GELI and that may be our difference and the reason for not finding any pools to import. I don't even have a wild guess on that topic. Sorry. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
main-n254654-d4e8207317c on RISC-V rv64imafdc works fine
So this is a RISC-V instance with ZFS only and definately EFI with no problems booting main-n254654-d4e8207317c kernel : admsys@ison:~ $ su - Password: root@ison:~ # zfs list NAMEUSED AVAIL REFER MOUNTPOINT rv64 16.2G 91.4G 96K /rv64 rv64/ROOT 1.79G 91.4G 96K none rv64/ROOT/default 1.79G 91.4G 1.42G / rv64/opt150M 91.4G 10.3M /opt rv64/opt/bw 139M 91.4G 136M /opt/bw rv64/tmp576K 91.4G 104K /tmp rv64/usr 14.2G 91.4G 96K /usr rv64/usr/home 8.29M 91.4G 6.48M /usr/home rv64/usr/local 158M 91.4G 147M /usr/local rv64/usr/obj 11.7G 91.4G 5.86G /usr/obj rv64/usr/ports 208K 91.4G 96K /usr/ports rv64/usr/src 2.34G 91.4G 2.20G /usr/src rv64/var 2.99M 91.4G 96K /var rv64/var/audit 208K 91.4G 96K /var/audit rv64/var/crash 152K 91.4G 96K /var/crash rv64/var/log 1.28M 91.4G 368K /var/log rv64/var/mail 472K 91.4G 128K /var/mail rv64/var/tmp824K 91.4G 124K /var/tmp root@ison:~ # ls /boot beastie.4th gptboot.efi logo-orb.4th boot1.efi images logo-orbbw.4th brand-fbsd.4th kernel lua brand.4th kernel.old menu-commands.4th check-password.4th loader.4th menu.4th color.4th loader.conf menu.rc defaultsloader.conf.d menusets.4th delay.4th loader.efi modules dtb loader.rc screen.4th efi loader_4th.efi shortcuts.4th efi.4th loader_lua.efi support.4th entropy loader_simp.efi uboot firmwarelogo-beastie.4thversion.4th fonts logo-beastiebw.4th zfs frames.4th logo-fbsdbw.4th root@ison:~ # root@ison:~ # ls -lapb /boot/efi/efi/ total 64 drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 ./ drwxr-xr-x 1 root wheel 16384 Jan 1 1980 ../ drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 boot/ drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 freebsd/ root@ison:~ # ls -lapb /boot/efi/efi/boot/ total 1408 drwxr-xr-x 1 root wheel16384 Jan 29 19:21 ./ drwxr-xr-x 1 root wheel16384 Jan 29 19:21 ../ -rwxr-xr-x 1 root wheel 1404812 Jan 29 19:21 bootriscv64.efi root@ison:~ # ls -lapb /boot/efi/efi/freebsd/ total 1408 drwxr-xr-x 1 root wheel16384 Jan 29 19:21 ./ drwxr-xr-x 1 root wheel16384 Jan 29 19:21 ../ -rwxr-xr-x 1 root wheel 1404812 Jan 29 19:21 loader.efi root@ison:~ # root@ison:~ # root@ison:~ # uname -apKU FreeBSD ison 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n254654-d4e8207317c-dirty: Thu Apr 14 21:08:09 UTC 2022 root@ison:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC riscv riscv64 1400056 1400051 root@ison:~ # root@ison:~ # However on AMD64 for some certain machine config with UEFI we know the process fails. If only modern laptops had serial ports :\ -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: [FIXED] Re: main-n254654-d4e8207317c results in "no pools available to import"
On 4/26/22 16:17, Thomas Laus wrote: On 4/11/22 11:17, Dennis Clarke wrote: Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. The rev seems to be main-n254654-d4e8207317c. I can boot single user mode and get a command prompt but nothing past that. Is there something borked in ZFS in CURRENT ? Group: Everything is running back to normal for me today after my weekly build of MAIN. My combination of EFI, GELI and ZFS are working for me after: FreeBSD 14.0-CURRENT #1 main-n255058-fa8a6585c75: Tue Apr 26 12:13:10 EDT 2022 It looks like another update to something else fixed the "no pools available to import" issue Same here : FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n255054-67fc95025cc: Tue Apr 26 06:58:45 UTC 2022 root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400057 1400057 Somethng "magic" has changed and whatever that was it fixed the EFI boot issue. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Is INET6 a required option these days? (kernel build failure)
On 9/29/24 16:02, Rodney W. Grimes wrote: On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote: ... NOT all things need to be network connected! At great risk of tossing yet another coat of paint onto the bikeshed I must agree that a machine with nothing other than serial connection(s) was the norm a long long long time ago. Hench the need for things like UUCP and the dreaded anonymous UUCP. Not that I am going to dig out my old modems and set that up. Today. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
regarding that stack of newline chars expressed at boot
This is from the "better late than never" file. So yes, any machine I had with a serial console was kicking out a newline char on every one of the "autoboot_delay" countdown. Seems to be a default of 10 secs and so therefore I was seeing ten lines of stuff. Seems to be related to : https://cgit.freebsd.org/src/commit/?id=101afbc6ee2f06f77e6886f1f3ffe115c579967c The trivial solution is to NOT use and old fashioned 80x24 DEC VT100 type XTerm size for the session that connects to serial. The behavior vanishes at 80x25 now. I see that as the old DOS PC-Term size that some folks at Microsoft loved. Many years ago. Maybe it would be more elegant to just output the countdown secs number and then utter 010 BS chars and keep kicking out numbers that overwrite whatever was there before? Or do nothing. Hardly an issue really. Just seemed weird when I saw it. Thanks for letting me paint the bikeshed. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: regarding that stack of newline chars expressed at boot
On 9/24/24 11:06, Warner Losh wrote: https://reviews.freebsd.org/D46771 might fix this setup. Dennis, can you test it? It seems to work for me, but it's good to have more eyes on it. Sorry ! coffee spill brain error here ... It now works fine ! Helps to do the installworld and *then* reboot. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: regarding that stack of newline chars expressed at boot
On 9/24/24 11:06, Warner Losh wrote: https://reviews.freebsd.org/D46771 might fix this setup. Dennis, can you test it? It seems to work for me, but it's good to have more eyes on it. I am seeing the same stuff : | | .-- `--. | |.---.. | | +-+ Autoboot in 10 seconds. [Space] to pause Autoboot in 9 seconds. [Space] to pause Autoboot in 8 seconds. [Space] to pause Autoboot in 7 seconds. [Space] to pause Autoboot in 6 seconds. [Space] to pause Autoboot in 5 seconds. [Space] to pause Autoboot in 4 seconds. [Space] to pause Autoboot in 3 seconds. [Space] to pause Autoboot in 2 seconds. [Space] to pause Autoboot in 1 seconds. [Space] to pause There seems to be some blank space there at the bottom of the little box to the left of the "beastie". Perhaps one of them can go away ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: zpools no longer exist after boot
On 11/29/24 09:49, Ronald Klop wrote:
> Van: Dennis Clarke
> Datum: donderdag, 28 november 2024 15:45
> Aan: Alan Somers
> CC: Current FreeBSD
> Onderwerp: Re: zpools no longer exist after boot
>>
>> On 11/28/24 08:52, Alan Somers wrote:
>> > On Thu, Nov 28, 2024, 7:06AM Dennis Clarke
>> wrote:
>> >
>> >>
>> >> This is a baffling problem wherein two zpools no longer exist after
>> >> boot. This is :
>> .
>> .
>> .
>> > Do you have zfs_enable="YES" set in /etc/rc.conf? If not then
>> nothing will
>> > get imported.
>> >
>> > Regarding the cachefile property, it's expected that "zpool import"
>> will
>> > change it, unless you do "zpool import -O cachefile=whatever".
>> >
>>
>> The rc script seems to do something slightly different with zpool
>> import -c $FOOBAR thus :
>>
>>
>> titan# cat /etc/rc.d/zpool
>> #!/bin/sh
>> #
>> #
>>
>> # PROVIDE: zpool
>> # REQUIRE: hostid disks
>> # BEFORE: mountcritlocal
>> # KEYWORD: nojail
>>
>> . /etc/rc.subr
>>
>> name="zpool"
>> desc="Import ZPOOLs"
>> rcvar="zfs_enable"
>> start_cmd="zpool_start"
>> required_modules="zfs"
>>
>> zpool_start()
>> {
>> local cachefile
>>
>> for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do
>> if [ -r $cachefile ]; then
>> zpool import -c $cachefile -a -N
>> if [ $? -ne 0 ]; then
>> echo "Import of zpool cache
>> ${cachefile} failed," \
>> "will retry after root mount hold
>> release"
>> root_hold_wait
>> zpool import -c $cachefile -a -N
>> fi
>> break
>> fi
>> done
>> }
>>
>> load_rc_config $name
>> run_rc_command "$1"
>> titan#
>>
>>
>>
>> I may as well nuke the pre-existing cache file and start over :
>>
>>
>> titan# ls -l /etc/zfs/zpool.cache /boot/zfs/zpool.cache
>> -rw-r--r-- 1 root wheel 1424 Jan 16 2024 /boot/zfs/zpool.cache
>> -rw-r--r-- 1 root wheel 4960 Nov 28 14:15 /etc/zfs/zpool.cache
>> titan#
>> titan#
>> titan# rm /boot/zfs/zpool.cache
>> titan# zpool set cachefile="/boot/zfs/zpool.cache" t0
>> titan#
>> titan# ls -l /boot/zfs/zpool.cache
>> -rw-r--r-- 1 root wheel 1456 Nov 28 14:27 /boot/zfs/zpool.cache
>> titan#
>> titan# zpool set cachefile="/boot/zfs/zpool.cache" leaf
>> titan#
>> titan# ls -l /boot/zfs/zpool.cache
>> -rw-r--r-- 1 root wheel 3536 Nov 28 14:28 /boot/zfs/zpool.cache
>> titan#
>> titan# zpool set cachefile="/boot/zfs/zpool.cache" proteus
>> titan#
>> titan# ls -l /boot/zfs/zpool.cache
>> -rw-r--r-- 1 root wheel 4960 Nov 28 14:28 /boot/zfs/zpool.cache
>> titan#
>> titan# zpool get cachefile t0
>> NAME PROPERTY VALUE SOURCE
>> t0cachefile /boot/zfs/zpool.cache local
>> titan#
>> titan# zpool get cachefile leaf
>> NAME PROPERTY VALUE SOURCE
>> leaf cachefile /boot/zfs/zpool.cache local
>> titan#
>> titan# zpool get cachefile proteus
>> NAME PROPERTY VALUE SOURCE
>> proteus cachefile /boot/zfs/zpool.cache local
>> titan#
>>
>> titan#
>> titan# reboot
>> Nov 28 14:34:05 Waiting (max 60 seconds) for system process `vnlru' to
>> stop... done
>> Waiting (max 60 seconds) for system process `syncer' to stop...
>> Syncing disks, vnodes remaining... 0 0 0 0 0 0 done
>> All buffers synced.
>> Uptime: 2h38m57s
>> GEOM_MIRROR: Device swap: provider destroyed.
>> GEOM_MIRROR: Device swap destroyed.
>> uhub5: detached
>> uhub1: detached
>> uhub4: detached
>> uhub2: detached
>> uhub3: detached
>> uhub6: detached
>> uhub0: detached
>> ix0: link state changed to DOWN
>> .
>> .
>> .
>>
>> Starting iscsid.
>> Starting iscsictl.
>> Clearing /tmp.
>> Updating /var/run/os-release done.
>> Updating motd:.
>> Creating and/or trimming log files.
>> Starting syslogd.
>> No core dumps found.
>> Starting local daemons:failed to open c
zpools no longer exist after boot
This is a baffling problem wherein two zpools no longer exist after boot. This is : titan# uname -apKU FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #1 main-n273749-4b65481ac68a-dirty: Wed Nov 20 15:08:52 GMT 2024 root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 amd64 1500027 1500027 titan# titan# zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT t0 444G 91.2G 353G- -27%20% 1.00x ONLINE - titan# The *only* zpool that seems to exist in any reliable way is the little NVME based unit for booting. The other two zpools vanished and yet the devices exist just fine : titan# titan# camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (pass1,ada1) at scbus2 target 0 lun 0 (ses0,pass2) at scbus6 target 0 lun 0 (ses1,pass3) at scbus7 target 0 lun 1 (pass4,nda0) at scbus8 target 0 lun 0 (da0,pass5) titan# titan# nvmecontrol devlist nvme0: SAMSUNG MZVKW512HMJP-000L7 nvme0ns1 (488386MB) titan# titan# zpool status t0 pool: t0 state: ONLINE status: Some supported and requested features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. scan: scrub repaired 0B in 00:00:44 with 0 errors on Wed Feb 7 09:56:40 2024 config: NAMESTATE READ WRITE CKSUM t0 ONLINE 0 0 0 nda0p3ONLINE 0 0 0 errors: No known data errors titan# Initially I thought the problem was related to cachefile being empty for these zpools. However if I set the cachefile to something reasonable then the cachefile property vanishes at a reboot. The file, of course, exists just fine : titan# zpool get cachefile proteus NAME PROPERTY VALUE SOURCE proteus cachefile - default titan# titan# zpool set cachefile="/var/log/zpool_cache" proteus titan# zpool get cachefile proteus NAME PROPERTY VALUE SOURCE proteus cachefile /var/log/zpool_cache local titan# ls -ladb /var/log/zpool_cache -rw-r--r-- 1 root wheel 1440 Nov 28 11:45 /var/log/zpool_cache titan# So there we have 1440 bytes of data in that file. titan# zpool set cachefile="/var/log/zpool_cache" t0 titan# zpool get cachefile t0 NAME PROPERTY VALUE SOURCE t0cachefile /var/log/zpool_cache local titan# titan# ls -ladb /var/log/zpool_cache -rw-r--r-- 1 root wheel 2880 Nov 28 11:46 /var/log/zpool_cache titan# Now we have 2 * 1440 bytes = 2880 bytes of some zpool cache data. titan# zpool set cachefile="/var/log/zpool_cache" leaf titan# zpool get cachefile leaf NAME PROPERTY VALUE SOURCE leaf cachefile /var/log/zpool_cache local titan# titan# zpool get cachefile t0 NAME PROPERTY VALUE SOURCE t0cachefile /var/log/zpool_cache local titan# titan# zpool get cachefile proteus NAME PROPERTY VALUE SOURCE proteus cachefile /var/log/zpool_cache local titan# titan# reboot From here on ... the only zpool that exists after boot is the local little NVME samsung unit. So here I can import those pools and then see that the cachefile property has been wiped out : titan# titan# zpool import proteus titan# zpool import leaf titan# titan# zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT leaf 18.2T 984K 18.2T- - 0% 0% 1.00x ONLINE - proteus 1.98T 361G 1.63T- - 1%17% 1.00x ONLINE - t0444G 91.2G 353G- -27%20% 1.00x ONLINE - titan# titan# zpool get cachefile leaf NAME PROPERTY VALUE SOURCE leaf cachefile - default titan# titan# zpool get cachefile proteus NAME PROPERTY VALUE SOURCE proteus cachefile - default titan# titan# zpool get cachefile t0 NAME PROPERTY VALUE SOURCE t0cachefile - default titan# titan# ls -l /var/log/zpool_cache -rw-r--r-- 1 root wheel 4960 Nov 28 11:52 /var/log/zpool_cache titan# The cachefile exists and seems to have grown in size. However a reboot will once again provide nothing but the t0 pool. Baffled. Any thoughts would be welcome. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: zpools no longer exist after boot
On 11/28/24 10:55, Alan Somers wrote: On Thu, Nov 28, 2024, 9:47 AM Dennis Clarke wrote: On 11/28/24 09:52, Alan Somers wrote: On Thu, Nov 28, 2024, 8:45 AM Dennis Clarke wrote: ... For "zpool import", the "-c" argument instructs zfs which cachefile to search for importable pools. "-O", on the other hand, specifies how the cachefile property should be set after the pool is imported. I have to wonder what value there is in NOT having the cachefile property set in a zpool ? Certainly given that the zpool RC script really wants to check in a few places and then use those cache files. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken Usually the default value for cachefile is sufficient. In fact, the only time I've ever needed to set cachefile has been when I DON'T want the pool to import at boot. I wonder if there was some other reason, since resolved, why your pools didn't import the first time. And subsequently they didn't import because you set the cachefile to a non default value? I am at a loss. Really. Getting the iSCSI stuff working was a real treat and this just makes things even more strange. I really do not know. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: zpools no longer exist after boot
On 11/28/24 08:52, Alan Somers wrote:
On Thu, Nov 28, 2024, 7:06 AM Dennis Clarke wrote:
This is a baffling problem wherein two zpools no longer exist after
boot. This is :
.
.
.
Do you have zfs_enable="YES" set in /etc/rc.conf? If not then nothing will
get imported.
Regarding the cachefile property, it's expected that "zpool import" will
change it, unless you do "zpool import -O cachefile=whatever".
The rc script seems to do something slightly different with zpool import
-c $FOOBAR thus :
titan# cat /etc/rc.d/zpool
#!/bin/sh
#
#
# PROVIDE: zpool
# REQUIRE: hostid disks
# BEFORE: mountcritlocal
# KEYWORD: nojail
. /etc/rc.subr
name="zpool"
desc="Import ZPOOLs"
rcvar="zfs_enable"
start_cmd="zpool_start"
required_modules="zfs"
zpool_start()
{
local cachefile
for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do
if [ -r $cachefile ]; then
zpool import -c $cachefile -a -N
if [ $? -ne 0 ]; then
echo "Import of zpool cache
${cachefile} failed," \
"will retry after root mount hold
release"
root_hold_wait
zpool import -c $cachefile -a -N
fi
break
fi
done
}
load_rc_config $name
run_rc_command "$1"
titan#
I may as well nuke the pre-existing cache file and start over :
titan# ls -l /etc/zfs/zpool.cache /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 1424 Jan 16 2024 /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 4960 Nov 28 14:15 /etc/zfs/zpool.cache
titan#
titan#
titan# rm /boot/zfs/zpool.cache
titan# zpool set cachefile="/boot/zfs/zpool.cache" t0
titan#
titan# ls -l /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 1456 Nov 28 14:27 /boot/zfs/zpool.cache
titan#
titan# zpool set cachefile="/boot/zfs/zpool.cache" leaf
titan#
titan# ls -l /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 3536 Nov 28 14:28 /boot/zfs/zpool.cache
titan#
titan# zpool set cachefile="/boot/zfs/zpool.cache" proteus
titan#
titan# ls -l /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 4960 Nov 28 14:28 /boot/zfs/zpool.cache
titan#
titan# zpool get cachefile t0
NAME PROPERTY VALUE SOURCE
t0cachefile /boot/zfs/zpool.cache local
titan#
titan# zpool get cachefile leaf
NAME PROPERTY VALUE SOURCE
leaf cachefile /boot/zfs/zpool.cache local
titan#
titan# zpool get cachefile proteus
NAME PROPERTY VALUE SOURCE
proteus cachefile /boot/zfs/zpool.cache local
titan#
titan#
titan# reboot
Nov 28 14:34:05 Waiting (max 60 seconds) for system process `vnlru' to
stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 0 0 done
All buffers synced.
Uptime: 2h38m57s
GEOM_MIRROR: Device swap: provider destroyed.
GEOM_MIRROR: Device swap destroyed.
uhub5: detached
uhub1: detached
uhub4: detached
uhub2: detached
uhub3: detached
uhub6: detached
uhub0: detached
ix0: link state changed to DOWN
.
.
.
Starting iscsid.
Starting iscsictl.
Clearing /tmp.
Updating /var/run/os-release done.
Updating motd:.
Creating and/or trimming log files.
Starting syslogd.
No core dumps found.
Starting local daemons:failed to open cache file: No such file or directory
.
Starting ntpd.
Starting powerd.
Mounting late filesystems:.
Starting cron.
Performing sanity check on sshd configuration.
Starting sshd.
Starting background file system
FreeBSD/amd64 (titan) (ttyu0)
login: root
Password:
Nov 28 14:36:29 titan login[4162]: ROOT LOGIN (root) ON ttyu0
Last login: Thu Nov 28 14:33:45 on ttyu0
FreeBSD 15.0-CURRENT (GENERIC-NODEBUG) #1
main-n273749-4b65481ac68a-dirty: Wed Nov 20 15:08:52 GMT 2024
Welcome to FreeBSD!
Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories: https://www.FreeBSD.org/security/
FreeBSD Handbook: https://www.FreeBSD.org/handbook/
FreeBSD FAQ: https://www.FreeBSD.org/faq/
Questions List:https://www.FreeBSD.org/lists/questions/
FreeBSD Forums:https://forums.FreeBSD.org/
Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with: pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.
Show the version of FreeBSD installed: freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages: man man
FreeBSD directory layout: man hier
To change this login announcement, see motd(5).
You have new mail.
titan#
titan# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP
HEALTH ALTROOT
leaf 18.2T 984K
Re: zpools no longer exist after boot
On 11/28/24 10:02, Dimitry Andric wrote: On 28 Nov 2024, at 14:05, Dennis Clarke wrote: This is a baffling problem wherein two zpools no longer exist after boot. This is : ... titan# camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (pass1,ada1) at scbus2 target 0 lun 0 (ses0,pass2) at scbus6 target 0 lun 0 (ses1,pass3) at scbus7 target 0 lun 1 (pass4,nda0) at scbus8 target 0 lun 0 (da0,pass5) It has been my experience that with disks connected to external enclosures, these sometimes take a long time to come up. If they come up only after the kernel initially detects ZFS pools, they will not be shown or imported at all. If you look at dmesg or boot logs, are the external disks detected around the same time as the NVMe device? The only remote device is the iSCSI based unit and it seems to be visible neatly. In fact the zpools, all of them, are now available at boot time thanks to using the correct cachefile name. There may be a need to make some note somewhere in a man page that the zpool cachefile used in the RC script is important. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: zpools no longer exist after boot
WORD: nojail
. /etc/rc.subr
name="zpool"
desc="Import ZPOOLs"
rcvar="zfs_enable"
start_cmd="zpool_start"
required_modules="zfs"
zpool_start()
{
local cachefile
for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do
if [ -r $cachefile ]; then
zpool import -c $cachefile -a -N
if [ $? -ne 0 ]; then
echo "Import of zpool cache
${cachefile} failed," \
"will retry after root mount hold
release"
root_hold_wait
zpool import -c $cachefile -a -N
fi
break
fi
done
}
load_rc_config $name
run_rc_command "$1"
titan#
titan#
titan#
titan# ls -l /etc/zfs/zpool.cache /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 1424 Jan 16 2024 /boot/zfs/zpool.cache
-rw-r--r-- 1 root wheel 4960 Nov 28 14:15 /etc/zfs/zpool.cache
titan#
May as well delete them. I have nothing to lose at this point.
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
Re: zpools no longer exist after boot
On 11/28/24 08:58, Ronald Klop wrote: Btw: The /etc/rc.d/zpool script looks into these cachefiles: for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do I didn’t check where the cachefile pool property is used. Hope this helps resolving the issue. Or maybe helps you to provide more information about your setup. Ah ha ! So the cachefile property needs to be a specific filename or that script will have no clue. Take a look : titan# zpool get cachefile leaf proteus t0 NAME PROPERTY VALUE SOURCE leaf cachefile - default proteus cachefile - default t0 cachefile - default titan# Those files exist and they seem to be either from early this year or today : titan# ls -l /etc/zfs/zpool.cache /boot/zfs/zpool.cache -rw-r--r-- 1 root wheel 1424 Jan 16 2024 /boot/zfs/zpool.cache -rw-r--r-- 1 root wheel 4960 Nov 28 13:03 /etc/zfs/zpool.cache titan# titan# date -u Thu Nov 28 14:13:51 UTC 2024 titan# titan# uptime 2:13PM up 2:19, 1 user, load averages: 0.00, 0.00, 0.00 titan# titan# zpool set cachefile="/etc/zfs/zpool.cache" leaf titan# zpool set cachefile="/etc/zfs/zpool.cache" proteus titan# zpool set cachefile="/etc/zfs/zpool.cache" t0 However that will not work : titan# zpool get cachefile leaf proteus t0 NAME PROPERTY VALUE SOURCE leaf cachefile - default proteus cachefile - default t0 cachefile - default Let me try just one pool : titan# zpool get cachefile leaf NAME PROPERTY VALUE SOURCE leaf cachefile - default titan# zpool set cachefile="/etc/zfs/zpool.cache" leaf titan# zpool get cachefile leaf NAME PROPERTY VALUE SOURCE leaf cachefile - default titan# So this is even worse. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
top seems confused about memory ?
On a machine here I see top reports this with " top -CSITa -s 10" last pid: 6680; load averages:0.29,0.12,0 up 0+11:40:46 02:23:01 51 processes: 2 running, 47 sleeping, 2 waiting CPU: 0.6% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.2% idle Mem: 587M Active, 480G Inact, 1332K Laundry, 7410M Wired, 456M Buf, 11G Free ARC: 3624M Total, 85M MFU, 3359M MRU, 32M Anon, 118M Header, 27M Other 2919M Compressed, 32G Uncompressed, 11.13:1 Ratio Swap: 32G Total, 32G Free THR USERNAMETHR PRI NICE SIZERES STATEC TIME CPU COMMAND 13 root 40 187 ki31 0B 640K CPU0 0 464.8H 3967.69% [idle] 101142 root 1 480 1530M 574M piperd 34 0:27 24.69% /usr/lo 10 root731 -16- 0B11M parked 18 112:10 3.14% [kernel 102993 root 1 21030M15M select 26 0:03 2.77% /usr/bi Seems only 11G of memory is free ? That seems impossible. titan# sysctl hw.physmem hw.physmem: 549599244288 titan# titan# titan# sysctl -a | grep 'free' | grep 'mem' vm.uma.vmem.stats.frees: 0 vm.uma.vmem.keg.domain.1.free_slabs: 0 vm.uma.vmem.keg.domain.1.free_items: 0 vm.uma.vmem.keg.domain.0.free_slabs: 0 vm.uma.vmem.keg.domain.0.free_items: 0 vm.uma.vmem_btag.stats.frees: 523236 vm.uma.vmem_btag.keg.domain.1.free_slabs: 0 vm.uma.vmem_btag.keg.domain.1.free_items: 34398 vm.uma.vmem_btag.keg.domain.0.free_slabs: 0 vm.uma.vmem_btag.keg.domain.0.free_items: 34378 vm.kmem_map_free: 528152154112 kstat.zfs.misc.arcstats.memory_free_bytes: 11707904000 titan# I have no idea what "top" is reporting but 11G free on a machine doing nothing seems ... unlikely. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: top seems confused about memory ?
On 11/28/24 21:25, Dennis Clarke wrote: On a machine here I see top reports this with " top -CSITa -s 10" last pid: 6680; load averages: 0.29, 0.12, 0 up 0+11:40:46 02:23:01 51 processes: 2 running, 47 sleeping, 2 waiting CPU: 0.6% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.2% idle Mem: 587M Active, 480G Inact, 1332K Laundry, 7410M Wired, 456M Buf, 11G Free ARC: 3624M Total, 85M MFU, 3359M MRU, 32M Anon, 118M Header, 27M Other 2919M Compressed, 32G Uncompressed, 11.13:1 Ratio Swap: 32G Total, 32G Free THR USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 13 root 40 187 ki31 0B 640K CPU0 0 464.8H 3967.69% [idle] 101142 root 1 48 0 1530M 574M piperd 34 0:27 24.69% /usr/lo 10 root 731 -16 - 0B 11M parked 18 112:10 3.14% [kernel 102993 root 1 21 0 30M 15M select 26 0:03 2.77% /usr/bi Seems only 11G of memory is free ? That seems impossible. titan# sysctl hw.physmem hw.physmem: 549599244288 titan# titan# titan# sysctl -a | grep 'free' | grep 'mem' vm.uma.vmem.stats.frees: 0 vm.uma.vmem.keg.domain.1.free_slabs: 0 vm.uma.vmem.keg.domain.1.free_items: 0 vm.uma.vmem.keg.domain.0.free_slabs: 0 vm.uma.vmem.keg.domain.0.free_items: 0 vm.uma.vmem_btag.stats.frees: 523236 vm.uma.vmem_btag.keg.domain.1.free_slabs: 0 vm.uma.vmem_btag.keg.domain.1.free_items: 34398 vm.uma.vmem_btag.keg.domain.0.free_slabs: 0 vm.uma.vmem_btag.keg.domain.0.free_items: 34378 vm.kmem_map_free: 528152154112 kstat.zfs.misc.arcstats.memory_free_bytes: 11707904000 titan# I have no idea what "top" is reporting but 11G free on a machine doing nothing seems ... unlikely. even worse ... under load it seems to make no sense at all : last pid: 98884; load averages: 32.01, 30.51, 25 up 0+12:33:20 03:15:35 172 processes: 34 running, 136 sleeping, 2 waiting CPU: 78.4% user, 0.0% nice, 1.8% system, 0.0% interrupt, 19.8% idle Mem: 7531M Active, 450G Inact, 9588K Laundry, 27G Wired, 456M Buf, 14G Free ARC: 17G Total, 7543M MFU, 4337M MRU, 37M Anon, 260M Header, 5005M Other 7207M Compressed, 24G Uncompressed, 3.39:1 Ratio Swap: 32G Total, 32G Free THR USERNAMETHR PRI NICE SIZERES STATEC TIME CPU COMMAND 13 root 40 187 ki31 0B 640K RUN 0 486.9H 792.70% [idle] 103554 root 1 156 i0 786M 632M CPU37 37 0:44 99.82% /usr/bi 101148 root 1 156 i0 1317M 822M CPU2 2 2:20 99.82% /usr/bi -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: zpools no longer exist after boot
On 11/28/24 09:52, Alan Somers wrote: On Thu, Nov 28, 2024, 8:45 AM Dennis Clarke wrote: ... For "zpool import", the "-c" argument instructs zfs which cachefile to search for importable pools. "-O", on the other hand, specifies how the cachefile property should be set after the pool is imported. I have to wonder what value there is in NOT having the cachefile property set in a zpool ? Certainly given that the zpool RC script really wants to check in a few places and then use those cache files. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: zpools no longer exist after boot
On 11/28/24 08:52, Alan Somers wrote: On Thu, Nov 28, 2024, 7:06 AM Dennis Clarke wrote: This is a baffling problem wherein two zpools no longer exist after boot. This is : ... Do you have zfs_enable="YES" set in /etc/rc.conf? If not then nothing will get imported. Regarding the cachefile property, it's expected that "zpool import" will change it, unless you do "zpool import -O cachefile=whatever". Oh absolutely. Also : zfs_enable="YES" # # the iSCSI initiator iscsid_enable="YES" iscsictl_enable="YES" iscsictl_flags="-Aa" # That explains the iSCSI device provided over 10Gbit : titan# titan# camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (pass1,ada1) at scbus2 target 0 lun 0 (ses0,pass2) at scbus6 target 0 lun 0 (ses1,pass3) at scbus7 target 0 lun 1 (pass4,nda0) at scbus8 target 0 lun 0 (da0,pass5) titan# See the FREEBSD CTLDISK 001 ? That is over iSCSI. However, as I say, the devices exist but the pools vanish unless I import them and deal with them one by one. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
EFI RT page fault in init pid = 1
I wonder if anyone else has seen such a message at shutdown : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x7c38f87a stack pointer = 0x28:0xfe035500bba8 frame pointer = 0x28:0x5 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1 (init) rdi: fe035500bcd8 rsi: 0004 rdx: rcx: r8: r9: rax: 800b0040 rbx: 0002 rbp: 0005 r10: 800b r11: r12: f80103969000 r13: f80101c57140 r14: 4008 r15: f801019895a8 trap number = 12 EFI RT page fault acpi0: Powering system off I have not seen such a thing while the machine was running. Machine in question is 15.0-CURRENT : Loading kernel... /boot/kernel/kernel text=0x1826b8 text=0xd92d38 text=0x437223 data=0x180+0xe80 data=0x19e1e0+0x461e20 0x8+0x198e70+0x8+0x1bcd67 Loading configured modules... /boot/kernel/vmm.ko size 0x37e660 at 0x2156000 /etc/hostid size=0x25 /boot/kernel/zfs.ko size 0x6082b8 at 0x24d5000 /boot/kernel/geom_mirror.ko size 0x21428 at 0x2ade000 /boot/entropy size=0x1000 /boot/kernel/cryptodev.ko size 0x8808 at 0x2b01000 staging 0x6b20 (not copying) tramp 0x6b14b000 PT4 0x6b142000 Start @ 0x80383000 ... Loading splash ok GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb ---<>--- Copyright (c) 1992-2025 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 15.0-CURRENT #3 main-n274510-3d0a0dda3a7d-dirty: Thu Jan 2 01:28:25 GMT 2025 root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 FreeBSD clang version 19.1.5 (https://github.com/llvm/llvm-project.git llvmorg-19.1.5-0-gab4b5a2db582) VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz (2394.50-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff Features2=0x7ffefbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21cbfbb Structured Extended Features3=0x9c000400 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 549739036672 (524272 MB) avail memory = 535434485760 (510630 MB) . . . etc I suspect there are changes recently in the RT EFI world ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Fwd: OpenSSL Security Advisory
All : Just a heads up. I hope this lands in ports *really* fast. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken PS: no FreeBSD on Raspberry Pi5 yet. Too many ugly blobs still. Forwarded Message Subject: OpenSSL Security Advisory Date: Tue, 11 Feb 2025 16:54:29 +0100 From: Tomas Mraz To: openssl-project , openssl-users OpenSSL Security Advisory [11th February 2025] == RFC7250 handshakes with unauthenticated servers don't abort as expected (CVE-2024-12797) Severity: High Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode is set. Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients. RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSL_VERIFY_PEER. Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSL_get_verify_result(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are also not affected by this issue. OpenSSL 3.4, 3.3 and 3.2 are vulnerable to this issue. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.1. OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2. OpenSSL 3.2 users should upgrade to OpenSSL 3.2.4. This issue was reported on 18th December 2024 by Apple Inc. The fix was developed by Viktor Dukhovni. General Advisory Notes == URL for this Security Advisory: https://openssl-library.org/news/secadv/20250211.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://openssl-library.org/policies/general/security-policy/
Re: ZFS: Rescue FAULTED Pool
The most useful thing to share right now would be the output of `zpool import` (with no pool name) on the rebooted system. That will show where the issues are, and suggest how they might be solved. Hello, this exactly happens when trying to import the pool. Prior to the loss, device da1p1 has been faulted with numbers in the colum/columns "corrupted data"/further not seen now. ~# zpool import pool: BUNKER00 id: state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-72 config: BUNKER00FAULTED corrupted data raidz1-0 ONLINE da2p1 ONLINE da3p1 ONLINE da4p1 ONLINE da7p1 ONLINE da6p1 ONLINE da1p1 ONLINE da5p1 ONLINE ~# zpool import -f BUNKER00 cannot import 'BUNKER00': I/O error Destroy and re-create the pool from a backup source. ~# zpool import -F BUNKER00 cannot import 'BUNKER00': one or more devices is currently unavailable This is indeed a sad situation. You have a raidz1 pool with one or MORE devices that seem to have left the stage. I suspect more than one. I can only guess what you see from "camcontrol devlist" as well as data from "gpart show -l" where we would see the partition data along with and GPT labels. If in fact you used GPT scheme. You have a list of devices that all say "p1" there and so I guess you made some sort of a partition table. ZFS does not need that but it can be nice to have. In any case, it really does look like you have _more_ than one failure in there somewhere and only dmesg and some separate tests on each device would reveal the truth. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Safe to do the usual end-of-month buildworld/buildkernel on RISC-V ?
All : Not sure if I heard rumours correctly but perhaps someone can chime in on this. Was there a problem wherein the SiFive RISC-V board would panic with the latest kernel updates? Here I mean the "Unmatched". I have the new P550 on order and should be able to look at that next month ( tomorrow? more like next week ) but for now it is nice to have the SiFive Unmatched in a usable state. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Is there any way to nudge security/libfido2? It blocks chunks of KDE
It seems to have been a while since I was able to run a poudriere bulk build and get KDE available. At least on 15-CURRENT. There is a little brick in the path called security/libfido2 : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283697 commit 74ecdf86d8d2a94a4bfcf094a2e21b4747e4907f resulted in the appropriate declarations for the correct versions of _POSIX_C_SOURCE via __POSIX_VISIBLE and then we get error: call to undeclared function 'ppoll'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] Sort of annoying as even 14.2-RELEASE on amd64 and ports 2024Q4 fails : [142amd64-2024Q4] [2025-01-04_10h11m35s] [committing] Queued: 5 Built: 4 Failed: 1 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 00:04:44 The 15.0-CURRENT is much much worse : [150amd64-latest] [2025-01-04_08h12m11s] [committing] Queued: 365 Built: 323 Failed: 2 Skipped: 40 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 01:52:01 In any case ... is there a way to nudge that ? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: EFI RT page fault in init pid = 1
On 1/4/25 06:45, Konstantin Belousov wrote: On Fri, Jan 03, 2025 at 06:43:55PM -0500, Dennis Clarke wrote: I wonder if anyone else has seen such a message at shutdown : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x7c38f87a stack pointer = 0x28:0xfe035500bba8 frame pointer = 0x28:0x5 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1 (init) rdi: fe035500bcd8 rsi: 0004 rdx: rcx: r8: r9: rax: 800b0040 rbx: 0002 rbp: 0005 r10: 800b r11: r12: f80103969000 r13: f80101c57140 r14: 4008 r15: f801019895a8 trap number = 12 EFI RT page fault acpi0: Powering system off I have not seen such a thing while the machine was running. Machine in question is 15.0-CURRENT : The reporting of the faults during the calls into EFI RT was added recently. Before that, such faults were silently ignored. Now, the report is printed and then the fault is ignored. There is no actionable items for users; a developer might be interested. I see ! Thank you. No need to redo buildworld etc etc and yes this seems to be consistent now and even the address data is the same. All except for r13 : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x7c38f87a stack pointer = 0x28:0xfe035500bba8 frame pointer = 0x28:0x5 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1 (init) rdi: fe035500bcd8 rsi: 0004 rdx: rcx: r8: r9: rax: 800b0040 rbx: 0002 rbp: 0005 r10: 800b r11: r12: f80103969000 r13: f80101c56140 r14: 4008 r15: f801019895a8 trap number = 12 EFI RT page fault acpi0: Powering system off -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: poudriere and the user ... is it mostly a lost idea?
On 1/15/25 21:20, Mark Millard wrote: Dennis Clarke wrote on Date: Wed, 15 Jan 2025 15:16:58 UTC : Over the past month or so I see endless fails in builds for the big three user facing window manager things. This means that a simple user type person can not get a desktop. Really? Yes really. For at least a month or more you can not build KDE5 nor LXDE nor XFCE desktop. . . . Here you seem to have leaped from your context's bulk build problems to most everyone else's bulk builds of similar software having similar bulk build problems. I apologize for the rant. Clearly a rant. Pure frustration as I try to do some testing of the big RELEASE stuff from 13.4 up to 15-CURRENT. It was a hand waving rant wherein I have seens build failures for weeks and weeks and it really feels like a hit or miss throw a dart good luck and spin the wheel maybe you are a winner today situation. (Since Jan-7 I'm I'm temporarily without access to the FreeBSD systems that I normally do. Also, I do not normally build those specific ports. So I do not have evidence about those from my own activities.) I have plenty of logs. Piles of them. Perhaps the problem is that I am building on a 15-CURRENT machine which has poudriere jails like so : titan# poudriere jails -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH 134amd64 13.4-RELEASE-p2 1304000 3f40d5821eca amd64 git+https 2025-01-10 10:42:08 /poudriere/jails/134amd64 142amd64 14.2-RELEASE 1402000 c8918d6c7412amd64 git+https 2024-12-03 12:50:29 /poudriere/jails/142amd64 140amd64 14.2-STABLE 1402501 e6de39be80e2 amd64 git+https 2025-01-13 21:36:43 /poudriere/jails/140amd64 150amd64 15.0-CURRENT 1500030 amd64 src=/usr/src 2025-01-12 07:44:29 /poudriere/jails/150amd64 titan# The one called 140stable is a bit strange given that I built it with the branch called "releng" for 14 and what I get is 14.2-STABLE. Whatever that is. I had the silly notion that something called "STABLE" is a good place to build packages. A stable is where one may keep horses. Maybe goats. Other than that I really do not know if building packages in that jail would be of any value compared to the 142amd64 jail. Who knows? I surely do not. I tend to kick off something like this : titan# ls -lApbtr /poudriere/data/packages/ total 60 drwxr-xr-x 3 root wheel 15 Jan 15 21:40 134amd64-latest/ drwxr-xr-x 3 root wheel 15 Jan 16 07:20 150amd64-2025Q1/ drwxr-xr-x 3 root wheel 15 Jan 16 07:23 140amd64-2025Q1/ drwxr-xr-x 3 root wheel 15 Jan 16 10:15 142amd64-latest/ drwxr-xr-x 3 root wheel 15 Jan 16 10:36 142amd64-2025Q1/ drwxr-xr-x 3 root wheel 15 Jan 16 14:00 150amd64-latest/ drwxr-xr-x 3 root wheel 15 Jan 16 14:09 134amd64-2025Q1/ titan# titan# /usr/bin/time -p idprio 0 poudriere bulk -r -j 140amd64 -p 2025Q1 -f /root/pkg.list [00:00:00] Creating the reference jail... done [00:00:00] Mounting system devices for 140amd64-2025Q1 [00:00:01] Stashing existing package repository [00:00:01] Mounting ccache from: /var/cache/ccache [00:00:01] Mounting ports from: /poudriere/ports/2025Q1 [00:00:01] Mounting packages from: /poudriere/data/packages/140amd64-2025Q1 [00:00:01] Mounting distfiles from: /poudriere/distfiles /etc/resolv.conf -> /poudriere/data/.m/140amd64-2025Q1/ref/etc/resolv.conf [00:00:01] Starting jail 140amd64-2025Q1 Updating /var/run/os-release done. [00:00:01] Will build as nobody:nobody (65534:65534) [00:00:01] Logs: /poudriere/data/logs/bulk/140amd64-2025Q1/2025-01-16_14h18m02s [00:00:01] Loading MOVED for /poudriere/data/.m/140amd64-2025Q1/ref/usr/ports [00:00:02] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS [00:00:02] Inspecting ports tree for modifications to git checkout... no [00:00:03] Ports top-level git hash: 1bbe39c25 [00:00:03] Gathering ports metadata [00:00:08] Calculating ports order and dependencies [00:00:10] Trimming IGNORED and blacklisted ports [00:00:10] Sanity checking the repository [00:00:10] Checking packages for incremental rebuild needs [00:00:13] Deleting rsync-3.4.0.pkg: new version: 3.4.1 [00:00:14] Deleting mariadb1011-server-10.11.10_1.pkg: missing dependency: rsync-3.4.0 [00:00:14] Deleting mariadb114-server-11.4.4.pkg: missing dependency: rsync-3.4.0 [00:00:15] Deleting stale symlinks... done [00:00:15] Deleting empty directories... done [00:00:15] Unqueueing existing packages [00:00:16] Unqueueing orphaned build dependencies [00:00:16] Sanity checking build queue [00:00:16] Processing PRIORITY_BOOST [00:00:16] Balancing pool [140amd64-2025Q1] [2025-01-16_14h18m02s] [balancing_pool] Queued: 13 Built: 0 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 13 T ime: 00:00:15 [00:00:16] Recording filesystem state for prepkg... done [00:00:16] B
poudriere and the user ... is it mostly a lost idea?
All : Over the past month or so I see endless fails in builds for the big three user facing window manager things. This means that a simple user type person can not get a desktop. Really? Yes really. For at least a month or more you can not build KDE5 nor LXDE nor XFCE desktop. With FreeBSD there is a trivial idea that it exists in source form and one can compile *anything* needed. Am I wrong here? So correct me, with a taser to the left, gently, if I am wrong. Sure, a user can just use whatever packages are being provided by some magic server somewhere in a fluffy cloud with coloured unicorns that dance on the rainbows. Failed: ?? Poudriere lately always says fail. Every day. Every time. For the last month or more and I suspect more if I drag the logs out. I do not want to do that. I just am curious and perhaps misled with a silly notion that FreeBSD can be used by, you know, a user. This is not ubuntu and I am so thankful for that. This is not IBM or Red Fat. Why do I always see things like this : Queued: 31 Built: 21 Failed: 1 Skipped: 9 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 00:09:43 Every day. Over and over. For 14.2 and 13.4 and even 15.0 ? Every day. [142amd64-latest] [2025-01-15_15h06m30s] [parallel_build] Queued: 315 Built: 20 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 295 Time: 00:03:39 It will fail. For 2025Q1 or 2024Q4 or whatever is "latest". Fail. So I am happy to kick this hornets nest. Let the flames begin. Fine. The whole desktop user experience is broken and has been for a long time. I have the logs. I see the fails. Over and over. For a long time now. So then, do I labour under the false assumption that FreeBSD can be, you know, used? By a ... you know ... a human type? Am I lost here ? If the power to serve is just a backend server. Then fine. State that up front and lets drop the whole user stuff into a deep oubliette. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: poudriere and the user ... is it mostly a lost idea?
On 1/15/25 11:14, Gleb Popov wrote: On Wed, Jan 15, 2025 at 6:17 PM Dennis Clarke wrote: The whole desktop user experience is broken and has been for a long time. I have the logs. I see the fails. Over and over. It is the usual boring process. If something's not working for you - create a Bugzilla issue, share your logs. You said you have the logs, but didn't share them even in this mail. How're we supposed to help you? You missed the point. Entirely, passed you in both lanes. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: any images for freebsd-current?
On 2/6/21 2:59 PM, Steve Kargl wrote: > Any one aware of where images from freebsd-current? > freebsd.org appears to offer no images. > try https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ Also .. have you tried RISC-V ?? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: any images for freebsd-current?
On 2/6/21 4:02 PM, Steve Kargl wrote: > On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via freebsd-current > wrote: >> On 2/6/21 2:59 PM, Steve Kargl wrote: >>> Any one aware of where images from freebsd-current? >>> freebsd.org appears to offer no images. >>> >> >> try >> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ >> >> Also .. have you tried RISC-V ?? >> > > 13.0 does not equal 14.0. On my Dell Latitude D530 laptop, > i386-freebsd current ran well up to about Dec 2, 2020. Since > an attempted update in early Jan 2021, I've had nothing but > daily panics and other issues. There are two possibilities: > (1) failing hardware and/or (2) recently introduced i386-freebsd > kernel issues. Installing amd64-freebsd may eliminate one > of the two possibilities. > so install the latest there and then do a buildworld and buildkernel. easy. Dennis ___ 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: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K
On 2/11/21 8:57 PM, Gary Palmer wrote: > On Thu, Feb 11, 2021 at 05:34:40PM -0700, Russell L. Carter wrote: >> Greetings, >> >> I really want to jump from stable/12 to stable/13 but one thing is >> causing a hesitancy. And that is, my main raidz2 system has >> a system boot zfs mirror pair that has boot partition size >> (Mediasize) of 64K, and when I tried to zpool upgrade that pool a >> year or 2 ago I got some scary message something like "boot >> partition size is not large enough". I asked about this on the >> lists but never received an answer. So, laziness required me >> to ignore the problem and not zpool upgrade any of my 15 or so >> zpools in the interim. >> >> A few weeks ago I tried to make buildworld/installworld upgrade >> 12->13 but the boot failed in the mounting filesystems phase with it >> couldn't find a bootable target. So after restoring 12 I decided >> to wait a bit. In the interim I have upgraded every zpool but that >> one system pool. All the other freebsd-boot partitions have a size >> of 512K. >> >> So what is the current advice? Is a freebsd-boot partition size >> of 64K laughably obsolete, and I should get with the program and >> repartition those disks, or can I march blindly into the upgrade? >> >> I guess I just want to understand where these sizes are going in >> the future. > > Most layouts put a swap partition after the boot partition. If > that is the case for you also, if you can disable the swapping to the > swap partition you can probably increase boot and reduce swap size > pretty easily. Otherwise you're probably going to have to split > the mirror, repartition one drive, rebuild the mirror, reboot onto > that drive and then do the same to the other drive. I've done it > before on a headless system in a remote DC. With planning it's > perfectly doable. I think I built a test vm in VirtualBox and > made sure it all worked on that before trying it for real. > The process is trivial with ZFS and a mirror setup. No need to reboot. Think of the mirror as a "left" and "right" side. If you have a three way mirror than you are singing in the rain. Regardless just break the mirror. Do whatever you want with the disks that are now free and clear of the previous mirror config. Use gpart and set them up with whatever you need. Then attach the disk(s) back onto the mirror and wait for the thing to re-silver. Run a scrub if you want. Depends on the size. Just know that a large amount of storage ( more than 64T ) will take a long time to scrub and for that matter a long time to re-silver. Maybe a day. Once everything is re-synced as a mirror just repeat the process on the other side of the mirror. No need to reboot until you feel like testing the whole show. This sort of situation is also a good reason to use three way mirrors with a hot spare pool. When possible. Makes the whole process entirely worry free and nothing more than a cup of coffee to ponder it. For the sake of details what does "gpart show" report? Dennis Clarke ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 13-RC1 PVSCSI install error with VMware
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote: > Hello, > > A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI > drive. > At the end of the install it fails with the following error: > https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV > > Is it planned to be fixed before release ? Interesting error. Was this : 1) VMware Workstation of some flavour ? 2) ESXi or VMware vSphere server based ? What are the specs of the virtual machine ? Just some basics here. A little data please. In the meanwhile I will fire up RC1 on both Xeon based hardware and on VMware vSphere and VMware workstation just to see what happens. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 13-RC1 PVSCSI install error with VMware
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote: > Hello, > > A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI > drive. > At the end of the install it fails with the following error: > https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV > > Is it planned to be fixed before release ? I just took a look at : Configuring disks to use VMware Paravirtual SCSI (PVSCSI) controllers (1010398) https://kb.vmware.com/s/article/1010398 Where it seems you are definately using ESXi and I also have ESXi here to test with. However it is unclear how you configured your disk(s) and controllers. Can you provide some details on the config and how you arrived at this bug? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 13-RC1 PVSCSI install error with VMware
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote: > Hello, > > A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI > drive. > At the end of the install it fails with the following error: > https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV > > Is it planned to be fixed before release ? Sorry but it all works great here : sedna_esxi# cat /vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/deathstar/deathstar.vmx .encoding = "UTF-8" config.version = "8" virtualHW.version = "10" nvram = "deathstar.nvram" pciBridge0.present = "TRUE" svga.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" hpet0.present = "TRUE" displayName = "deathstar" extendedConfigFile = "deathstar.vmxf" virtualHW.productCompatibility = "hosted" floppy0.present = "FALSE" numvcpus = "2" memSize = "8192" powerType.powerOff = "hard" powerType.reset = "hard" tools.upgrade.policy = "manual" scsi0.virtualDev = "pvscsi" scsi0.present = "TRUE" scsi0:0.deviceType = "scsi-hardDisk" scsi0:0.fileName = "d_0.vmdk" scsi0:0.present = "TRUE" ide1:0.deviceType = "cdrom-image" ide1:0.fileName = "/vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/iso_images/FreeBSD-13.0-RC1-amd64-disc1.iso" ide1:0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.networkName = "vm_net_01" ethernet0.addressType = "generated" ethernet0.present = "TRUE" svga.autodetect = "TRUE" guestOS = "other-64" vcpu.hotadd = "TRUE" mem.hotadd = "TRUE" tools.syncTime = "FALSE" uuid.bios = "56 4d d6 67 c5 ca b8 fb-79 d3 d1 8b bc 26 1b ea" vc.uuid = "52 c3 0a e2 b1 48 4f 38-8f 18 69 01 ec 77 bf 07" scsi0:1.deviceType = "scsi-hardDisk" scsi0:1.fileName = "d_1.vmdk" scsi0:1.present = "TRUE" bios.forceSetupOnce = "FALSE" sched.swap.derivedName = "/vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/deathstar/deathstar-f1184228.vswp" uuid.location = "56 4d d6 67 c5 ca b8 fb-79 d3 d1 8b bc 26 1b ea" replay.supported = "FALSE" replay.filename = "" scsi0:0.redo = "" scsi0:1.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "160" ethernet0.pciSlotNumber = "32" vmci0.pciSlotNumber = "33" scsi0.sasWWID = "50 05 05 67 c5 ca b8 f0" ethernet0.generatedAddress = "00:0c:29:26:1b:ea" ethernet0.generatedAddressOffset = "0" vmci0.id = "-1138353174" monitor.phys_bits_used = "40" vmotion.checkpointFBSize = "16777216" cleanShutdown = "FALSE" softPowerOff = "FALSE" sedna_esxi# I hate being that guy that says "works for me"(tm) however ... it does. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 13.0-RC5 Now Available
On 4/3/21 3:34 PM, Glen Barber wrote: > The fifth RC build of the 13.0-RELEASE release cycle is now available. > Beautiful. If we see RC8 then that is fine. Testing is a wonderful process and I feel far better about a well tested release than an instant "oops" with 13.1 kicked out a week later. Also, I really am waiting to see the ten year old bug 159356 laid to rest : [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-specific https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=159356 Sort of a thorn in my side for years. Regardless, release candidates are a "good thing"(tm). -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: boot hangs after installworld at FreeBSD 14.0-CURRENT main-n248198-72f7ddb587a
7d6ec2d52e2fec2ce10e82c12ec0e4ddd | Author: Jason A. Harmening | Date: Sat Jul 17 22:35:42 2021 -0700 | | FFS: remove ffs_fsfail_task | | Now that dounmount() supports a dedicated taskqueue, we can simply call | it with MNT_DEFERRED directly from the failing context. This also | avoids blocking taskqueue_thread with a potentially-expensive unmount | operation. | | Reviewed by:kib, mckusick | Tested by: pho | Differential Revision: https://reviews.freebsd.org/D31016 | Are you on arm64 or ppc64 or some such tier-NOT-1 ? Even my RISC-V stuff seems to be working well. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
pkg sqlite database borked ( again ). How to restore?
I had another kernel panic on an AMD64 server. This has resulted in the pkg database being messed up. Also I was running a QEMU instance for aarch64 and that ended up with a messed up pkg database also. I saw some docs in section 4.4.8. Restoring the Package Database here: https://docs.freebsd.org/en/books/handbook/ports/#pkgng-intro However that does not work and issues a truely worthless error : europa# uname -apKU FreeBSD europa 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n250839-be60d8f276f: Fri Nov 19 00:02:38 GMT 2021 root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400042 1400042 europa# europa# ls -lap /var/backups/pkg* -rw-r--r-- 1 root wheel 2714084 Nov 29 03:04 /var/backups/pkg.sql.xz -rw-r--r-- 1 root wheel 2714084 Nov 28 03:20 /var/backups/pkg.sql.xz.1 -rw-r--r-- 1 root wheel 2714084 Nov 27 03:03 /var/backups/pkg.sql.xz.2 -rw-r--r-- 1 root wheel 2714084 Nov 26 03:03 /var/backups/pkg.sql.xz.3 -rw-r--r-- 1 root wheel 2714084 Nov 25 03:29 /var/backups/pkg.sql.xz.4 -rw-r--r-- 1 root wheel 2712568 Nov 24 03:04 /var/backups/pkg.sql.xz.5 -rw-r--r-- 1 root wheel 2712568 Nov 23 03:03 /var/backups/pkg.sql.xz.6 -rw-r--r-- 1 root wheel 2711928 Nov 22 03:54 /var/backups/pkg.sql.xz.7 europa# So I took a backup from there that looked reasonable : europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump europa# europa# pkg backup -r /var/db/pkg/local.sqlite.dump Restoring database: Restoring: 100% pkg: sqlite error while executing backup step in file backup.c:98: not an error pkg: sqlite error -- (null) europa# echo $? 1 europa# I don't know what to make of that mess. Can I create a new blank sqlite3 database and then restore from that dump file or is there a method that works better? Also is there a blank sqlite3 database for pkg on the install media? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: pkg sqlite database borked ( again ). How to restore?
On 11/29/21 06:22, Jamie Landeg-Jones wrote: > Dennis Clarke via freebsd-current wrote: > >> europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump >> >> europa# >> europa# pkg backup -r /var/db/pkg/local.sqlite.dump >> Restoring database: >> Restoring: 100% >> pkg: sqlite error while executing backup step in file backup.c:98: not >> an error > > The backup file consists of sql statements, the pkg backup -r I think > requires a binary db file. > > I think you need to do this: > > pkg shell < /var/db/pkg/local.sqlite.dump > > Cheers, Jamie > Ah well ... that seems to toss a ton of errors and yet works ? europa# europa# pkg shell < /var/db/pkg/local.sqlite.dump Error: near line 4: table packages already exists Error: near line 212: UNIQUE constraint failed: packages.name Error: near line 246: table mtree already exists Error: near line 247: table pkg_script already exists Error: near line 611: table script already exists Error: near line 612: UNIQUE constraint failed: script.script_id Error: near line 684: table option already exists Error: near line 685: UNIQUE constraint failed: option.option_id Error: near line 1049: table option_desc already exists Error: near line 1050: table pkg_option already exists Error: near line 1591: table pkg_option_desc already exists Error: near line 1592: table pkg_option_default already exists Error: near line 1593: table deps already exists Error: near line 2393: table files already exists Error: near line 61890: UNIQUE constraint failed: files.path Error: near line 61891: UNIQUE constraint failed: files.path Error: near line 61892: UNIQUE constraint failed: files.path Error: near line 61893: UNIQUE constraint failed: files.path Error: near line 61894: UNIQUE constraint failed: files.path Error: near line 61895: UNIQUE constraint failed: files.path Error: near line 61896: UNIQUE constraint failed: files.path Error: near line 61897: UNIQUE constraint failed: files.path Error: near line 61898: UNIQUE constraint failed: files.path Error: near line 61899: UNIQUE constraint failed: files.path Error: near line 61900: UNIQUE constraint failed: files.path Error: near line 61901: UNIQUE constraint failed: files.path Error: near line 61902: UNIQUE constraint failed: files.path Error: near line 61903: UNIQUE constraint failed: files.path Error: near line 61904: UNIQUE constraint failed: files.path Error: near line 61905: UNIQUE constraint failed: files.path Error: near line 61906: UNIQUE constraint failed: files.path Error: near line 61907: UNIQUE constraint failed: files.path Error: near line 61908: UNIQUE constraint failed: files.path Error: near line 61909: UNIQUE constraint failed: files.path Error: near line 61910: UNIQUE constraint failed: files.path Error: near line 61911: UNIQUE constraint failed: files.path Error: near line 61912: UNIQUE constraint failed: files.path Error: near line 61913: UNIQUE constraint failed: files.path Error: near line 61914: UNIQUE constraint failed: files.path Error: near line 61915: UNIQUE constraint failed: files.path Error: near line 61916: UNIQUE constraint failed: files.path Error: near line 61917: UNIQUE constraint failed: files.path Error: near line 61918: UNIQUE constraint failed: files.path Error: near line 61919: UNIQUE constraint failed: files.path Error: near line 61920: UNIQUE constraint failed: files.path Error: near line 61921: UNIQUE constraint failed: files.path Error: near line 61922: UNIQUE constraint failed: files.path Error: near line 61923: UNIQUE constraint failed: files.path Error: near line 61924: UNIQUE constraint failed: files.path Error: near line 61925: UNIQUE constraint failed: files.path Error: near line 61926: UNIQUE constraint failed: files.path Error: near line 61927: UNIQUE constraint failed: files.path Error: near line 61928: UNIQUE constraint failed: files.path Error: near line 61929: UNIQUE constraint failed: files.path Error: near line 61930: UNIQUE constraint failed: files.path Error: near line 61931: UNIQUE constraint failed: files.path Error: near line 61932: UNIQUE constraint failed: files.path Error: near line 61933: UNIQUE constraint failed: files.path Error: near line 61934: UNIQUE constraint failed: files.path Error: near line 61935: UNIQUE constraint failed: files.path Error: near line 61936: UNIQUE constraint failed: files.path Error: near line 61937: UNIQUE constraint failed: files.path Error: near line 61938: UNIQUE constraint failed: files.path Error: near line 61939: UNIQUE constraint failed: files.path Error: near line 61940: UNIQUE constraint failed: files.path Error: near line 61941: UNIQUE constraint failed: files.path Error: near line 61942: UNIQUE constraint failed: files.path Error: near line 61943: UNIQUE constraint failed: files.path Error: near line 61944: UNIQUE constraint failed: files.path Error: near line 61945: UNIQUE constraint failed: files.path Error: near line
