NetBSD Planet

I am trying to use OpenVPN as a client under NetBSD using this command:

openvpn --client --config /etc/openvpn/config.ovpn

I am getting the following output and errors:

localhost# openvpn --client --config /etc/openvpn/openvpn.ovpn 
2024-04-26 10:29:35 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2024-04-26 10:29:35 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2024-04-26 10:29:35 OpenVPN 2.6.10 x86_64--netbsd [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] [AEAD]
2024-04-26 10:29:35 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Enter Auth Username:********
Enter Auth Password:********
2024-04-26 10:32:48 TCP/UDP: Preserving recently used remote address: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 Socket Buffers: R=[32768->32768] S=[32768->32768]
2024-04-26 10:32:48 Attempting to establish TCP connection with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCP connection established with [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 TCPv4_CLIENT link local: (not bound)
2024-04-26 10:32:48 TCPv4_CLIENT link remote: [AF_INET]**.191.33.**:1701
2024-04-26 10:32:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2024-04-26 10:32:48 TLS: Initial packet from [AF_INET]**.191.33.**:1701, sid=0006909e 9b0d208f
2024-04-26 10:32:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-04-26 10:32:48 VERIFY OK: depth=1, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_CA, CN=UniFi_OpenVPN_CA
2024-04-26 10:32:48 VERIFY KU OK
2024-04-26 10:32:48 Validating certificate extended key usage
2024-04-26 10:32:48 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-04-26 10:32:48 VERIFY EKU OK
2024-04-26 10:32:48 VERIFY OK: depth=0, C=US, ST=New York, L=New York, O=Ubiquiti Inc., OU=UniFi_OpenVPN_Server, CN=UniFi_OpenVPN_Server
2024-04-26 10:33:53 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-04-26 10:33:53 [UniFi_OpenVPN_Server] Peer Connection Initiated with [AF_INET]**.191.33.**:1701
2024-04-26 10:33:53 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-04-26 10:33:53 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-04-26 10:33:53 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.7.1,route 192.168.4.0 255.255.255.0,route 192.168.2.0 255.255.255.0,route 192.168.1.0 255.255.255.0,route 192.168.3.0 255.255.255.0,route-gateway 192.168.7.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.7.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2024-04-26 10:33:53 OPTIONS IMPORT: --ifconfig/up options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route options modified
2024-04-26 10:33:53 OPTIONS IMPORT: route-related options modified
2024-04-26 10:33:53 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-04-26 10:33:53 TUN/TAP device /dev/tun0 opened
2024-04-26 10:33:53 /sbin/ifconfig tun0 192.168.7.2 192.168.7.1 mtu 1500 netmask 255.255.255.0 up
2024-04-26 10:33:53 /sbin/route add -net 192.168.7.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.7.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net **.191.33.** 192.168.1.254 -netmask 255.255.255.255
route: writing to routing socket: File exists
add net **.191.33.**: gateway 192.168.1.254: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 0.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 0.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 128.0.0.0 192.168.7.1 -netmask 128.0.0.0
add net 128.0.0.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.4.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.4.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.2.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.2.0: gateway 192.168.7.1
2024-04-26 10:33:53 /sbin/route add -net 192.168.1.0 192.168.7.1 -netmask 255.255.255.0
route: writing to routing socket: File exists
add net 192.168.1.0: gateway 192.168.7.1: File exists
2024-04-26 10:33:53 ERROR: OpenBSD/NetBSD route add command failed: external program exited with error status: 1
2024-04-26 10:33:53 /sbin/route add -net 192.168.3.0 192.168.7.1 -netmask 255.255.255.0
add net 192.168.3.0: gateway 192.168.7.1
2024-04-26 10:33:53 GID set to nogroup
2024-04-26 10:33:53 UID set to nobody
2024-04-26 10:33:53 Initialization Sequence Completed
2024-04-26 10:33:53 Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'lzo'
2024-04-26 10:33:53 Timers: ping 10, ping-restart 60

I have a working internet connection when running OpenVPN as a client, but I can't access any of the machines on the network **.191.33.**, I know I should be able to SSH into 192.168.1.114, but I can't reach that machine through OpenVPN, there are firewall rules in the Ubuiquity box allowing traffic from 192.168.7.* to 192.168.1.* I know this is working, its testet from Mac and PC using the OpenVPN Client, I just can't get it to work on NetBSD

This is my routing table before running OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table when running OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
0/1                192.168.7.1        UGS         -        -      -  tun0
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
128/1              192.168.7.1        UGS         -        -      -  tun0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.2/24       192.168.7.1        UGS         -        -      -  tun0
192.168.3/24       192.168.7.1        UGS         -        -      -  tun0
192.168.4/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7.1        192.168.7.2        UH          -        -      -  tun0
192.168.7.2        tun0               UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table after stopping OpenVPN:

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
0/1                192.168.7.1        UGS         -        -      -  tun0
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
128/1              192.168.7.1        UGS         -        -      -  tun0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.2/24       192.168.7.1        UGS         -        -      -  tun0
192.168.3/24       192.168.7.1        UGS         -        -      -  tun0
192.168.4/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7/24       192.168.7.1        UGS         -        -      -  tun0
192.168.7.2        tun0               UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

This is my routing table when i have destroyed tun0:

ifconfig tun0 destroy

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            192.168.1.254      UGS         -        -      -  iwn0
**.191.33.**/32    192.168.1.254      UGS         -        -      -  iwn0
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
192.168.1/24       link#2             UC          -        -      -  iwn0
192.168.1.68       link#2             UHl         -        -      -  lo0
192.168.1.254      00:1e:80:a2:2e:ff  UHL         -        -      -  iwn0

The route to **.191.33.** is still there when stopping OpenVPN and destroying the tunnel tun0, I don't know if this is expected behaviour.

x11/picom is currently v9.1 released on Feb 13 2022 and updated in pkgsrc on Sep 4 2022.
Currently, picom is at v11.2 released on Feb 13 2024, a package for this version is available as wip/picom.

All versions of picom after v9.1 require MesaLib >= 21 and need to be built with graphics/MesaLib from pkgsrc, as the base system uses MesaLib 19.

~> uname -rsv
NetBSD 10.99.10 NetBSD 10.99.10 (GENERIC) #0: Mon Apr 22 03:38:49 UTC 2024  [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC
~> glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Haswell Mobile  (0xa16)
    Version: 19.1.17
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.17
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 19.1.17
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.1.17
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Although, the base system also contains MesaLib 21, this is not on by default.
After some discussion with maya@ and wiz@, thank you both, I've decided to build a custom install image with MesaLib 21 enabled.

Upgrading the system using this custom image should allow me to build wip/picom without the need to install graphics/MesaLib from pkgsrc.

As a bonus, this should also avoids the need to have multiple LLVM versions installed, as graphics/MesaLib requires LLVM-13 and I already have 17 installed.

We need to fetch the sources, only src and xsrc are needed, and create the image using build.sh.
Note: approx. 32 Gb of free disk space are required.

~> ./build.sh -h
Usage: build.sh [-EnoPRrUux] [-a ARCH] [-B BID] [-C EXTRAS]
                [-c COMPILER] [-D DEST] [-j NJOB] [-M MOBJ] [-m MACH]
                [-N NOISY] [-O OOBJ] [-R RELEASE] [-S SEED] [-T TOOLS]
                [-V VAR=[VALUE]] [-w WRAPPER] [-X X11SRC]
                [-Z VAR]
                OPERATION ...
       build.sh ( -h | -? )

 Build OPERATIONs (all imply "obj" and "tools"):
    build               Run "make build".
    distribution        Run "make distribution" (includes DESTDIR/etc/ files).
    release             Run "make release" (includes kernels & distrib media).

 Other OPERATIONs:
    help                Show this help message, and exit.
    makewrapper         Create nbmake-${MACHINE} wrapper and nbmake.
                        Always performed.
    cleandir            Run "make cleandir".  [Default unless -u is used]
    dtb                 Build devicetree blobs.
    obj                 Run "make obj".  [Default unless -o is used]
    tools               Build and install tools.
    install=IDIR        Run "make installworld" to IDIR to install all sets
                        except 'etc'.  Useful after "distribution" or "release".
    kernel=CONF         Build kernel with config file CONF.
    kernel.gdb=CONF     Build kernel (including netbsd.gdb) with config
                        file CONF.
    releasekernel=CONF  Install kernel built by kernel=CONF to RELEASEDIR.
    kernels             Build all kernels.
    installmodules=IDIR Run "make installmodules" to IDIR to install all
                        kernel modules.
    modules             Build kernel modules.
    rumptest            Do a linktest for rump (for developers).
    sets                Create binary sets in
                        RELEASEDIR/RELEASEMACHINEDIR/binary/sets.
                        DESTDIR should be populated beforehand.
    distsets            Same as "distribution sets".
    sourcesets          Create source sets in RELEASEDIR/source/sets.
    syspkgs             Create syspkgs in
                        RELEASEDIR/RELEASEMACHINEDIR/binary/syspkgs.
    iso-image           Create CD-ROM image in RELEASEDIR/images.
    iso-image-source    Create CD-ROM image with source in RELEASEDIR/images.
    live-image          Create bootable live image in
                        RELEASEDIR/RELEASEMACHINEDIR/installation/liveimage.
    install-image       Create bootable installation image in
                        RELEASEDIR/RELEASEMACHINEDIR/installation/installimage.
    disk-image=TARGET   Create bootable disk image in
                        RELEASEDIR/RELEASEMACHINEDIR/binary/gzimg/TARGET.img.gz.
    params              Create params file with various make(1) parameters.
    show-params         Show various make(1) parameters.
    list-arch           Show a list of valid MACHINE/MACHINE_ARCH values,
                        and exit.  The list may be narrowed by passing glob
                        patterns or exact values in MACHINE or MACHINE_ARCH.
    mkrepro-timestamp   Show the latest source timestamp used for reproducible
                        builds and exit.  Requires -P or -V MKREPRO=yes.

 Options:
    -a ARCH        Set MACHINE_ARCH=ARCH.  [Default: deduced from MACHINE]
    -B BID         Set BUILDID=BID.
    -C EXTRAS      Append EXTRAS to CDEXTRA for inclusion on CD-ROM.
    -c COMPILER    Select compiler from COMPILER:
                       clang
                       gcc
                   [Default: gcc]
    -D DEST        Set DESTDIR=DEST.  [Default: destdir.${MACHINE}]
    -E             Set "expert" mode; disables various safety checks.
                   Should not be used without expert knowledge of the build
                   system.
    -h             Show this help message, and exit.
    -j NJOB        Run up to NJOB jobs in parallel; see make(1) -j.
    -M MOBJ        Set obj root directory to MOBJ; sets MAKEOBJDIRPREFIX=MOBJ,
                   unsets MAKEOBJDIR.
    -m MACH        Set MACHINE=MACH.  Some MACH values are actually
                   aliases that set MACHINE/MACHINE_ARCH pairs.
                   [Default: deduced from the host system if the host
                   OS is NetBSD]
    -N NOISY       Set the noisiness (MAKEVERBOSE) level of the build to NOISY:
                       0   Minimal output ("quiet").
                       1   Describe what is occurring.
                       2   Describe what is occurring and echo the actual
                           command.
                       3   Ignore the effect of the "@" prefix in make
                           commands.
                       4   Trace shell commands using the shell's -x flag.
                   [Default: 2]
    -n             Show commands that would be executed, but do not execute
                   them.
    -O OOBJ        Set obj root directory to OOBJ; sets a MAKEOBJDIR pattern
                   using OOBJ, unsets MAKEOBJDIRPREFIX.
    -o             Set MKOBJDIRS=no; do not create objdirs at start of build.
    -P             Set MKREPRO and MKREPRO_TIMESTAMP to the latest source
                   CVS timestamp for reproducible builds.
    -R RELEASE     Set RELEASEDIR=RELEASE.  [Default: releasedir]
    -r             Remove contents of TOOLDIR and DESTDIR before building.
    -S SEED        Set BUILDSEED=SEED.  [Default: NetBSD-majorversion]
    -T TOOLS       Set TOOLDIR=TOOLS.  If unset, and TOOLDIR is not set
                   in the environment, nbmake will be (re)built
                   unconditionally.
    -U             Set MKUNPRIVED=yes; build without requiring root privileges,
                   install from an unprivileged build with proper file
                   permissions.
    -u             Set MKUPDATE=yes; do not run "make cleandir" first.
                   Without this, everything is rebuilt, including the tools.
    -V VAR=[VALUE] Set variable VAR=VALUE.
    -w WRAPPER     Create nbmake script as WRAPPER.
                   [Default: ${TOOLDIR}/bin/nbmake-${MACHINE}]
    -X X11SRC      Set X11SRCDIR=X11SRC.  [Default: /usr/xsrc]
    -x             Set MKX11=yes; build X11 from X11SRCDIR.
    -Z VAR         Unset ("zap") variable VAR.
    -?             Show this help message, and exit.

The following steps can be done with one command only but, I was curious about the time it takes for each step.
NOTE: The build should be done in unprivileged mode, else creating the install image will fail.

Without any further due ...

~> cd /usr/src
~> ./build.sh -u -U -j4 -O ~/obj tools
[...]
===> Summary of results:
	 build.sh command:    ./build.sh -u -U -j4 -O /home/pin/obj tools
	 build.sh started:    Thu Apr 25 15:21:18 CEST 2024
	 NetBSD version:      10.99.10
	 MACHINE:             amd64
	 MACHINE_ARCH:        x86_64
	 Build platform:      NetBSD 10.99.10 amd64
	 HOST_SH:             /bin/sh
	 No $TOOLDIR/bin/nbmake, needs building.
	 Bootstrapping nbmake
	 share/mk MAKECONF:   /etc/mk.conf
	 MAKECONF file:       /etc/mk.conf
	 TOOLDIR path:        /home/pin/obj/tooldir.NetBSD-10.99.10-amd64
	 DESTDIR path:        /home/pin/obj/destdir.amd64
	 RELEASEDIR path:     /home/pin/obj/releasedir
	 Created /home/pin/obj/tooldir.NetBSD-10.99.10-amd64/bin/nbmake
	 Updated makewrapper: /home/pin/obj/tooldir.NetBSD-10.99.10-amd64/bin/nbmake-amd64
	 Tools built to /home/pin/obj/tooldir.NetBSD-10.99.10-amd64
	 build.sh ended:      Thu Apr 25 15:49:31 CEST 2024

~> ./build.sh -u -U -j4 -V HAVE_MESA_VER=21 -x -O ~/obj release
[...]
===> Summary of results:
	 build.sh command:    ./build.sh -u -U -j4 -V HAVE_MESA_VER=21 -x -O /home/pin/obj release
	 build.sh started:    Thu Apr 25 15:52:10 CEST 2024
	 NetBSD version:      10.99.10
	 MACHINE:             amd64
	 MACHINE_ARCH:        x86_64
	 Build platform:      NetBSD 10.99.10 amd64
	 HOST_SH:             /bin/sh
	 share/mk MAKECONF:   /etc/mk.conf
	 MAKECONF file:       /etc/mk.conf
	 TOOLDIR path:        /home/pin/obj/tooldir.NetBSD-10.99.10-amd64
	 DESTDIR path:        /home/pin/obj/destdir.amd64
	 RELEASEDIR path:     /home/pin/obj/releasedir
	 Updated makewrapper: /home/pin/obj/tooldir.NetBSD-10.99.10-amd64/bin/nbmake-amd64
	 Successful make release
	 build.sh ended:      Thu Apr 25 22:57:38 CEST 2024

~> ./build.sh -u -U -j4 -V HAVE_MESA_VER=21 -x -O ~/obj install-image
[...]
===> Summary of results:
	 build.sh command:    ./build.sh -u -U -j4 -V HAVE_MESA_VER=21 -x -O /home/pin/obj install-image
	 build.sh started:    Fri Apr 26 05:02:44 CEST 2024
	 NetBSD version:      10.99.10
	 MACHINE:             amd64
	 MACHINE_ARCH:        x86_64
	 Build platform:      NetBSD 10.99.10 amd64
	 HOST_SH:             /bin/sh
	 share/mk MAKECONF:   /etc/mk.conf
	 MAKECONF file:       /etc/mk.conf
	 TOOLDIR path:        /home/pin/obj/tooldir.NetBSD-10.99.10-amd64
	 DESTDIR path:        /home/pin/obj/destdir.amd64
	 RELEASEDIR path:     /home/pin/obj/releasedir
	 Updated makewrapper: /home/pin/obj/tooldir.NetBSD-10.99.10-amd64/bin/nbmake-amd64
	 Successful make install-image
	 build.sh ended:      Fri Apr 26 05:23:55 CEST 2024

We should now have the desired install images in obj/releasedir/images.

~> ls /home/pin/obj/releasedir/images/
.rw-r--r-- pin wheel 161 B  Fri Apr 26 05:23:41 2024  MD5
.r--r--r-- pin wheel 426 MB Fri Apr 26 05:23:28 2024  NetBSD-10.99.10-amd64-bios-install.img.gz
.r--r--r-- pin wheel 426 MB Fri Apr 26 05:13:03 2024  NetBSD-10.99.10-amd64-install.img.gz
.rw-r--r-- pin wheel 359 B  Fri Apr 26 05:23:55 2024  SHA512

As we built release above, a manual upgrade is also possible but, let's unpack the newly built image, copy it to an usb and use sysinst.

~> gunzip NetBSD-10.99.10-amd64-install.img.gz
~> su
Password:
# dd if=/dev/zero of=/dev/rsd0d bs=1m count=1m
# dd if=NetBSD-10.99.10-amd64-install.img ibs=1m | progress dd of=/dev/rsd0d obs=1m
2493 MiB    6.52 MiB/s 2500+0 records in
5120000+0 records out
2621440000 bytes transferred in 382.641 secs (6850912 bytes/sec)
5120000+0 records in
2500+0 records out
2621440000 bytes transferred in 382.721 secs (6849480 bytes/sec)
  2500 MiB    6.53 MiB/s
# exit

Boot from the newly created install media and perform an upgrade of the system.

~> uname -rsv
NetBSD 10.99.10 NetBSD 10.99.10 (GENERIC) #0: Thu Apr 25 22:39:14 CEST 2024  pin@mybox:/home/pin/obj/sys/arch/amd64/compile/GENERIC
~> glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 4400 (HSW GT2) (0xa16)
    Version: 21.3.7
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4400 (HSW GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.7
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 21.3.7
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.3.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

And yes, I only have one version of MesaLib and LLVM installed 😊

In February last year I wrote about running a FreeBSD desktop, and concluded that sometimes you need to give yourself permission to tinker.

Well recently I’ve started tinkering with Alpine Linux! It’s been recommended to me for years, so I’m finally getting around to checking it out. There’s a lot to like if you come from BSD, which we’ll dig into here.

A potted history

The Alpine website describes it as:

an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.

Its small footprint and design decisions also make it more secure:

All userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.

Natanael Copa discussed the genesis of the project back in 2005, making it older than I realised. Like the BSDs, it’s found its way into embedded systems, routers, and mobile devices, as well as general purpose servers and desktops.

Alpine is also a popular base for use in Linux containers, owing to its compact size and limited dependencies. There are also toolchains for easily running it in a chroot(8), which is interesting for someone who uses NetBSD chroots(8) and FreeBSD jails extensively for testing and deployments.

Installation

Alpine comes in a few different versions, including builds for ARM, PPC64, x86, and x86_64.

I downloaded the Xen ISO image because I was booting it on a VM at work, before realising I misread Dom0 as DomU. The former refers to a Xen hypervisor, not a guest. Either way, it booted and installed the same as a standard ISO.

The install process is about as simple as you could make it. You log into the live environment with root and no password, then execute setup-alpine.

You’re asked basic questions for your keymap, networking, timezone, and root authentication. You can also inject an SSH key from the start, which is useful if you’re deploying a fleet of VMs or servers with an orchestration tool after the fact, or you’re deploying to a mediocre hosting provider that doesn’t give you an OOB console.

You’re also given the choice of a few different SSH servers and ntp clients, which let me choose my preferred OpenSSH and openntpd. It also correctly identified it was operating under Xen.

It can also configure an LVM, but I stuck with what Alpine calls standard sys partitions for now. This uses ext4.

Post-install and exploration

Booting into Alpine for the first time, your given a hint as to why it’s special: dmesg(1) informs you you’re running OpenRC! It’s portable, small, fast, efficient, transparent, and secure. It’s also very familiar to a BSD person used to writing rc scripts. /etc/rc.conf and crond(8)!? Yes!!!

At the risk of embellishing my feelings about this, it is such a relief that there are Linux distros like Devuan, Gentoo, and Alpine using this. It’s a breath of alpine air, and has legitimately made Linux fun again.

Along with OpenRC, Alpine is bundled with musl, and runs busybox. Both are obviously more limited than GCC and the GNU coreutils, but they further contribute to the base system’s smaller size and attack surface. llvm is also available, as is the MirBSD Korn shell, one of my two preferred interactive shells.

Um, Ruben, I’d like to interject for a moment. What you are referring to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, a GNU grilled cheese sandwich merely featuring Linux as the…

… nope!

Packages

Speaking of installing packages, let’s take a look at that. Alpine’s default package manager is apk. As is normal on Linux, this handles updating the base system and all packages, because it makes no distinction. I’d be interested to see if I could also run an unprivileged copy of this as I like to do on the BSDs, but I haven’t checked yet. There’s also pkgsrc, so no biggie.

Configuration is in /etc/apk/repositories, where you can enable the community repo by uncommenting the second URL supplied by the installer. Alpine also has a testing repo, and you can add your own.

Usage is easy, though I’ve still been mistyping apt install instead of apk add, because old habits die hard. There’s an official web interface, and Alpine repos are on pkgs.org.

A few packages later, and I had my “essentials” going, like I do on my console-only laptop:

Perhaps the package I was most surprised about was zfs. It was literally two commands to install and load the kernel module (though obviously root on ZFS would be more involved). What that would look like after an upgrade I’d have to see, but thus far I’m impressed.

# apk add zfs zfs-lts
# modprobe zfs

Conclusion

I’ve barely scratched the surface, but there’s enough here for me to seriously consider a switch to it as my primary Linux distro for testing and servers. I love that htop(1) and lsof(1) only shows a small list of recognisable processes, that it uses OpenRC, that package management seems straight forward, and that it’s so simple to configure. I’ve wondered what a modern, functional “Occam’s Linux” would look like. This is it.

I’d be interested in seeing if uutils runs if I need something more than busybox, but for a server I doubt it.

I heard you liked Alpine, so I etc…

By Ruben Schade in Sydney, 2024-04-26.

I have a fresh NetBSD 10 amd64 install, unfortunately there is no driver support for my built-in devices, and the usb sound cards that I currently own, don’t appear to be supported either. I mainly want to use audio in connection with TomPlay and a program such as Impro-Visor or Musical MIDI Accompaniment. TomPlay works out of the box for me in Nightly, but I need audio.

$ audiocfg list
0: [*] audio0 @ hdafg0: NVIDIA product 0099
       playback: 2ch, 48000Hz
       record:   2ch, 48000Hz
       (P-) slinear_le 16/16, 2ch, { 48000 }
       (P-) slinear_le 16/16, 4ch, { 48000 }
       (P-) slinear_le 16/16, 6ch, { 48000 }
       (P-) slinear_le 16/16, 8ch, { 48000 }
       (PR) slinear_le 16/16, 2ch, 48000-48000Hz
1: [ ] audio1 @ hdafg1: Realtek product 0222
       playback: 2ch, 48000Hz
       record:   2ch, 48000Hz
       (PR) slinear_le 16/16, 2ch, { 44100, 48000, 96000, 192000 }
       (PR) slinear_le 20/32, 2ch, { 44100, 48000, 96000, 192000 }
       (PR) slinear_le 24/32, 2ch, { 44100, 48000, 96000, 192000 }
       (  ) ac3 16/16, 2ch, { 44100, 48000, 96000, 192000 }

Hot on the heels of NetBSD 10.0 comes NetBSD 9.4, a minor release in the previous release branch.

NetBSD 9.4 is primarily a bug and security fix release, however, there are some new features, such as support for more MegaRAID controllers, ZTE MF112 and D-Link DWM222 USB 3G modems, and improved CPU feature detection for newer AMD/Intel devices. All users of netbsd-9 should upgrade if they are not following the stable branch.

↫ NetBSD 9.4 release announcement

A very important note here is that the version of OpenSSL in NetBSD 9.4 is no longer supported unless you have a support contract with OpenSSL. They suggest upgrading to NetBSD 10.0, or to use OpenSSL from pkgsrc.

The NetBSD Project is pleased to announce NetBSD 9.4, the fourth release from the NetBSD 9 stable branch.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.3 in August 2022, as well as some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0. Users running 9.3 or an earlier release are strongly recommended to upgrade.

The general NetBSD community is very excited about NetBSD 10.0, the latest NetBSD release, but if for some reason you can not (or do not want to) update to 10.0, it is strongly recommended to update to 9.4. This is especially true for users still using a NetBSD 8.x release as that old release branch will be desupported by the end of April 2024.

Full release notes, including download links

Found a nice compac machine from 2004.
Have been using it as a Win2k machine but i wanted to put it to use.

Sorry

So i found som old Enterprise gear, 18gb SCSI
And a pci scsi contoler.
Adaptec AWA 2940
Neither OpenBSD or NetBSD can handle either scsi controler
gives me

eisop0 unexpected phase mismatch

Duckduckgo gave me

https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg00343.html

So atm i am stuck with Linux

I am asking. Whats going on?
Can i do something?

ive also tried this on a socket 775 machine that why i put 64bit in the headline

Since most of you seem to be using NetBSD as your main BSD, I want to ask a few questions on how to fix certain things.

First one is about the terminal.
Whenever I do something like git diff, the message "WARNING: terminal is not fully functional" shows up before it executes the command, and when I do top, I get "top: can't open termcap file".
Terminal emulator is Suckless st, and shell is ZSH.

Second one is more specific about ZSH.
The home, end, and delete keys don't seem to function as expected in the shell.
In Neovim, the home key works, the end key doesn't, and delete key opens help.txt in a separate buffer.

Third thing is that even though I'm using OhMyZSH, NetBSD is seemingly the only OS where I can't seem to go up in history based on user input.
On OpenBSD, FreeBSD, Linux, OpenIndiana, and even macOS, if I write "ne" and do arrow up, it'll rotate between "neofetch" and "neomutt", and pressing tab will highlight words that start with "ne" so I can autocomplete it.
But on NetBSD, writing "ne" and arrow up will just give me whatever the last command was, and pressing tab will spawn a list of programs starting with "ne", but are not selectable at all, so it behaves much more like GNU Bash.

And the forth thing is more something I can't understand, and that's Neofetch reporting I'm using up 7 GiB of RAM out of 8 GiB, even though I have nothing running apart from ST, CWM, and SSH in the background.
Very similar to how memory usage shows up in FreeBSD, except in FreeBSD I'm using ZFS, but on NetBSD that's just UFS.
So why is that?

As for the first 3 problems, any ideas how to fix those?

If you sorta squint and tilt your head, it’s a games theme this week.

• Roguelike vs. Roguelite: What’s the Difference?  (via)
• Awesome-Selfhosted.  (also via)
• rigg 1.0 released – a new way to run indie games on OpenBSD.
• SEthernet: Modern, low-cost 10/100 Ethernet for the Macintosh SE and SE/30.
• Mastodon for Apple II (][+, //c, IIe, and IIgs)
• Hex marks the spot.  (via)
• pkgsrc-2024Q1 branch released, and NetBSD 10.0.
• Further Explorations, the companion volume to 50 Years of Text Games, is available for standalone purchase.  Related: merchandise.
• The Greenwich prime meridian isn’t where it used to be.
• FreeBSD Speedrun.
• Terminal status bar with only stock tools.

Your unrelated music for the week: New Strategies for Modern Crime Vol 1.  (via)

Hi! My name is Ruben Schade, and I’m a solution architect for an indie cloud company who mostly runs Linux, but tries to use FreeBSD and NetBSD where he can. This is my story. LAW AND ORDER DUN DUN

The post

Yesterday I saw the news that Microsoft will be including ads in an upcoming Windows 11 update, which so perfectly encapsulates all that’s wrong with modern IT. I saw a few people post about it on Mastodon, which generated dozens of comments from Linux fans saying the real solution was to switch to their OS.

Before I went to bed, I posted:

Linux people, please understand this. Sometimes people need to run Windows. They’re allowed to complain about Windows ads, or tracking, or any other enshittification problems, without you saying “use Linux” every time.

Suffice to say, I woke up to a storm of certain Linux people… not understanding this. But a few themes emerged, which I thought I’d respond to in aggregate here instead.

Replies that miss/ignore the point

• I don’t understand why someone would need to run Windows. If I offered you $1,000, I’ll bet you could think of some reasons. Don’t take me up on that though, I’m trying to save for a house. In this economy!?

• Using Windows makes you a cog in the capitalist machine. This assumes agency. Also, no.

• I’m philosophically against Windows. I might be too. It’s irrelevant.

• You don’t have a right to complain if you use Windows. Big we should improve society somewhat vibes with this.

• You deserve all the hate coming your way. I’ve certainly learned my lesson.

• It’s GNU/Linux. No comment. Wait, that’s a comment. Fsck.

• I don’t understand why you’re so angry/frustrated/etc. Probably the most honest thing they could have said.

Replies that address the point

• Run within a VM. This at least solves the technical issue of certain hardware or software not working on Linux. Running a VM isn’t always feasible, but the point at least acknowledges that Windows is unfortunately still necessary.

• Use Wine, or some other shim. Again, not always tenable, and you’re smart enough to know why. But the community is making incredible strides, even in gaming.

• I love how many people are proving your point. Self-awareness definitely seems lacking among a cohort of Linux people, even though we may see eye to eye on a lot of things. That does make me a bit sad.

By Ruben Schade in Sydney, 2024-04-14.

I have a machine capable of PCI passthrough with Linux+libvirt. So I know it's supported by BIOS and hardware.

I have installed QEMU in the this machine with NetBSD. When I run QEMU with -device vfio-pci,host=<some id> I get this error:

qemu-system-x86_64: -device vfio-pci: 'vfio-pci' is not a valid device model name

I can't find a tutorial to use IOMMU with NetBSD. Is it possible to do PCI passthrough when the host is NetBSD? How do I do it?

I am trying to write a driver for NetBSD that will reserve 10 pages of virtual memory, then provide the first 5 pages with physical addresses. At the end, I output the page number, its physical address, and flags such as Valid, User and Modified. However, it seems to me that the flags are not working correctly, since for all pages, all flags have the same value, which is 1 (true). Please help me figure out what I'm doing wrong.

#include <sys/cdefs.h>
#include <sys/module.h>
#include <sys/param.h>
#include <sys/sysctl.h>
#include <uvm/uvm.h>

MODULE(MODULE_CLASS_MISC, driver, NULL);
#define PAGESIZE 0x1000
extern paddr_t avail_end;
vaddr_t va;
struct pglist plist;
static int lab4_modcmd(modcmd_t cmd, void* arg) {
   va = uvm_km_alloc(kernel_map, PAGESIZE*10, 0, UVM_KMF_VAONLY);
   if (va == 0) {
      return 0;
   }
   int error = uvm_pglistalloc(PAGESIZE*5, 0, avail_end, 0, 0, &plist, 5, 0);
   if (!error) printf ("LAB4 loaded\n");
   struct vm_page *page = TAILQ_FIRST(&plist);
   for(int i = 0; page; i++) {
      pd_entry_t *ppte;
      ppte = L2_BASE+pl2_i(va+PAGESIZE*i);
      paddr_t pa = VM_PAGE_TO_PHYS(page);
      printf("Page - %d\n", i+1);
      printf("Valid - %d\n", ((*ppte & PG_V) ? 1 : 0));
      printf("Used - %d\n", ((*ppte & PG_U) ? 1 : 0));
      printf("Modified - %d\n", ((*ppte & PG_M) ? 1 : 0));
      printf("Physical address - 0x%lx\n", pa);
      printf("\n");
      page = TAILQ_NEXT(page, pageq.queue);
   }
   uvm_pglistfree(&plist);
   uvm_km_free(kernel_map, va, PAGESIZE*10, UVM_KMF_VAONLY);
   return 0;
}

I tried to look for other examples where these flags are used.

It’s funny that I field almost as many sysadmin questions about Minecraft than I do BSDs thesedays. Even Minecraft on BSD! This post addresses the most common question after running Minecraft on FreeBSD, and on NetBSD. I’ll assume here that you have a functional server, and know how it works.

Say you have a map running on your local Java Minecraft install, and you want to import it as another into a Java multiworld server running Paper (as I recommend), such as one running MyWorlds or Multiverse. How do you do this?

Locating your Minecraft data directory

First, access your saved local world in the appropriate location:

• Windows: %appdata%\.minecraft
• Mac: ~/Library/Application Support/minecraft/
• Linux: ~/.minecraft/

Within this folder, you’ll have a folder called world. This contains your world data, along with subfolders for the associated Nether (DIM-1) and End (DIM1) worlds. These are generated when you first create the world, even if you’ve never accessed them:

• ./world/
  • ./DIM-1/
  • ./DIM1/

Importing without mutliworld, and some context

Importing is easy on a Minecraft server without multiworlds. You copy the world folder into the Minecraft server folder before starting the server, then run. If you’re importing into an existing server, you’ll want to backup and move the existing world folder elsewhere first before replacing it, unless you don’t need it anymore.

You’ll notice that after importing, the server has rearranged the worlds into their own folders in the server directory:

• ./world/
• ./world_nether/
• ./world_the_end/

This works, but what if you use a multiworld plugin and want a custom folder name for this world?

Importing with a multiworld plugin

It’s important to note that the Minecraft server will only import world folders. If your imported world is called something like resourceserver, it won’t import the Nether or End worlds automatically. This might not matter to you, but you’ll end up teleporting to your server’s default Nether or End, not the ones you expected.

The temptation is to rename DIM-1 to world_nether, and DIM1 to world_the_end, as several forum posters and AI-generated guides suggest. This doesn’t work, because the other two worlds are missing metadata. Thanks GPT, you monumental waste of resources!

The solution I’ve found is to temporarily rename the imported world as world, let the server import it, then rename it to what you wanted. In more detail:

1. Stop the Minecraft server, and temporarily rename the existing server world folder to something else, like world_backup.

2. Copy your local imported world folder into the server, leaving the name of the folder set as world.

3. Start the Minecraft server, letting it rearrange the folders into world, world_nether, and world_the_end, then generate the required metadata for each.

4. Stop the Minecraft server again, then rename the folders to what you want, such as resourceserver, resourceserver_nether, and resourceserver_the_end.

5. Rename your original world_backup back to world again, assuming you want this to be the default.

6. Start the Minecraft server again, and import your world.

Importing the world, and its attached Nether and End

If you use MyWorlds like I do, you can now import the worlds from the game with these:

/myworlds load resourceserver
/myworlds load resourceserver_nether
/myworlds load resourceserver_the_end

Donezo.

By Ruben Schade in Sydney, 2024-04-11.

SmolBSD is a tiny BSD UNIX (NetBSD) system creation tool, primarily aimed at building modern, lightweight, fast micro VMs. SmolBSD can start a service in (way) under a second, giving it the ability to be used as a virtualized container, thus reducing attack surface and actually isolating workflows.

↫ SmolBSD website

Neat.

A few weeks ago, Apple released new versions of Xcode and Command Line Tools. Not thinking too hard about how my pkgsrc developer environment often gets broken by OS or tool updates, I updated promptly. For one thing, I’m kinda used to it. For another, it doesn’t usually break. For a third thing, managing dependencies — anything not my code that can break my code — means responsibility for dealing with the inevitable trouble, and therefore the sooner I find it the better. (More on my approach to life with dependencies.)

A vendor-provided toolchain is a significant dependency. So I accepted the Command Line Tools update, and it commandeered my spare time for two weeks as I hurried carefully to repair one of the world’s biggest continuous-integration cauldrons on one of its most popular platforms. When I ran my usual pkg_rolling-replace -suv to rebuild anything outdated, it did not go well at all.

Did I mention that a few weeks ago we were aiming to stabilize for yesterday’s quarterly release? Suddenly, if we didn’t scramble to straighten things out for macOS users, we’d have to manage a complicated situation for a while. But if we created a mess on other platforms by moving rashly, that’d be even worse.

The usual feedback mechanism for proposed infrastructure changes is to compare full bulk builds before and after. There was no time for that.

Happily, the conclusion of the story is boring: as always, the pkgsrc 2024Q1 stable branch supports macOS and its developer tools, including the latest releases of each. (So does -current pkgsrc, of course, if that’s your thing.)

Curious what we had to do to keep it boring? Read on.

Stricter clang defaults

Upstream Clang 16 and GCC 14 have promoted several warnings to errors by default, and Apple’s Clang 15 has followed suit. (Gentoo has very helpfully documented this for packagers.) These changes are intentional and well-intentioned, pushing maintainers to ship more reliable code. But pkgsrc’s job is to build nearly 30,000 codebases we don’t maintain. And stricter compiler defaults break a lot of builds.

As you might hope, we can make the breakage go away in one place.

In pkgsrc, packages declare which programming languages are required for their build. The compiler framework then selects package-and-platform-appropriate compilers, places them preferentially in the package’s build environment, and — crucially — intercepts compiler invocations and rewrites them for a variety of purposes.

When we look into pkgsrc’s clang logic, we find prior art for this specific class of problem. In September 2020, Xcode 12 (and its associated Command Line Tools) arrived even later in our quarterly schedule and promoted -Wimplicit-function-declaration to an error. The surgical fix: on macOS only, if invoking clang reveals the new stricter default, we pass -Wno-error=implicit-function-declaration to demote the error back to a warning.

Apple Clang 15’s new strictures aren’t observable in the same way, so we adjust our workaround: if clang doesn’t complain when we try demoting the new errors back to warnings, we pass those arguments too, via the same compiler-framework mechanism.

Missing m4 and yacc

This messy regression found only in the Command Line Tools 15.3.0.0.1.1708646388 update — not in the corresponding full Xcode 15.3 (build 15E204a) update — must have been unintended.

On macOS, some of the familiar Unix tools in /usr/bin are in fact stubs. When invoked, they either execute into the corresponding installed program (living somewhere under /Library/Developer) or prompt the user to install the Command Line Tools.

This Command Line Tools update uninstalls m4 and yacc from /Library/Developer. But since the OS-provided /usr/bin/m4 and /usr/bin/yacc stubs still exist, running m4 or yacc still does something: it pops up a window prompting you to reinstall the CLT. Unfortunately, as the latest available version doesn’t provide those tools, reinstalling is a waste of time.

As you might once again hope, we can hide the problem without personally visiting 29,000+ packages.

In pkgsrc, we also have a framework to control which non-compiler tools are invoked during builds. Packages declare which tools are required for their build. The tools framework then selects package-and-platform-appropriate incarnations of the declared tools and places them preferentially in the package’s build environment.

We just got handed a few new twists to handle in the framework, is all.

First, because this clever new CLT failure mode outfoxes our usual tool-detection mechanism, we special-case m4 and yacc detection on macOS, performing an existence check for the stubs’ targets. Then the selection mechanism’s usual fallback logic can provide them some other way. This prevents the primary source of needless CLT install popups. For non-macOS platforms, no change.

Second, because some packages might not yet be declaring all their tool dependencies, we special-case m4 and yacc handling on macOS: when they’re not declared, we place them in the build environment anyway, as no-ops. If the package build happens to invoke them, nothing happens. This prevents the secondary source of needless CLT install popups, at the risk of breaking macOS builds for packages that are missing these tool declarations and have heretofore gotten lucky; in such cases, the breakage will be obvious and the fix easy. For non-macOS platforms, no change. (At leisure, we might like to broaden this approach to help find and fix all undeclared tools on all platforms.)

Third, because the flex tool expects to invoke a GNU-compatible m4, we adjust the tools framework to infer gm4 from a flex declaration so that the framework controls which m4 gets found. This more correctly expresses our intent on all platforms, and in the macOS package build environment it restores /usr/bin/flex to a working state.

Broader xcrun search

We were already relying on xcrun for a couple of things, so when our new tool-detection special cases were sometimes getting surprising results from it, that was concerning. Turns out xcrun no longer looks solely in Apple-controlled locations, but also consults the environment’s $PATH. By invoking xcrun with an empty PATH and --no-cache, we obtain controlled, predictable tool detection.

Conclusion

Under the constraints, we changed as little as possible, as safely as possible, as similarly as possible to previous proven changes, avoiding novel constructs or any whiff of unforeseen consequences. We could not have done nearly as safe or thorough a job without good abstractions already in place. Total lines of pkgsrc infrastructure code changed: less than 100. Now that 2024Q1 is out, we have room to refactor.

These 15.3 updates also include a brand new linker. So far it hasn’t given us any trouble. If that changes, wanna guess whether we have one place to take care of it?

Way back in the day, back when I wasn’t even working at OSNews yet, I used to run QNX as my desktop operating system, together with a small number of other enthusiasts. It was a struggle, for sure, but it was fun, exciting, and nobody else was crazy enough to do so. Sadly, the small QNX desktop community wasn’t even remotely interesting to QNX, and later Blackberry when they acquired the company, and eventually the stand-alone Neutrino-powered version of QNX disappeared behind confusing signup screens and other dark patterns. It meant the end of our small little community.

Much to my utter surprise and delight, I saw a post by js about how he ported GCC 10 to QNX – in this case, to QNX 6.5 SP1, released in 2012 – and submitted it to pkgsrc. His ultimate goal is to port one of his other projects, ObjFW, to QNX. He makes use of pkgsrc to do this kind of work, which also means he had to make pkgsrc bootstrap and a lot of other software work on QNX.

We’re at QNX 8.0 by now, and as much as I bang my head against QNX and BlackBerry’s wall of marketing and corporate speak, I just can’t find out if it’s even still possible to download QNX Neutrino and install it on real generic hardware today.

This is the ninth post in my toolchains adventures series. Please check the previous posts in the toolchains category for more context about this journey. There was no Q4 2023 report as there wasn't really anything worthwhile to write about.

I've been taking a break from Pkgsrc to only focus on OpenBSD at this point, for which I updated binutils to version 2.42 in the ports tree.

During this OpenBSD release cycle, the remaining parts required to get pinsyscalls(2) working have been committed, and I added support upstream for the PT_OPENBSD_SYSCALLS segment type to readelf in GNU Binutils, as well as in LLVM versions of objdump and readobj.

Lastly, I also wrote a blog post about Speedbuilding LLVM/Clang in 3 minutes on Power10.

As usual, I’ve also been busy reading different material, and adding new resources to toolchains.net.

binutils commits:

LLVM commits

NetBSD 10.0 has been released, and it brings a lot of improvements, new features, and fixes compared to the previous release, 9.3. First and foremost, there are massive performance improvements when it comes to compute and filesystem-bound applications on multicore and multiprocessor systems. NetBSD 10.0 also brings WireGuard support compatible with implementations on other systems, although this is still experimental.

There’s also a lot of added support for various ARM SoCs and boards, including Apple’s M1 chip, and there’s new support for compat_linux on AArch64, for running Linux programs. Of course, there’s also a ton of new and updated drivers, notably the graphics drivers which are now synced to Linux 5.6, bringing a ton of improvements with them.

This is just a small sliver of all the changes, so be sure to read the entire release announcement for everything else.

The NetBSD project is pleased to announce the eighteenth major release of the NetBSD operating system NetBSD 10.0!
See the release announcement for details.

The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the development branch to get ready for branching, a lot of development went into this new release.

This also caused the release announcement to be one of the longest we ever did.

If you want to try NetBSD 10.0 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

Recently, a backdoor was discovered in the xz compression library. xz/liblzma are included as a part of NetBSD and used by the project for distribution of new releases and packages.

The version of xz shipped in all stable (and unstable) versions of NetBSD predates any code changes by the author of the backdoor. NetBSD is therefore safe and unaffected by the recent discoveries. It is believed that the attack only targets Linux/glibc, but checking this allowed us to rule out any other attempts at compromising the library by the author.

The version of xz shipped in pkgsrc, however, is affected. Using xz from pkgsrc is a non-default setting on NetBSD, and requires explicit opt-in. Most users of NetBSD will not install xz from pkgsrc because the version from the base system is preferred. However, users of pkgsrc on other platforms will need to take precautions.

Regardless of NetBSD being affected or not, the discovery of the backdoor is a wake-up call and further discussion will be happening internally over how to proceed.

A sixth Release Candidate of my other favourite OS was made available on the 12th of March. From the NetBSD blog:

RC6 fixes a few issues with the new named/bind imported for RC5 plus several minor issues.

If you want to test 10.0 RC6 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

This is old news for the NetBSD community, but I mentioned that I’d been testing RC5 last month, so I felt like I should pass this on.

By Ruben Schade in Sydney, 2024-03-22.

I'm debugging the NetBSD kernel with gdb, but I would like to be able to display information about the memory region an address is in. I'm mainly interested in finding out the permissions of a page of memory, along with the size of the region it is enclosed in (if the latter part of that question makes sense).

Does the kernel have a concept of memory regions in kernel space? i.e. a contiguous block of pages (virtual addresses) reserved for a specific purpose (which is kept track of somewhere)? Or is it down to each specific module to keep track of which blocks of memory belong to a logical group?

Here's an example of what I'm looking for:

(gdb) addressinfo 0xffffffff80e1000

                Start                End    Offset    Perm     Size
    0xffffffff80e0000  0xffffffff80e2000    0x1000    r--p     0x2000   

I don't mind adding a hook to the kernel for a GDB script to output this information, if this functionality does not exist. At the minimum it would be useful to add a hook for GDB scripts to view the page permissions.

Command line / history is I guess the mini-theme.

• ELIZA Effect, something important to remember about AI.  From a dinosaur blog of all places.
• The Art and History of Lettering Comics.  Authoritative work from a master in the field.  You have seen his work even if you do not realize it.  (via)
• State of the Terminal.  (via)
• The Life and Death of the Bulbdial Clock.  Links to interesting sources.
• Failing to Fail: The Spiderweb Software Way.  (via)
• Regular Expression Matching Can Be Simple And Fast.  (via)
• Related: Structural Regular Expressions (PDF).  You may not be surprised to see it’s by the author of sam.  (via)
• Followup: video is up for the most recent NYCBUG event, “NetBSD for the Advanced Minimalist“.
• Editing long commands in your shell.  (via)

It took almost a year of tinkering, buying parts, testing, configuring, fixing, cursing, and shouting with excitement, but I now have a KVM setup that finally works, across two decades of computer history from a Commodore VC-20 to a Dell Dimension Pentium III!

We start with this assortment of parts to take signals and convert them to VGA for my KVM, inspected for quality by one of Clara’s Prince Cats. Some of these ended up being replaced or not used.

Clokwise from left to right we have:

1. The RetroTINK-2X-Pro, with a Belkin HDMI to VGA adaptor. This box of wonders converts and upscales the S-Video from my 8-bit Commodore machines with zero configuration and fuss. The Belkin converts this to a crisp VGA signal for the KVM.

2. A DB13W3 connector. This converts the Sun TurboXGX frame buffer card on my Sun SPARCStation 5 to VGA.

3. The GGLabs CGAtoRGBv2. This converts the EGA signal from my Am386 tower to 15 KHz VGA, which surprisingly my VGA LCD accepts. It might also work with my Commodore 128’s 80-column mode eventually, if I get its VDC working.

4. A cheap S-Video and Composite to VGA converter (retired). I used this with the Apple //e before I got the ∀2 Analog VGA card. It was fine.

5. Luis Antoniosi’s MCEtoVGA converter (retired). Worked fine for EGA, but the GGLabs card has no artefacting or fuzziness.

6. The ∀2 Analog (not pictured). This card generates a VGA signal from any slot on an Apple ][, including my //e Platinum. 80 column colour is not only feasible on this machine now, but it looks stunning!

The next piece was my handsome beige KVM, which I got on eBay for a steal because it had no cables; something I later came to regret! But I finally have cables now.

With these connectors, we now have the KVM ports set up like this:

1. Am386 EGA → CGAtoRGBv2 → VGA
2. NEC APEX 486 DX2 → VGA
3. DIY childhood P1 → VGA
4. Dell Dimension 4100 P3 → VGA
5. Sun SPARCStation 5 → DV13W3 adaptor → VGA
6. 8-bit Commodores → RetroTINK → HDMI → VGA
7. Apple //e Platinum → ∀2 Analog → VGA
8. Reserved for another upstream KVM? Gulp

And it works! I can press the button on the KVM, or invoke a key command, and jump between DOS 3.3 on my Apple //e, to NetBSD on the SPARCStation, then across to GEM on the 386, then check where my BNSF GP38-2 is up to in Train Simulator on my Dell.

It’s a hornet nest of cables, and I can’t tell you how happy I am now! Well, I guess I just did! Now it’s time to update Sasara.moe with all this stuff.

FAQs

• Why did you do a lossy conversion from HDMI to VGA? Beacuse the RetroTINK outputs HDMI, and my KVM uses VGA.

• Why use a VGA KVM, not DVI or HDMI? Because VGA is the highest common denominator across all these machines, and my beige NEC LCD uses VGA.

• Surely your Dell has DVI? Yes, but see above.

• Which 8-bit Commodore machines do you use with this setup? Right now it’s a VC-20 [sic], 64C, C128 (40-column mode only, the 80-column VDC circutry is currently borked), C16, and a Plus/4. Clara’s and my shared retro server Sasara.moe has the full list. The 64C is my daily driver, with the others in a glass cabinet to the side where I can easily access them and swap them out (unlike the massive Apple //e)!

• I can never get these converters! How did you? It can be tricky, they come in and out of stock constantly. The best thing to do is to subscribe to Tindie sellers so you get an update as soon as they’re available, and keep some money budgeted to the side so you can pounce.

• You should use $FOO or do $BAR instead. Where were you yesterday?

• What did you use for the keyboard and mouse? I used AT to PS/2 for the keyboards, and serial to PS/2 for the mouses where necessary. This did rule out having a more modern optical mouse unfortunately, but I have nostalgia for that Microsoft Dove soap bar mouse anyway.

• Have you tried the RGBtoHDMI? I’ve heard great things, but this setup works for me.

• Can you help me troubleshoot my own complicated video setup? In the words of a ship’s rigger, I’m a frayed knot. This was all trial and error, mostly error, and I’m not in a hurry to repeat the experience.

• What VGA cables did you use? I ended up finding some second-hand Belkin KVM cables, and a high-quality shielded cable to go to the monitor.

• What about your other machines? I have some other late 1990s PCs, but their function mostly overlaps with the Dell that has the best specs. At some point I’ll wire them into this spaghetti, but right now they’re museum pieces until I get more space.

• Was it worth it? If you’re in a tiny apartment like me, its the difference between having retrocomputing as an accessible hobby, and not. If I had a decent-sized place with a hobby room, I’d much rather have dedicated setups for each machine, or at least each generation of machine.

• Do any of Clara’s Prince Cats help with configuring the machines too? As a matter of fact, yes.

By Ruben Schade in Sydney, 2024-03-17.

The NetBSD project is pleased to announce the sixth release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the development branch to get ready for branching, a lot of development went into this new release.

This also caused the release announcement to be one of the longest we ever did.

Since RC1 there have been numerous changes, including major updates to external software included in the release: Postfix, OpenSSH, and the firmware used for Raspberry PI devices. Various issues with RC1 have been fixed, including installer (sysinst) crashes. Lots of architecture specific fixes happend, e.g. various toolchain changes for VAX (so it is now finaly self-hosting again), and kernel changes for macppc, netwinder, and alpha.

For RC3 only few (relatively) minor changes were made, including https certificate verification in libfetch (which is used by pkg_ad(1)), and also improvements to the EFI bootloader to better deal with booting from CD (or in virtual machines ISO images), plus lots of various bug fixes.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

RC5 has a few important security related updates of third party components (named, nsd, unbound, wpa_supplicant).

RC6 fixes a few issues with the new named/bind imported for RC5 plus several minor issues.

Especially on amd64 machines please notes that we got a new DRM/KMS subsystem version, and this may lead to fallout on some hardware. Unfortunately not all known bugs from the release engineering pre-release task list could be fixed in time for this release - we will continue to improve the current state and hope to have more of them solved for the next (10.1) release.

If you want to test 10.0 RC6 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

The March 6 NYCBUG meeting is coming up, and it sounds like something I’d want to see: NetBSD for the Advanced Minimalist, working remote using only a $100 Pinebook.  Be sure to RSVP if you can go cause this is in-person and they need to know who is coming into the NYU facility.

The NetBSD project is pleased to announce the fifth (and probably last) release candidate of the upcoming 10.0 release, please help testing!
See the release announcement for details.

The netbsd-10 release branch is more than a year old now, so it is high time the 10.0 release makes it to the front stage. This matches the long time it took for the development branch to get ready for branching, a lot of development went into this new release.

This also caused the release announcement to be one of the longest we ever did.

Since RC1 there have been numerous changes, including major updates to external software included in the release: Postfix, OpenSSH, and the firmware used for Raspberry PI devices. Various issues with RC1 have been fixed, including installer (sysinst) crashes. Lots of architecture specific fixes happend, e.g. various toolchain changes for VAX (so it is now finaly self-hosting again), and kernel changes for macppc, netwinder, and alpha.

For RC3 only few (relatively) minor changes were made, including https certificate verification in libfetch (which is used by pkg_ad(1)), and also improvements to the EFI bootloader to better deal with booting from CD (or in virtual machines ISO images), plus lots of various bug fixes.

RC4 became necessary as a few very important DRM/KMS issues especially for Intel GPUs have been resolved. And as an (unexpected) bonus support for the Nintendo Wii has been added to the evbppc port.

RC5 has a few important security related updates of third party components (named, nsd, unbound, wpa_supplicant).

Especially on amd64 machines please notes that we got a new DRM/KMS subsystem version, and this may lead to fallout on some hardware. Unfortunately not all known bugs from the release engineering pre-release task list could be fixed in time for this release - we will continue to improve the current state and hope to have more of them solved for the next (10.1) release.

If you want to test 10.0 RC5 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

I have create a disk image on netbsd

newfs -F -s 10G 1.img

How to mount it?

I have tried "nodev" but give error and try to mount /mnt/p2

mount -v -o nodev /home/user/1.img /mnt/p2