Monday, March 20, 2023

32/64-Bit and NetBSD 10 BETA

 I've had "Pentium" type machine for decades, starting with using NetBSD 0.9 on a 386 or 486 in 1997?, and now, trying out various processors and systems for beta testing 10.0.

Initially, one "hand-me-down" box seemed like an older, 32-bit processor, based on how MS-Windows viewed the details, complaining the OS version could not be updated beyond Windows 9 32 bit, or so. Thus my first pass with NetBSD was to install the i386 release, testing it for several weeks before the light dawned that this weak looking machine had more to offer if set up right. Motherboard has a 2014 date stamp and my research shows this board was designed for laptops then slipped into a largish case because marketing/.


[ 1.000000] NetBSD 10.0_BETA (GENERIC) #0: Mon Jan 23 16:02:49 UTC 2023

[ 1.000000]

[ 1.000000] NetBSD 10.0_BETA (GENERIC) #0: Sun Feb 12 12:39:37 UTC 2023
[ 1.000000]
/netbsd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for NetBSD 10.0, not stripped

[     1.000004] cpu0: AMD A8-6410 APU with AMD Radeon R5 Graphics 
[     1.000004] cpu0: node 0, package 0, core 0, smt 0
[     1.000004] cpu0: SVM disabled by the BIOS
[     1.000004] cpu1 at mainbus0 apid 1
[     1.000004] cpu1: AMD A8-6410 APU with AMD Radeon R5 Graphics  
[     1.000004] cpu1: node 0, package 0, core 1, smt 0
[     1.000004] cpu2 at mainbus0 apid 2
[     1.000004] cpu2: AMD A8-6410 APU with AMD Radeon R5 Graphics  
[     1.000004] cpu2: node 0, package 0, core 2, smt 0
[     1.000004] cpu3 at mainbus0 apid 3
[     1.000004] cpu3: AMD A8-6410 APU with AMD Radeon R5 Graphics   
[     1.000004] cpu3: node 0, package 0, core 3, smt 0

4-cores, N threads(?)

Two for the price of one

First win: the AMD64 beta ISO fits on a standard CD image footprint. Yay.

Next, big win: the machine has both VGA and DVI outputs, which may sound archaic with HDMI and higher resolutions available (more on the higher end AMD system later), but it turns out this little board contains 2 independent video outputs. With a couple adapters, I've got dual-HDMI screens and X Windows stretching in them.

Minor fault: the onboard ethernet adapter only runs at 100BT. On closer examination, there is an onboard mini-PCIE connector that could conceivably allow a Gigabit board in its place. Given the risk of breaking the installed board (which NetBSD works fine with), or installing a replacement board that might not work, I decided to go with an outboard USB ethernet dongle (more on that hardware also later).


Without changing the system (I guess there be BIOS mysteries here), going x86 kicked up the visible memory seen by NetBSD.

[     1.000000] total memory = 2759 MB
[     1.000000] avail memory = 2684 MB

[     1.000000] total memory = 7863 MB
[     1.000000] avail memory = 7581 MB

Also good news, there is an empty memory slot onboard. Now, to find chips that fit...

I wonder how old that CR2032 button battery is? Hmm.


[     4.877451] [drm] Radeon Display Connectors
[     4.877451] [drm] Connector 0:
[     4.877451] [drm]   DVI-D-1

[     4.888080] [drm] Connector 1:
[     4.888080] [drm]   VGA-1

[     4.947445] radeondrmkmsfb0 at radeon0
[     4.957450] [drm] Initialized radeon 2.50.0 20080528 for radeon0 on minor 0
[     4.957450] radeondrmkmsfb0: framebuffer at 0xc0615000, size 1920x1080, depth 32, stride 7680

X Windows starts up just fine; the switch from twm to cwtm is still pleasant (one app installed twm and I quickly rewrote that xtartup script).

XSCreensaver works nicely; the range of hacks and their speed are always a system performance indicator, as well as hardware and software library depth. Two separate hacks running at the same time is pretty cool, maybe the first UNIX system I've had (and there have been many) bifurcating for me.

$ file xscreensaver-get.core
xscreensaver-get.core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), NetBSD-style, from 'xscreensaver-get', pid=18023, uid=1000, gid=100, nlwps=1, lwp=18023 (signal 11/code 32767)


The "net" in NetBSD implies internet operations should be simple and thorough. I've installed this OS enough times to know where interface are configured, how Network Time Protocol works best, and basic home mesh set up. Good news for this motherboard containing a supported ethernet board.

I was unsatisfied with the restricted 100BT connection and tried several alternatives for wired and wireless.

For wifi, I have one USB dongle that NetBSD is happy with, and others that either don't work at all, or have partial connectivity. I switched out one that as been running fine on an even older i386 server and it's been fine (the big test will be running wireless only, rather than dual connections).

Think Penguin sells open source hardware. Linux OS targeted, but sometimes NetBSD uses benefit from that communal spirit. Not always, though. Short version (more below): the wireless dongle didn't work for me on NetBSD, but the gigabit USB dongle did.


[     1.055110] re0 at pci1 dev 0 function 0: RealTek 8100E/8101E/8102E/8102EL PCIe 10/100BaseTX (rev. 0x07)
[     1.055110] re0: interrupting at msix1 vec 0
[     1.055110] re0: RTL8106E (0x4480)

There appear to be antenna wires connected to the PCIE board, though NetBSD doesn't report any interface other than the wired one.


[     2.727276] rgephy0 at axen0 phy 3: RTL8211E 1000BASE-T media interface
[     2.777269] rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto

Mar  8 21:32:16 amd64 /netbsd: [ 771903.1443413] athn0 at uhub1 port 2
Mar  8 21:32:17 amd64 /netbsd: [ 771904.1242585] : Atheros AR9271
Mar  8 21:32:17 amd64 /netbsd: [ 771904.1242585] athn0: rev 1 (1T1R), ROM rev 15, address 

Mar  8 21:47:22 amd64 dhcpcd[4518]: re0: carrier lost - roaming
Mar  8 21:47:22 amd64 dhcpcd[4518]: axen0: changing route to ...

interface rates:

ping times:

Arrows are before the ThinkPenguin AXEN0 interface was connected


For beta testing, I like to install familiar software, run benchmarks, and look for anomalies. The first oddity was the CPU temperature increase after switching from an i386 NetBSD beta build to the amd64.

On the left side, i386 running under 27 degrees Celsius average, with the amd64 on the right closer to 38 degrees. Inexplicable so far.

Byte Bench

Dhrystone 2 using register variables     6703557.1 lps   (10.0 secs, 10 samples)
Double-Precision Whetstone                 1321.6 MWIPS (10.0 secs, 10 samples)
Recursion Test--Tower of Hanoi           116108.7 lps   (20.0 secs, 3 samples)
Dhrystone 2 using register variables        116700.0  6703557.1      574.4
Double-Precision Whetstone                      55.0     1321.6      240.3

H Bench (or its close rival lmbench)

lmbench1.1 results for NetBSD ...
Process fork+exit: 1002.1667 microseconds
Process fork+execve: 2887.0000 microseconds
Process fork+/bin/sh -c: 6732.0000 microseconds

$ cat  /usr/pkg/share/hbench/Results/netbsd10.0-x86_64/amd64/lat_syscall_getpid

NetBSD Unit Tests

There are test suites under /usr/tests on recent NetBSD systems, which I was unaware of until recently, so running these tests are as much for me to learn about the system architecture as it is to find errors o omissions. In a prior post, I reported more failures on architectures for as ARM than on i386 or amd64, which makes a little sense given their relative code base ages. 

Fortunately, I managed a complete test run while this system was running the NetBSD i386 build, and have finished another round using the amd64 build. Interesting results in that a few failures are mutual while most of the very small set are from only one build.

Line counts for the test runs:

   12101 testsuite-amd64.csv
   11957 testsuite-i386.csv

Common (shared) failure(s), as extracted from the CSV output (timestamps omitted for clarity):

  • tc, sbin/envstat/t_envstat, zerotemp, failed, Test case was expecting a failure but none were raised
  • tp, sbin/envstat/t_envstat, failed

Failures seen only on i386:

  1. tp  include/t_paths  failed
  2. tp  kernel/kqueue/t_empty  failed
  3. tp  lib/libarchive/t_libarchive  failed
  4. tp  lib/libc/kevent_nullmnt/t_nullmnt  failed
  5. tp  lib/librumphijack/t_tcpip  failed
  6. tp  net/net/t_bind  failed
  7. tp  net/net/t_unix  failed
  8. tp  net/altq/t_cbq  failed
  9. tp  crypto/opencrypto/t_opencrypto  failed
                  Failures seen only on amd64:

                  1. tp  lib/libc/net/t_servent  failed
                  2. tp  net/if_wg/t_basic  failed
                  3. tp  usr.bin/cc/t_tsan_data_race  failed
                  4. tp  usr.bin/make/t_make  failed
                  5. tp  usr.sbin/tcpdump/t_tcpdump  failed
                  6. tp  fs/tmpfs/t_vnode_leak  failed
                  Apologies if this semi-manual error search missed any useful test results. 

                  [     1.055087] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)
                  [     1.055123] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)


                  <tp id="sbin/envstat/t_envstat">
                  <tc id="zerotemp">
                  <so>amdtemp0 = 39.250 =~ 39</so>
                  <so>Skipping non-existent coretemp0</so>
                  <so>Skipping non-existent acpitz0</so>
                  <failed>Test case was expecting a failure but none were raised</failed>


                  <tp id="sbin/envstat/t_envstat">
                  <tc id="zerotemp">
                  <so>amdtemp0 = 45.125 =~ 45</so>
                  <so>Skipping non-existent coretemp0</so>
                  <so>Skipping non-existent acpitz0</so>
                  <failed>Test case was expecting a failure but none were raised</failed>

                  I presume the root cause for this hardware might be similar to the other 686?

                  [     1.000004] cpu0: AMD A8-6410 APU with AMD Radeon R5 Graphics 

                  $ /sbin/dmesg | /usr/bin/grep -i temp
                  [     1.055087] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)
                  [     1.055123] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)

                  $ /usr/sbin/envstat
                                        Current  CritMax  WarnMax  WarnMin  CritMin  Unit
                    cpu0 temperature:    39.375                                      degC

                  On an AtomPC i386, envstat was fine:

                  tc, sbin/envstat/t_envstat, zerotemp, passed

                  <tp id="sbin/envstat/t_envstat">
                  <tc id="zerotemp">
                  <so>Skipping non-existent amdtemp0</so>
                  <so>coretemp0 = 58.000 =~ 58</so>
                  <so>acpitz0 = 127.000 =~ 127</so>
                  <passed />

                  $ /sbin/dmesg | /usr/bin/grep -i temp
                  [     1.010406] coretemp0 at cpu0: thermal sensor, 1 C resolution, Tjmax=100

                  $ /usr/sbin/envstat
                                        Current  CritMax  WarnMax  WarnMin  CritMin  Unit
                         temperature:    52.000  127.000                             degC
                         temperature:    51.000  127.000                             degC
                    cpu0 temperature:    53.000                                      degC

                  Think Penguin

                  Their wifi dongle has only worked on a small number of OSes I've tried, though I had hoped it would 'just work.' Part number: TPE-N150USB.

                  The gigabit dongles have been fine so far, and no losses on a temperamental Pi 02W. Though it has gone offline once (no dump). TPE-1000NET3

                  Mar 19 00:00:00 aa syslogd[974]: restart
                  Mar 19 12:31:31 aa syslogd[806]: restart
                  Mar 19 12:31:31 aa /netbsd: [   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, [...]
                  1.0000000]     The Regents of the University of California.  All rights reserved.

                  Mar 19 12:31:31 aa /netbsd: [   1.0000000] NetBSD 10.0_BETA (GENERIC) #0: Fri Jan 13 19:15:32 UTC 2023
                  Mar 19 12:31:31 aa /netbsd: [   1.0000000]
                  Mar 19 12:31:31 aa /netbsd: [   1.0000000] total memory = 448 MB
                  Mar 19 12:31:31 aa /netbsd: [   1.0000000] avail memory = 422 MB

                  The Other 686

                  Alas, my idea to install NetBSD on a homebrew AMD board hasn't worked yet due to video card matching and budget. FreeBSD skirted the "bad" board by least common denominator rules which kicked in vanilla VGA X/console window to at least boot. I had 9.x running and decided for the time being not to keep swapping out hardware to have yet another NetBSD 10 beta testbed. 

                  There are a few programs that I haven't got working to my satisfaction on the 6-core/12-thread machine, thus I'm using the NetBSD "laptop in a biggish box" as the main X display and putting databases or apps not needing video interaction on FreeBSD.

                  One program that really snaps with faster hardware is ocrmypdf; transactions that were taking a minute on an ARM processor kick over in 10 seconds now.

                  [     1.000003] cpu0: AMD Ryzen 5 5600X 6-Core Processor   

                  [     1.005359] amdzentemp0 at amdsmn0: AMD CPU Temperature Sensors (Family19h)
                  [     1.005359] amdzentemp0: autoconfiguration error: unable to register with sysmon (error=22)

                  Sunday, March 12, 2023

                  Zabbix migrations, in place / out of place

                  I've had Zabbix running on PostgreSQL for over a year now it seems, and during that time Zabbix has released a couple major updates, and I've tried to build the newest servers and agents I could on a variety of BSD and Linux flavors. My go-to platform, NetBSD, doesn't have the latest and greatest of every app out there, so I moved on to FreeBSD as the primary Zabbix home base, er at home.

                  I've had 2 levels of the Zabbix server on NetBSD, once on i386 and once on Arm but for this post I'll ignore those branches and focus on 2 FreeBSD directions for data and applications with the history ramifications.

                  When I started Zabbix 5 server was the best I could manage; as I tried other variations I had 6.2 up and running eventually. I figure out that exporting and importing history/trends from one Zabbix box to another is simple but time consuming as valuable data feeds increase.

                  Platform 1: Upgrade database in place; conform to schema changes

                  In early 2022, I started monitoring with Zabbix en masse, as they say.

                  -rw-r--r--  1 root  wheel  20385599 Aug  8  2022 postgresql-11.17.tar.bz2

                  -rw-r--r--  1 root  wheel  22132996 Aug  8  2022 postgresql-14.5.tar.bz2

                  While upgrading, I needed both versions 11 and 14; FreeBSD would not install one if the other was already. Hence, skipping the "make clean" part meant slightly quicker re-installs.

                  Installing zabbix62-server-6.2.3...
                  pkg-static: zabbix62-server-6.2.3 conflicts with zabbix54-server-5.4.9 (installs files into the same place).

                  ===>  zabbix62-frontend-php74-6.2.3 conflicts with installed package(s):

                  ===>  Installing for zabbix62-server-6.2.3
                  ===>  Checking if zabbix62-server is already installed
                  ===>   zabbix62-server-6.2.3 is already installed

                   Installed packages to be REMOVED:
                          zabbix62-server: 6.2.3

                  Starting version (2022):

                  • Jan 30 21:58:37 freebsd1 pkg-static[69272]: postgresql11-server-11.14 installed

                  Upgrade phases (2023):

                  • Feb 20 15:46:38 freebsd1 pkg[11293]: postgresql11-server-11.17 deinstalled
                  • Feb 20 16:59:17 freebsd1 pkg-static[65464]: postgresql11-server-11.17 installed
                  • Feb 20 17:14:14 freebsd1 pkg[69391]: postgresql11-server-11.17 deinstalled
                  • Feb 20 17:15:10 freebsd1 pkg-static[69814]: postgresql14-server-14.5 installed

                  The "deinstalls" probably include the pre-packaged server version that only supports mysql/mariadb.


                  Configuration file error

                      DB type "POSTGRESQL" is not supported by current setup. Possible values MYSQL.


                  Feb  3 23:17:58 freebsd1 pkg-static[89086]: php80-pgsql-8.0.15 installed
                  Feb  3 23:57:55 freebsd1 pkg-static[15828]: php80-pgsql-8.0.15 deinstalled
                  Feb  4 02:51:20 freebsd1 pkg-static[52566]: php74-pgsql-7.4.27 installed

                  This sequence shows the installed package mix failed to include PHP 8.0; this limit was something I searched for in early installs. Zabbix didn't work with PHP 8 on the systems I could muster.

                  Data changes

                  Along the way, Zabbix changed history table keys so newer versions may not deal with older versions if there is redundancy (as I understand it). So history needed to be dumped and reloaded, being renamed along the way so that there was a fall back. If it worked.

                    38636366 Jan 17 03:14 backup_zabbix_history_text.sql
                   302137397 Jan 17 03:15 backup_zabbix_history_uint.sql

                   174197724 Jan 17 03:16 backup_zabbix_trends.sql
                   101438770 Jan 17 03:16 backup_zabbix_trends_uint.sql

                  => select count(*) from history_old;

                  Platform 2: New database, import hosts and templates, manually import history.

                  Database Server versions

                  May 12 15:13:26 freebsd2 pkg[11749]: postgresql14-server-14.5 installed
                  May 12 15:49:32 freebsd2 pkg[14127]: postgresql14-server-14.5 deinstalled
                  May 12 16:13:38 freebsd2 pkg[15371]: postgresql14-server-14.5 installed

                  My notes aren't clear on why 2 tries, but at least that's still correct on the Zabbix application server side. I moved the database in 2023 to a different system meaning no need to upgrade the original host unless I need to do a refresh there sometime (mmm, backups).

                  Feb 18 23:17:41 freebsd3 pkg-static[33301]: postgresql15-server-15.1_1 installed
                  Feb 18 23:26:00 freebsd3 pkg[42270]: postgresql15-server reinstalled: 15.1_1 -> 15.1_1
                  Feb 18 23:40:46 freebsd3 pkg[45979]: postgresql15-server-15.1_1 deinstalled
                  Feb 18 23:47:06 freebsd3 pkg-static[64934]: postgresql15-server-15.1_1 installed

                  I struggled a bit here with getting the package/port to include PostgreSQL. If I slipped, the make had to be re-done with particular incantations to forget my previous mistake. So I won't do it again, it's [ make rmconfig ].

                  Hammer time

                  20230220:143137.337 Unable to start Zabbix server due to unsupported PostgreSQL database version (11.17).
                  20230220:143137.337 Must be at least (13.0).
                  20230220:143137.337 Use of supported database version is highly recommended.
                  20230220:143137.337 Override by setting AllowUnsupportedDBVersions=1 in Zabbix server configuration file at your own risk.

                  =# INSERT INTO history SELECT * FROM history_old ON CONFLICT (itemid,clock,ns) DO NOTHING;
                  INSERT 0 9281304

                  COPY 1357
                  COPY 3828
                  COPY 0
                  COPY 18
                  COPY 1
                  COPY 9311373
                  COPY 5024
                  COPY 0
                  COPY 0

                  => select count(*) from history;
                  (1 row)

                  => select count(*) from history_old;


                  Here, unlike the legacy system, the PHP 8 version is working with Zabbix.

                  May 12 15:50:41 freebsd2 pkg[14127]: php82-pgsql-8.2.0.r2 installed
                  May 12 16:12:16 freebsd2 pkg[15371]: php82-pgsql-8.2.0.r2 deinstalled
                  Jan 10 20:20:05 freebsd2 pkg-static[50148]: php81-pgsql-8.1.14 installed

                  Data migration

                  To have a faster response time, I used system 3 as a database server, and installed PostgreSQL 15 over the previously running version 14.

                  Basic export import steps follow, along with dump size.

                  1. Shutdown Zabbix application server
                  2. Run a database export
                  3. Set up target system at least the same database version
                  4. Create database and schema as needed
                  5. Run database import
                  6. Shutdown original database
                  7. Alter Zabbix server configuration
                  8. Viola (ha)

                  2023-02-19 06:25:02.997 UTC [9256] FATAL:  terminating connection due to administrator command

                  -rw-r--r--  1 postgres  postgres  562198532 Feb 19 06:01 /dump/zabbix_freebsd2.dump

                  This is the wholly grail; if I miss this screen or fail to check the right box, it's not show time, it's dump and reload time.

                  From then to now:

                  -rw-r--r--  1 freebsd  freebsd  24382685 Dec 23  2021 zabbix-5.4.9.tar.gz
                  -rw-r--r--  1 freebsd  freebsd  24510838 Jan 31  2022 zabbix-5.4.10.tar.gz
                  -rw-r--r--  1 freebsd  freebsd  41038757 Dec  5 08:44 zabbix-6.2.6.tar.gz

                  Meanwhile 6.2.7 and 6.2.8 are probably out, on some platforms at least.

                  History results (from platform 1):

                  The gaps are due to sensors or test systems going offline or elsewhere.


                  What did I find most different after trying the upgraded platform and the fresh platform? One obvious nicety is the delivery of open street maps in the base server. This only shows up for me in the fresh install, though.

                  Next big difference is the change from a single agent status level to seeing two of them, squeezed into one lamp.

                  Perhaps multiple interfaces may be configured to show here, though my first tries to add second adapters didn't pan out.

                  Option: HeartbeatFrequency is available on later agent versions, so check if this needs to be set (missing means an earlier configuration file).

                  This dash display works simply enough:

                  Groups and other metadata containers/tags have changed somewhat from the earliest versions I've used (5).

                  Which way for future upgrades? It depends, as usual. If the keys change, that's doable. Larger data collections are unlikely at my pace; for others trends would need to be analyzed. Avoiding "database unsupported" is always a good idea.


                  Along the way, I found this bug (hit it myself):

                  ZBX_NOTSUPPORTED: Cannot obtain a descriptor to access kernel virtual memory.

                  Although the question refers to NetBSD 8 and Zabbix 4 (both outdated in 2023), the error may still hit if you use an older agent software base. NetBSD patches to get an agent the correct system internal metrics are out there, maybe on package source work-in-progress, and maybe in a distribution near you. I went through each system I test to get a Zabbix 6.2.6 agent running, so they'd match the server version and not have quirks with features absent or deformed.

                  The FreeBSD kernel limited the import speed, I presume.

                  Feb 20 17:40:48 freebsd1 kernel: Limiting open port RST response from 223 to 200 packets/sec
                  Feb 20 17:40:50 freebsd1 kernel: Limiting open port RST response from 224 to 200 packets/sec
                  Feb 20 17:41:24 freebsd1 kernel: Limiting open port RST response from 220 to 200 packets/sec