Re: serial/ulscom: response timeout using pySerial/esptool.py
Am Sat, 27 Apr 2024 11:28:55 +0200 FreeBSD User schrieb: Just for the record: running a small "victim NAS" based on an HP EliteDesk 800 G2 mini, XigmaNAS (latest official version, kernel see below), installing packages from an official FreeBSD site for FBSD 13.2-RELEASE, gives me on an ESP32 D1 mini, not working with the afore mentioned host, gives this (after a loop of 100x issued the esptool.py command, no issues detected): [...] nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac esptool.py v4.5 Serial port /dev/cuaU0 Connecting.. Chip is ESP32-D0WD-V3 (revision v3.1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: XX:XX:XX:XX:XX:XX Uploading stub... Running stub... Stub running... MAC: XX:XX:XX:XX:XX:XX Hard resetting via RTS pin... [...] .. and those from AZdelivery (larger and older chips): [...] nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac esptool.py v4.5 Serial port /dev/cuaU0 Connecting. Chip is ESP32-D0WDQ6 (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: XX:XX:XX:XX:XX:XX Uploading stub... Running stub... Stub running... MAC: XX:XX:XX:XX:XX:XX Hard resetting via RTS pin... [...] or [... considered a different revision, but in fact the same old ESP32 as it reveals itself as ..] nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac esptool.py v4.5 Serial port /dev/cuaU0 Connecting... Chip is ESP32-D0WDQ6 (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: XX:XX:XX:XX:XX:XX Uploading stub... Running stub... Stub running... MAC: XX:XX:XX:XX:XX:XX Hard resetting via RTS pin... Big question is: is this an issue introduced with FBSD 14? In 2020 I played around with my first attempts using the Arduino IDE which worked pretty well, with some minor issues (I had to perform several attempts to get connected, using 12- and 13-STABLE that time). But the Arduino IDE doen't work as well > Am Thu, 25 Apr 2024 21:51:21 +0200 > Tomek CEDRO schrieb: > > > CP2102 are pretty good ones and never let me down :-) > > > > Is your UART connection to ESP32 working correctly? Can you see the > > boot message and whatever happens next in terminal (cu / minicom)? Are > > RX TX pins not swapped? Power supply okay? > > The ESP32 used are > - ESP32-WROOM32 D1 mini, have 10 pieces of those, on each single one same > behaviour on same > host > - ESP32-WROOM32 sold by Chinese distributor AZdelivery in Germany, I got a > bunch of them, > Revision 1 (baught 2020) and a more recent revision V4, baught a couple of > months ago. > > AGAIN: ALL chips do not communicate with my private hosts (dmesg: CPU > microcode: updated from > 0x1f to 0x21 CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.18-MHz > K8-class CPU)), OS: > FreeBSD 15.0-CURRENT #39 main-n269723-4ba444de708b: Sat Apr 27 06:42:44 CEST > 2024 amd64, > mainboard is a crappy Z77 Pro4 ASrock, > > pciconf excerpts: > [...] > ichsmb0@pci0:0:31:3:class=0x0c0500 rev=0x04 hdr=0x00 vendor=0x8086 > device=0x1e22 > subvendor=0x1849 subdevice=0x1e22 vendor = 'Intel Corporation' > device = '7 Series/C216 Chipset Family SMBus Controller' > class = serial bus > subclass = SMBus > bar [10] = type Memory, range 64, base 0xf7c15000, size 256, enabled > bar [20] = type I/O Port, range 32, base 0xf040, size 32, enabled > .. > ehci1@pci0:0:29:0: class=0x0c0320 rev=0x04 hdr=0x00 vendor=0x8086 > device=0x1e26 > subvendor=0x1849 subdevice=0x1e26 vendor = 'Intel Corporation' > device = '7 Series/C216 Chipset Family USB Enhanced Host Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xf7c17000, size 1024, enabled > cap 01[50] = powerspec 2 supports D0 D3 current D0 > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] = PCI Advanced Features: FLR TP > .. > xhci0@pci0:0:20:0: class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 > device=0x1e31 > subvendor=0x1849 subdevice=0x1e31 vendor = 'Intel Corporation' > device = '7 Series/C210 Series Chipset Family USB xHCI Host > Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 64, base 0xf7c0, size 65536, enabled > cap 01[70] = powerspec 2 supports D0 D3 current D0 > cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message > > > > > > > Are boards generic devkits of custom hardware? ESP32 in addition to RX > > TX needs two control lines Reset and Bo
Re: serial/ulscom: response timeout using pySerial/esptool.py
Am Thu, 25 Apr 2024 21:51:21 +0200 Tomek CEDRO schrieb: > CP2102 are pretty good ones and never let me down :-) > > Is your UART connection to ESP32 working correctly? Can you see the > boot message and whatever happens next in terminal (cu / minicom)? Are > RX TX pins not swapped? Power supply okay? The ESP32 used are - ESP32-WROOM32 D1 mini, have 10 pieces of those, on each single one same behaviour on same host - ESP32-WROOM32 sold by Chinese distributor AZdelivery in Germany, I got a bunch of them, Revision 1 (baught 2020) and a more recent revision V4, baught a couple of months ago. AGAIN: ALL chips do not communicate with my private hosts (dmesg: CPU microcode: updated from 0x1f to 0x21 CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.18-MHz K8-class CPU)), OS: FreeBSD 15.0-CURRENT #39 main-n269723-4ba444de708b: Sat Apr 27 06:42:44 CEST 2024 amd64, mainboard is a crappy Z77 Pro4 ASrock, pciconf excerpts: [...] ichsmb0@pci0:0:31:3:class=0x0c0500 rev=0x04 hdr=0x00 vendor=0x8086 device=0x1e22 subvendor=0x1849 subdevice=0x1e22 vendor = 'Intel Corporation' device = '7 Series/C216 Chipset Family SMBus Controller' class = serial bus subclass = SMBus bar [10] = type Memory, range 64, base 0xf7c15000, size 256, enabled bar [20] = type I/O Port, range 32, base 0xf040, size 32, enabled .. ehci1@pci0:0:29:0: class=0x0c0320 rev=0x04 hdr=0x00 vendor=0x8086 device=0x1e26 subvendor=0x1849 subdevice=0x1e26 vendor = 'Intel Corporation' device = '7 Series/C216 Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xf7c17000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP .. xhci0@pci0:0:20:0: class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 device=0x1e31 subvendor=0x1849 subdevice=0x1e31 vendor = 'Intel Corporation' device = '7 Series/C210 Series Chipset Family USB xHCI Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0xf7c0, size 65536, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message > > Are boards generic devkits of custom hardware? ESP32 in addition to RX > TX needs two control lines Reset and Boot that will switch the chip to > bootloader / flashing mode. Most USB-to-UART use RTS/CTS lines for > that. Are you sure these lines are available on your board and > connected to the target correctly? Do you have Reset and Boot buttons > on the board so you could trigger bootloader by hand (hold Boot, press > and release Reset, device will be in bootloader upload mode, retry > esptool flashing now). You can also play with the buttons with active > terminal attached (i.e. minicom) to see if they work as expected. I tried minivom, but I have to confess, I'm a "noice" in that matter, so do not expect professional debugging infos: Unsuccessful issueing the following command on three different types of ESP32 as described above, I use at least two of them and even one (a D1 mini) just unfolded from its sealed anti static bag) while observing the minicom attached via -D /dev/cuaU1: [...] [ohartmann]: esptool.py --chip esp32 --baud 115200 --connect-attempts 400 --port /dev/cuaU1 read_mac esptool.py v4.7.0 Loaded custom configuration from /pool/home/ohartmann/esptool.cfg Serial port /dev/cuaU1 Connecting... A serial exception error occurred: device reports readiness to read but returned no data (device disconnected or multiple access on port?) Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers. For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html [...] On the reference minicom terminal I observed with the D1 mini (minicom -b 115200 -D /dev/cuaU1): [...] Welcome to minicom 2.8 OPTIONS: I18n Compiled on Apr 27 2024, 09:04:50. Port /dev/cuaU1, 10:50:53 Press CTRL-A Z for help on special keys ts Jul 29 2019 12:21:46 rst:x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) waiting for download U� U� U� U� U� U� U� U [... the older ESP32 from 2020 ...] rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DOUT, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:1044 load:0x40078000,len:10124 load:0x40080400,len:5828 entry 0x400806a8 �un 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) waiting for download es Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH]�(�:��� � [... and the one purchased last year, called
Re: TXT Kernel linking failed on -CURRENT
Konstantin, good day! 25.04.2024 0:09, Konstantin Belousov пишет: On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: linking kernel ld: error: undefined symbol: ktrcapfail referenced by vfs_lookup.c vfs_lookup.o:(namei) referenced by vfs_lookup.c vfs_lookup.o:(namei_setup) referenced by vfs_lookup.c vfs_lookup.o:(vfs_lookup) referenced 3 more times *** [kernel] Error code 1 Try https://reviews.freebsd.org/D44931 Yes, now system and kernel builds fine. Thanks!
serial/ulscom: response timeout using pySerial/esptool.py
Hello, Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926: Thu Apr 25 18:48:56 CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at hand). Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560 notebook, Fujitsu Esprimo Q5XX (simple desktop, Pentium Gold) or an oldish Fujitsu Celsius 7XX workstation, 6 core Haswell XEON. Phenomenon: a couple of weeks now I try to connect to several Xtensa ESP32 dev boards (ESP32-WROOM32 with CP2101 or CP2104 UART) via comms/py-esptool (doesn't matter whether it is tho port's py39-esptool 4.5 or the latest py-esptool 4.7.0, doesn't matter whether pkg package or self compiled on CURRENT and 14-STABLE, on all hardware platforms same result). Attaching the ESP devel module via Micro USB cable (several type, differnt vendors tried ...) show dmesg: [...] ugen0.4: at usbus0 uslcom0 on uhub3 uslcom0: on usbus0 [...] When trying to connect to the ESP32 via below shown command (--trace not every time issued), I get no connection: [ohartmann]: esptool.py --trace --chip esp32 --baud 115200 --port /dev/cuaU1 flash_id esptool.py v4.7.0 Loaded custom configuration from /pool/home/ohartmann/esptool.cfg Serial port /dev/cuaU1 Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 07071220 | ... | | TRACE +0.000 Write 46 bytes: c824 000707122055 | ...$ UUU | 55c0 | U. TRACE +0.102 No serial data received. TRACE +0.052 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 07071220 | ... | | TRACE +0.000 Write 46 bytes: c824 000707122055 | ...$ UUU | 55c0 | U. TRACE +0.107 No serial data received. TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 07071220 | ... | | TRACE +0.000 Write 46 bytes: c824 000707122055 | ...$ UUU | 55c0 | U. TRACE +0.107 No serial data received. TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 07071220 | ... | | TRACE +0.000 Write 46 bytes: c824 000707122055 | ...$ UUU | 55c0 | U. A serial exception error occurred: device reports readiness to read but returned no data (device disconnected or multiple access on port?) Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers. For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html [...] Whatever baud rate issued, in most cases on all tested OS versions and almost all hardware platforms except the Fujistu Celsius 7XX (2015 model) I do not get any connection! And it get more weird: To avoid out-of-sync-software I recompiled everything via "portmaster -df comms/py-pyserial comms/py-esptool" and after that, everything was fine, the connection was made, I got results out of the chip. Seconds later same problems. I exchanged cablings, exchanged the ESP32 model and vendor. Invariants are 14-STABLE, daily compiled, CURRENT. daily compiled. On my private box (old Z77 based IvyBridge ASRock crap), a couple of Lenovo T560 running 14-STABLE and several Fujitsu Esprimo Q5XX boxes there is always this weird error message, but in very rare cases I get connection. Only exception: the Fujsitus Celsius 7XX workstation (14-STABLE, last complied today noon). No matter what ESP32, no matter what vendor, no matter what cablin used: connection is established at any BAUD rate issued at any time. Not one single failure as shown above in any session (I checked several tenth times)! Now I'm out of ideas and I suspect the CP210X ulscom serial driver to have trouble with most onboard serial chipsets. Can anyone help me track down this issue? Is there anything I could have missed? I drives me nuts ... Thanks in advance, Oliver -- O. Hartmann
TXT Kernel linking failed on -CURRENT
Sorry for HTML-trash from previous mail :) Hi, FreeBSD Community! I have a teach with FreeBSD and use -CURRENT on my test machine. And some days ago after - git pull - make buildworld - make buildkernel There is /etc/src.conf and BSDSERV below, what can cause that error? Thanks for help! My /usr/src state is: git log -n 1 commit a0d7d68a2dd818ce84e37e1ff20c8849cda6d853 (HEAD -> main, origin/main, origin/HEAD) Author: Cy Schubert kernel building failed with such messages: -- --- force-dynamic-hack.pico --- cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -shared -O2 -pipe -fno-strict-aliasing -march=native -nostdinc -I. -I/usr/src/sys -I/u sr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -MD -MF.depend.force-dynamic-hack.pico -MTforce-dynamic-hack.pico -fdebug-pr efix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fn o-asynchronous-unwind-tables -ffreestanding -fwrapv -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdi agnostics-show-option -Wno-unknown-pragmas -Wswitch -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negativ e-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx -std=gnu99 -nostdlib force-dynamic-hack.c -o force-dynamic-hack.pico --- vers.c --- MAKE="make" sh /usr/src/sys/conf/newvers.sh BSDSERV --- vers.o --- cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -march=native -nostdinc -I. -I/usr/src/sys -I/usr/src /sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/ usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -Wall -Wstrict-proto types -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wswitch -Wno-error=tautologi cal-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx -std=gnu99 -Werror vers.c --- kernel --- linking kernel ld: error: undefined symbol: ktrcapfail >>> referenced by vfs_lookup.c >>> vfs_lookup.o:(namei) >>> referenced by vfs_lookup.c >>> vfs_lookup.o:(namei_setup) >>> referenced by vfs_lookup.c >>> vfs_lookup.o:(vfs_lookup) >>> referenced 3 more times *** [kernel] Error code 1 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BSDSERV make[2]: 1 error make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BSDSERV 1098.27 real 2002.17 user 176.26 sys make[1]: stopped in /usr/src make: stopped in /usr/src /etc/src.conf === WITHOUT_APM=yes WITHOUT_ASSERT_DEBUG=yes WITHOUT_AUTHPF=yes WITHOUT_BHYVE=yes WITHOUT_BLACKLIST=yes WITHOUT_BLUETOOTH=yes WITHOUT_CCD=yes WITHOUT_CXGBETOOL=yes WITHOUT_DEBUG_FILES=yes WITHOUT_DTRACE=yes WITHOUT_FLOPPY=yes WITHOUT_GOOGLETEST=yes WITHOUT_HAST=yes WITHOUT_HTML=yes WITHOUT_HYPERV=yes WITHOUT_INET6=yes WITHOUT_IPFILTER=yes WITHOUT_ISCSI=yes WITHOUT_KDUMP=yes WITHOUT_KERNEL_SYMBOLS=yes WITH_MALLOC_PRODUCTION=yes WITHOUT_MLX5TOOL=yes WITHOUT_NVME=yes WITHOUT_OFED=yes WITHOUT_PF=yes WITHOUT_PTHREADS_ASSERTIONS=yes WITHOUT_RADIUS_SUPPORT=yes WITHOUT_RELRO=yes WITHOUT_SSP=yes WITHOUT_WARNS=yes WITHOUT_WERROR=yes WITHOUT_TESTS=yes WITHOUT_WIRELESS=yes BSDSERV === cpu HAMMER ident BSDSERV device amdtemp options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options VIMAGE # Subsystem virtualization, e.g. VNET options INET # InterNETworking options TCP_OFFLOAD
Kernel linking error on -CURRENT
Hi, FreeBSD Community! I have a teach with FreeBSD and use -CURRENT on my test machine.And some days ago after- git pull- make buildworld- make buildkernel There is /etc/src.conf and BSDSERV below, what can cause that error?Thanks for help! kernel building failed with such messages:- force-dynamic-hack.pico ---cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -shared -O2 -pipe -fno-strict-aliasing -march=native -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -MD -MF.depend.force-dynamic-hack.pico -MTforce-dynamic-hack.pico -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wswitch -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx -std=gnu99 -nostdlib force-dynamic-hack.c -o force-dynamic-hack.pico--- vers.c ---MAKE="make" sh /usr/src/sys/conf/newvers.sh BSDSERV--- vers.o ---cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -march=native -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wswitch -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx -std=gnu99 -Werror vers.c--- kernel ---linking kernelld: error: undefined symbol: ktrcapfail>>> referenced by vfs_lookup.c>>> vfs_lookup.o:(namei)>>> referenced by vfs_lookup.c>>> vfs_lookup.o:(namei_setup)>>> referenced by vfs_lookup.c>>> vfs_lookup.o:(vfs_lookup)>>> referenced 3 more times*** [kernel] Error code 1 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BSDSERVmake[2]: 1 error make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BSDSERV 1098.27 real 2002.17 user 176.26 sys make[1]: stopped in /usr/src make: stopped in /usr/src /etc/src.conf===WITHOUT_APM=yesWITHOUT_ASSERT_DEBUG=yesWITHOUT_AUTHPF=yesWITHOUT_BHYVE=yesWITHOUT_BLACKLIST=yesWITHOUT_BLUETOOTH=yesWITHOUT_CCD=yesWITHOUT_CXGBETOOL=yesWITHOUT_DEBUG_FILES=yesWITHOUT_DTRACE=yesWITHOUT_FLOPPY=yesWITHOUT_GOOGLETEST=yesWITHOUT_HAST=yesWITHOUT_HTML=yesWITHOUT_HYPERV=yesWITHOUT_INET6=yesWITHOUT_IPFILTER=yesWITHOUT_ISCSI=yesWITHOUT_KDUMP=yesWITHOUT_KERNEL_SYMBOLS=yesWITH_MALLOC_PRODUCTION=yesWITHOUT_MLX5TOOL=yesWITHOUT_NVME=yesWITHOUT_OFED=yesWITHOUT_PF=yesWITHOUT_PTHREADS_ASSERTIONS=yesWITHOUT_RADIUS_SUPPORT=yesWITHOUT_RELRO=yesWITHOUT_SSP=yesWITHOUT_WARNS=yesWITHOUT_WERROR=yesWITHOUT_TESTS=yesWITHOUT_WIRELESS=yes BSDSERV===cpu HAMMERident BSDSERVdevice amdtempoptions SCHED_ULE # ULE scheduleroptions PREEMPTION # Enable kernel thread preemptionoptions VIMAGE # Subsystem virtualization, e.g. VNEToptions INET # InterNETworkingoptions TCP_OFFLOAD # TCP offloadoptions TCP_BLACKBOX # Enhanced TCP event loggingoptions TCP_HHOOK # hhook(9) framework for TCPoptions TCP_RFC7413 # TCP Fast Openoptions KERN_TLS # TLS transmit & receive offloadoptions FFS # Berkeley Fast Filesystemoptions SOF
Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d
Am Tue, 9 Apr 2024 09:18:49 -0700 Gleb Smirnoff schrieb: > On Tue, Apr 09, 2024 at 04:47:07AM -0700, David Wolfskill wrote: > D> --- trap 0xc, rip = 0x80b208c5, rsp = 0xfe048c204920, rbp = > 0xfe > D> 048c204960 --- > D> __mtx_lock_flags() at __mtx_lock_flags+0x45/frame 0xfe048c204960 > D> clnt_vc_create() at clnt_vc_create+0x4f4/frame 0xfe048c204ab0 > D> local_rpcb() at local_rpcb+0x11b/frame 0xfe048c204b50 > D> rpcb_unset() at rpcb_unset+0x24/frame 0xfe048c204bb0 > D> svc_tp_create() at svc_tp_create+0xee/frame 0xfe048c204c90 > D> sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfe048c204e00 > D> amd64_syscall() at amd64_syscall+0x158/frame 0xfe048c204f30 > D> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe048c204f30 > D> --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x3f00a2dfd2a, rsp = > 0x3f00 > D> 96f7168, rbp = 0x3f0096f7230 --- > D> KDB: enter: panic > D> [ thread pid 1208 tid 101107 ] > D> Stopped at kdb_enter+0x33: movq$0,0x104eb92(%rip) > D> db> > > This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf. > > Sorry for that! > Hello all. The crash is still present on the most recent checked out sources as of minutes ago. I just checked out on HEAD the latest commits (see below, just for the record and to prevent being wrong here). [...] commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/main, origin/HEAD) Author: Alan Cox Date: Mon Apr 8 00:05:27 2024 -0500 arm64 pmap: Add ATTR_CONTIGUOUS support [Part 2] Create ATTR_CONTIGUOUS mappings in pmap_enter_object(). As a result, when the base page size is 4 KB, the read-only data and text sections of large (2 MB+) executables, e.g., clang, can be mapped using 64 KB pages. Similarly, when the base page size is 16 KB, the read-only data section of large executables can be mapped using 2 MB pages. Rename pmap_enter_2mpage(). Given that we have grown support for 16 KB base pages, we should no longer include page sizes that may vary, e.g., 2mpage, in pmap function names. Requested by: andrew Co-authored-by: Eliot Solomon Differential Revision: https://reviews.freebsd.org/D44575 commit e205fd318a296ffdb7392486cdcec7f660fcffcf Author: Gleb Smirnoff Date: Tue Apr 9 09:16:52 2024 -0700 rpc: use new macros to lock socket buffers Fixes: d80a97def9a1db6f07f5d2e68f7ad62b27918947 commit cb20a74ca06381e96c41cb4495d633710cc6cb79 Author: Stephen J. Kiernan Date: Wed Apr 3 17:04:57 2024 -0400 -- O. Hartmann
Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports
Am Tue, 9 Apr 2024 17:10:52 +0200 Rainer Hurling schrieb: > Am 09.04.24 um 09:20 schrieb Baptiste Daroussin: > > On Sat 06 Apr 09:23, Rainer Hurling wrote: > >> Am 06.04.24 um 09:05 schrieb FreeBSD User: > >>> Hello, > >>> > >>> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> > >>> 1.21.0 on CURRENT > >>> and 14-STABLE, I can't update several ports: > >>> > >>> www/apache24 > >>> databases/redis > >>> > >>> pkg core dumps while performing installation. apache24 and redis are > >>> ports I realized > >>> this misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants > >>> latest builds, > >>> i.e. FreeBSD 15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr 5 > >>> 20:30:39 CEST 2024 > >>> amd64). > >>> > >>> After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG > >>> jail with > >>> poudriere) building packages for 14.0-RELENG, I observed the same > >>> behaviour when > >>> updating packages on target hosts where pkg is first updated, on those > >>> hosts, > >>> nextcloud-server and icinga2 host utilizing also databases/redis and > >>> www/apache24, pkg > >>> fails the same way. > >>> > >>> I do not dare to update our poudriere hosts since the problem seems to > >>> pop up when pkg > >>> 1.21.0 is installed, no matter whether I use poudriere built ports (from > >>> our own builder > >>> hosts) or recent source tree with portmaster/make build process. > >>> > >>> Looks like a serious bug to me and not a site/user specific problem. > >>> Hopefully others do > >>> realize the same ... > >>> > >>> Thanks in advance, > >>> > >>> oh > >> > >> > >> Hmm, I just tried to reproduce that. Both ports mentioned, databases/redis > >> and www/apache24, can be built and installed with Portmaster. The box is a > >> 15.0-CURRENT with pkg-1.21.0. > >> > >> Maybe 'pkg check -Bn' or 'portmaster --check-depends --check-port-dbdir' > >> show some inconsistencies? > >> > >> Best wishes, > >> Rainer > >> > >> > > using portmaster or not are strictly unlikely to be helpful here. > > > > The right way to test if to report running with pkg - and also to > > recommand > > testing with default options in pkg.conf. > > > > Best regards, > > Bapt > > This is correct and certainly better. I was not aware of this. > > Fortunately, my less optimal suggestions helped O. Hartmann in this case > to find the missing and outdated dependencies. > > In any case, many thanks for this helpfull advice. > > Regards, > Rainer > > Hello, @Babptist : it should be pkg -d, shouldn't it? Or do I miss again something here? With today's update to pkg 1.21.1 the problem has vanished. @R. Hurling: Thanks for the tip using the checks. I missed that and somehow it revealed some problems here I hopefully have fixed so far. Kind regads and thanks, oh -- O. Hartmann
Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg-static core dumps on some ports
Am Sat, 6 Apr 2024 09:05:00 +0200 FreeBSD User schrieb: > Hello, > > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 > on CURRENT and > 14-STABLE, I can't update several ports: > > www/apache24 > databases/redis > > pkg core dumps while performing installation. apache24 and redis are ports I > realized this > misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants latest > builds, i.e. FreeBSD > 15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr 5 20:30:39 CEST 2024 > amd64). > > After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG > jail with > poudriere) building packages for 14.0-RELENG, I observed the same behaviour > when updating > packages on target hosts where pkg is first updated, on those hosts, > nextcloud-server and > icinga2 host utilizing also databases/redis and www/apache24, pkg fails the > same way. > > I do not dare to update our poudriere hosts since the problem seems to pop up > when pkg 1.21.0 > is installed, no matter whether I use poudriere built ports (from our own > builder hosts) or > recent source tree with portmaster/make build process. > > Looks like a serious bug to me and not a site/user specific problem. > Hopefully others do > realize the same ... > > Thanks in advance, > > oh > > Hello, after following a recommnedation checking dependencies on ports via pkg check -Bn, recompiling pkg via "portmaster -df ports-mgmt/pkg" along with all ports found by the check command as well a sqlite (precaustion), still the pkg-static binary drops core dumps on some ports. Phenomenon: When updating existing ports, like www/apache24 databases/redis net/openldap26-server misc/e2fsprogs-libuuid building the port runs smootly, but pkg-static dies on deleting attempt of the old/to-be-reinstalled port. The problem arises by using portmaster as well as performing "make install/make deinstall" in the specific target port. Last port I hit is misc/e2fsprogs-libuuid. My skills debugging core dumps are rather limited, our boxes do have debugging disabled. Since the problem spreads across several hosts running CURRENT (same IcyBridge CPU generation, but one host most recent CURRENT with LLVM18, the other one running a CURRENT compiled 4 days ago and as of last week the problem arose also on 14-STABLE on a box in the lab when performing the tansition from pkg 1.20.9_1 -> 1.21.0), I'd exclude a hardware/memory issue. Using (a freshly recompiled) gdb 14 from ports gives not much: [...] root@thor:/usr/ports # gdb /usr/local/sbin/pkg-static /packages/portmaster-backup/pkg-static.core GNU gdb (GDB) 14.1 [GDB v14.1 for FreeBSD] Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd15.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/sbin/pkg-static... (No debugging symbols found in /usr/local/sbin/pkg-static) [New LWP 101269] Core was generated by `/usr/local/sbin/pkg-static delete -yf e2fsprogs-libuuid-1.47.0'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 0x00b3de2b in strlen_baseline () Kind regards, oh -- O. Hartmann
Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1
Am Thu, 4 Apr 2024 01:14:52 -0500 Kyle Evans schrieb: > On 4/4/24 00:49, FreeBSD User wrote: > > Hello, > > > > I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1: > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094 > > > > FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited > > skills do not allow > > me to judge wether the described exploit mechanism also works on FreeBSD. > > RedHat already sent out a warning, the workaround is to move back towards > > an older variant. > > > > I have to report to my superiors (we're using 14-STABLE and CURRENT and I > > do so in > > private), so I would like to welcome any comment on that. > > > > Thanks in advance, > > > > O. Hartmann > > > > > > See so@'s answer from a couple days ago: > > https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html > > TL;DR no > > Thanks, > > Kyle Evans Thank you very much. Kind regards, oh -- O. Hartmann
pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports
Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports: www/apache24 databases/redis pkg core dumps while performing installation. apache24 and redis are ports I realized this misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants latest builds, i.e. FreeBSD 15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr 5 20:30:39 CEST 2024 amd64). After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG jail with poudriere) building packages for 14.0-RELENG, I observed the same behaviour when updating packages on target hosts where pkg is first updated, on those hosts, nextcloud-server and icinga2 host utilizing also databases/redis and www/apache24, pkg fails the same way. I do not dare to update our poudriere hosts since the problem seems to pop up when pkg 1.21.0 is installed, no matter whether I use poudriere built ports (from our own builder hosts) or recent source tree with portmaster/make build process. Looks like a serious bug to me and not a site/user specific problem. Hopefully others do realize the same ... Thanks in advance, oh -- O. Hartmann
Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1
Am Thu, 04 Apr 2024 08:06:26 +0200 (CEST) sth...@nethelp.no schrieb: > >> I have to report to my superiors (we're using 14-STABLE and CURRENT > >> and I do so in private), > >> so I would like to welcome any comment on that. > > > > No it does not affect FreeBSD. > > > > The autoconf script checks that it is running in a RedHat or Debian > > package build environment before trying to proceed. There are also > > checks for GCC and binutils ld.bfd. And I'm not sure that the payload > > (a precompiled Linux object file) would work with FreeBSD and > > /lib/libelf.so.2. > > > > See > > > > https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 > > See also the following message from the FreeBSD security officer: > > https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > Thank you very much for the quick answer. Kind regards oh -- O. Hartmann
Re: NFSv4 crash of CURRENT
> >>> Maybe it is the > >>> same problem. > >>> > >>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and > >>> type tab to > >>> autocomplete it crashes with the below stack trace. If I plainly mount > >>> ports on > >>> /usr/ports and do the same everything works. I am using NFSv3 > >>> > >>> Peter > >>> > >>> > >>> > >>> > >>> Fatal trap 12: page fault while in kernel mode > >>> cpuid = 2; apic id = 04 > >>> fault virtual address = 0x89 > >>> fault code = supervisor read data, page not present > >>> instruction pointer = 0x20:0x809645d4 > >>> stack pointer= 0x28:0xfe00acadb830 > >>> frame pointer= 0x28:0xfe00acadb830 > >>> 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 = 6869 (csh) > >>> trap number = 12 > >>> panic: page fault > >>> cpuid = 2 > >>> time = 1705306940 > >>> KDB: stack backtrace: > >>> #0 0x806232f5 at kdb_backtrace+0x65 > >>> #1 0x805d7a02 at vpanic+0x152 > >>> #2 0x805d78a3 at panic+0x43 > >>> #3 0x809d58ad at trap_fatal+0x38d > >>> #4 0x809d58ff at trap_pfault+0x4f > >>> #5 0x809af048 at calltrap+0x8 > >>> #6 0x804c7a7e at ncl_bioread+0xb7e > >>> #7 0x804b9d90 at nfs_readdir+0x1f0 > >>> #8 0x8069c61a at vop_sigdefer+0x2a > >>> #9 0x809f8ae0 at VOP_READDIR_APV+0x20 > >>> #10 0x81ce75de at autofs_readdir+0x2ce > >>> #11 0x809f8ae0 at VOP_READDIR_APV+0x20 > >>> #12 0x806c3002 at kern_getdirentries+0x222 > >>> #13 0x806c33a9 at sys_getdirentries+0x29 > >>> #14 0x809d6180 at amd64_syscall+0x110 > >>> #15 0x809af95b at fast_syscall_common+0xf8 > >>> > >>> > >>> > >>> On 15 Jan 2024, at 06:46, FreeBSD User >>> <mailto:free...@walstatt-de.de>> wrote: > >>> > >>> Am Sun, 14 Jan 2024 20:34:12 -0800 > >>> Cy Schubert >>> <mailto:cy.schub...@cschubert.com>> schrieb: > >>> > >>> In message > >>> >>> <mailto:CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.c> > >>> > >>> om> > >>> , Rick Macklem writes: > >>> > >>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop >>> <mailto:ronald-li...@klop.ws>>= wrote: > >>> > >>> > >>> > >>> Van: FreeBSD User mailto:freebsd@walstatt-dede>> > >>> Datum: 13 januari 2024 19:34 > >>> Aan: FreeBSD CURRENT >>> <mailto:freebsd-current@freebsd.org>> > >>> Onderwerp: NFSv4 crash of CURRENT > >>> > >>> Hello, > >>> > >>> running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a= > >>> > >>> : Sat Jan 13 18:08:32 > >>> > >>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned cl= > >>> > >>> ient, other is FreeBSD > >>> > >>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. > >>> > >>> I can crash the client reproducable by accessing the one or other NFSv4 F= > >>> > >>> S (a simple ls -la). > >>> > >>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla a= > >>> > >>> ccess to the client > >>> > >>> host, luckily the box recovers. > >>> > >>> Did you rebuild both the nfscommon and nfscl modules from the same > >>> sources? > >>> I did a commit to main that changes the interface between these two > >>> modules and did bump the > >>> __FreeBSD_version to 1500010, which should cause both to be rebuilt. > >>> (If you have "options NFSCL" in your kernel config, both should have > >>> been rebuilt as a part of > >>> the kernel build.) > >>> > >>> > >>> Is anyone by chance seeing autofs in the backtrace too? > >>> > >>> > >>> > >>> Hello Cy Shubert, > >>> > >>> I forgot to mention that those crashes occur with autofs mounted > >>> filesystems. Good > >>> question, by the way, I will check whether crashes also happen when > >>> mounting the > >>> tradidional way. > >>> > >>> Kind regards, > >>> > >>> oh > >>> > >>> -- > >>> O. Hartmann > > > -- O. Hartmann
Re: NFSv4 crash of CURRENT
Am Mon, 15 Jan 2024 11:53:31 +0100 Peter Blok schrieb: > Hi, > > Forgot to mention I’m on 13-stable. The fix that is causing the crash with > automounted NFS > is: > > commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b > Author: Konstantin Belousov > Date: Tue Jan 2 00:22:44 2024 +0200 > > nfsclient: limit situations when we do unlocked read-ahead by nfsiod > > (cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e) > > When I remove the fix, the problem is gone. Add it back and the crash happens. > > Peter > > > On 15 Jan 2024, at 09:31, Peter Blok wrote: > > > > Hi, > > > > I do have a crash on a NFS client with stable of today > > (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. > > Maybe it is the > > same problem. > > > > I have ports automounted on /am/ports. When I do cd /am/ports/sys and type > > tab to > > autocomplete it crashes with the below stack trace. If I plainly mount > > ports on /usr/ports > > and do the same everything works. I am using NFSv3 > > > > Peter > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 2; apic id = 04 > > fault virtual address = 0x89 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x809645d4 > > stack pointer = 0x28:0xfe00acadb830 > > frame pointer = 0x28:0xfe00acadb830 > > 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 = 6869 (csh) > > trap number = 12 > > panic: page fault > > cpuid = 2 > > time = 1705306940 > > KDB: stack backtrace: > > #0 0x806232f5 at kdb_backtrace+0x65 > > #1 0x805d7a02 at vpanic+0x152 > > #2 0x805d78a3 at panic+0x43 > > #3 0x809d58ad at trap_fatal+0x38d > > #4 0x809d58ff at trap_pfault+0x4f > > #5 0x809af048 at calltrap+0x8 > > #6 0x804c7a7e at ncl_bioread+0xb7e > > #7 0x804b9d90 at nfs_readdir+0x1f0 > > #8 0x8069c61a at vop_sigdefer+0x2a > > #9 0x809f8ae0 at VOP_READDIR_APV+0x20 > > #10 0x81ce75de at autofs_readdir+0x2ce > > #11 0x809f8ae0 at VOP_READDIR_APV+0x20 > > #12 0x806c3002 at kern_getdirentries+0x222 > > #13 0x806c33a9 at sys_getdirentries+0x29 > > #14 0x809d6180 at amd64_syscall+0x110 > > #15 0x809af95b at fast_syscall_common+0xf8 > > > > > > > >> On 15 Jan 2024, at 06:46, FreeBSD User >> <mailto:free...@walstatt-de.de>> wrote: > >> > >> Am Sun, 14 Jan 2024 20:34:12 -0800 > >> Cy Schubert mailto:cy.schub...@cschubert.com>> > >> schrieb: > >> > >>> In message > >>> >>> <mailto:CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.c> > >>> > >>> om> > >>> , Rick Macklem writes: > >>>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop > >>>> >>>> <mailto:ronald-li...@klop.ws>>= wrote: > >>>>> > >>>>> > >>>>> Van: FreeBSD User >>>>> <mailto:free...@walstatt-de.de>> > >>>>> Datum: 13 januari 2024 19:34 > >>>>> Aan: FreeBSD CURRENT >>>>> <mailto:freebsd-current@freebsd.org>> > >>>>> Onderwerp: NFSv4 crash of CURRENT > >>>>> > >>>>> Hello, > >>>>> > >>>>> running CURRENT client (FreeBSD 15.0-CURRENT #4 > >>>>> main-n267556-69748e62e82a= > >>>> : Sat Jan 13 18:08:32 > >>>>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned > >>>>> cl= > >>>> ient, other is FreeBSD > >>>>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. > >>>>> > >>>>> I can crash the client reproducable by accessing the one or other NFSv4 > >>>>> F= > >>>> S (a simple ls -la). > >>>>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla > >>>>> a= > >>>> ccess to the client > >>>>> host, luckily the box recovers. > >>>> Did you rebuild both the nfscommon and nfscl modules from the same > >>>> sources? > >>>> I did a commit to main that changes the interface between these two > >>>> modules and did bump the > >>>> __FreeBSD_version to 1500010, which should cause both to be rebuilt. > >>>> (If you have "options NFSCL" in your kernel config, both should have > >>>> been rebuilt as a part of > >>>> the kernel build.) > >>>> > >>> > >>> Is anyone by chance seeing autofs in the backtrace too? > >>> > >>> > >> > >> Hello Cy Shubert, > >> > >> I forgot to mention that those crashes occur with autofs mounted > >> filesystems. Good > >> question, by the way, I will check whether crashes also happen when > >> mounting the > >> tradidional way. > >> > >> Kind regards, > >> > >> oh > >> > >> -- > >> O. Hartmann > > > good catch! -- O. Hartmann
Re: NFSv4 crash of CURRENT
Am Sun, 14 Jan 2024 20:34:12 -0800 Cy Schubert schrieb: > In message om> > , Rick Macklem writes: > > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop = > > wrote: > > > > > > > > > Van: FreeBSD User > > > Datum: 13 januari 2024 19:34 > > > Aan: FreeBSD CURRENT > > > Onderwerp: NFSv4 crash of CURRENT > > > > > > Hello, > > > > > > running CURRENT client (FreeBSD 15.0-CURRENT #4 > > > main-n267556-69748e62e82a= > > : Sat Jan 13 18:08:32 > > > CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned > > > cl= > > ient, other is FreeBSD > > > 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized. > > > > > > I can crash the client reproducable by accessing the one or other NFSv4 > > > F= > > S (a simple ls -la). > > > The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla > > > a= > > ccess to the client > > > host, luckily the box recovers. > > Did you rebuild both the nfscommon and nfscl modules from the same sources? > > I did a commit to main that changes the interface between these two > > modules and did bump the > > __FreeBSD_version to 1500010, which should cause both to be rebuilt. > > (If you have "options NFSCL" in your kernel config, both should have > > been rebuilt as a part of > > the kernel build.) > > > > Is anyone by chance seeing autofs in the backtrace too? > > Hello Cy Shubert, I forgot to mention that those crashes occur with autofs mounted filesystems. Good question, by the way, I will check whether crashes also happen when mounting the tradidional way. Kind regards, oh -- O. Hartmann
Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET) Felix Reichenberger schrieb: > > Hello, > > > > I've got a problem with recent CURRENT, running vnet JAILs. > > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET > > 2024 amd64 > > > > Main Host has IPFW configured and is open for services like OpenLDAP on > > UDP/TCP and ICMP > > (ipfw is configured via rc.conf in this case, host is listening on both > > protocol families > > IPv4 and IPv6). > > > > The host itself has openldap-server 2.6 as a service. The host's interface > > is igb0 with > > assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces > > via a bridge > > with the same physical device as the host (igb0). After a while (the time > > elapsed is > > unspecific) the jail is unable to contact the host via IPv6: neither UDP, > > TCP nor ICMP > > sent from the JAIL is reaching the host. IPv4 is working like a charme! No > > problems there. > > > > When pinging the Jail from the main host via ping -6, the jail is > > responding! After the > > first ping -6, the jail now is able to ping -6 the main host. > > > > After a fresh reboot, the problem is not present and occurs after a while > > and it seems to > > happen first to very active jails. > > > > Kind regards, > > > > oh > > > > > > -- > > O. Hartmann > > > > Hello, > > This behavior might be caused by IPFW blocking some IPv6 neighbor > discovery/advertisement > messages. > After some time, the link layer addresses of the IPv6 neighbors in the NDP > cache may expire, > making the associated IPv6 addresses inaccessible. > Do your IPFW rules allow ICMPv6 messages to and from IPv6 multicast addresses? > > Regards. > Thank you for responding. Thank you for his valuable hint! The jail(s) itself/themselfes as well as the host use the regular ipfw rc setup script as provided with the base system, adding simply those ports open which provide services - a plain and simple approach. Checking the jails on the host in question (jails are contacting OpenLDAP server on host, OpenLDAP server configured for test purposes to listen only on IPv6) leaves me with inconclusive results. Assuming a jail, called host-git, and a host, master. Deleting the NDP entries aon hostgit via "ndp -c" leaves me with the initial reported issue here, the solution is to ping the host-git first from host-master to "magically open" the IPv6 connection. After that, ldapsearch or any other IPv6 connections originating on the host-git work again. That seems odd. jails are vnet. Jails reside on a bridgeXX interface, sharing the physical NIC of the master host. Just for the record. I use a similar setup on a XigmaNAS host (13.2-RELEASE-p8), also with active IPFW on the master host's side as well as IPFW enabled on the Jail's side. Difference to the above mentioned setup: The jail is located on a different host, contacting master-host via a switched network. Regards, oh -- O. Hartmann
Re: NFSv4 crash of CURRENT
Am Sat, 13 Jan 2024 19:41:30 -0800 Rick Macklem schrieb: > On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote: > > > > > > Van: FreeBSD User > > Datum: 13 januari 2024 19:34 > > Aan: FreeBSD CURRENT > > Onderwerp: NFSv4 crash of CURRENT > > > > Hello, > > > > running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: > > Sat Jan 13 > > 18:08:32 CET 2024 amd64). One NFSv4 server is same OS revision as the > > mentioned client, > > other is FreeBSD 13.2-RELEASE-p8. Both offer NFSv4 filesystems, > > non-kerberized. > > > > I can crash the client reproducable by accessing the one or other NFSv4 FS > > (a simple ls > > -la). The NFSv4 FS is backed by ZFS (if this matters). I do not have > > physicla access to > > the client host, luckily the box recovers. > Did you rebuild both the nfscommon and nfscl modules from the same sources? Yes, as requested, as soon as the commit occured. I recompiled the whole OS from a "make -j4 cleanworld cleandir" . But I have a custom kernel with several custom options statically compiled in. > I did a commit to main that changes the interface between these two > modules and did bump the > __FreeBSD_version to 1500010, which should cause both to be rebuilt. > (If you have "options NFSCL" in your kernel config, both should have > been rebuilt as a part of > the kernel build.) Monday I will try to compile in several debug options whe I get hands on the machine again and I can test Tuesday on several other boxes running CURRENT (after update) how they interact with themselfes (CURRENT) and other (FBSD14, FBSD13) via NFSv4. > > rick > > > > I have no idea what causes this problem ... > > > > Kind regards, > > > > O. Hartmann > > > > > > -- > > O. Hartmann > > > > > > > > > > > > Do you have something like a panic message, stack trace or core dump? > > > > Regards > > Ronald > -- O. Hartmann
IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)
Hello, I've got a problem with recent CURRENT, running vnet JAILs. FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024 amd64 Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP and ICMP (ipfw is configured via rc.conf in this case, host is listening on both protocol families IPv4 and IPv6). The host itself has openldap-server 2.6 as a service. The host's interface is igb0 with assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces via a bridge with the same physical device as the host (igb0). After a while (the time elapsed is unspecific) the jail is unable to contact the host via IPv6: neither UDP, TCP nor ICMP sent from the JAIL is reaching the host. IPv4 is working like a charme! No problems there. When pinging the Jail from the main host via ping -6, the jail is responding! After the first ping -6, the jail now is able to ping -6 the main host. After a fresh reboot, the problem is not present and occurs after a while and it seems to happen first to very active jails. Kind regards, oh -- O. Hartmann
Re: uSB: uslcom: CP2102 weirdness when serial communication via cu/tip/cutecom
Am Thu, 23 Nov 2023 20:37:26 +0100 FreeBSD User schrieb: > Hello, > > I'm facing some strange behaviour when connecting to a CP2102 USB-UART bridge > built-in into > a I2C-USB device (I2C is handled by an Amtel88, USB-UART is handled by an > CP2102, see here: > > https://de.elv.com/pc-usb-i2c-interface-200958 > > for an sketch/overview. The device is recognised as > > uslcom0 on uhub6 > uslcom0: on usbus0 > > for more details via usbconfig see below. > > Using FreeBSD CURRENT and 14-STABLE (both most recent) connecting to the > device via > > cu -l /dev/cuaUX -s 115200 > > results in most cases in a stuck connection. The LED of the device is > responding to every > keystroke made in the terminal, but I never see any output (which should). > In some rare cases disconneting and reconnecting the USB link and connecting > via "cu" gives > the opportunity for a couple of seconds to enter "?" in the terminal which > provides some > firmware data on the device - then the communications goes dark. This > behaviour is erratic > and non predictable. > > I tried several platforms (hardware), all USB 3, tried FreeBSD 14-STABLE and > CURRENT. On a > notebook (Lenovo T560) running 14-STABLE the very same situation, but trying > the Lenovo with > Xubuntu 23.10 gives me a working "cu" and I'm able reading environmental data > from the > device. > > Using the methusalem USB 2 port of a computer were available gives me a few > seconds more on > FreeBSD, before the serial connection goes mute. > > In cases were possible I tried the same hardware with FreeBSD and Linux > Xubuntu, FreeBSD > fails, Xubuntu prevails the task. At this point I was quite sure that > FreeBSD's uslcom-driver > might be the culprit. > > Out of couriosity I tried a FSBD-13.2RELENG image for AARCH64 (PINE64 I have > at hand) and > connected the same way, the same device acts as normal as I see under Linux > Xubuntu. I'm able > to take environmental data as long as I please without a problem so far. > > Can someone hint me how to debug such a situation? I'm unwilling to use Linux > since our > infrastructure is based on FreeBSD and ... well, no further explanation on > that subject ;-) > > Thanks in advance, > > O. Hartmann Forgot this one: [...] usbconfig -d 0.7 dump_all_desc ugen0.7: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x10c4 idProduct = 0xea60 bcdDevice = 0x0100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x bmAttributes = 0x0080 bMaxPower = 0x00fa Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x0002 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0040 bInterval = 0x bRefresh = 0x bSynchAddress = 0x -- O. Hartmann
epair/vbridge: no IPv6 traffic egress until first IPv6 packet flows in
Hello, at first: observation is below, marked [OBSERVATION]. Running recent CURRENT (FreeBSD 15.0-CURRENT #26 main-n265831-3523f0677ef: Mon Oct 9 14:00:42 CEST 2023 amd64), I've configured a bridge (bridge0), the hosts's interface igb0 (I350-T2 two port Gigabit Network Connection ) is member of that bridge and so a couple of epair(4) devices belonging to a couple of jails. IP filter is ipfw, each jail does have profile "WORKSTATION" configured and enabled, so the host itself. On those hosts I use the standard rc facility. Additionally, following MIB knobs are set to the following values: net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 and net.link.ether.inet.allow_multicast: 0 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.garp_rexmit_count: 0 net.link.ether.inet.max_log_per_second: 1 net.link.ether.inet.maxhold: 16 net.link.ether.inet.wait: 20 net.link.ether.inet.proxyall: 0 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.arp.log_level: 6 net.link.ether.ipfw: 0 On epairs as well as on the main hosts igb0 NIC, both IPv4 and IPv6 are configured, IPv6 uses ULA and setup doesn't has anything fancy. Pinging and connecting to hosts "outside" the box of the host in question (all FreeBSD CURRENT/14-STABLE) is possible without ANY(!) restriction or something nonregular. [OBSERVATION] JAILs can ping any(!) IPv4 host in the net, the main-jail-bearing-host (main-host) itself or any host on the configured bridge() (important: jail -> main-host). JAILs can ping IPv6 any host on the bridge() or in the net or in the internet, BUT NOT the main-host (igb0-owner). NO IPv6 related service FROM jail TOWARD main-host is possible, it is all blocked (and I do not know what blocks or how ...). Disbaling IPFW via "ipfw disable firewall" on all jails and main-host doesn't have any effect in this state. BUT: if the main-host IPv6 pings a jail on that bridge (packet flowing into (the) jail/ingress from jail's perspective), the jail itself suddenly is then able to ping or do network traffic in IPv6! Other jails remain dead that way for IPv6 until I ping them. I haven't or I'm unable to check(ed) why ipv6-icmp is mysteriously "opening" the connection. SSH'ing via IPv6/TCPv6 from the main-host into a jail (tcp/22) works also perfectly and works as the "openener" - a stuck ping -6 towards the main-host then immediately starts flowing. I remember that such a similar problem occured somewhere around FreeBSD 10/11 and the problem vanished somehow in the vain of development/patching. Even disabling IPFW on all entities or switching to profile "open" doesn't help. Some services, like LDAP, nslcd do not work from jails if the jail remains in the initial state. That troubles me. Pinging via IPv6 icmp the jail seems to loosen all restraints, LDAP works, ping works, everything on IPv6 is normal as expected. But the JAIL has to be pinged from the outside first! As stated, I'm out of ideas here and what troubles me most is the fact even LDAP doesn't work until the jail is pinged via icmp6 first time.After this "init", everything is normal. IPv4 seems to be unharmed ... Thanks for your patience and reading, Kind regards oh -- O. Hartmann
Re: CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives?
Am Fri, 30 Jun 2023 16:45:52 +0200 Pierre Pronchery schrieb: My apology for the delay. Shortly after the post here and several patches the problem vanished into thin air - alos by using tigervnc as the client and not, as proposed on the FreeBSD Wiki page, xfreerdp. Thank you very much for helping! Regards oh > Hi everyone, > > I believe I understand where the issue loading OpenSSL's > legacy provider comes from (for MD4 support) and I am currently working > on a fix here: > https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0-providers > > Basically the OpenSSL provider module for legacy algorithms is not built > correctly, since the switch to OpenSSL 3.0.9 in base. The same goes with > the FIPS module, where finding an elegant solution is more difficult > than for the legacy one, but I'm getting there. > > Anyway, I will keep updating this branch until it's ready for a pull-up > request, very likely with force-pushes in order to polish the commits > before submission. > > Let me know how it goes! > > Cheers, > -- Pierre > > On 6/29/23 23:56, Dustin Marquess wrote: > > On Jun 29, 2023 at 11:36 AM -0500, FreeBSD User > > , wrote: > > > > Am Thu, 29 Jun 2023 16:41:51 +0200 > > Guido Falsi schrieb: > > > > On 29/06/23 16:35, FreeBSD User wrote: > > > > Hello, > > > > running a recent CURRENT, 14.0-CURRENT #10 > > main-n263871-fd774e065c5d: Thu Jun 29 05:26:55 > > CEST 2023 amd64, xfreerdp (net/freerdp) doesn't working > > anymore on Windows 10 guest in > > bhyve. It seems OpenSSL 3 is the culprit (see the error > > message from xfreerdp below). I > > opened already a PR (see: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a > > very quick response I was informed that recent FreeRDP > > doesn't support OpenSSL 3 yes > > (https://github.com/FreeRDP/FreeRDP/pull/8920). > > > > Checking for HowTo's setting up bhyve guests, I dodn't > > realise any setting for > > alternatives to RDP. As I do not fully understand how bhyve > > passes through its guest's > > framebuffer device/ or native GUI, I'm a bit helpless in > > searching for another solution to > > contact the Windows10 guest from the X11 desktop of the hosts. > > > > Trying remmina turns out to be a fail, because in our > > installation libsoup2 and libsoup3 > > are installed both and remmina complains about having both > > symbols, also I realised > > remmina seems to utilize net/freerdb as the RDP backend. > > > > Since I have no clue how to install "blindly" a VNCserver > > within the Windows10 guest, I > > presume VNC is not an option in any way. > > > > Is there any way to access the bhyve guest's native > > graphical interface? As in the PR shown > > above already documented (setup taken from the FreeBSD > > Wiki/bhyve), a framebuffer is > > already configured. > > > > It would be nice if someone could give a hint. > > > > > > I had the same issue, with Windows 10 pro hosts, but the fault is in > > windows, which, by default, tries to negotiate an ancient > > protocol (NTLM > > using RC4 if I understand correctly). > > > > With modern windows RDP servers there are better protocols > > available, > > you can get them in remmina by forcing "TLS protocolo security" > > in the > > advanced tab, security protocol negotiation (second row). > > > > Doing this (after some experimentation with various options) > > solved the > > issue for me. > > > > > > Thank you very much for the quick response. > > > > net/remmina is not an option on most of my workstations, since some > > required ports install > > libsoup3, and remmina complains about having found libsoup2 symbols > > as well as libsoup3 > > symbols when starting up - and quits. > > > > Since remmina utilises net/freerdp, I was wondering if I could > > enforce TLS security by any > > kind of a switch, and trying the following > > > >
Re: CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives?
Am Thu, 29 Jun 2023 16:41:51 +0200 Guido Falsi schrieb: > On 29/06/23 16:35, FreeBSD User wrote: > > Hello, > > > > running a recent CURRENT, 14.0-CURRENT #10 main-n263871-fd774e065c5d: Thu > > Jun 29 05:26:55 > > CEST 2023 amd64, xfreerdp (net/freerdp) doesn't working anymore on Windows > > 10 guest in > > bhyve. It seems OpenSSL 3 is the culprit (see the error message from > > xfreerdp below). I > > opened already a PR (see: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a > > very quick response I was informed that recent FreeRDP doesn't support > > OpenSSL 3 yes > > (https://github.com/FreeRDP/FreeRDP/pull/8920). > > > > Checking for HowTo's setting up bhyve guests, I dodn't realise any setting > > for > > alternatives to RDP. As I do not fully understand how bhyve passes through > > its guest's > > framebuffer device/ or native GUI, I'm a bit helpless in searching for > > another solution to > > contact the Windows10 guest from the X11 desktop of the hosts. > > > > Trying remmina turns out to be a fail, because in our installation libsoup2 > > and libsoup3 > > are installed both and remmina complains about having both symbols, also I > > realised > > remmina seems to utilize net/freerdb as the RDP backend. > > > > Since I have no clue how to install "blindly" a VNCserver within the > > Windows10 guest, I > > presume VNC is not an option in any way. > > > > Is there any way to access the bhyve guest's native graphical interface? As > > in the PR shown > > above already documented (setup taken from the FreeBSD Wiki/bhyve), a > > framebuffer is > > already configured. > > > > It would be nice if someone could give a hint. > > > > I had the same issue, with Windows 10 pro hosts, but the fault is in > windows, which, by default, tries to negotiate an ancient protocol (NTLM > using RC4 if I understand correctly). > > With modern windows RDP servers there are better protocols available, > you can get them in remmina by forcing "TLS protocolo security" in the > advanced tab, security protocol negotiation (second row). > > Doing this (after some experimentation with various options) solved the > issue for me. > Thank you very much for the quick response. net/remmina is not an option on most of my workstations, since some required ports install libsoup3, and remmina complains about having found libsoup2 symbols as well as libsoup3 symbols when starting up - and quits. Since remmina utilises net/freerdp, I was wondering if I could enforce TLS security by any kind of a switch, and trying the following xfreerdp /v:192.168.0.128:5900 /u:ohartmann /sec:tls resulting in [...] [17:58:18:972] [1702:bb812700] [WARN][com.winpr.utils.ssl] - OpenSSL LEGACY provider failed to load, no md4 support available! [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:12800067:DSO support routines::could not load the shared library [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:12800067:DSO support routines::could not load the shared library [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read returned an error: error:07880025:common libcrypto routines::reason(524325) [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 35: Resource temporarily unavailable [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] - freerdp_post_connect failed My setup is bhyve -c 4 -m 4G -w -H \ -s 0,hostbridge \ -s 3,ahci-hd,/pool/home/ohartmann/bhyve/win10/disk_win10.img \ -s 5,virtio-net,tap0 \ -s 29,fbuf,tcp=0.0.0.0:5900,w=1920,h=1200,vga=io \ -s 30,xhci,tablet \ -s 31,lpc \ -l com1,stdio \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ win10 and this is a working image setup a couple of weeks ago when VBox has been defective on CURRENT - should say: it worked once. I can not interpret the error above. bhyve is novel to me and I have to admit that I make some capital mistakes here - but can't find satisfying doucumentation ... Kind reagrds, Oliver -- O. Hartmann
CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives?
Hello, running a recent CURRENT, 14.0-CURRENT #10 main-n263871-fd774e065c5d: Thu Jun 29 05:26:55 CEST 2023 amd64, xfreerdp (net/freerdp) doesn't working anymore on Windows 10 guest in bhyve. It seems OpenSSL 3 is the culprit (see the error message from xfreerdp below). I opened already a PR (see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a very quick response I was informed that recent FreeRDP doesn't support OpenSSL 3 yes (https://github.com/FreeRDP/FreeRDP/pull/8920). Checking for HowTo's setting up bhyve guests, I dodn't realise any setting for alternatives to RDP. As I do not fully understand how bhyve passes through its guest's framebuffer device/ or native GUI, I'm a bit helpless in searching for another solution to contact the Windows10 guest from the X11 desktop of the hosts. Trying remmina turns out to be a fail, because in our installation libsoup2 and libsoup3 are installed both and remmina complains about having both symbols, also I realised remmina seems to utilize net/freerdb as the RDP backend. Since I have no clue how to install "blindly" a VNCserver within the Windows10 guest, I presume VNC is not an option in any way. Is there any way to access the bhyve guest's native graphical interface? As in the PR shown above already documented (setup taken from the FreeBSD Wiki/bhyve), a framebuffer is already configured. It would be nice if someone could give a hint. Thanks in advance, oh -- O. Hartmann
Re: WITH_BEARSSL: -8112 bytes available
Am Wed, 31 May 2023 12:15:12 -0600
Warner Losh schrieb:
Sorry for the late response.
> On Mon, May 29, 2023 at 2:59 AM FreeBSD User wrote:
>
> > Hello,
> >
> > on CURRENT, enabling in /etc/src.conf
> >
> > WITH_BEARSSL=
> >
> > seems to result in a slightly enlarged loader binary, which seems to have
> > a fixed size
> > supposed on the error I get. See below.
> >
> > The system is amd64 (64 bit), for the record.
> >
> > Somewhere in the past developers mentioned this upcoming problem and
> > provided a knob to adjust
> > the used size - I forgot about that knob and I couldn't find it even in
> > the loader docs - or
> > looked at the wrong places.
> >
> > Can someone help me out here?
> >
> > The first error stops compileing world/kernel, but taking a second run,
> > the error goes away.
> >
> > Kind regards and thanks in advance,
> >
> > oh
> >
> >
> >
> > [...]
> > --- all_subdir_stand/efi ---
> > SOURCE_DATE_EPOCH=1451606400 objcopy -j .peheader -j .text -j .sdata -j
> > .data -j .dynamic -j
> > .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame -j
> > set_Xcommand_set -j
> > set_Xficl_compile_set --output-target=efi-app-x86_64 loader_4th.sym
> > loader_4th.efi ---
> > all_subdir_stand/i386 ---
> >
> > -8112 bytes available 7.71 real12.86 user 3.08 sys
>
>
> bummer. I hate it when it's that close.
>
> You can try setting LOADERSIZE=56 in your environment. We currently set
> the maximum to 550,000
I tried to find find anything related to LOADER or SIZE in the docs. I remember
you mentioned
the existence of that variable months ago, but with no clue what to look after,
it is almost
impossible yo figure out as a non developer what the right knob might be.
A grep -r on /usr/src shows up only in
[...]
./stand/i386/loader/Makefile:LOADERSIZE?= 55 # Largest known
safe size for
loader.bin
./stand/i386/loader/Makefile: @set -- `ls -l ${.TARGET}` ;
x=$$((${LOADERSIZE}-$$5)); \
[...]
There is no sign/trace of it in any man page related to loader and sibblings. I
found the
variable rather quickly after knowing what to look after.
> bytes because that's the most conservative number due to variation in the
> available BIOS space available.
> This likely can be set even higher if you don't have add-in cards that are
> consuming space in the lower 640k
> of memory. 640k is the absolute limit, but you need 20-30k of stack for the
> loader so pushing this much past
> 625,000 or maybe 630,000 increases the risk of run-time crashes as the
> stack smashes through the top of
> the loader program. You may also have to disable the lua build, since it
> uses more stack and is just a smidge
> larger than the forth build. _simp will be the smallest of them all. On my
> system, without bearssl, I see:
> -r-xr-xr-x 3 root wheel 503808 May 22 15:25 /boot/loader_lua
> -r-xr-xr-x 1 root wheel 446464 May 22 15:25 /boot/loader_4th
> -r-xr-xr-x 1 root wheel 385024 May 22 15:25 /boot/loader_simp
In my case, with supposedly blewn up loader size by BEARSSL enables, it is:
-r-xr-xr-x 1 root wheel - 503808 3 Juni 12:33 /boot/loader_4th*
-r-xr-xr-x 1 root wheel - 643584 3 Juni 12:33 /boot/loader_4th.efi*
-r-xr-xr-x 1 root wheel - 503808 3 Juni 07:45 /boot/loader_4th.old*
-r-xr-xr-x 3 root wheel - 569344 3 Juni 12:33 /boot/loader_lua*
-r-xr-xr-x 2 root wheel - 737280 3 Juni 12:33 /boot/loader_lua.efi*
-r-xr-xr-x 1 root wheel - 569344 3 Juni 07:45 /boot/loader_lua.old*
-r-xr-xr-x 1 root wheel - 446464 3 Juni 12:33 /boot/loader_simp*
-r-xr-xr-x 1 root wheel - 589312 3 Juni 12:33 /boot/loader_simp.efi*
-r-xr-xr-x 1 root wheel - 446464 3 Juni 07:45 /boot/loader_simp.old*
on FreeBSD 14.0-CURRENT #58 main-n263387-556b43492297: Fri Jun 2 20:19:55 CEST
2023 amd64.
> which suggests a ~60k bump for adding forth and ~115k bump for lua. So the
> 560,000 may need to be 625,000
> which is living life on the edge for 4th, and simply too big for lua.
>
> I'd be open to adding docs on this, since I don't think this option is
> currently documented since I added it
> to experiment around with a good value.
See above, personally I'd like to see some hints on that variable, even if I do
not fiddle
around with it.
>
> And no, I really do not want to support 'loadable modules'. BIOS booting is
> on the way out, and people
> that want to do complex stuff in the boot loader will simply have to do
> that in UEFI or maybe kboot/LinuxBoot.
> There's low RoI on adding this complexity, imho. We'd be better off, imho,
> making things like the graphics
> console optional since the fonts and code fo
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Am Sat, 15 Apr 2023 07:36:25 -0700 Cy Schubert schrieb: > In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>, > FreeBSD Us > er writes: > > Am Thu, 13 Apr 2023 22:18:04 -0700 > > Mark Millard schrieb: > > > > > On Apr 13, 2023, at 21:44, Charlie Li wrote: > > > > > > > Mark Millard wrote: > > > >> FYI: in my original report for a context that has never had > > > >> block_cloning enabled, I reported BOTH missing files and > > > >> file content corruption in the poudriere-devel bulk build > > > >> testing. This predates: > > > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch > > > >> but had the changes from: > > > >> https://github.com/openzfs/zfs/pull/14739/files > > > >> The files were missing from packages installed to be used > > > >> during a port's build. No other types of examples of missing > > > >> files happened. (But only 11 ports failed.) > > > > I also don't have block_cloning enabled. "Missing files" prior to > > > > brt_rev > > ert may actually > > > > be present, but as the corruption also messes with the file(1) > > > > signature, > > some tools like > > > > ldconfig report them as missing. > > > > > > For reference, the specific messages that were not explicit > > > null-byte complaints were (some shown with a little context): > > > > > > > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - not found > > > ===> Installing existing package /packages/All/libxml2-2.10.3_1.pkg > > > [CA72_ZFS] Installing libxml2-2.10.3_1... > > > [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - found > > > (/usr/local/lib/libxml2.so) . . . > > > [CA72_ZFS] Extracting libxslt-1.1.37: .. done > > > ===> py39-lxml-4.9.2 depends on shared library: libxslt.so - found > > > (/usr/local/lib/libxslt.so) ===> Returning to build of py39-lxml-4.9.2 > > > . . . > > > ===> Configuring for py39-lxml-4.9.2 > > > Building lxml version 4.9.2. > > > Building with Cython 0.29.33. > > > Error: Please make sure the libxml2 and libxslt development packages are > > > in > > stalled. > > > > > > > > > [CA72_ZFS] Extracting libunistring-1.1: .. done > > > ===> libidn2-2.3.4 depends on shared library: libunistring.so - not > > > found > > > > > > > > > > > [CA72_ZFS] Extracting gmp-6.2.1: .. done > > > ===> mpfr-4.2.0,1 depends on shared library: libgmp.so - not found > > > > > > > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > > ===> Installing existing package /packages/All/gmp-6.2.1.pkg > > > [CA72_ZFS] Installing gmp-6.2.1... > > > the most recent version of gmp-6.2.1 is already installed > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > > > *** Error code 1 > > > > > > > > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 > > > > > > > > > checking for GNU > > > M4 that supports accurate traces... configure: error: no acceptable m4 > > > coul > > d be found in > > > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. > > > GNU M4 1.4.15 uses a buggy replacement strstr on some systems. > > > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. > > > > > > > > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > > > > > > > > === > > > Mark Millard > > > marklmi at yahoo.com > > > > > > > > > > Hello > > > > whar is the recent status of fixing/mitigate this desatrous bug? Especially > > f > > or those with the > > new option enabled on ZFS pools. Any advice? > > > > In an act of precausion (or call it panic) I shutdown several servers to > > prev > > ent irreversible > > damages to databases and data storages. We face on one host with /usr/ports > > r > > esiding on ZFS > > always errors on the same files created while staging (using portmaster, > > leav > > es the system > > with noninstalled software, i.e. www/apache24 in our case). Deleting the > > work > > folder doesn't > > seem to change anything, even when starting a scrubbing of the entire pool > > (R > > AIDZ1 pool) - > > cause unknown, why it affects always the same files to be corrupted. Same > > wit > > h deve/ruby-gems. > > > > Poudriere has been shutdown for the time being to avoid further issues. > > > > Are there any advies to proceed apart from conserving the boxes via > > shutdown? > > > > Thank you ;-) > > oh > > > > > > > > -- > > O. Hartmann > > With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded > blocks. #14739" patch I didn't have any issues, except for email messages > with corruption in my sent directory, nowhere else. I'm still investigating > the email messages issue. IMO one is generally safe to run poudriere on the > latest ZFS with the additional patch. > > My tests of the additional patch concluded that it resolved my last
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Am Thu, 13 Apr 2023 22:18:04 -0700 Mark Millard schrieb: > On Apr 13, 2023, at 21:44, Charlie Li wrote: > > > Mark Millard wrote: > >> FYI: in my original report for a context that has never had > >> block_cloning enabled, I reported BOTH missing files and > >> file content corruption in the poudriere-devel bulk build > >> testing. This predates: > >> https://people.freebsd.org/~pjd/patches/brt_revert.patch > >> but had the changes from: > >> https://github.com/openzfs/zfs/pull/14739/files > >> The files were missing from packages installed to be used > >> during a port's build. No other types of examples of missing > >> files happened. (But only 11 ports failed.) > > I also don't have block_cloning enabled. "Missing files" prior to > > brt_revert may actually > > be present, but as the corruption also messes with the file(1) signature, > > some tools like > > ldconfig report them as missing. > > For reference, the specific messages that were not explicit > null-byte complaints were (some shown with a little context): > > > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - not found > ===> Installing existing package /packages/All/libxml2-2.10.3_1.pkg > [CA72_ZFS] Installing libxml2-2.10.3_1... > [CA72_ZFS] Extracting libxml2-2.10.3_1: .. done > ===> py39-lxml-4.9.2 depends on shared library: libxml2.so - found > (/usr/local/lib/libxml2.so) . . . > [CA72_ZFS] Extracting libxslt-1.1.37: .. done > ===> py39-lxml-4.9.2 depends on shared library: libxslt.so - found > (/usr/local/lib/libxslt.so) ===> Returning to build of py39-lxml-4.9.2 > . . . > ===> Configuring for py39-lxml-4.9.2 > Building lxml version 4.9.2. > Building with Cython 0.29.33. > Error: Please make sure the libxml2 and libxslt development packages are > installed. > > > [CA72_ZFS] Extracting libunistring-1.1: .. done > ===> libidn2-2.3.4 depends on shared library: libunistring.so - not found > > > [CA72_ZFS] Extracting gmp-6.2.1: .. done > ===> mpfr-4.2.0,1 depends on shared library: libgmp.so - not found > > > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > ===> Installing existing package /packages/All/gmp-6.2.1.pkg > [CA72_ZFS] Installing gmp-6.2.1... > the most recent version of gmp-6.2.1 is already installed > ===> nettle-3.8.1 depends on shared library: libgmp.so - not found > *** Error code 1 > > > autom4te: error: need GNU m4 1.4 or later: /usr/local/bin/gm4 > > > checking for GNU > M4 that supports accurate traces... configure: error: no acceptable m4 could > be found in > $PATH. GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended. > GNU M4 1.4.15 uses a buggy replacement strstr on some systems. > Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug. > > > ld: error: /usr/local/lib/libblkid.a: unknown file type > > > === > Mark Millard > marklmi at yahoo.com > > Hello whar is the recent status of fixing/mitigate this desatrous bug? Especially for those with the new option enabled on ZFS pools. Any advice? In an act of precausion (or call it panic) I shutdown several servers to prevent irreversible damages to databases and data storages. We face on one host with /usr/ports residing on ZFS always errors on the same files created while staging (using portmaster, leaves the system with noninstalled software, i.e. www/apache24 in our case). Deleting the work folder doesn't seem to change anything, even when starting a scrubbing of the entire pool (RAIDZ1 pool) - cause unknown, why it affects always the same files to be corrupted. Same with deve/ruby-gems. Poudriere has been shutdown for the time being to avoid further issues. Are there any advies to proceed apart from conserving the boxes via shutdown? Thank you ;-) oh -- O. Hartmann
Re: CURRENT: Panic VERIFY(!zil_replaying(zilog, tx)) failed (and crashing)
Am Sun, 9 Apr 2023 14:37:03 +0200 Mateusz Guzik schrieb: > On 4/9/23, FreeBSD User wrote: > > Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: > > Sun Apr 9 > > 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via > > > > zpool upgrade POOLNAME > > > > some boxes keep crashing when starting compiler runs (the trigger is > > different on boxes). > > > > ZFS module is statically compiled into the kernel (if this is of > > importance) > > > > Last known good was: > > > > [...] > > Apr 9 07:10:04 <0.2> thor kernel: FreeBSD 14.0-CURRENT #7 > > main-n262051-75379ea2e461: Sun Apr > > 9 00:12:57 CEST 2023 Apr 9 07:10:04 <0.2> thor kernel: > > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR amd64 Apr 9 07:10:04 <0.2> > > thor kernel: > > FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git > > llvmorg-15.0.7-0-g8dfdcc7b7bf6) Apr 9 07:10:04 <0.2> thor kernel: > > VT(efifb): resolution > > 2560x1440 Apr 9 07:10:04 <0.2> thor kernel: module zfsctrl already > > present! > > [...] > > > > The file /var/crash/info.X > > > > contains: > > > > [...] > > > > root@thor:/var/crash # more info.2 > > Dump header from device: /dev/gpt/swap > > Architecture: amd64 > > Architecture Version: 2 > > Dump Length: 1095192576 > > Blocksize: 512 > > Compression: none > > Dumptime: 2023-04-09 11:43:41 + > > Hostname: thor.local > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b: Sun Apr > > 9 12:01:02 CEST > > 2023 > > root@thor:/usr/obj/usr/src/amd64.amd64/sys/THOR > > Panic String: VERIFY(!zil_replaying(zilog, tx)) failed > > > > Dump Parity: 2961465682 > > Bounds: 2 > > Dump Status: good > > > > Until reconfigured for more debug stuff I do not have more to present. > > > > I rememeber now really scraed that there was a HEADSUP in the list regarding > > some serious ZFS > > problems - I didn't find it right now. > > > > Thanks in advance, > > > > That's fallout from the new block cloning feature, adding the author > Thanks. As of this moment, all systems with the newest kernel and the new ZFS option enabled, crash - the reason is mostly in different ZFS datasets. I guess there is no way back once this faulty option is enabled? Regards, oh -- O. Hartmann
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Am Thu, 30 Mar 2023 17:27:31 +0200 Dag-Erling Smørgrav schrieb: > FreeBSD User writes: > > I tried to put the option > > > > WITHOUT_MODULE="an" > > it's spelled WITHOUT_MODULES, cf. make.conf(5). > > DES Correct, and so I use it ... ;-) [...] # BUILD and INSTALL! # Options to put in make.conf during both build- & installworld. # See man src.conf(5) for more details on WITHOUT_ tags. CONF_WORLD=' WITHOUT_MODULES="an" WITHOUT_AMD=YES WITHOUT_APM=YES WITHOUT_ASSERT_DEBUG=YES WITHOUT_AT=YES WITHOUT_BHYVE=YES WITHOUT_BLUETOOTH=YES WITHOUT_BOOTPARAMD=YES WITHOUT_BOOTPD=YES WITHOUT_CALENDAR=YES WITHOUT_CCD=YES WITHOUT_CDDL=YES WITHOUT_CTM=YES WITHOUT_DEBUG_FILES=YES WITHOUT_DICT=YES WITHOUT_DIALOG=YES WITHOUT_EXAMPLES=YES WITHOUT_EE=YES WITHOUT_FINGER=YES WITHOUT_FLOPPY=YES WITHOUT_FREEBSD_UPDATE=YES WITHOUT_FDT=YES WITHOUT_GAMES=YES WITHOUT_GCOV=YES WITHOUT_GOOGLETEST=YES WITHOUT_HAST=YES WITHOUT_HTML=YES WITHOUT_HYPERV=YES WITHOUT_INETD=YES WITHOUT_IPFILTER=YES [...] -- O. Hartmann
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Am Thu, 30 Mar 2023 15:53:19 +0200 Mateusz Guzik schrieb: > On 3/30/23, FreeBSD User wrote: > > Hello folks, > > > > some strange misbehaviour in a NanoBSD compilation is driving me nuts. > > Recently I posted some > > error messages regarding > > > > [...] > > src/sys/dev/an/if_an_pci.c:143:1: error: a > > function definition without a prototype is deprecated in all versions of C > > and is not > > supported in C2x [-Werror,-Wdeprecated-non-prototype] > > [...] > > > > but being able compiling the kernel was "a lucky shot/mistake" and in the > > vain of discussion > > it has been revealed that my nanoBSD specific "make.conf/src.conf" > > configurations were wrong. > > > > So, again: > > > > The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2 > > main-n261876-f5a365e51fee: Thu > > Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE (git > > pull on a > > daily/hourly/most recentl basis when trying to build). > > > > As I understand the src/buildworld config, it seems crucial to have CURRENT > > and 13-STABLE > > somehow separated due to their divergende in used LLVM/CLANG (CURRENT has > > LLVM 15, 13-STABLE > > is with LLVM 14). > > > > Putting > > > > WITHOUT_SYSTEM_COMPILER=YES > > WITHOUT_SYSTEM_LINKER=YES > > > > into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent the > > usage of > > CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 > > compiler and linker > > should be used to buildworld. > > > > But this doesn't seem to happen (at least in my case), since buildworld > > fails to build with: > > > > [...] > > cc -target x86_64-unknown-freebsd13.2 > > --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp > > -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin > > -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat > > -DBUILD_TYPE=A > > -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET > > -DBC_DEFAULT_TTY_MODE > > -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH > > -DBC_ENABLE_LIBRARY=0 > > -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT > > -DBC_ENABLE_RAND > > -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 > > -DDC_ENABLED -DNDEBUG > > -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include > > -DBC_ENABLE_NLS=1 > > -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero > > -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang > > -std=gnu99 > > -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall > > -Wno-format-y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Wreturn-type > > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > > -Wcast-align > > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign > > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > > -Wno-string-plus-int > > -Wno-unused-const-variable -Wno-error=unused-but-set-variable > > -Qunused-arguments -Wl,-zrelro > > -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o > > dc.o dc_lex.o > > dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o > > program.o rand.o read.o > > vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit ld: error: args.o: > > Opaque pointers are > > only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: > > 'LLVM 14.0.5') cc: > > error: linker command failed with exit code 1 (use -v to see invocation) *** > > [gh-bc] Error > > code 1 > > > > make[5]: stopped in > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc > > [...] > > > > > > I'm now out of options here :-( > > > > are you even using the dev/an driver? No, it is commented out in the kernel config file. That error occurs when using the CURRENT system's compiler building the nanoBSD binaries. > > you should probably just remove it from the kernel (and any other > driver of the sort) I tried to put the option WITHOUT_MODULE="an" into the nanoBSD sections building world/installing world as initially describe
Re: NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Am Thu, 30 Mar 2023 16:56:09 +0200 Mateusz Guzik schrieb: > On 3/30/23, Mateusz Guzik wrote: > > On 3/30/23, FreeBSD User wrote: > >> Hello folks, > >> > >> some strange misbehaviour in a NanoBSD compilation is driving me nuts. > >> Recently I posted some > >> error messages regarding > >> > >> [...] > >> src/sys/dev/an/if_an_pci.c:143:1: error: a > >> function definition without a prototype is deprecated in all versions of > >> C > >> and is not > >> supported in C2x [-Werror,-Wdeprecated-non-prototype] > >> [...] > >> > >> but being able compiling the kernel was "a lucky shot/mistake" and in the > >> vain of discussion > >> it has been revealed that my nanoBSD specific "make.conf/src.conf" > >> configurations were wrong. > >> > >> So, again: > >> > >> The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2 > >> main-n261876-f5a365e51fee: Thu > >> Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE > >> (git > >> pull on a > >> daily/hourly/most recentl basis when trying to build). > >> > >> As I understand the src/buildworld config, it seems crucial to have > >> CURRENT > >> and 13-STABLE > >> somehow separated due to their divergende in used LLVM/CLANG (CURRENT has > >> LLVM 15, 13-STABLE > >> is with LLVM 14). > >> > >> Putting > >> > >> WITHOUT_SYSTEM_COMPILER=YES > >> WITHOUT_SYSTEM_LINKER=YES > >> > >> into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent > >> the > >> usage of > >> CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 > >> compiler and linker > >> should be used to buildworld. > >> > >> But this doesn't seem to happen (at least in my case), since buildworld > >> fails to build with: > >> > >> [...] > >> cc -target x86_64-unknown-freebsd13.2 > >> --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp > >> -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin > >> -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat > >> -DBUILD_TYPE=A > >> -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET > >> -DBC_DEFAULT_TTY_MODE > >> -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH > >> -DBC_ENABLE_LIBRARY=0 > >> -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT > >> -DBC_ENABLE_RAND > >> -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 > >> -DDC_ENABLED -DNDEBUG > >> -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include > >> -DBC_ENABLE_NLS=1 > >> -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero > >> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang > >> -std=gnu99 > >> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall > >> -Wno-format-y2k -W > >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > >> -Wpointer-arith -Wreturn-type > >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > >> -Wcast-align > >> -Wchar-subscripts -Wnested-externs -Wold-style-definition > >> -Wno-pointer-sign > >> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > >> -Wno-string-plus-int > >> -Wno-unused-const-variable -Wno-error=unused-but-set-variable > >> -Qunused-arguments -Wl,-zrelro > >> -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o > >> dc.o dc_lex.o > >> dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o > >> program.o rand.o read.o > >> vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit ld: error: > >> args.o: > >> Opaque pointers are > >> only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: > >> 'LLVM 14.0.5') cc: > >> error: linker command failed with exit code 1 (use -v to see invocation) > >> *** > >> [gh-bc] Error > >> code 1 > >> > >> make[5]: stopped in > >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc > >> [...] &
NanoBSD: CURRENT unable to compile 13-STABLE : ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5')
Hello folks, some strange misbehaviour in a NanoBSD compilation is driving me nuts. Recently I posted some error messages regarding [...] src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] [...] but being able compiling the kernel was "a lucky shot/mistake" and in the vain of discussion it has been revealed that my nanoBSD specific "make.conf/src.conf" configurations were wrong. So, again: The builder host is a recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n261876-f5a365e51fee: Thu Mar 30 11:23:19 CEST 2023 amd64), the target is a most recent 13-STABLE (git pull on a daily/hourly/most recentl basis when trying to build). As I understand the src/buildworld config, it seems crucial to have CURRENT and 13-STABLE somehow separated due to their divergende in used LLVM/CLANG (CURRENT has LLVM 15, 13-STABLE is with LLVM 14). Putting WITHOUT_SYSTEM_COMPILER=YES WITHOUT_SYSTEM_LINKER=YES into CONF_BUILD= AND CONF_WORLD= of NanoBSD configuration should prevent the usage of CURRENT's LLVM 15 and instead a cross compiling with 13-STABLE's LLVM 14 compiler and linker should be used to buildworld. But this doesn't seem to happen (at least in my case), since buildworld fails to build with: [...] cc -target x86_64-unknown-freebsd13.2 --sysroot=/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp -B/pool/home/ohartmann/Projects/router/router/apu2c4/world/obj/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat -DBUILD_TYPE=A -DBC_DEFAULT_BANNER=0 -DBC_DEFAULT_PROMPT=0 -DBC_DEFAULT_SIGINT_RESET -DBC_DEFAULT_TTY_MODE -DBC_ENABLED -DBC_ENABLE_EDITLINE -DBC_ENABLE_EXTRA_MATH -DBC_ENABLE_LIBRARY=0 -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_HISTORY -DBC_ENABLE_PROMPT -DBC_ENABLE_RAND -DDC_DEFAULT_PROMPT=0 -DDC_DEFAULT_SIGINT_RESET -DDC_DEFAULT_TTY_MODE=0 -DDC_ENABLED -DNDEBUG -I/pool/home/ohartmann/Projects/router/router/apu2c4/src/contrib/bc/include -DBC_ENABLE_NLS=1 -flto -DNDEBUG -fPIE -mretpoline -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -Wl,-zrelro -pie -Wl,-zretpolineplt -o gh-bc args.o bc.o bc_lex.o bc_parse.o data.o dc.o dc_lex.o dc_parse.o file.o history.o lang.o lex.o main.o num.o opt.o parse.o program.o rand.o read.o vector.o vm.o bc_help.o dc_help.o lib.o lib2.o -ledit ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.7' Reader: 'LLVM 14.0.5') cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [gh-bc] Error code 1 make[5]: stopped in /pool/home/ohartmann/Projects/router/router/apu2c4/src/usr.bin/gh-bc [...] I'm now out of options here :-( Thanks in advance, Oliver -- O. Hartmann
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Wed, 8 Mar 2023 12:13:49 +0100
tue...@freebsd.org schrieb:
> > On 8. Mar 2023, at 11:42, FreeBSD User wrote:
> >
> > Am Wed, 8 Mar 2023 11:28:11 +0100
> > Dimitry Andric schrieb:
> >
> >> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> >> ...
> >>> But I don't understand why the make environment is trying to compile a
> >>> piece of code that
> >>> is disabled via "nodevice" as shown in my initial report herein:
> >>>
> >>> [...]
> >>> src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a
> >>> prototype is
> >>> deprecated in all versions of C and is not supported in C2x
> >>> [-Werror,-Wdeprecated-non-prototype]
> >>> [...]
> >>
> >> The "nodevice" is for your custom kernel configuration, but as far as I
> >> can see an(4) is still built as a module, see sys/modules/Makefile:
> >>
> >> ...
> >> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> >> _agp= agp
> >> _an=an
> >>
> >> -Dimitry
> >>
> >
> > Oh, I'm sorry,
> > my fault in logic!
> >
> > Is there a "knob" to explicitely disable that specific module from being
> > built from a
> > point of view of a user like me (not touching the base build system)?
> Use
> WITHOUT_MODULES=an
> in
> /etc/make.conf
>
> Best regards
> Michael
> >
> > --
> > O. Hartmann
>
>
With setting
WITHOUT_SYSTEM_COMPILER=YES
WITHOUT_SYSTEM_LINKER=YES
in CONF_BUILD and CONF_WORLD and WITHOUT_CROSS_COMPILER=YES commented out (not
building/not
cross compile?) and a fresh and clean start of the build, I run into
[...]
ld: error: args.o: Opaque pointers are only supported in -opaque-pointers mode
(Producer:
'LLVM15.0.7' Reader: 'LLVM 14.0.5') cc: error: linker command failed with exit
code 1 (use -v
to see invocation) *** [gh-bc] Error code 1
[...]
That seems to be the issue mostly discussed herein regarding LLVM14 and LLVM15.
Having set
WITHOUT_CROSS_COMPILER=YES
WITHOUT_SYSTEM_COMPILER=YES
WITHOUT_SYSTEM_LINKER=YES
WITHOUT_MODULES=an
in both CONF_BUILD and CONF_WORLD (I do so because I do not know which one is
really affecting
the build), I receive the reported compiling error problem in if_an.c.
Setting WITHOUT_MODULES=an in both CONF_BUILD and CONF_WORLD (nanoBSD!) doesn't
seem to have
any effect.
Regardfs,
oh
--
O. Hartmann
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Wed, 8 Mar 2023 11:28:11 +0100
Dimitry Andric schrieb:
> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> ...
> > But I don't understand why the make environment is trying to compile a
> > piece of code that
> > is disabled via "nodevice" as shown in my initial report herein:
> >
> > [...]
> > src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a
> > prototype is
> > deprecated in all versions of C and is not supported in C2x
> > [-Werror,-Wdeprecated-non-prototype]
> > [...]
>
> The "nodevice" is for your custom kernel configuration, but as far as I
> can see an(4) is still built as a module, see sys/modules/Makefile:
>
> ...
> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> _agp= agp
> _an=an
>
> -Dimitry
>
Oh, I'm sorry,
my fault in logic!
Is there a "knob" to explicitely disable that specific module from being built
from a point of
view of a user like me (not touching the base build system)?
--
O. Hartmann
pgpoewHqtwo_9.pgp
Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Thu, 2 Mar 2023 11:13:51 +0100 Dimitry Andric schrieb: > On 2 Mar 2023, at 06:41, FreeBSD User wrote: > > > > Am Mon, 27 Feb 2023 23:46:21 +0100 > > Dimitry Andric schrieb: > ... > > > > I tried to find some documentation on my CURRENT host regarding > > "WITH_SYSTEM_COMPILER". > > None found via man src.conf, nor via make make.conf. Please delegate me to > > some place > > where I can find such infos. > > Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it > means that you want to skip building the bootstrap compiler, and just > use the host compiler. The src.conf(5) man page documents the inverse > settings instead: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently > installed compiler matches the planned bootstrap compiler type > and revision, then it will not be built. This does not prevent a > compiler from being built for installation though, only for > building one for the build itself. The WITHOUT_CLANG option > controls that. > > WITHOUT_SYSTEM_LINKER > Do not opportunistically skip building a cross-linker during the > bootstrap phase of the build. Normally, if the currently > installed linker matches the planned bootstrap linker type and > revision, then it will not be built. This does not prevent a > linker from being built for installation though, only for > building one for the build itself. The WITHOUT_LLD option > controls that. > > This option is only relevant when WITH_LLD_BOOTSTRAP is set. > > I find the double negative phrasing "do not skip" always confusing. But > the logic is normally: > > * The early phase of buildworld retrieves the versions of your host's > compiler and linker > * It compares it against the versions in the source tree > * If the host compiler and linker are deemed "good enough", they are > used as-is > * If the host compiler or linker are not suitable, the compiler or > linker are bootstrapped from the source tree > > But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use > the host compiler, which might or might not work, depending on the > circumstances. You may have to use NO_WERROR or other tricks. > > > ... > >> The safest solution is to let cross-tools do its thing, which will check > >> the host compiler, and automatically build an appropriate version of the > >> compiler and linker for the stable branch, if required. > > > > I had a misunderstanding in the terminus "cross compiling", I check now the > > build with this > > option set to be enabled. > > Yes, this is a bit confusing, but in fact it *can* be a real cross > compiler, if you are targeting another architecture, for example doing > "make buildworld TARGET=arm64" from an x86_64 host. > > And of course if you are building natively, it is 'just' a regular > bootstrap compiler. > > -Dimitry > As it turns out, I already used in both sections CONF_BUILD= CONF_WORLD= of nanoBSD's configuration WITHOUT_SYSTEM_COMPILER and added also WITHOUT_SYSTEM_LINKER to be safe. But I don't understand why the make environment is trying to compile a piece of code that is disabled via "nodevice" as shown in my initial report herein: [...] src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] [...] From my point of view neither compiler suite, LLVM14 or LLVM15, should have picked up the if_an driver so far. Or do I miss something here? If so, my apologys. Kind regards Oliver -- O. Hartmann pgpqQrUscz3_U.pgp Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Thu, 2 Mar 2023 11:13:51 +0100 Dimitry Andric schrieb: > On 2 Mar 2023, at 06:41, FreeBSD User wrote: > > > > Am Mon, 27 Feb 2023 23:46:21 +0100 > > Dimitry Andric schrieb: > ... > > > > I tried to find some documentation on my CURRENT host regarding > > "WITH_SYSTEM_COMPILER". > > None found via man src.conf, nor via make make.conf. Please delegate me to > > some place > > where I can find such infos. > > Ah I was confused, WITH_SYSTEM_COMPILER is actually the default, and it > means that you want to skip building the bootstrap compiler, and just > use the host compiler. The src.conf(5) man page documents the inverse > settings instead: > > WITHOUT_SYSTEM_COMPILER > Do not opportunistically skip building a cross-compiler during > the bootstrap phase of the build. Normally, if the currently > installed compiler matches the planned bootstrap compiler type > and revision, then it will not be built. This does not prevent a > compiler from being built for installation though, only for > building one for the build itself. The WITHOUT_CLANG option > controls that. > > WITHOUT_SYSTEM_LINKER > Do not opportunistically skip building a cross-linker during the > bootstrap phase of the build. Normally, if the currently > installed linker matches the planned bootstrap linker type and > revision, then it will not be built. This does not prevent a > linker from being built for installation though, only for > building one for the build itself. The WITHOUT_LLD option > controls that. > > This option is only relevant when WITH_LLD_BOOTSTRAP is set. > > I find the double negative phrasing "do not skip" always confusing. But > the logic is normally: > > * The early phase of buildworld retrieves the versions of your host's > compiler and linker > * It compares it against the versions in the source tree > * If the host compiler and linker are deemed "good enough", they are > used as-is > * If the host compiler or linker are not suitable, the compiler or > linker are bootstrapped from the source tree > > But WITH_SYSTEM_COMPILER turns off all these checks and forces it to use > the host compiler, which might or might not work, depending on the > circumstances. You may have to use NO_WERROR or other tricks. Thank you for the explanation. I read the man page of src.conf in a haste solving my problem and did not spend much time in reading carefully. I'd appreciate to see YOUR explanation in the official man page, or at least a more non-logical-twisted version. ;-) oh > > > ... > >> The safest solution is to let cross-tools do its thing, which will check > >> the host compiler, and automatically build an appropriate version of the > >> compiler and linker for the stable branch, if required. > > > > I had a misunderstanding in the terminus "cross compiling", I check now the > > build with this > > option set to be enabled. > > Yes, this is a bit confusing, but in fact it *can* be a real cross > compiler, if you are targeting another architecture, for example doing > "make buildworld TARGET=arm64" from an x86_64 host. > > And of course if you are building natively, it is 'just' a regular > bootstrap compiler. > > -Dimitry > -- O. Hartmann pgpo5n59s79UP.pgp Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Mon, 27 Feb 2023 23:46:21 +0100
Dimitry Andric schrieb:
> On 27 Feb 2023, at 22:23, Paul Mather wrote:
> >
> > On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote:
> >
> >> On 27 Feb 2023, at 19:19, FreeBSD User wrote:
> >>>
> >>> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23
> >>> main-n261147-b8bb73ab724b: Sun
> >>> Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git
> >>> stable/13).
> >>>
> >>> Building an appliance based on 13-STABLE sources, a customized kernel via
> >>> nanoBSD, since
> >>> a couple of weeks for now building the sources fails in kernel sources:
> >>>
> >>> [...]
> >>> --- modules-all ---
> >>> --- all_subdir_an ---
> >>> /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1:
> >>> error: a function definition without a prototype is deprecated in all
> >>> versions of C and
> >>> is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> >>> [..]
> >>>
> >>> Disabling all wireless options in the kernel config starts dropping
> >>> errors of a similar
> >>> kind on other kernel places.
> >>>
> >>> Compiling on FBSD 13-STABLE seems to be all right.
> >>>
> >>> Can this be fixed. please? What causes the error and how can this be
> >>> resolved if the
> >>> subtree of FreeBSD's sources is a submodule?
> >>
> >> Not sure what you mean with "subtree is a submodule", but this is likely
> >> caused by skipping the cross-tools stage somehow. Do you have any
> >> specific make.conf or src.conf settings for that?
> >
> >
> > I got bitten by this recently. In my case, it was Poudriere (running on
> > 14-CURRENT)
> > trying to build a 13-STABLE jail. The Poudriere jail's "src.conf" was
> > taken from the
> > actual system for which Poudriere builds packages. It had (amongst others)
> > these two
> > options:
> >
> > WITH_SYSTEM_COMPILER=yes
> > WITHOUT_CROSS_COMPILER=yes
> >
> >
> > When I commented these out in the jail-src.conf Poudriere file the jail
> > built correctly.
> >
> > I figure the system built fine because its system compiler is LLVM 14.x.
> > The Poudriere
> > system compiler is LLVM 15.x, which has the breaking change wrt. old-style
> > prototypes.
Hello,
I tried to find some documentation on my CURRENT host regarding
"WITH_SYSTEM_COMPILER". None
found via man src.conf, nor via make make.conf. Please delegate me to some
place where I can
find such infos.
>
> Yes, that is what I suspected in Oliver's case: if you skip the
> cross-tools stage in a buildworld of stable/13 on a 14-CURRENT host, by
> setting WITH_SYSTEM_COMPILER, you are bound to run into compilation
> errors that have been fixed in 14-CURRENT, but not yet MFC'd.
From nanoBSD's perspective, all relevant build config files are merged into a
huge file
containing three elementary sections,
CONF_BUILD
CONF_INSTALL
CONF_WORLD
in neither of them I had defined "WITH_SYSTEM_COMPILER=YES" in any way, but I
had configured
in both CONF_INSTALL and CONF_WORLD "WITHOUT_CROSS_COMPILER=YES". I deleted
that knob for now
from "CONF_WORLD" and left it in CONF_INSTALL ("... Options to put in make.conf
during
installworld only ...").
>
> The safest solution is to let cross-tools do its thing, which will check
> the host compiler, and automatically build an appropriate version of the
> compiler and linker for the stable branch, if required.
I had a misunderstanding in the terminus "cross compiling", I check now the
build with this
option set to be enabled.
>
> That said, I will be merging clang 15.0.7 and a bunch of other things
> that should solve all these errors to stable/13 at some point, but not
> before the 13.2-RELEASE is out. This is to avoid making life more
> difficult for our release engineering team.
>
> -Dimitry
>
Thank you for the efforts,
Oliver
--
O. Hartmann
pgpw_vAxYhaNd.pgp
Description: OpenPGP digital signature
Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C
Am Mon, 27 Feb 2023 20:57:19 +0100 Dimitry Andric schrieb: > On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > > main-n261147-b8bb73ab724b: Sun > > Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git > > stable/13). > > > > Building an appliance based on 13-STABLE sources, a customized kernel via > > nanoBSD, since a > > couple of weeks for now building the sources fails in kernel sources: > > > > [...] > > --- modules-all --- > > --- all_subdir_an --- > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_pci.c:143:1: > > error: a function definition without a prototype is deprecated in all > > versions of C and is > > not supported in C2x [-Werror,-Wdeprecated-non-prototype] > > [..] > > > > Disabling all wireless options in the kernel config starts dropping errors > > of a similar > > kind on other kernel places. > > > > Compiling on FBSD 13-STABLE seems to be all right. > > > > Can this be fixed. please? What causes the error and how can this be > > resolved if the > > subtree of FreeBSD's sources is a submodule? > > Not sure what you mean with "subtree is a submodule", but this is likely > caused by skipping the cross-tools stage somehow. Do you have any > specific make.conf or src.conf settings for that? > > -Dimitry > Using a subtree "./src" withing the tree of our own repository for FreeBSD's sources, it is a git submodule. According to your question about specific src.conf and make.conf - Sometimes I really do not know what NanoBSD or any cross compiling tool is picking up which one: the host's one or the one supposed to control NanoBSD's build. So, the host itself does have a specific /etc/src.conf, make.conf is only about some ports options to apply for the host. For the NanoBSD sources, it is considered one file, a merger of make.conf, src.conf, and yes, those ones or in that case this one is highly customized due to spefici requirements for space reduction. Since that has been in the past a source of evil, I tried also with a "vanilla" setup of this sepcific NanoBSD driven config (the host's src.conf/make.conf has been left untouched) - in other words, deleting it, making a full fledged kernel/base system with all the compiler settings at FreeBSD's default - with the same result as shown above. Can you hint me towards what to look after in specific? Kind regards, Oliver -- O. Hartmann pgpEGWMl2A7GD.pgp Description: OpenPGP digital signature
13-STABLE: crashing on graphical clients (Firefox, Librewolf, GIMP et cetera)
Hallo everybody, a week ago I compiled a new 13-STABLE (FreeBSD 13.2-STABLE #77 stable/13-n254681-44a6088278ea: Sat Feb 25 07:44:36 CET 2023 amd64, custom kernel, same happens with the recent regular GENERIC kernel). ZFS root installation. Graphics driver: drm-510-kmod-5.10.163_2graphics/drm-510-kmod libdrm-2.4.115,1 graphics/libdrm xf86-video-intel-2.99.917.916_3,1 x11-drivers/xf86-video-intel Hardware: Lenovo T560, 16 GB RAM, : [...] CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (2800.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406e3 Family=0x6 Model=0x4e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbf Structured Extended Features3=0xbc002e00 XSAVE Features=0xf IA32_ARCH_CAPS=0xc04 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16462184448 (15699 MB) CPU microcode: no matching update found Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-119 Launching APs: 1 3 2 random: entropy device external interface kbd1 at kbdmux0 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.00s smbios0: at iomem 0xd7064000-0xd706401e smbios0: Version: 2.8, BCD Revision: 2.8 aesni0: acpi0: [...] GPU: [...] drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). [drm] Got stolen memory base 0xda80, size 0x200 drmn0: could not load firmware image 'i915/skl_dmc_ver1_27.bin' drmn0: [drm] Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling runtime power management. drmn0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915lkpi_iic0: on drmn0 iicbus0: on lkpi_iic0 iic0: on iicbus0 lkpi_iic1: on drmn0 iicbus1: on lkpi_iic1 iic1: on iicbus1 lkpi_iic2: on drmn0 iicbus2: on lkpi_iic2 iic2: on iicbus2 sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! lkpi_iic3: on drm1 iicbus3: on lkpi_iic3 iic3: on iicbus3 lkpi_iic4: on drm2 iicbus4: on lkpi_iic4 iic4: on iicbus4 lkpi_iic5: on drm4 iicbus5: on lkpi_iic5 iic5: on iicbus5 [drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0 VT: Replacing driver "efifb" with new "fb". start FB_INFO: type=11 height=1080 width=1920 depth=32 pbase=0xe000 vbase=0xf800e000 name=drmn0 flags=0x0 stride=7680 bpp=32 end FB_INFO [...] Phenomena: - WindowMaker (wmaker) crashes on startup - while using blackbox or twm working, windowmanager starts, but: running any(!) larger X11 client - singleuser mode or console mode without graphics is all right There is NO coredump, nor does the kernel jump into kernel debugging although I tried to configure that. Regards and thanks in advance, oh -- O. Hartmann
Re: CURRENT: Crash in multiuser mode while shutdown
Am Sun, 19 Feb 2023 06:19:04 -0800 Rick Macklem schrieb: > I committed a patch that would cause crashes if > the system was using jails on Feb. 11, but it was > fixed the next day. It bogusly had a prison_cleanup() > method in it. > > But if you kernel wasn't from main on about Feb. 11 > or you aren't running jails, I don't think this is it. Sources are most recent. > > It is too bad you don't have a backtrace? I need the box today, the other one is a poudriere host and can't be interrupted on short notice, I will enable debugging as I finish my work. The I hope I can provide you with a backtrace. cpu-data has been updated recently, I use this on these two IvyBridge methusalem riggs, I may disable this first and see what happens ... Regards oh > > rick > > On Sun, Feb 19, 2023 at 1:38 AM FreeBSD User wrote: > > > > Hello, > > > > most recent CURRENT crashes on shutdown from multiuser mode (singleuser > > mode, used after > > repairing failed FFS filesystems, is all right). The crashes go on since > > roughly a 1/2 week > > from now. The boxes involved are all cumtomized kernels (in most cases hard > > linked modules > > into kernel). Is there a known issue? > > > > Otherwise I have to reconfigure all systems for debugging an d will report > > aftwards more. > > > > > > Regards and thanks in advance > > Oliver > > -- > > O. Hartmann > > -- O. Hartmann
Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW
Am Sun, 19 Feb 2023 13:30:13 +0300 "Andrey V. Elsukov" schrieb: > 18.02.2023 18:42, FreeBSD User пишет: > > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN > > interface. We use NPTv6 to translate ULA addresses for the inner > > IPv6 networks. We use IPv6 privacy on the tun0 interface. The > > router/firewall is operating after a reboot or restart of mpd5 > > correctly, IPv6 and IPv4 networks have conection to the internet. > > When the ISP rotates it IPs, the IPv6 address is configured using > > SLAAC and mpd5 seems to act weird: > > > > - the IPv4 address is always set correct, IPFW and in-kernel NAT > > route/filter traffic correctly - sometimes old IPv6 address is dumped > > and only a new IPv6 address - in such a case, the old IPv6 is gone, > > the new pair (temporary and MACified address are the only IPv6 > > addresses attached to the interface. - sometimes the old IPv6 address > > set (= temporary) are marked "deprecated" and/or "detached" and a new > > set is attached to the interface tun0, in some rare occassion also an > > IPv6 address WITHOUT its "temoprary" sibbling is attached. > > > > In any of the cases above, IPFW's NPTv6 gets confused, routing isn't > > working properly anymore. > > > > In any cases of a change of the IPv6 address, IPFW has to be > > restartet! > > Hi, > > I assume you are using ext_if option in your NPTv6 instance configuration. That is correct. > > I think there might be several problems that lead to your situation: > > 1. NPTv6 tracks IPv6 addresses deletion, but since an old IPv6 address > that was used as external prefix kept on the interface, it ignores > appearance of new IPv6 address. > > 2. Then, even if you delete old IPv6 address by hand, NPTv6 won't try to > peak another one until there won't appear new address. > > 3. There should be some logic that takes into account presence of > temporary and deprecated addresses on the interface. > -- O. Hartmann pgpGnCla7RwGj.pgp Description: OpenPGP digital signature
CURRENT: Crash in multiuser mode while shutdown
Hello, most recent CURRENT crashes on shutdown from multiuser mode (singleuser mode, used after repairing failed FFS filesystems, is all right). The crashes go on since roughly a 1/2 week from now. The boxes involved are all cumtomized kernels (in most cases hard linked modules into kernel). Is there a known issue? Otherwise I have to reconfigure all systems for debugging an d will report aftwards more. Regards and thanks in advance Oliver -- O. Hartmann
IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW
Hello, running a small nanoBSD firewall/router appliance, the WAN interface (tun0) is confugred via SLAAC when it comes to IPv6. The allpliance is running in-kernel compiled IPFW. The OS is FreeBSD 13-STABLE, compiled on a recuurant weekly basis. On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN interface. We use NPTv6 to translate ULA addresses for the inner IPv6 networks. We use IPv6 privacy on the tun0 interface. The router/firewall is operating after a reboot or restart of mpd5 correctly, IPv6 and IPv4 networks have conection to the internet. When the ISP rotates it IPs, the IPv6 address is configured using SLAAC and mpd5 seems to act weird: - the IPv4 address is always set correct, IPFW and in-kernel NAT route/filter traffic correctly - sometimes old IPv6 address is dumped and only a new IPv6 address - in such a case, the old IPv6 is gone, the new pair (temporary and MACified address are the only IPv6 addresses attached to the interface. - sometimes the old IPv6 address set (= temporary) are marked "deprecated" and/or "detached" and a new set is attached to the interface tun0, in some rare occassion also an IPv6 address WITHOUT its "temoprary" sibbling is attached. In any of the cases above, IPFW's NPTv6 gets confused, routing isn't working properly anymore. In any cases of a change of the IPv6 address, IPFW has to be restartet! In cases with marked deprecated and/or detached addresses, IPFW has to be restarted, AND the deprecated and/or detached IPv6 addresses has to be deleted manually. Otherwise - so it seems to me - NPTv6 takes the wrong (outdated) prefix. NPTv6 should not take any deprecated, detached prefix if a valid prefix is available. Even deleting the deprecated IPv6 requires a restart of IPFW. No matter how long I wait, NPTv6 never gets the changed prefix by itself. Kind regards, Oliver -- O. Hartmann
Re: Tooling Integration and Developer Experience
On 1/30/23 13:53, Warner Losh wrote: On Mon, Jan 30, 2023 at 3:40 AM Kurt Jaeger wrote: Hi, On 1/30/23 02:54, Julian H. Stacey wrote: The main idea: to prevent information fragmentation andimprove discoverability, cross-referencing abilities, search, etc. With regards to improving discoverability, Phabricator's Owner tool could be a good tactical move: it allow to bind code area to peoples in order to automatically add them to reviews. If you know phabricator in more detail, is there any kind of tool to understand the activity going on ? In bugs.freebsd.org, there is the dashboard: https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html I think we might need something similar to help us understand the current state of the phabricator instance and the work being done. Phab allows Dashboards, but no-one had the time to configure some queries to provide relevant stats. Phab is a terrible tool for discovery. For example, how do I query all the reviews I've ticked 'OK' that are still open, by non-committers? How do I flag things as 'interesting to me'? I can tick a flag, but I can't query flags. Also, I can't get an email address for submitter either. That makes it more of a pain to land the commit. You can search flags here [1]. You can filter them by color and the object (i.e. differential revision or any other Phab thing). Flags are personal and not visible to anybody else For common use I think tags are better and are queryable in here [2]. Tags require projects, projects can be created by administrators, this is a bit counter-intuitive, but it works But there's two other issues: The FreeBSD project has had a long history of being behind, regardless of the tools we use. There's a labor shortage to process these things as well. Second, lots of people want to talk, but few want to do the work. I tried leading an effort in this area,but grew weary of the passive-aggressive comments about how I basically sucked for not having it done already (from the same people that did 0 actual work on it). I'd love to help and do the grunt work. What is important is some form of consensus that project actually needs this. I don't know how this works, the is very little visibility from the Core on these matters. [1]https://reviews.freebsd.org/flag/ [2] https://reviews.freebsd.org/differential/query/advanced/ -- Ihor Antonov
Re: Tooling Integration and Developer Experience
On 1/30/23 10:08, Kurt Jaeger wrote: Hi! ihor@antonovs.family wrote: This can be as easy as moving everything into Phabricator. There's the issue that Phabricator itself is no longer supported upstream: https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/ https://github.com/phacility/phabricator I have notes from Oct. 2021 which point to a fork: https://we.phorge.it/ That fork seems to be somewhat alive. Moving our phab instance to phorge is probably no trivial task. Should be no harder than regular update. They even have a HOWTO https://we.phorge.it/w/installation_and_setup/update_from_phabricator/ From operational point of view it requires the least amount of effort, comparing to full-scale migration to any other platform. The Phorge seems to be active, so we can ask them to improve query functionality..(I am an optimist) Overall short-term plan could look like this: 1. Upgrade to Phorge 2. Setup Maniphest for bugs and tasks 3. Migrate bugs into Maniphest 4. Enable Harbormaster (Build/CI) - this requires coordination with whoever is working on pre-commit CI. This should improve things quite a bit already. Long term we can add Ponder and Phriction (Wiki and Q) and move current wiki into it too. Infra operations are hard, and I have experience with it. I'd be happy to help. -- Ihor Antonov
Tooling Integration and Developer Experience
On 1/30/23 02:54, Julian H. Stacey wrote: > Jamie Landeg-Jones wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix >> to an admittedly trivial issue, but it's soon going to hit one year old, >> and has not had any feedback. Not even "this is rubbish. close ticket" >> >> | jamie@catwalk:~ % stat 'so good they named it twice' >> | stat: so good they named it twice: stat: No such file or directory >> >> As such, it's the oldest of my patches to be completely ignored, but then, >> most of my fixes I haven't even submitted, because, what's the point? >> I've instead spent time writing something so the patches are automatically >> aplied to my src tree, and distributed to all my servers. Forked from: 1 year src-patch anniversary. I feel Jamie's pain, this kind of experience can be very discouraging to any contributor without commit bit. All developers like quick feedback loops. Nobody wants to wait a year. I think FreeBSD project looses a lot of potential contributors due to issues of this kind. I don't believe there is any ill intent, there is no elite cast of grumpy commit-bit holders who only work on what they are interested in, ignoring the project as a whole. Far from it. But I do hope that the situation can be improved and I want to offer my view and opinion. The Problem --- I do believe that the source of all problems is lack of integration in tooling and communication. Let me elaborate: FreeBSD project has a lot of tools, but the tools are not well integrated together: - There are too many places where a patch can be posted: phabricator, github, bugzilla, mailing list. - There are too many places to have a conversation: mailing lists, phabricator reviews, bugzilla comments, github issues and PRs, forum, multiple IRC channels spanning multiple IRC servers, etc. - A posted patch is cat in the bag, there is no pre-commit CI to do some basic sanity-checking, commit-bit holders need to do a lot of work to verify the commit (run CI on it) - Tools are not integrated. There is no information flow between them, no effective cross-referencing, lookup or discover, etc. - Bugs in Bugzilla are not visible in Phabricator. - Commits in Phabricator do not resolve bugs in Bugzilla - Jenkins CI/CD and Phabricator don't know about each other. ... there are probably more examples, but this is enough to draw a few conclusions: 1. Information is fragmented and is easily lost or forgotten. 2. It takes manual human effort to update information in multiple systems. 3. Human attention (developers, contributors, etc.) to different systems is spread unequally. This leads to poor developer experience, regardless of commit-bit status. A patch posted in bugzilla went unnoticed for a year until frustrated and desperate contributor started complaining about it in the mailing list, and was committed hours later. The is also a lack of designated maintainers (I am drawing the analogy from Linux kernel) A role who's job is to integrate: collect all patches, feedback, reports about a specific area (kernel subsystem, userland tool or whatnot), and update/curate the knowledge and communication around this area. In my 15+ year career in IT I've seen multiple projects fail due to communication and integration issues. Without concentrated effort and strong leadership these problems rarely go away on their own. Proposed Solutions -- In the order of implementation: 1. Tooling integration: This can be as easy as moving everything into Phabricator. Phabricator, apart from features that we already use, has support for CI/CD, bug reports, wiki, project planning and milestones, chat, etc. Alternative platforms can be used as well: GitLab, SourceHut The main idea: to prevent information fragmentation and improve discoverability, cross-referencing abilities, search, etc. The challenge: is inertia and migration of existing information out of currently used tools. The sentiment: we don't need more tools, we need fewer tools that work better together. 2. Growing the community: Integrated tooling improves productivity and allows focusing on quickening the feedback loop: accepting/rejecting/commenting one-off contributions faster. Regular contributors will be more visible and will get commit-bit faster. With enough commit-bit holders focused maintainership practice can be started. In the end this is just my opinion, I hope it will spark some conversation. Thanks for reading this far :) -- Ihor Antonov
Re: Version of OpenSSL included in upcoming 14.0-RELEASE
On 1/28/23 07:34, Yasuhiro Kimura wrote: ... Though I'm not familiar with the incompatibility between OpenSSL 1.1.1 and 3.0, I believe it is too optimistic to regard that build of 14-CURRENT succeeds without any error just by updating /usr/src/crypto/openssl from 1.1.1 to 3.0. So it will take for a while (a few weeks?) to finish it. And it also affects build of ports. To be honest, it is rather my main concern as ports committer. I checked Bugzilla and found following PR. openssl 3 does have some breaking changes that mostly will be visible to ports. Alpine Linux switched to openssl v3 not so long ago, I will see if they posted any kind of summary.. -- Ihor Antonov
Re: local-unbound regression
I discovered that recent unbound update broke my VPN scripts, after some investigation I think I found the problem - default location of the config file was reset to upstream value. My config file is at /var/unbound/unbound.conf (as created by local-unbound-setup) but when I use local-unbound-control I see this error message: # local-unbound-control flush_stats [1673972554] unbound-control[16206:0] error: Could not open /usr/local/etc/unbound/unbound.conf: No such file or directory [1673972554] unbound-control[16206:0] fatal error: could not read config file I have not yet created bugzilla bug https://cgit.freebsd.org/src/commit/?id=1838dec31895fd4752fa8631322ab93be0705a66 /* Pathname to the Unbound configuration file */ -#define CONFIGFILE "/var/unbound/unbound.conf" +#define CONFIGFILE "/usr/local/etc/unbound/unbound.conf" It looks like it was intentional, but then my local-unbound-setup keeps creating configuration in the old destination... And it looks like a POLA violation - I can imagine lot's of users might have configs in /var/unbound -- Ihor Antonov
local-unbound regression
I discovered that recent unbound update broke my VPN scripts, after some investigation I think I found the problem - default location of the config file was reset to upstream value. My config file is at /var/unbound/unbound.conf (as created by local-unbound-setup) but when I use local-unbound-control I see this error message: # local-unbound-control flush_stats [1673972554] unbound-control[16206:0] error: Could not open /usr/local/etc/unbound/unbound.conf: No such file or directory [1673972554] unbound-control[16206:0] fatal error: could not read config file I have not yet created bugzilla bug -- Ihor Antonov
Re: netlink socket does not accept SOCK_DGRAM
On 1/15/23 12:43, Alexander V. Chernikov wrote: The snl(3) manpage itself includes some examples, including the complete working program in the end man snl No manual entry for snl Looks like not connected to the buildworld.. -- Ihor Antonov
Re: netlink socket does not accept SOCK_DGRAM
It’s a bug. The manage should state SOCK_RAW, but both options should be supported, which is not the case ATM. I’ll fix it in a couple of days. Meanwhile it may be worth looking into snl(3) which abstracts issues like this one. Thanks, I will take a look. Is there an example somewhere of snl usage? (my C skills are not very strong)
netlink socket does not accept SOCK_DGRAM
man 4 rtnetlink says:
int socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
The following snippet fails
int fd = socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);
if (fd < 0) {
perror("Failed to open netlink socket");
return -1;
}
printf("all good\n");
close(fd);
return 0;
I get: Failed to open netlink socket: Protocol wrong type for socket
but if I change
int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
I get "all good"
Am I doing something wrong or is this a bug?
$ uname -a FreeBSD zen.hq 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n259967-11b5b9e8a520: Sat Jan 7 16:39:30 UTC 2023
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
$ kldstat | grep netl
391 0x839fc00014af8 netlink.ko
--
Ihor Antonov
mention AF_NETLINK in man 2 socket
Looks like there are no references to {PF|AF}_NETLINK in the socket manpage.
--
Ihor Antonov
CAM: extract HDD informations about failure/to fail?
Hello, well, the aim of my post sounds strange, but I'm serious. Background: I run at home a 14-CURRENT based server with a ZFS volume (RAIDZ) comprised from 4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since one got a permanent SMART error. So all HDDs have been replaced by now with four times Seagte IronWolfe Pro 4TB drives. So far, so good. Now I face a weird sound sourcing at one of the new HDDs. The box is supposed to be a heavy duty poudriere build facility, so the drives are up 24/7. It seems that one (or even more) drives emitt a weird sound like the spindle motor is loosing for a fraction of a second power and spiining up the the drive again. Searching the net reveals that at least one Seagate customer did have the same issue and he provided an audio file of that very weird sound, to be found here: Post at reddit: https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/ and herin the post of the audio file: https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file I checked S.M.A.R.T for any unusual data, but everything is fine. The values for Power_Cycle_Count Power-Off_Retract_Count Start_Stop_Count seem all within a reasonable range compared to the life time in hours (did some simple statistsics ), nothing looks unusual. Also, the advanced view onto each drive via smartctl -x doesn't give me any hint of a power failure as a source for the noise. So, big question here is: the drives are attached to a HBA, LSI3008 based SAS9300-8i. Is it possible to retrieve via CAM more health paramteres than those gathered by SMART/smartmontools and if the answer is yes, how can this be achieved? It close to impossible to isolate the drive making the noise. My guts tell me to RMA the supposed to be faulty drive and not to wait until it dies from "spindle motor desease" or something that is the source for the noises. Thanks in advance, oh -- O. Hartmann
Bug 206165 - resolv.conf(5) is missing documentation on options (i.e. EDNS0)
Hello folks, I ran today into a problem, that the reolveer option "edns0" isn't documented (as well as some others). Searching the net reveals, that there is a PR open with exactly that issue since January 2016, since then, code has changed I presume. Could someone please take care of that issue? "man 5 resolver" does not cover all options one can provide via /etc/resolv.conf, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165 Thank you very much in advance, O. Hartmann -- O. Hartmann
Re: security/clamav: /var/run on TMPFS renders the port broken by design
Am Sun, 28 Aug 2022 06:11:20 -0700 Cy Schubert schrieb: > In message <20220828130107.1a76d54a.gre...@freebsd.org>, Michael Gmelin > writes: > > > > > > > > On Sun, 28 Aug 2022 03:21:24 -0700 > > Cy Schubert wrote: > > > > > In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>, > > > Michael Gmelin w > > > rites: > > > > > > > > > > > > > > > > > On 28. Aug 2022, at 10:42, free...@oldach.net wrote: > > > > >=20 > > > > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 > > > > > (CEST): > > > > >> As stated before in this thread, replacing /var/run with tmpfs > > > > >> is not a supported configuration. > > > > >=20 > > > > > Not supported? What is the purpose of /etc/rc.d/var then? That > > > > > creates a t= > > > > mpfs backed /var, populates it through mtree, and makes a proper > > > > /var/run av= ailable. > > > > >=20 > > > > > However it doesn't (yet) create /var/run/clamav of course. > > > > >=20 > > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that > > > > > walks thro= > > > > ugh /usr/local/etc/mtree/* and runs mtree on each of the files > > > > found as need= ed. All that the security/clamav port would need to > > > > do then is to drop an ap= propriate small mtree file as > > > > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is > > > > the same logic as dropping service scripts as /usr/local/= > > > > etc/rc.d/clamav-*. > > > > > > > > =46rom a user's perspective, it would be preferable to have this > > > > happen at s= ervice start though, as (unlike in the setup > > > > described) reboots don't happen= that frequently, but files in > > > > /var/run might get deleted manually. Maybe so= me rc framework > > > > based solution would make sense, e.g., a variable `mtree_fil= es`, > > > > which, if set, is applied in the default start_precmd. Besides > > > > being mo= re resilient, this would also have the advantage that all > > > > required file syst= ems should be available at that point and the > > > > separation between system and p = orts would be more clear. Another > > > > advantage would be that directories are on= ly created for services > > > > that are actually enabled/started. > > > > > > Unfortunately this requires all ports to include an mtree file. > > > Relying on port maintainers who are human to ensure that these files > > > are created and updated when ports are created and maintained will > > > result in more human error. I've learned over my long career to rely > > > more on automation than human beings. Automation [should] never fail > > > and when it does it does temporarily until the bug is found and > > > fixed. Human beings inconsistently fail. > > > > > > If it were an auto-discovery script that created an mtree file as > > > part of the packaging process, it would be another matter. But this > > > optional solution path should be discussed on ports@, not here. > > > > > > > > > > I don't have much skin in the game, but I created a little proof of > > concept to allow further discussion (which is not ports-specific, as it > > works for all service scripts): > > > > https://reviews.freebsd.org/D36385 > > I've been toying with the idea for a few months but was never bothered to > create a review or even a script for that matter. > > > > > This basically allows both system admins and port maintainers to > > create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's > > always relative to the service script called) which are automatically > > applied on service start. It's non-intrusive and doesn't require any > > sweeping changes to existing ports/services. > > Understood that this is a manual process. > > > > > In this specific case, the requester could create > > /usr/local/etc/mtree/clamav-clamd with the required content (or > > persuade the port maintainer to include that file). > > > > You could of course add some construct to the ports framework that > > picks up certain directories from the package list automatically and > > places them into an mtree file as part of the build or installation > > process. But that would be an additional feature on top of this change. > > Someone could. Personally, I think that's a lot of work compared to simply > saving the state of /var/run at shutdown and restoring it at boot. I can't > speak for the ports management though. > > > > > This is meant to inspire more discussions, I'm not trying to force > > anything in. ;) > > Agreed. > > I cobbled something up yesterday that saves the directory tree state of > /var/run prior to shutdown (or manually) and restores it at boot. > > https://reviews.freebsd.org/D36386 > > People can try it out if they want. If there's enough interest I'd be > willing to commit it. > > We have a few options on the table and probably more. The ports > infrastructure option is probably the most work. Adding functionality to > all the ports that use /var/run is also a lot of
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
Am Sat, 27 Aug 2022 13:16:43 +0200 tue...@freebsd.org schrieb: > > On 27. Aug 2022, at 08:30, FreeBSD User wrote: > > > > Hello, > > > > I'm referencing to Bug 259699 [2] and Bug 259585 [1]. > > > > Port security/clamav is without doubt for many of FreeBSD users an > > important piece of > > security software so I assume a widespread usage. > > > > It is also a not uncommon use case to use NanoBSD or any kind of > > low-memory-footprint > > installation schemes in which /var/run - amongst other system folders - are > > created at boot > > time as TMPFS and highly volatile. > > > > In our case, the boxes running a small security appliance based upon > > FreeBSD is rebooted > > every 24 hours and so /var/run is vanishing. > Why are you rebooting every 24 hours? The appliance has to be on a non-writable medium and is to be rebooted every 24 hours to cleanse temporary memory. This is given in the specs and by the department(s) the appliance is for. Kind regards > > Best regards > Michael > > > > To make the long story short: > > > > The solution for this problem would be a check for existence and take > > action addendum in > > precmd() routine of the rc-script as sketched in Bug 259699. > > The maintainer rejects such a workaround by arguing this would violate POLA > > (see comment 4 > > in PR 259699 [2]. The maintainer's argument regaring to mtree's files are > > sound to me. > > > > The question is: how can this issue be solved? > > > > It is really hard to always chenge our local repository and patch whenever > > clamav has been > > patched and modified for what reason ever. > > > > Tahanks for reading, > > > > kind regards > > > > O. Hartmann > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585 > > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699 > > > > > > -- > > O. Hartmann > > > > -- O. Hartmann
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
Am Sat, 27 Aug 2022 11:21:40 +0200 Michael Gmelin schrieb: > > On 27. Aug 2022, at 08:31, FreeBSD User wrote: > > > > Hello, > > > > I'm referencing to Bug 259699 [2] and Bug 259585 [1]. > > > > Port security/clamav is without doubt for many of FreeBSD users an > > important piece of > > security software so I assume a widespread usage. > > > > It is also a not uncommon use case to use NanoBSD or any kind of > > low-memory-footprint > > installation schemes in which /var/run - amongst other system folders - are > > created at boot > > time as TMPFS and highly volatile. > > > > In our case, the boxes running a small security appliance based upon > > FreeBSD is rebooted > > every 24 hours and so /var/run is vanishing. > > > > To make the long story short: > > > > The solution for this problem would be a check for existence and take > > action addendum in > > precmd() routine of the rc-script as sketched in Bug 259699. > > The maintainer rejects such a workaround by arguing this would violate POLA > > (see comment 4 > > in PR 259699 [2]. The maintainer's argument regaring to mtree's files are > > sound to me. > > > > The question is: how can this issue be solved? > > > > It is really hard to always chenge our local repository and patch whenever > > clamav has been > > patched and modified for what reason ever. > > > > Tahanks for reading, > > > > Why don’t you simply add an rc script to your appliance that creates the > missing > directory/directories on boot before clamav is started? > > Best > Michael > > > Why not fixing this on a more general basis? Best regards, oh -- O. Hartmann
security/clamav: /ar/run on TMPFS renders the port broken by design
Hello, I'm referencing to Bug 259699 [2] and Bug 259585 [1]. Port security/clamav is without doubt for many of FreeBSD users an important piece of security software so I assume a widespread usage. It is also a not uncommon use case to use NanoBSD or any kind of low-memory-footprint installation schemes in which /var/run - amongst other system folders - are created at boot time as TMPFS and highly volatile. In our case, the boxes running a small security appliance based upon FreeBSD is rebooted every 24 hours and so /var/run is vanishing. To make the long story short: The solution for this problem would be a check for existence and take action addendum in precmd() routine of the rc-script as sketched in Bug 259699. The maintainer rejects such a workaround by arguing this would violate POLA (see comment 4 in PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound to me. The question is: how can this issue be solved? It is really hard to always chenge our local repository and patch whenever clamav has been patched and modified for what reason ever. Tahanks for reading, kind regards O. Hartmann [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699 -- O. Hartmann
ZFS: cannot import zroot: I/O error
Hello, I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox 4.1.24/26 (do not know exactly). The host is a special system based on Linux und VirtualBox and I have no chances to configure the VBox. Somehow the VBox crashed and hung up the complete computer, so I had to cold start it after approx. 30 minutes of waiting. After that, rhe virtual drive and its ZFS filesystem was wrecked, shwing a stream of zio_read error: 5 ZFS: i/o error - all block copies unavailable After a quick search I found some advices howto try fixing, last an longest one was zpool import -fFX -N -R /alternate/path zroot which took approx 20 minutes - with no success. There are some valuable data on the partition, which are all backed up, but it would take its time to restore everything, so I'd like to ask whether there is any cance to "repair" the mysterious damage. I'm able to boot off from an USB flash drive ... Kind regards oh -- O. Hartmann
Re: NFSv4: Invalid fstype: Invalid argument
Am Sun, 3 Jul 2022 11:57:33 +0200 FreeBSD User schrieb: Sorry for the noise, the learning process is still in progress and I learned about the until-now-not-fully-understood V4: entry in /etc/exports. Thanks for reading and patience. regards, oh > Hello folks, > > > Trying to mount a NFS filesystem offered by a FreeBSD 12.3-p5 (XigmaNAS) from > a recent > CURRENT (FreeBSD 14.0-CURRENT #19 main-n256512-ef86876b846: Sat Jul 2 > 23:31:53 CEST 2022 > amd64) via > > :/etc # mount -t nfs -o vers=4 192.168.0.11:/mnt/NAS00/home /tmp/mnt > > results in > > mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument > > and checking whether I can mount NFSv3 (I have explicitely set NFSv4 only on > the server side, > see below) via > > :/etc # mount -t nfs -o vers=3,mntudp 192.168.0.11:/mnt/NAS00/home /tmp/mnt > [udp] 192.168.0.11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered > or > :/etc # mount -t nfs -o vers=3,mntudp [fd01:a37::11]:/mnt/NAS00/home /tmp/mnt > [udp6] fd01:a37::11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered > > Womdering about the TCP conenction attempts, I checked the configurations on > both, the > CURRENT and XigmaNAS (server) side. > > [... server side ...] > nas01: ~# ps -waux|grep mountd > root 4332 0.0 0.0 11684 2652 - Is 23:13 0:00.01 > /usr/sbin/mountd -l -r -S > -R /etc/exports /etc/zfs/exports > > rpcinfo -p >program vers proto port service > 104 tcp111 rpcbind > 103 tcp111 rpcbind > 102 tcp111 rpcbind > 104 udp111 rpcbind > 103 udp111 rpcbind > 102 udp111 rpcbind > 104 local111 rpcbind > 103 local111 rpcbind > 102 local111 rpcbind > 1000241 udp671 status > 1000241 tcp671 status > 1000210 udp 1003 nlockmgr > 1000210 tcp603 nlockmgr > 1000211 udp 1003 nlockmgr > 1000211 tcp603 nlockmgr > 1000213 udp 1003 nlockmgr > 1000213 tcp603 nlockmgr > 1000214 udp 1003 nlockmgr > 1000214 tcp603 nlockmgr > > I do not see mountd nor nfsd being registered, hope this is all right within > a NFSv4-only > environment. > > Well, on the CURRENT server that provides without flaws NFSv4 for the CURRENT > client I try to > access the XigmaNAS NFSv4 fs from, rpcinfo looks like: > > (current server): > root@walhall:/usr/src # rpcinfo -p >program vers proto port service > 104 tcp111 rpcbind > 103 tcp111 rpcbind > 102 tcp111 rpcbind > 104 udp111 rpcbind > 103 udp111 rpcbind > 102 udp111 rpcbind > 104 local111 rpcbind > 103 local111 rpcbind > 102 local111 rpcbind > 1000241 udp774 status > 1000241 tcp774 status > 1000210 udp746 nlockmgr > 1000210 tcp661 nlockmgr > 1000211 udp746 nlockmgr > 1000211 tcp661 nlockmgr > 1000213 udp746 nlockmgr > 1000213 tcp661 nlockmgr > 1000214 udp746 nlockmgr > 1000214 tcp661 nlockmgr > > Well, I also checked from client to current server and client to XigmaNAS > server via rpcinfo > -p and I get always the very same result. > > Checking the accessibility of the server host on the net via nmap gives this > result (please > be aware we use a dual stack network and need both IPv6 and IPv4 access so > this attempt shows > IPv4 access, but IPv6 access is also granted and assured): > > UDP: > :/etc # nmap -sU 192.168.0.11 > Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:05 CEST > Nmap scan report for nas01.intern (192.168.0.11) > Host is up (0.00094s latency). > Not shown: 996 closed ports > PORT STATE SERVICE > 111/udp open rpcbind > 514/udp open|filtered syslog > 2049/udp open nfs > 5353/udp open zeroconf > > and TCP (since port 2049/NFSv4 is tcp): > :/etc # nmap -sS 192.168.0.11 > Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:34 CEST > Nmap scan report for nas01.intern (192.168.0.11) > Host is up (0.00074s latency). > Not shown: 996 closed ports > PORT STATE SERVICE > 22/tcp open ssh > 111/tcp open rpcbind > 443/tcp open https > 2049/tcp open nfs > > I'm out of ideas here. What does > > mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid
NFSv4: Invalid fstype: Invalid argument
Hello folks, Trying to mount a NFS filesystem offered by a FreeBSD 12.3-p5 (XigmaNAS) from a recent CURRENT (FreeBSD 14.0-CURRENT #19 main-n256512-ef86876b846: Sat Jul 2 23:31:53 CEST 2022 amd64) via :/etc # mount -t nfs -o vers=4 192.168.0.11:/mnt/NAS00/home /tmp/mnt results in mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument and checking whether I can mount NFSv3 (I have explicitely set NFSv4 only on the server side, see below) via :/etc # mount -t nfs -o vers=3,mntudp 192.168.0.11:/mnt/NAS00/home /tmp/mnt [udp] 192.168.0.11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered or :/etc # mount -t nfs -o vers=3,mntudp [fd01:a37::11]:/mnt/NAS00/home /tmp/mnt [udp6] fd01:a37::11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered Womdering about the TCP conenction attempts, I checked the configurations on both, the CURRENT and XigmaNAS (server) side. [... server side ...] nas01: ~# ps -waux|grep mountd root 4332 0.0 0.0 11684 2652 - Is 23:13 0:00.01 /usr/sbin/mountd -l -r -S -R /etc/exports /etc/zfs/exports rpcinfo -p program vers proto port service 104 tcp111 rpcbind 103 tcp111 rpcbind 102 tcp111 rpcbind 104 udp111 rpcbind 103 udp111 rpcbind 102 udp111 rpcbind 104 local111 rpcbind 103 local111 rpcbind 102 local111 rpcbind 1000241 udp671 status 1000241 tcp671 status 1000210 udp 1003 nlockmgr 1000210 tcp603 nlockmgr 1000211 udp 1003 nlockmgr 1000211 tcp603 nlockmgr 1000213 udp 1003 nlockmgr 1000213 tcp603 nlockmgr 1000214 udp 1003 nlockmgr 1000214 tcp603 nlockmgr I do not see mountd nor nfsd being registered, hope this is all right within a NFSv4-only environment. Well, on the CURRENT server that provides without flaws NFSv4 for the CURRENT client I try to access the XigmaNAS NFSv4 fs from, rpcinfo looks like: (current server): root@walhall:/usr/src # rpcinfo -p program vers proto port service 104 tcp111 rpcbind 103 tcp111 rpcbind 102 tcp111 rpcbind 104 udp111 rpcbind 103 udp111 rpcbind 102 udp111 rpcbind 104 local111 rpcbind 103 local111 rpcbind 102 local111 rpcbind 1000241 udp774 status 1000241 tcp774 status 1000210 udp746 nlockmgr 1000210 tcp661 nlockmgr 1000211 udp746 nlockmgr 1000211 tcp661 nlockmgr 1000213 udp746 nlockmgr 1000213 tcp661 nlockmgr 1000214 udp746 nlockmgr 1000214 tcp661 nlockmgr Well, I also checked from client to current server and client to XigmaNAS server via rpcinfo -p and I get always the very same result. Checking the accessibility of the server host on the net via nmap gives this result (please be aware we use a dual stack network and need both IPv6 and IPv4 access so this attempt shows IPv4 access, but IPv6 access is also granted and assured): UDP: :/etc # nmap -sU 192.168.0.11 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:05 CEST Nmap scan report for nas01.intern (192.168.0.11) Host is up (0.00094s latency). Not shown: 996 closed ports PORT STATE SERVICE 111/udp open rpcbind 514/udp open|filtered syslog 2049/udp open nfs 5353/udp open zeroconf and TCP (since port 2049/NFSv4 is tcp): :/etc # nmap -sS 192.168.0.11 Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:34 CEST Nmap scan report for nas01.intern (192.168.0.11) Host is up (0.00074s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 443/tcp open https 2049/tcp open nfs I'm out of ideas here. What does mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument mean? Is it the server reporting that it doesn't serve the requested fstyp or is there an issue with the local filesystem/mountpoint (located on UFS/FFS, the backend NFS fs are all located on ZFS)? I'm drifting like a dead man in the water here and I did not find aome answeres to the error reported here in the net applicable to the problem seen. Some hints are highly appreciated. Tahnks in advance and kind regards, oh -- O. Hartmann
vnet/if_bridge: ARP issues: connection failure
Hello, the problem I'm about to report is not specific to CURRENT, I report this to CURRENT because I'm list member. The problem occurs on FreeBSD 12.3-RELEASE-p5. Setup: connecting to vnet jails bound to a dedicated NIC via if_bridge results in an erratic behaviour (from my point of view). The box has two NICs, em0 which is dedicated for managing the host and igb0 for services like NFS, SMB and jails (the host is de facto a Xigmanas box). The NIC igb0 also has an IPv4 which is accessible without problem (sshd is listening on em0 and igb0 and any service bound to igb0 and its IP itself works like a charme, execept anything that is connected via if_bridge/vnet). Both, em0 and igb0, are member of the same network and connected to the same switch (I guess, it's the campus infrastructure, I have no access to that). Phenomenon: trying to ping a jail results initially in a long term waiting and often in "Host is down" - but then, sudenly, the jail is responding. Trying to connect to port 22/tcp of any jail doesn't work in 90% of the cases, but randomly, a host (out of five) does respond and the connection can be established. Terminating the connection and tryin again is in 99% then a fail. Once connected the ssh connection fries after a couple of seconds of inactivity. Checking ARP on the jail (login via host and jexec) and listening via tcpdump -XXvi vnet0 arp on a jail while pinging the jail from the netowrk shows up the typical requests, but not every request is then acompanied by a reply. I'm not firm in terms of networking and investigating ARP issues, so I followed some instructions found with ARP issues on FBSD, vnet and routing. MIB settings (on the host itself, vnet untouched): net.inet.ip.forwarding: 0 net.link.bridge.ipfw: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 I also realised that on the igb0 interace checksum errors occured while rxcsum is enabled. I disbaled special features via "ifconfig igb0 -rxcsum -txcsum -tso -lro I'm out of ideas here. Another box, the same base OS, similar setup (two NICs, same ambition), but with the difference that the second NIC resides on a different network and is connected to a different switch, also if_bridge and vnet attached jails, there is no problem. Either there is a serious bug in 12.3-p5 (haven't had the chance to check on 13/CURRENT) or I'm doing something terribly wrong. Some technical details: em0@pci0:0:25:0:class=0x02 card=0x29828016 chip=0x153b8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I217-V' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf7d0, size 131072, enabled bar [14] = type Memory, range 32, base 0xf7d35000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xf080, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP gb0@pci0:4:0:0:class=0x02 card=0x00028086 chip=0x15848086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf790, size 1048576, enabled bar [1c] = type Memory, range 32, base 0xf7a0, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 5 messages, enabled Table in map 0x1c[0x0], PBA in map 0x1c[0x2000] cap 10[a0] = PCI-Express 2 endpoint max data 128(512) FLR NS max read 512 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 x ecap 0017[1a0] = TPH Requester 1 Kind regards, oh
Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery
On Thu, 28 Apr 2022 13:36:21 -0600 Alan Somers wrote: > On Thu, Apr 28, 2022 at 1:29 PM Marek Zarychta > wrote: > > > > W dniu 28.04.2022 o 21:21, FreeBSD User pisze: > > > Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to > > > rescue > > > them and store the data on ZFS volumes. Mounting of the HDD doesn't work, > > > FreeBSD > > > 12.3 obviously lack in some etx2 features, namely "needs_recovery". The > > > kernel > > > reports: > > > > > > WARNING: mount of da4p3 denied due to unsupported optional features: > > > needs_recovery > > > > > > How can this problem be solved? > > > > > > Thanks in advance, > > > > > > oh > > > > > Probably as the name of the mailing list suggest you should upgrade to > > 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it. > > > > -- > > Marek Zarychta > > > > You might also try sysutils/fusefs-ext2 from ports. > Hi all, thanks for the response. First of all, I'm bound to FreeBSD 12.3, which is the base for XigmaNAS (used for the ease of use for those colleagues without FreeBSD experience). No clue, when this project will jump over to 13.0 or 13.1. Last time I installed ports on Xigmanas itself and tried to remove those ports, some of the base system essential also got removed - so the system was wrecked. Therefore, I'm planning to try jails and grant access to the jail and try to bind/mount the HDDs in question into the jail for backup - if this task is not an impossible mission on FBSD. Last, but the most problematic issue is: I do not know what the HDDs filesystem in reality really is! There is an EFI partition (FAT32), there is a second one, fstyp report unknown and here is the large partition identified as ext2fs by fstyp. But I think he former administration in the department used LVM on the more recent Linux boxes, so I might have to deal with that also. Kind regards, O. Hartmann Another issue on several of those HDDs in question seems to be
ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery
Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue them and store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3 obviously lack in some etx2 features, namely "needs_recovery". The kernel reports: WARNING: mount of da4p3 denied due to unsupported optional features: needs_recovery How can this problem be solved? Thanks in advance, oh
Re: 13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine
On Tue, 19 Apr 2022 06:48:04 -0600 Warner Losh wrote: Hello again, I'm on 13-STABLE, version FreeBSD 13.1-STABLE #30 stable/13-n250552-364a69a529b: Tue Apr 26 07:32:42 CEST 2022 amd64 (builder host). Sources for a NanoBSD of 13.0-RELENG (latest as of today) doesn't build, still the reported [vdso] error (see below). > The vdso error is fixed by cherry-picking > b3b462229f972e2ed24d450d7d2f8855cdd58a87. Still does not build. > I'm not sure about the second error, though if it's a general profile > error, you make need WITHOUT_PROFILE=t in both the build and install phases. This is now working on the above reported builder host version. The key was, indeed, setting WITHOUT_PROFILE=t. Thank you for the hint. On CURRENT I can build both, 13.0-RELENG and 13.1-RELENG without issues. Kind regards, Oliver Hartmann > > > On Tue, Apr 19, 2022 at 5:46 AM FreeBSD User wrote: > > > I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and > > 13.1-RELENG > > on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been > > made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13. > > > > As with today, building from sources either 13.1-RELENG and 13.0-RELENG on > > a > > CURRENT host (recent 14-CURRENT!) works without problems. > > > > On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu > > Apr 14 > > 10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails! > > > > On building from sources 13.0-RELENG I receive while in installworld: > > > > [...] > > -- > > >>> Install check world > > -- > > mkdir -p /tmp/install.6R4Ifq8o > > ... > > cp: [vdso]: No such file or directory > > *** Error code 1 > > [...] > > > > and on building from sources 13.1-RELENG while in installworld we get: > > > > [...] > > ===> usr.bin/lex/lib (install) > > install -l h -o root -g wheel -m 444 > > > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib > > ln_p.a > > > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a > > install: link > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a > > -> /home/ohartman > > > > n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a: > > No such file or directory > > *** Error code 71 > > > > > > Thanks in advance, > > > > O. Hartmann > > > >
Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error
On Fri, 1 Apr 2022 12:09:21 -0400 Ed Maste wrote: > On Fri, 1 Apr 2022 at 12:04, FreeBSD User wrote: > > > > I tried the patch given at the URL above (Phabricator). Patch applied on > > recent CURRENT and trying to "make installworld" leaves me with this error, > > see bewlo. What I'm doing weong here? > > You're not doing anything wrong, I had another bug in the version of > the patch you tried. I've updated Phabricator again, please try again. > Hello, sorry for the very late response. After the commit, everything on CURRENT was all right and worked as expected. Many thanks for the fast response! Kind regards, O. Hartmann
13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine
I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and 13.1-RELENG on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13. As with today, building from sources either 13.1-RELENG and 13.0-RELENG on a CURRENT host (recent 14-CURRENT!) works without problems. On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu Apr 14 10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails! On building from sources 13.0-RELENG I receive while in installworld: [...] -- >>> Install check world -- mkdir -p /tmp/install.6R4Ifq8o ... cp: [vdso]: No such file or directory *** Error code 1 [...] and on building from sources 13.1-RELENG while in installworld we get: [...] ===> usr.bin/lex/lib (install) install -l h -o root -g wheel -m 444 /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib ln_p.a /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a install: link /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a -> /home/ohartman n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a: No such file or directory *** Error code 71 Thanks in advance, O. Hartmann
PAM: SSH: reject login when homdir does not exist?
Hello fellows, happy Easter! I run into a security issue this morning here and tried to look for a solution. We use OpenLDAP for all "regular users" login on hosts and web services. Authentication is required from some cloud/moodle services via LDAP, but some users not having any homedirectory on any machine within the domain will still be allowed to login, even if the home dir is not present. They get loged in onto the root of the filesystem, when login via SSH. Is there a way to prohibit login if homedir isn't present? Can you point me to the right place (PAM or something, pam_env isn't available on FreeBSD)? If this is a trivial issue and caused by lack of my personell knowledge, please excuse. Kind regards, O. Hartmann
Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error
Am Fri, 1 Apr 2022 10:08:11 -0400 Ed Maste schrieb: > On Fri, 1 Apr 2022 at 10:00, Jens Schweikhardt > wrote: > > > > Hello *, > > Looks like a semicolon is missing after the "fi". > > Indeed, and there was a close bracket missing as well. I've put a > (hopefully) fixed version in review at > https://reviews.freebsd.org/D34734. > I tried the patch given at the URL above (Phabricator). Patch applied on recent CURRENT and trying to "make installworld" leaves me with this error, see bewlo. What I'm doing weong here? Kind reagrds, O. Hartmann [...] >>> Install check world -- --- installworld --- mkdir -p /tmp/install.7P7AV5IW4F progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh sort strip sysctl test time true uname wc zic tzsetup makewhatis; do if progpath=`env PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH ($PATH)." >&2; exit 1; fi; done); if [ -z "" ] ; then libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do $line; if [ "$1" = "[preloaded]" || "$1" = "[vdso]" ]; then continue; fi; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs /tmp/install.7P7AV5IW4F [: missing ] sh: [preloaded]: not found [: missing ] sh: [vdso]: not found [: missing ] sh: libc.so.7: not found [: missing ] sh: libcap_fileargs.so.1: not found [: missing ] sh: libcasper.so.1: not found [: missing ] sh: libedit.so.8: not found [: missing ] sh: libformw.so.6: not found [: missing ] sh: libm.so.5: not found [: missing ] sh: libmd.so.6: not found [: missing ] sh: libncursesw.so.9: not found [: missing ] sh: libnv.so.0: not found [: missing ] sh: libprivatebsddialog.so.0: not found [: missing ] sh: libregex.so.1: not found [: missing ] sh: libthr.so.3: not found [: missing ] sh: libtinfow.so.9: not found [: missing ] sh: libutil.so.9: not found [: missing ] sh: libxo.so.0: not found cp: [vdso]: No such file or directory *** [installworld] Error code 1 make[1]: stopped in /usr/src -- O. Hartmann
Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error
Am Fri, 1 Apr 2022 16:00:10 +0200 (CEST) Jens Schweikhardt schrieb: > Hello *, > Looks like a semicolon is missing after the "fi". > Jens > > - Ursprüngliche Mail - > Von: "Ed Maste" > An: "FreeBSD User" > CC: "freebsd-current" > Gesendet: Freitag, 1. April 2022 15:50:31 > Betreff: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file > or directory > *** Error > > On Fri, 1 Apr 2022 at 08:54, FreeBSD User wrote: > > > > On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 > > amd64, it is without any problem possible to build most recent 13-STABLE > > sources as of today (stable/13-n250195-26e8bb3a4e1). > > > > On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST 2022 > > amd64 this is not possible anymore > > Could you give this patch a try? > > diff --git a/Makefile.inc1 b/Makefile.inc1 > index c91034ed42fe..bd58f48a64d2 100644 > --- a/Makefile.inc1 > +++ b/Makefile.inc1 > @@ -1366,6 +1366,9 @@ distributeworld installworld stageworld: > _installcheck_world .PHONY > libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs > 2>/dev/null | sort -u | \ > while read line; do \ > set -- $$line; \ > + if [ "$$1" = "[preloaded]"; then \ > + break; \ > + fi \ > if [ "$$2 $$3" != "not found" ]; then \ > echo $$2; \ > else \ > Hello, it is also impossible to installworld - same error. I'm on FreeBSD 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 amd64, sources are up to date as of now. It isn't only an issue with crossbuilding another FreeBSD branch. Kind regards, O. Hartmann -- O. Hartmann
CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error
On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 amd64, it is without any problem possible to build most recent 13-STABLE sources as of today (stable/13-n250195-26e8bb3a4e1). On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST 2022 amd64 this is not possible anymore, the build process dies with the error shown below: [...] >>> Install check world -- mkdir -p /tmp/install.l1zhrZWFwP progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh sort strip sysctl test true uname wc zic tzsetup makewhatis; do if progpath=`env PATH=/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/usr/sbin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/usr/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/sbin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH ($PATH)." >&2; exit 1; fi; done); if [ -z "" ] ; then libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do set -- $line; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs /tmp/install.l1zhrZWFwP cp: [vdso]: No such file or directory *** Error code 1 Stop. make[5]: stopped in /pool/sources/13-STABLE/src *** Error code 1
Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!
On Mon, 28 Feb 2022 17:11:27 +0100
Michael Gmelin wrote:
[...]
schnipp
[...]
> >
> > poudriere jail -l:
> >
> > # poudriere jail -l
> > JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> > 123-amd64 12.3-RELEASE amd64
> > url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24
> > 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
> > url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24
> > 14:11:32 /mnt/poudriere/jails/130-amd64
> >
> > The jail.conf for this specific jail is as follows:
> >
> > [...]
> > pulverfass-001 {
> > devfs_ruleset = 13;
> > enforce_statfs = 1;
> > exec.clean;
> > exec.consolelog =
> > /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start
> > = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown';
> > host.hostname = X;
> > mount.devfs;
> > mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
> > path = /mnt/extensions/bastille/jails/pulverfass-001/root;
> > securelevel = 0;
> >
> > vnet;
> > vnet.interface = e0b_bastille4;
> > exec.prestart += "jib addm bastille4 igb0";
> > exec.prestart += "ifconfig e0a_bastille4 description \"vnet host
> > interface for Bastille jail pulverfass-001\""; exec.poststop += "jib
> > destroy bastille4";
> >
> > allow.mount;
> > allow.mount.fdescfs;
> > allow.mount.devfs;
> > allow.mount.tmpfs;
> > allow.mount.nullfs;
> > allow.mount.procfs;
> > allow.mount.linsysfs;
> > allow.mount.linprocfs;
> > allow.mount.zfs;
> >
> > allow.chflags;
> > allow.raw_sockets;
> > allow.socket_af;
> > allow.sysvipc;
> >
> > linux = new;
> >
> > exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
> > exec.start += "/sbin/zfs mount -a";
> > exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
> >
> > }
> > [...]
> >
> > Tracking the execution of the build process by issuing
> >
> > poudriere -x bulk ...
> >
> > and examin the resulting trace doesn' tgive me any hint, the error
> > reported above immediately occurs when the jail is about to be
> > started:
> >
> > + set -u +x
> > + jail -c persist 'name=123-amd64-head-default'
> > 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref'
> > 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1'
> > 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation
> > not permitted
> > + exit_handler
> > [...]
> >
> > Searching the net revealed some issues with setting IP4 and IP6 in
> > poudriere, but those findings are dated back to 2017 and 2014 and I
> > guess this is solved right now.
> >
> > The difference between our manually jail.conf driven setup and the
> > XigmaNAS/bastille based one is, bastille uses jib/netgraph based
> > seutups of the vnet and the ip4/ip6 is setup from rc.conf, while we
> > use epair in the other world and the ip is setup from withing the
> > jail definition in jail.conf.
> >
> > I'm out of ideas here and after two days of trial and error and
> > trying to understand what's going on lost ... Any hints or tipps?
> >
> > Thanks in advance,
> >
> > O. Hartmann
>
> Hi Oliver,
>
> I don't see `children.max` set in any of the configuration you shared
> above.
>
> Cheers
> Michael
>
Hello Michael,
bummer! I was so selfconfident because I copied the initial config from a
working test
and had this attribute already set that I never checked again its existence -
and started
reorganizing the jail.conf attributes ...
A fine observation and a full hit: after setting children.max= 128; the
poudriere jail
started working ... didn't wait for the finish so far.
I'm sorry for the noise - thanks for you eyes ...
Kind regards,
Oliver
bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!
Hello folks,
we run at least two poudriere build systems on recent CURRENT boxes and one of
these
poudriere build systems is working within a jail - setup via FreeBSD's
/etc/jail.conf and
by misusing the port ezjail for copying/deploying our self-compiled jail
binary. The
poudriere jail uses ZFS and is, to make it short, working like a charme.
Now we try to setup another poudriere, but this time the base is XigmaNAS
12.3.0.4/9009,
which is based upon 12.X-RELENG, utilizing "bastille". Bastille is up to date
(in terms
od the XigmaNAS plugin).
Following the setup we used on the native CURRENT "jailed poudriere" builder
and also
following this reference (for those who want to check on this)
https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere
which seems quite recent and with the exception, that we use "vnet" on all of
our systems
for jails and so does XigmaNAS.
Starting a building process via poudriere ends up with
# poudriere bulk -p head -z default -j 123-amd64 -f
/usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating the
reference
jail... done [00:00:01] Mounting system devices for 123-amd64-head-default
[00:00:01] Warning: Using packages from previously failed, or uncommitted,
build:
/mnt/poudriere/data/packages/123-amd64-head-default/.building [00:00:01]
Mounting ports
from: /mnt/poudriere/ports/head [00:00:01] Mounting packages from:
/mnt/poudriere/data/packages/123-amd64-head-default [00:00:01] Mounting
distfiles from:
/mnt/poudriere/ports/distfiles [00:00:01] Copying /var/db/ports from:
/usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02] Appending
to
make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf ->
/mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf [00:00:02]
Starting
jail 123-amd64-head-default jail: jail_set: Operation not permitted
[00:00:02] Cleaning up
[00:00:02] Unmounting file systems
poudriere jail -l:
# poudriere jail -l
JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
123-amd64 12.3-RELEASE amd64 url=https://download.freebsd.org/releases/a ...
3-RELEASE/
2022-02-24 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24 14:11:32
/mnt/poudriere/jails/130-amd64
The jail.conf for this specific jail is as follows:
[...]
pulverfass-001 {
devfs_ruleset = 13;
enforce_statfs = 1;
exec.clean;
exec.consolelog = /mnt/extensions/bastille/logs/pulverfass-001_console.log;
exec.start = '/bin/sh /etc/rc';
exec.stop = '/bin/sh /etc/rc.shutdown';
host.hostname = X;
mount.devfs;
mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
path = /mnt/extensions/bastille/jails/pulverfass-001/root;
securelevel = 0;
vnet;
vnet.interface = e0b_bastille4;
exec.prestart += "jib addm bastille4 igb0";
exec.prestart += "ifconfig e0a_bastille4 description \"vnet host interface for
Bastille
jail pulverfass-001\""; exec.poststop += "jib destroy bastille4";
allow.mount;
allow.mount.fdescfs;
allow.mount.devfs;
allow.mount.tmpfs;
allow.mount.nullfs;
allow.mount.procfs;
allow.mount.linsysfs;
allow.mount.linprocfs;
allow.mount.zfs;
allow.chflags;
allow.raw_sockets;
allow.socket_af;
allow.sysvipc;
linux = new;
exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
exec.start += "/sbin/zfs mount -a";
exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
}
[...]
Tracking the execution of the build process by issuing
poudriere -x bulk ...
and examin the resulting trace doesn' tgive me any hint, the error reported
above
immediately occurs when the jail is about to be started:
+ set -u +x
+ jail -c persist 'name=123-amd64-head-default' 'path=/mnt/poudriere/data/.m/ \
123-amd64-head-default/ref' 'host.hostname=basehost.local.domain' \
'ip4.addr=127.0.0.1' 'ip6.addr=::1' allow.chflags allow.sysvipc
jail: jail_set: Operation not permitted
+ exit_handler
[...]
Searching the net revealed some issues with setting IP4 and IP6 in poudriere,
but those
findings are dated back to 2017 and 2014 and I guess this is solved right now.
The difference between our manually jail.conf driven setup and the
XigmaNAS/bastille
based one is, bastille uses jib/netgraph based seutups of the vnet and the
ip4/ip6 is
setup from rc.conf, while we use epair in the other world and the ip is setup
from
withing the jail definition in jail.conf.
I'm out of ideas here and after two days of trial and error and trying to
understand
what's going on lost ... Any hints or tipps?
Thanks in advance,
O. Hartmann
13/STABLE: usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated'
With mergin a recent commit today involving /usr/src/sys/x86/x86/tsc.c of FreeBSD 13-STABLE, compiling the kernel results in the error shown below: [...] cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -shared -O3 -pipe -fno-strict-aliasing -march=native -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.hack.pico -MThack.pico -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-error=unused-but-set-variable -Wno-format-zero-length -mno-aes -mno-avx -std=iso9899:1999 -nostdlib hack.c -o hack.pico rm -f hack.c --- modules-all --- --- all_subdir_aac --- ===> aac (all) --- all_subdir_aacraid --- ===> aacraid (all) --- all_subdir_accf_data --- ===> accf_data (all) --- tsc.o --- /usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated' goto calibrated; Kind regards and thanks in advance, oh
Re: Arduino IDF -> make/automake based environment
On Wed, 29 Dec 2021 09:10:02 +0200 Daniel Braniss wrote: > > On 29 Dec 2021, at 01:25, FreeBSD User wrote: > > > > On Mon, 20 Dec 2021 14:35:10 +0100 > > Marc Fonvieille mailto:black...@freebsd.org>> wrote: > > > >> Le 19.12.2021 21:03, Andrew Stevenson a écrit : > >>> > >>> > >>>> On 19. Dec 2021, at 12:18, FreeBSD User wrote: > >>>> > >>>> environment. Since I'm interested in coding for some smaller AMTEL MCUs > >>>> and ESP32 > >>>> and like to digg a bit deeper than simply clicking a host base from a > >>>> menu, I'm not > >>>> afraid of doing some larger basic setup if needed. > >>> > >>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in > >>> ports. > >>> > >> > >> For ESP32, you should look at: > >> https://wiki.freebsd.org/electronics/arduino/esp32 > > > > Following these instructions with the most recent required ports on the > > latest > > 13-STABLE, results in an linker error: > > > > /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: > > cannot find crt1-sim.o: No such file or directory > > /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: > > cannot find _vectors.o: No such file or directory > > collect2: error: ld returned 1 exit status > > > > > >> and > >> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/ > >> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/> > >> > i gave up compiling the xtensa stuff, specially after espressif came out with > a riscv > version. so I downloaded the oficial idf and under FreeBSD-13 it almost > worked out of > the box, if you want I can search my notes … > > danny > Hello. I think, that will be the first step in the right direction (using the official eps-idf). Since I didn't come along with the salvation of the linker error reported earlier, I switched back to an older project from January this year. It is also based on the official FreeBSD Arduino 1.8.5 port and the xtensa compiler 5.2.0 from ports, but I used within sketchbook/hardware/esp32 the esp32 git branch release/v1.0 instead of master on which I faced the crt1-sim.o error. The goal is to compile HyperionLED (as a side product) with the recommended libraries for this project. It doesn't compile with ESP32 branch release/v1.0, the error is now [...] libraries/FastLED/src/platforms/esp/32/clockless_rmt_esp32.h:149:33: error: 'cpu_hal_get_cycle_count' was not declared ... [...] which lead me to the conclusion that a more recent version is required. With the recent version of ESP32 stuff in place, I face the mentioned crt1-sim.o error. Searching the web for that error leads to a discrepancy of ESP-IDF and the compiler stuff. I'll try the original esp-idf as you suggested (it is a pity it is backed by cmake, I'm not quite familiar with cmake yet). Any advice is highly appreciated. Kind regards, oh
Re: Arduino IDF -> make/automake based environment
On Mon, 20 Dec 2021 14:35:10 +0100 Marc Fonvieille wrote: > Le 19.12.2021 21:03, Andrew Stevenson a écrit : > > > > > > > On 19. Dec 2021, at 12:18, FreeBSD User wrote: > > > > > > environment. Since I'm interested in coding for some smaller AMTEL MCUs > > > and ESP32 > > > and like to digg a bit deeper than simply clicking a host base from a > > > menu, I'm not > > > afraid of doing some larger basic setup if needed. > > > > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in ports. > > > > For ESP32, you should look at: > https://wiki.freebsd.org/electronics/arduino/esp32 Following these instructions with the most recent required ports on the latest 13-STABLE, results in an linker error: /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: cannot find crt1-sim.o: No such file or directory /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: cannot find _vectors.o: No such file or directory collect2: error: ld returned 1 exit status > and > https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/ >
Re: Arduino IDF -> make/automake based environment
Am Mon, 20 Dec 2021 14:35:10 +0100 schrieb Marc Fonvieille : > Le 19.12.2021 21:03, Andrew Stevenson a écrit : > > > > > > > On 19. Dec 2021, at 12:18, FreeBSD User > > > wrote: > > > > > > environment. Since I'm interested in coding for some smaller > > > AMTEL MCUs and ESP32 and like to digg a bit deeper than simply > > > clicking a host base from a menu, I'm not afraid of doing some > > > larger basic setup if needed. > > > > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are > > in ports. > > For ESP32, you should look at: > https://wiki.freebsd.org/electronics/arduino/esp32 > and > https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/ > Great! Thanks a lot. Oliver
Arduino IDF -> make/automake based environment
Hello out there, I'm using the port devel/arduino18 as the basis for some small projects. I'd like to get rid of that clumsy JAVA based IDF and move towards a more make/automake based environment. Since I'm interested in coding for some smaller AMTEL MCUs and ESP32 and like to digg a bit deeper than simply clicking a host base from a menu, I'm not afraid of doing some larger basic setup if needed. But I have so far almost no experience in cross compiling on FreeBSD and I'd like to ask whether someone out here has already done setting up an environment based on the basic tools FreeBSD provides to develop in an crosscompiling sense. My IDE of choice would be Anjuta, but this is only a notice besides. As fas as I know, the base OS for most MCUs, including my choices ESP32, ESP8266, is a derivative of Amazone's FreeRTOS. Can the OS being compiled (cross compiled) on FreeBSD assuming the correct compiler is at hand (which is the case, I presume since the Arduino IDF is already working on FreeBSD)? Thanks in advance, Oliver
Re: CURRENT: ZFS freezes system beyond reboot
On Mon, 13 Dec 2021 09:30:50 +0200 Andriy Gapon wrote: > On 12/12/2021 18:45, Alan Somers wrote: > > You need to look at what's causing those errors. What kind of disks > > are you using, with what HBA? It's not surprising that any access to > > ZFS hangs; that's what it's designed to do when a pool is suspended. > > However, a pool does not have to be suspended on errors. > failmode property provides a couple of alternatives: > wait Blocks all I/O access until the device connectivity is > recovered and the errors are cleared. This is the > default behavior. > > continue Returns EIO to any new write I/O requests but allows > reads to any of the remaining healthy devices. Any > write requests that have yet to be committed to disk > would be blocked. > > panic Prints out a message to the console and generates a > system crash dump. > > But neither does any magic. > The errors will still be there. > Hello. The error's cause was not obvous. I used a SSD, partioned into two halfes, one for ZIL, the other for L2ARC. When showing "zpool status", the RAIDZ's HDDs (Hitachi/Seagate 4 TB NAS HDD) where "online", ZIL was "online" and L2ARC device/vdev showd - nothing. I had to power off/power on the box. For several hours nothing moved on, the box was frozen, any invocation of any ZFS volume related tool/command hanged the terminal/console. Several datasets showed errors at <0x0>, nothing serious. After deleting the ZIL and L2ARC extra SSD from the RAIDZ pool, verything went to normal again. It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole box even if the essential operating system stuff is isolated on a dedicated UFS filesystem. Kind regards, O. Hartmann
Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)
On Fri, 10 Dec 2021 19:41:07 +1030 Daniel O'Connor via freebsd-current wrote: > > On 25 Nov 2021, at 18:50, FreeBSD User wrote: > > > > Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov > > 22 > > 18:17:54 CET 2021 amd64) troubles me with our DNS server/service. > > Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 > > version and > > also, after the compilation of a fresh OS with LLVM13, the upgrade from > > bind-9.16.22 > > to bind-9.16.23 took place as well as ASLR being the default. > > > > Since then named is crashing with a mysterious segmentation fault (see PR > > 259921, > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921). > > > > Disabling ASLR as recommended to check whether ASLR triggers the SegFault > > did not > > solve the problem, so I suspect a miscompilation due to llvm13. > > > > On 13-STABLE bind-9.16.23 seem not to have this behaviour. > > > > I'm floating like a dead man in the water, can someone help? > > lang/sdcc also seg faults > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303), > although there disabling ASLR via proccontrol does fix it. > > Can you show a stacktrace for your seg fault? Hello. I have to prepare the boxes for debugging first, we switched everything off including core dumping. In the meanwhile, bind-9.16.24_1 has been issued in ports - the same problem occurs with that version, too, when compiled with llvm13. Kind regards, O. Hartmann > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > >
CURRENT: ZFS freezes system beyond reboot
Running CURRENT (FreeBSD 14.0-CURRENT #52 main-n251260-156fbc64857: Thu Dec 2 14:45:55 CET 2021 amd64), out of the sudden the ZFS RAIDZ pool suffered from an error: Solaris: WARNING: Pool 'POOL00' has encountered an uncorrectable I/O failure and has been suspended. The system does not repsond anymore on that pool, transactions to and from that pool are frozen, the system is 99.9% idle. The most "not so funny" part is: the box doesn't even recognize a "shutdown -r now" or a brute force "reboot". I still can login via ssh, but any action regarding the ZFS pool freezes the console/terminal. ZFS very often renders the system unresponsible forever. How can this be mitigated? The system in question is on a remote site and it seems not only to be bound to CURRENT, we realised similar problems on 13-STABLE as well. What can I do to "unfreeze" the ZFS? The main OS is, luckily, on an UFS/FFS filesystem and so not affected from that problem. By the way, here some more details, as far as I can pick those up: zpool clear POOL00 cannot clear errors for POOL00: I/O error Whatever took out the ZFS pool (can not see any hardware errors, the pool is part of services and especially a poudriere build system and under heavy load all the time, the box has 16 GB RAM), it also renders the rest of the system unusable in a way which is beyond a "reboot". Kind regrads, oh
Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress
Am Wed, 8 Dec 2021 10:43:41 -0500 schrieb Mark Johnston : > On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote: > > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD > > 14.0-CURRENT #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET > > 2021 amd64) fails with the linker error shown below. > > > > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be > > build. > > > > > > [...] > > cc -O2 -pipe -O3 -fno-common > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common > > -DNDEBUG -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall > > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > > -Wchar-subscripts -Wnested-externs -Wredundant-decls > > -Wold-style-definition -Wno-pointer-sign > > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > > -Wno-string-plus-int -Wno-unused-const-variable > > -Wno-error=unused-but-set-variable -Qunused-arguments > > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include > > -static > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib > > -o nm nm.o > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf > > -ldwarf > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > > -lelf > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc > > -lelftc_pie > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > > -lelf -legacy ld: error: undefined symbol: uncompress > > >>> referenced by libdwarf_elf_init.c > > >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive > > >>> /usr/lib/libdwarf.a > > cc: error: linker command failed with exit code 1 (use -v to see > > invocation) *** [nm] Error code 1 > > Is this build using WITHOUT_CLEAN? If so I think you'll need to try a > clean build if you had previous built world between dbf05458e3bd and > 8d5d329553b3. > Hello. Thanks for responding. The issue occured in poudriere and indeed, I set WITHOUT_CLEAN. After deleting the obj folder poudriere and the 14-CURRENT environment compiled the 13-STABLE source as expected. Thanks. oh
CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress
Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-CURRENT #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fails with the linker error shown below. Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build. [...] cc -O2 -pipe -O3 -fno-common -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DNDEBUG -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include -static -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.o -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -legacy ld: error: undefined symbol: uncompress >>> referenced by libdwarf_elf_init.c >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive >>> /usr/lib/libdwarf.a cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [nm] Error code 1
CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)
Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov 22 18:17:54 CET 2021 amd64) troubles me with our DNS server/service. Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 version and also, after the compilation of a fresh OS with LLVM13, the upgrade from bind-9.16.22 to bind-9.16.23 took place as well as ASLR being the default. Since then named is crashing with a mysterious segmentation fault (see PR 259921, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921). Disabling ASLR as recommended to check whether ASLR triggers the SegFault did not solve the problem, so I suspect a miscompilation due to llvm13. On 13-STABLE bind-9.16.23 seem not to have this behaviour. I'm floating like a dead man in the water, can someone help? Kind regards, oh
Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call
On Fri, 15 Oct 2021 23:25:01 +0300
Konstantin Belousov wrote:
> On Fri, Oct 15, 2021 at 10:20:55PM +0200, Jan Beich wrote:
> > FreeBSD User writes:
> >
> > > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd:
> > > Thu Oct 14
> > > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and
> > > also
> > > updating port graphics/drm-fbsd13-kmod to
> > > drm-fbsd13-kmod-5.4.144.g20211013,
> > > graphics/libdrm to libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes
> > > now with
> > > the following message:
> >
> > Which revision "13-STABLE" was before the update? If you didn't change
> > any kernel options (and bump into a pilot error) bisecting may help.
> >
> > >
> > > [~] firefox
> > > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close
> > > with
> > > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad
> > > system
> > > callgraphics/libdrm.
> >
> > Run under truss(1) or ktrace(1) (enable tracing descendants) to get the
> > syscall name or number. For example, Firefox requires CAPABILITIES for
> > cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust.
> >
> > [1] https://github.com/rust-lang/libc/pull/2406
>
> If you set kern.lognosys=3, it should be quite loud advertized which syscall
> was missed, ie. console + control terminal.
> terminal)
>
Hello,
thanks for the fast response.
I changed indeed one single kernel parameter: commenting out the
COMPAT_FREEBSD11. I
think Jan Beich pointed towards the right thing.
Thanks for the help and soryy for the noise.
Kind regards,
O. Hartmann
13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call
After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu Oct 14 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also updating port graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, graphics/libdrm to libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following message: [~] firefox Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system callgraphics/libdrm. info on packages installed: [~] pkg info -x drm drm-fbsd13-kmod-5.4.144.g20211013 drm-kmod-g20190710_1 libdrm-2.4.107_1,1 linux-c7-libdrm-2.4.97 It doesn't matter whether to update the ports (including firefox) from a regular FreeBSD ports repo or, in my case, compiling special kernel related kmod port like drm-fbsd13-kmod manually on each kernel build. The ports package of graphics/drm-fbsd13-kmod seems to be behind the version of drm-fbsd13-kmod-5.4.144.g20211013 when updating from regular package host, but it doesn't matter, the result then is the same: Bad system call on Firefox. So FreeBSD 13-STABLE seems to be the culprit. What happened? I saw the Linux KPI changed again, so might this trigger this? Kind regards, O. Hartmann
Re: git: "overlay" of own remote-branch on official freebsd-ports repo
On Tue, 12 Oct 2021 10:01:00 -0600 Warner Losh wrote: > On Tue, Oct 12, 2021 at 9:32 AM FreeBSD User wrote: > > > I do not know whether I'm right in this list, but since the subject is > > mutual so common > > in development and GIT, I have the strong feeling I'm right here. > > > > Im quite new to git, so apologizes for any inconvenience reading my > > question. > > > > Using poudriere on 14-CURRENT to create a selection of packages also > > includes updating > > the ports tree on a regular basis. I maintain some "special" ports not > > official part of > > the FreeBSD ports tree and some other ports are part of those I'm supposed > > to maintain. I > > keep personally track of the changes in a git repo of my own. > > > > Now I'd like to "overlay" the official portas repo by that of mine to > > include changes. > > With SVN, there was no problem to have local changes not overwritten by > > regular updates > > of the ports tree as long as the specific port in question wasn't updated > > by the official > > site. In git, this behaviour seems to have changed, any changes I made so > > far are gone > > after poudriere is adviced to update the tree. > > > > I'd like to ask how FreeBSD developers and maintainers do the trick. If > > there is an > > official cookbook fpr maintainers (I haven't found it yet ...), please be > > so kind and > > refer to it. Any advice is welcome. > > > > tl;dr: branches are cheap and well supported in git. You just make a branch > for your > local changes, and update that however you see fit. > > For ports I have like that, I've just created a branch in git. I rebase the > branch forward > each time I update. For me, though, the branch is mostly uncommitted in > upstream > changes that may not be ready for some reason... There's two ways to do > this. > You can just merge, which is OK if you aren't upstreaming the changes, or > you can > rebase if the changes or a subset of the changes likely will end up in > FreeBSD. > > Others might recommend stash, but I find it too unwieldy for more than a > couple > of things. > > So the workflow would be: > > git clone -o freebsd freebsd-ports > cd freebsd-ports > git checkout -b hartmann-specials > > > Now, you can use poudriere-ports with the -B hartmann-specials and your > local repo as the source of truth. > > to update > > cd freebsd-ports > git checkout main > git pull --rebase # or --ff-only, I use > --rebase because I push and it's habit > git rebase -i main hartmann-specials > > Note: if you need to have multiple trees with this branch you are modifying, > then a git pull --rebase will let you cope with the forced-pushes this > method > would require. You can also do it with git merge on hartmann-specials if you > don't need to keep the changes separate or you have a lot of downstreams > that would get cranky, which doesn't sound like the case here. > > Warner As I wrote, I'm quite new to git and always surprised. Thanks for the help and the neat tip. I'll try. Kind regards and thanks, Oliver
Re: git: "overlay" of own remote-branch on official freebsd-ports repo
On Tue, 12 Oct 2021 18:01:56 + Brooks Davis wrote: > On Tue, Oct 12, 2021 at 05:31:48PM +0200, FreeBSD User wrote: > > I'd like to ask how FreeBSD developers and maintainers do the trick. If > > there is an official cookbook fpr maintainers (I haven't found it yet ...), > > please be so kind and refer to it. Any advice is welcome. > > If you only want to add extra ports, I'd recommend maintaining a > separate repo for use with the ports collection's under-documented > overlay feature. This avoids the need to rebase or merge your trees. > > You create the overlay in poudriere with something like: > > poudriere ports -c -p cheri-ports-overlay -U > https://github.com/CTSRD-CHERI/cheri-ports-overlay.git -m git -B main > > You then use it by adding -O cheri-ports-overlay to your other poudriere > commands like poudriere bulk. > > Note that you may need to install poudriere-devel or install it by hand > to get this feature. > > -- Brooks Hello, that sounds very good and usefull. Thank you very much Kind regards, Oliver
git: "overlay" of own remote-branch on official freebsd-ports repo
I do not know whether I'm right in this list, but since the subject is mutual so common in development and GIT, I have the strong feeling I'm right here. Im quite new to git, so apologizes for any inconvenience reading my question. Using poudriere on 14-CURRENT to create a selection of packages also includes updating the ports tree on a regular basis. I maintain some "special" ports not official part of the FreeBSD ports tree and some other ports are part of those I'm supposed to maintain. I keep personally track of the changes in a git repo of my own. Now I'd like to "overlay" the official portas repo by that of mine to include changes. With SVN, there was no problem to have local changes not overwritten by regular updates of the ports tree as long as the specific port in question wasn't updated by the official site. In git, this behaviour seems to have changed, any changes I made so far are gone after poudriere is adviced to update the tree. I'd like to ask how FreeBSD developers and maintainers do the trick. If there is an official cookbook fpr maintainers (I haven't found it yet ...), please be so kind and refer to it. Any advice is welcome. Kind regards and thanks in advance, O. Hartmann
clang/llvm-tblgen --- ld: error: undefined symbol: setupterm
On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based appliance failed very early in the build process of the 13-STABLE sources as shown below. 13-STABLE is most recent, since the sources are fetched every time the build process is triggered. The framework for the build process is nanoBSD, the same error occurs when building poudriere's jail based upon 13-STABLE from scratch via the FreeBSD native build framework. "Cross building" of 13-STABLE on a CURRENT platform worked in most cases and most time, hopefully this hickup is a solveable problem and it would be nice to have this fixed. What is the reason for the linker fail? Are there any recommenadtions how to "cross build" 13-STABLE on a 14-CURRENT platform in case the approach of mine s not a desireable on? Thanks in advance, Oliver [...] sh /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh -s -o root -g wheel -m 555 compile_et /pool/home/ohartmann/Projects/router/router/apu2 c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: undefined symbol: setupterm >>> referenced by Process.cpp >>> Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >>> in archive >>> /pool/home/ohartmann/Projects/router/router/apu2c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
FreeBSD base pkg (packaging) and critical ports build alongside
Hello, I use FreeBSD-base packages built on self hosted systems to update 13-STABLE and CURRENT hosts. I run into the problem, that the packages of the FreeBSD base, built via the FreeBSD framework and from most recent 13-STABLE sources, are often oit of synchronisation with our poudriere packaging builders, that is especially true for critical ports with kernel modules, like i915 drm, virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources and probably the API changes more rapidly than those of the appropriate builder hosts for poudriere and since it takes a bunch of days to build a whole poudriere packages repository, there is often a gap between the revision of the kernel and the port containing kernel modules. So, the question is: how can I add ports to the building process of the FreeBSD sources tree in the way they get build every time I build the FreeBSD-base packages alongside the OS? Thanks in advance, oh
WITH_LLVM_BINUTILS: objcopy: error: invalid output format: 'efi-app-x86_64' *** [boot1.efi]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello list, Trying to "crosscompile" a 13-STABLE appliance on 14-CURRENT ( FreeBSD 14.0-CURRENT #8 main-n249550-8db1669959ce: Wed Sep 22 05:39:53 CEST 2021 amd64) with WITH_LLVM_BINUTILS=YES set in /etc/src.conf (and a complete fresh rebuild of the whole OS afterwards) results in some serious fallout lately. Compiling a recent, just updated this minute, 13-STABLE source, I face this error now and relate this to the llvm-binutils: [...] - --- boot1.efi --- if nm boot1.sym | grep ' U '; then echo "Undefined symbols in boot1.sym"; exit 1; fi SOURCE_DATE_EPOCH=1451606400 objcopy -j .peheader -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame --output-target=efi-app-x86_64 boot1.sym boot1.efi objcopy: error: invalid output format: 'efi-app-x86_64' *** [boot1.efi] Error code 1 I guess this is fallout from the binutils migration and compiling 13-STABLE on 14-CURRENT host is a special case. Can this be fixed easily or is the migration process to immature at this point? Kind regards, Oliver Hartmann - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYUtsZgAKCRA4N1ZZPba5 R9JSAQDozG5xwFhGxPTbhOPCJ731/GrxdI0lfjERziGMbXbg7QEApvkWChAKg9NM Ztgos3LH/+1Q9/gQ9CTYQbebxgcRgQM= =8J4u -END PGP SIGNATURE- -- O. Hartmann
Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden
Am Fri, 10 Sep 2021 09:04:30 -0400 Ed Maste schrieb: > On Fri, 10 Sept 2021 at 04:29, Gary Jennejohn wrote: > > > > Was the config.h in the patch the same as the one you committed? > > No it wasn't - USE_PAM was #defined in config.h after applying the > patch, while the committed version accidentally did not. > Hello out there, Just for clarification: after the last patches to the tree regarding openssh and recompilation of the base system, it seemed that everything turned to normal afterwards - in my case. Thanks. Kind regards, O. Hartmann -- O. Hartmann
Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden
Am Thu, 9 Sep 2021 22:12:09 +0200 Philipp Ost schrieb: > On 9/9/21 9:15 PM, FreeBSD User wrote: > [...] > > What has changed in the recent 14-CURRENT OpenSSH update that dramatically > > that working > > schematics do not work any more? > > OpenSSH has been updated to v8.7p1: > > https://cgit.freebsd.org/src/commit/?id=19261079b74319502c6ffa1249920079f0f69a72 > > One of the more prominent changes is the deprecation of SHA1. > > There's some additional information here: > https://lists.freebsd.org/archives/freebsd-hackers/2021-September/000289.html > > HTH > Philipp > I was and I'm aware of the published changes and deprecating SHA1 would imply non-use of SHA1-based public keys. But public key authentication works fine, for pure ssh and ssh-based rsync (scp untested). Password authentication doesn't work anymore either for pure ssh, scp and rsync. I can not find any hints to dramatic changes to that and this authentication scheme doesn't even work with the standard/vanilla sshd_config for the 14-CURRENT server side. And beware: this problem is present only in relations, were recent 14-CURRENT is the ssh server. oh -- O. Hartmann
OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden
Hello, after upgrading 14-CURRENT to recent sources September, the 8th 2021, we realizes today a strange non-standard behaviour when connecting attempts from several clients to 14-CURRENT based machines were made involving sshd. First discovered on 13-STABLE clients (NanoBSD, router/fw appliance). With non-public-key authentication we copy the config partition tar'ed over to a backup system. This worked great until yesterday. Today the connection is dropped immediately, /var/log/auth.log (sshd log on 14-CURRENT) states: Sep 9 19:19:10 <4.6> thor sshd[1350]: Failed password for user01 from 192.168.11.111 port 24332 ssh2 A usual ssh login attempt also fails this way: Permission denied, please try again. The same behaviour is to observe with Xubuntu 20.04 clients and several other FreeBSD 13.0-RELENG and 13-STABLE clients. Also 14-CURRENT-to-14-CURRENT connection attempts are negative! The only working scheme right now is public key authentication and that is for some scenarios not applicable. What has changed in the recent 14-CURRENT OpenSSH update that dramatically that working schematics do not work any more? By the way, on the target host's sshd, on all instances, settings like these [...] PasswordAuthentication yes ChallengeResponseAuthentication yes UsePAM yes are set explicitely, while "UsePAM" produces an error: /etc/ssh/sshd_config line 89: Unsupported option UsePAM this sound ridiculous, since the usage of that tag is documented in the man page as well as present in the example sshd_config and set yes by default. What is wrong here? How can the sshd issue be fixed? Kind regards and thanks in advance, O. Hartmann -- O. Hartmann
Re: ar: warning: can't open file: ccopy.pieo: No such file or directory
Am Wed, 11 Aug 2021 15:03:54 -0400 Ed Maste schrieb: > On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote: > > > > Hallo, > > > > latest upgrade of CURRENT sources renders buildworld into failure, box is > > running > > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST > > 2021 amd64: > > Assuming this was with BEARSSL enabled, it should be fixed with: > > commit 879675e9a0d84880cad9834e2ef98e8724c5532c > Author: Warner Losh > Date: Wed Aug 11 10:59:28 2021 -0600 > > stand: Add MK_PIE=no to defs.mk > > There's no need to build both pie and non-pie .o's for stand. There's > some other build thing with MK_BEAR_SSL=yes and/or MK_LOADER_VERIEXEC=yes > that causes the pie build to fail that the 'ar' stage now. Since we don't > need the PIE stuff and the non-PIE stuff, disable PIE for the boot loader. > > Reviewed by:emaste > Sponsored by: Netflix > Hello again, I think I face the very same problem on 14-CURRENT boxes building either 13-STABLE sources or 13-STABLE poudriere jails, when on the 14-CURRENT box WITH_BEARSSL is enabled in the 14-CURRENT host's /etc/src.conf. I have two scenarios: Building 13-STABLE for FreeBSD-pkg-base (having WITH_BEARSSL enabled in the src.conf dor the 13-STABLE source tree) and Building poudriere jail from a dedicated source tree for 13-STABLE (/pool/sources/13-STABLE/src) with WITH_BEARSSL enabled. The latter scenario sounds ridiculous to have BEARSSL enabled, but we use the very same src.conf file for both the packages for FreeBSD pkg base and so for the poudriere jail built from the same source tree. For a couple of weeks now I'm unable to build both the packages nor the jails. The question would be: is the solution you offered above and fixed the problem I had initailly also applicable to 13-STABLE without breakage of something else? Tahnk you very much in advance, O. Hartmann -- O. Hartmann
FreeBSD-13-STABLE: lib/libsecureboot/verify_file.c: error: use of undeclared identifier 'SOPEN_MAX'
Hello,
enabling
WITH_BEARSSL
in src.conf renders buildworld on 13-STABLE to fail, but not on
14-CURRENT.
This is the difference between the sources, obviously 14-CURRENT contains the
correct
definition of SOPEN_MAX, while 13-STABLE not (undefinied SOPNE_MAX triggers the
compiler to
fail,
/usr/src/lib/libsecureboot/verify_file.c:59:22: error: use of undeclared
identifier
'SOPEN_MAX'), see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258211
[...]
13-STABLE
:/pool/sources/13-STABLE/src # grep -r SOPEN_MAX .
./lib/libsecureboot/tests/Makefile:XCFLAGS.verify_file += -DSOPEN_MAX=64
./lib/libsecureboot/verify_file.c:static int ve_status[SOPEN_MAX+1];
./lib/libsecureboot/verify_file.c: if (fd >= 0 && fd < SOPEN_MAX) {
./lib/libsecureboot/verify_file.c: ve_status[SOPEN_MAX] = ves;
./lib/libsecureboot/verify_file.c: *@li ve_status[SOPEN_MAX] if
ve_status_state is none
./lib/libsecureboot/verify_file.c: fd >= 0 && fd < SOPEN_MAX)
./lib/libsecureboot/verify_file.c: return (ve_status[SOPEN_MAX]); /* most
recent */
[...]
14-CURRENT
./lib/libsecureboot/tests/Makefile:XCFLAGS.verify_file += -DSOPEN_MAX=64
./lib/libsecureboot/verify_file.c:#ifndef SOPEN_MAX
./lib/libsecureboot/verify_file.c:#define SOPEN_MAX 64
./lib/libsecureboot/verify_file.c:static int ve_status[SOPEN_MAX+1];
./lib/libsecureboot/verify_file.c: if (fd >= 0 && fd < SOPEN_MAX) {
./lib/libsecureboot/verify_file.c: ve_status[SOPEN_MAX] = ves;
./lib/libsecureboot/verify_file.c: *@li ve_status[SOPEN_MAX] if
ve_status_state is none
./lib/libsecureboot/verify_file.c: fd >= 0 && fd < SOPEN_MAX)
./lib/libsecureboot/verify_file.c: return (ve_status[SOPEN_MAX]); /* most
recent */
--
O. Hartmann
CURRENT: can not build 13-STABLE: missing .a lib files?
Running several flavours of CURRENT (all within the last three days rebuilt and updated, FreeBSD 14.0-CURRENT #16 main-n248811-1a4d7030bbf: Thu Aug 19 15:13:39 CEST 2021 amd64, and today, for instance, fail either to build a poudriere 13-STABLE jail or buildworld for 13-STABLE for FreeBSD base packages. "poudriere jail -j 13amd64 -u -b" dies somewhere unspectatcular with [...] ===> share/man/man4 (all) --- all_subdir_stand --- *** [libsa_pie.a] Error code 1 make[4]: stopped in /pool/poudriere/jails/13amd64/usr/src/stand/libsa while the package building process dies with a [...] install: libc_p.a: No such file or directory Kind regards, oh
Re: ar: warning: can't open file: ccopy.pieo: No such file or directory
Am Wed, 11 Aug 2021 15:03:54 -0400 Ed Maste schrieb: > On Wed, 11 Aug 2021 at 05:41, FreeBSD User wrote: > > > > Hallo, > > > > latest upgrade of CURRENT sources renders buildworld into failure, box is > > running > > FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST > > 2021 amd64: > > Assuming this was with BEARSSL enabled, it should be fixed with: > > commit 879675e9a0d84880cad9834e2ef98e8724c5532c > Author: Warner Losh > Date: Wed Aug 11 10:59:28 2021 -0600 > > stand: Add MK_PIE=no to defs.mk > > There's no need to build both pie and non-pie .o's for stand. There's > some other build thing with MK_BEAR_SSL=yes and/or MK_LOADER_VERIEXEC=yes > that causes the pie build to fail that the 'ar' stage now. Since we don't > need the PIE stuff and the non-PIE stuff, disable PIE for the boot loader. > > Reviewed by:emaste > Sponsored by: Netflix > Yes, it has. Thanks a lot. oh -- O. Hartmann
ar: warning: can't open file: ccopy.pieo: No such file or directory
Hallo, latest upgrade of CURRENT sources renders buildworld into failure, box is running FreeBSD 14.0-CURRENT #1 main-n248614-67f508db84b: Wed Aug 11 07:29:11 CEST 2021 amd64: [...] ===> sbin/dhclient (all) --- all_subdir_stand --- --- libsa32_pie.a --- building pie sa32 library ar -crsD libsa32_pie.a __main.pieo abort.pieo assert.pieo bcd.pieo environment.pieo getopt.pieo gets.pieo globals.pieo hexdump.pieo pager.pieo panic.pieo printf.pieo strdup.pieo strerror.pieo random.pieo sbrk.pieo tslog.pieo twiddle.pieo zalloc.pieo zalloc_malloc.pieo strcasecmp.pieo ntoh.pieo bcmp.pieo bcopy.pieo bzero.pieo ffs.pieo fls.pieo memccpy.pieo memchr.pieo memcmp.pieo memcpy.pieo memmove.pieo memset.pieo strcat.pieo strchr.pieo strchrnul.pieo strcmp.pieo strcpy.pieo stpcpy.pieo stpncpy.pieo strcspn.pieo strlcat.pieo strlcpy.pieo strlen.pieo strncat.pieo strncmp.pieo strncpy.pieo strnlen.pieo strpbrk.pieo strrchr.pieo strsep.pieo strspn.pieo strstr.pieo strtok.pieo swab.pieo abs.pieo strtol.pieo strtoll.pieo strtoul.pieo strtoull.pieo subr_boot.pieo clzsi2.pieo ctzsi2.pieo divmoddi4.pieo divmodsi4.pieo divdi3.pieo divsi3.pieo moddi3.pieo modsi3.pieo udivmoddi4.pieo udivmodsi4.pieo udivdi3.pieo udivsi3.pieo umoddi3.pieo umodsi3.pieo ashldi3.pieo ashrdi3.pieo lshrdi3.pieo hypervisor.pieo uuid_create_nil.pieo uuid_equal.pieo uuid_from_string.pieo uuid_is_nil.pieo uuid_to_string.pieo _setjmp.pieo bzlib.pieo crctable.pieo decompress.pieo huffman.pieo randtable.pieo adler32.pieo crc32.pieo infback.pieo inffast.pieo inflate.pieo inftrees.pieo zutil.pieo lz4.pieo closeall.pieo dev.pieo ioctl.pieo nullfs.pieo stat.pieo fstat.pieo close.pieo lseek.pieo open.pieo read.pieo write.pieo readdir.pieo smbios.pieo arp.pieo ether.pieo ip.pieo inet_ntoa.pieo in_cksum.pieo net.pieo udp.pieo netif.pieo rpc.pieo bootp.pieo rarp.pieo bootparam.pieo ufs.pieo nfs.pieo cd9660.pieo tftp.pieo gzipfs.pieo bzipfs.pieo dosfs.pieo ext2fs.pieo splitfs.pieo pkgfs.pieo time.pieo ffs_subr.pieo ffs_tables.pieo explicit_bzero.pieo crc32_libkern.pieo pwgets.pieo sha256c.pieo sha512c.pieo md5c.pieo rijndael-alg-fst.pieo rijndael-api-fst.pieo rijndael-api.pieo geliboot.pieo geliboot_crypto.pieo gelidev.pieo geli_metadata.pieo g_eli_hmac.pieo g_eli_key.pieo g_eli_key_cache.pieo pkcs5v2.pieo xform_aes_xts.pieo ccopy.pieo dec32be.pieo dec64be.pieo enc32be.pieo enc64be.pieo pemdec.pieo ec_all_m31.pieo ec_c25519_m31.pieo ec_c25519_m62.pieo ec_c25519_m64.pieo ec_default.pieo ec_p256_m31.pieo ec_p256_m62.pieo ec_p256_m64.pieo ec_prime_i31.pieo ec_pubkey.pieo ec_secp256r1.pieo ec_secp384r1.pieo ec_secp521r1.pieo ecdsa_atr.pieo ecdsa_default_vrfy_asn1.pieo ecdsa_i31_bits.pieo ecdsa_i31_vrfy_asn1.pieo ecdsa_i31_vrfy_raw.pieo multihash.pieo sha1.pieo sha2big.pieo sha2small.pieo i31_add.pieo i31_bitlen.pieo i31_decmod.pieo i31_decode.pieo i31_encode.pieo i31_fmont.pieo i31_iszero.pieo i31_moddiv.pieo i31_modpow.pieo i31_modpow2.pieo i31_montmul.pieo i31_muladd.pieo i31_ninv31.pieo i31_rshift.pieo i31_sub.pieo i31_tmont.pieo i32_div32.pieo i62_modpow2.pieo rsa_default_pkcs1_vrfy.pieo rsa_i31_pkcs1_vrfy.pieo rsa_i31_pub.pieo rsa_i62_pkcs1_vrfy.pieo rsa_i62_pub.pieo rsa_pkcs1_sig_unpad.pieo asn1enc.pieo x509_decoder.pieo x509_minimal.pieo readfile.pieo brf.pieo vesigned.pieo vets.pieo xmem.pieo vector.pieo dearmor.pieo decode.pieo opgp_key.pieo opgp_sig.pieo vectx.pieo veopen.pieo vepcr.pieo verify_file.pieo efi_variables.pieo efi_init.pieo zfs.pieo nvlist.pieo skein.pieo skein_block.pieo list.pieo zstd_shim.pieo zstd.pieo --- all_subdir_sbin --- --- all_subdir_sbin/dmesg --- ===> sbin/dmesg (all) --- all_subdir_stand --- ar: warning: can't open file: ccopy.pieo: No such file or directory 1.72 real 3.57 user 1.07 sys Kind regards oh -- O. Hartmann
