packages: modernize packages that build on the existing toolchain

[bhouse-nexthop]

Targets onie-modernization-2026. Independent — not stacked on any other modernization PR. It applies cleanly on onie-modernization-2026 and every package builds on the existing cross-toolchain (no dependency on the toolchain milestone, the python3 port, SBOM, or OCE).

Each package is now its own commit (one bump per commit, bisectable and reviewable in isolation).

New dependency libraries

Added to unblock consumers:

Package	Version	For
libmnl	1.0.5 (new)	ethtool's netlink interface
libaio	0.3.113 (new)	lvm2 ≥ 2.03's bcache I/O engine

Package upgrades

Package	From	To	Notes
ethtool	3.14	6.15	now uses libmnl for netlink
zlib	1.2.11	1.3.2	source → madler GitHub release (old SF mirror 404s)
lzo	2.09	2.10
libpcap	1.10.4	1.10.6
tcpdump	4.99.4	4.99.6	needs libpcap ≥ 1.10.5
dropbear	2020.81	2026.91
keyutils	1.5.10	1.6.3	source → kernel.org snapshot (.tar.bz2 → .tar.gz)
dmidecode	3.1	3.7	cross-compile patch refreshed
acpica-tools	20150410	20260408	source → GitHub release assets (acpica.org retired)
ipmitool	1.8.18	1.8.19	GitHub source archive (./bootstrap)
kexec-tools	2.0.22	2.0.32	drop upstreamed aarch64 / dt-sorting patches
btrfs-progs	v4.9.1	v7.0
pciutils	3.2.1	3.15.0	ONIE Makefile patch refreshed
gptfdisk	0.8.8	1.0.10	drop obsolete add-onie-partition-types patch
popt	1.16	1.19	drop obsolete aarch64 / uClibc-glob patches
openssl	1.1.1g	3.5.7 (LTS)	drops legacy 1.1.x support
mtd-utils	1.5.2	2.3.1
i2c-tools	3.1.1	4.4
dosfstools	3.0.26	4.2
busybox	1.25.1	1.38.0	see DHCP VIVSO note below
lvm2	2.02.105	2.03.41	requires libaio

All bumps target current upstream releases from canonical sources (stable hosts preferred over flaky mirrors); patch series were refreshed and dead/flaky source URLs fixed as part of each bump.

busybox 1.38 + DHCP VIVSO

busybox 1.38 dropped the vivso (opt-125) and tftpsiaddr (opt-150) names from udhcpc's stock table. The busybox commit restores them (extended patches/busybox/dhcp-additional-options.patch) and makes ONIE's discovery decode DHCP options type-aware in rootconf/default/lib/onie/udhcp4_sd / udhcp4_net, so VIVSO-based OCP discovery keeps working. (The OCE compliance PR is the gate that exercises this end-to-end.)

Testing

Validated by full local cross-builds producing a green recovery ISO, plus CI on the prior stack. Commits are individually bisectable (each builds in order).

[mshych]

Change this and the following 3 configs to the same default values

[bhouse-nexthop]

Done — restored to 8 / 10 / 1000 / 10.

You were right, and it is worse than a wrong default: it breaks the build. Those four are range 8 16 and range 10 1000000, so 0 is outside every one of them. kconfig discards an out-of-range value and treats the symbol as new, which makes silentoldconfig prompt — and a prompt with redirected console input aborts:

delay time for i2c writing 1 byte (SYS_EEPROM_I2C_WRITE_1B_DELAY) [10] (NEW) aborted!
Console input/output is redirected. Run 'make oldconfig' to update configuration.

Reproduced against real busybox 1.38.0 with this branch's patch series and a real machine config (accton_833435_b21, which leaves the 1B/2B delays to the base config):

• as submitted → silentoldconfig rc=2, no include/autoconf.h, build fails
• with these four restored → rc=0, and the machine's own overrides win (16 address bits, 4000 for 3B) with the base defaults filling the rest

167 of the 247 machines that set CONFIG_SYS_EEPROM_DEVICE_I2C=y leave at least one of the four to the base config, so all of them would have failed to build. CI missed it because kvm_x86_64 uses SYS_EEPROM_DEVICE_DISK, which leaves the i2c symbols invisible.

I then scanned the whole regenerated config for the same class of bug — any int/hex value outside its declared Kconfig range — and found two more, so I fixed those here too:

• CONFIG_SYS_EEPROM_MAX_SIZE=0 (range 256 65536, default 2048). Note this is out of range in the pre-bump config as well, so it is not from this PR; it is inert only because all 283 SYS_EEPROM=y machines set it explicitly. Happy to split it out if you would rather not carry an unrelated fix here.
• CONFIG_FEATURE_HTTPD_PORT_DEFAULT=0 (range 1 65535, default 80). New symbol in 1.38, inert today because no machine enables HTTPD.

Verified afterwards by running silentoldconfig for all 289 machine busybox configs in the tree against the fixed base config: 0 aborts.

[mshych]

Busybox additional notes:

1. busybox dropped timeout -t in 1.30 (coreutils syntax now), so 38 call sites in ufispace machine trees stop working — link_phy.sh PHY init on 6 platforms, and the NTP block in 29 copies of udhcp4_net (live, since those machines set CONFIG_NTPD=y). Same bucket: 30 ufispace busybox configs still set CONFIG_FEATURE_WGET_SSL_HELPER=y, a symbol gone since 1.26, which apply-config-patch now silently drops.
   As we discussed before: These are vendor-specific platform changes, and the question is what is preferable: pushing untested changes that may or may not work on a vendor platform, or letting vendors validate and opt into the new compiler/toolchain themselves. A vendor that wants to adopt the new toolchain should verify that its platform builds and functions correctly and then update its machine configuration as needed. Until that validation is done, we should not switch vendor-specific platforms to an unverified configuration.
   Please just flag it in the commit message / release notes so the affected vendors know what to rework.

2. oldconfig picked up four new upstream defaults not mentioned in the commit message: CONFIG_TLS, CONFIG_SSL_CLIENT, CONFIG_SSL_SERVER, CONFIG_FEATURE_WGET_HTTPS. Pre-bump ONIE had no TLS, so https:// installer URLs failed; now exec_installer will fetch them via code that prints note: TLS certificate validation not implemented. FEATURE_WGET_OPENSSL isn't a substitute (we ship no CA store, so -verify_return_error fails everything). Please set all four to "not set" and keep this PR behaviour-neutral; verified HTTPS deserves its own PR.

3. The config fix isn't stable: feeding the fixed busybox.config back through make oldconfig re-zeroes the four SYS_EEPROM_I2C_* values, SYS_EEPROM_MAX_SIZE and FEATURE_HTTPD_PORT_DEFAULT, because those symbols are invisible until a machine override makes them visible. So the next regeneration reintroduces the exact bug, and CI won't catch it (kvm_x86_64 uses SYS_EEPROM_DEVICE_DISK). Worth adding the sweep you ran by hand as a make target plus a CI step — all 285 machines take ~10s once busybox is unpacked.

[mshych]

i2c-tools bump breaks the build for every machine that uses i2c-tools for syseeprom, and it's invisible to CI. Those are exactly the machines you're asking about: build-config/Makefile only pulls in make/i2ctools.make when I2CTOOLS_SYSEEPROM = yes, which is 6 machines, and none of them override busybox.config — the base config has # CONFIG_SYS_EEPROM is not set, so they have no busybox syseeprom applet and depend entirely on the i2c-tools-built /usr/bin/onie-syseeprom. If i2c-tools doesn't build, those machines have no way to read the ONIE TLV EEPROM at all.
E.g. alphanetworks and celestica

[mshych]

OpenSSL bump.
OpenSSL 3.x installs ENGINESDIR=$(libdir)/engines-{SHLIB_VERSION}, i.e. /usr/lib/engines-3. OPENSSL_LIBS still says plain engines:

openssl.make
Ln 45–48
OPENSSL_LIBS =
engines
libcrypto.so libcrypto.so.3
libssl.so libssl.so.3
Both the chmod u+w -R loop in openssl-build and the cp -av loop in openssl-install therefore fail on that entry. They don't fail the build, because engines is the first item and a shell for loop exits with the status of its last iteration — I confirmed this:

chmod: cannot access '/tmp/enginetest/usr/lib/engines': No such file or directory
loop exit status = 0
So the effect is two error messages scrolling past and engines-3/ silently never reaching $(SYSROOTDIR). This is newly reachable in this PR: the base branch defaulted to OPENSSL_VERSION ?= 1.1.1g, whose OPENSSL_LIBS correctly said engines-1.1; the engines spelling came from the never-default 3.4.0 branch. install_sw does depend on install_engines and install_modules, so engines-3/ and ossl-modules/ both really exist in DEV_SYSROOT and are just not copied. The new comment # ONIE standardizes on OpenSSL 3.x (SONAME major 3, "engines" dir) is also wrong on that last point.

[mshych]

acpica-tools bump.

acpinames was deleted upstream, and asking for it recurses forever
changes.txt in 20260408 says "Removed support for the acpinames utility", generate/unix/acpinames/ is gone, and upstream PROGS is now acpibin acpidump acpiexamples acpiexec acpihelp acpisrc acpixtract iasl. ONIE still asks for it:

acpica-tools.make
Ln 30–30
ACPIBINS = acpibin acpidump acpiexec acpihelp acpinames acpisrc acpixtract
The upstream build rule is @cd $(BUILD_DIRECTORY_PATH)/$@; mkdir -p obj; $(MAKE) || exit "$$?" — separated by ;, not &&. So the failed cd leaves make in the top directory, where it re-invokes itself with the same PROGS, forever. Reproduced:

/bin/sh: 1: cd: can't cd to generate/unix/acpinames
make[1]: Entering directory '/tmp/dl/x/acpica-unix-20260408'
... (still climbing at make[15] when I killed it at 25s)
Severity is limited because ACPI_ENABLE is never set to yes anywhere in the tree — build-config/Makefile:432 is its only consumer — so no machine builds acpica today. That's exactly why local builds and CI missed it, but it means the acpica bump is unbuildable as written for anyone who opts in.

[mshych]

Other minor items:

1. The coverage gap.
   Three of the bumps are not compiled by any default build, which is worth flagging explicitly since it's the same blind spot that hid the acpica bug:

ipmitool 1.8.19 — IPMITOOL_ENABLE ?= no in build-config/arch/x86_64.make:159, so the x86_64 default and kvm_x86_64 skip it. But 106 machines under machine/ set IPMITOOL_ENABLE = yes. This is the bump with the most new machinery in it (GitHub tag archive instead of a dist tarball, a directory rename in the source step, and ./bootstrap/autoreconf at configure time), and it reaches 106 platforms without any build in the repo exercising it. I'd ask him to confirm he built this one specifically.
tcpdump 4.99.6 and libpcap 1.10.6 — TCPDUMP_ENABLE is never assigned a default anywhere, and zero machines set it to yes. libpcap.make is only ever included from tcpdump.make:12, so both are effectively dead code today. Low risk, but it means neither bump has been compiled.
For contrast, the ones a kvm_x86_64 build does cover are mtd-utils, gptfdisk, btrfs-progs, lvm2, ethtool + libmnl, dosfstools, kexec-tools, dmidecode, keyutils, dropbear, zlib, lzo, popt, openssl, mokutil and libaio — so the bulk of the PR is genuinely exercised. Related: only the DCO check runs on this PR, so the "CI on the prior stack" claim in the description isn't visible from here.

2. Small things to clean up.
   mtdutils-configure-help looks like debugging scaffolding that got committed — it's a real target wired into PHONY that just runs configure --help. Probably meant to be local.

libaio is the only package in the PR that receives neither ONIE_CFLAGS nor ONIE_LDFLAGS, so it builds with upstream's -g -fomit-frame-pointer -O2 and, more notably, without --sysroot=$(DEV_SYSROOT). It only needs libc so it should link against the toolchain's own sysroot, and -g gets stripped later, but it's an odd exception to the convention every other fragment follows. (libmnl passes CFLAGS but not LDFLAGS; that one is genuinely harmless, since automake puts CFLAGS on the link line and --sysroot rides along.)

The stale .sha1 cleanup is inconsistent: the PR deletes six (dosfstools 3.0.26, i2c-tools 3.1.1, mtd-utils e4c8885, openssl 1.0.2l/1.1.1g/3.4.0, pciutils 3.2.1) and leaves fifteen behind (acpica 20150410, btrfs-progs v4.9.1, dmidecode 3.1, dropbear 2020.81, ethtool 3.14, gptfdisk 0.8.8, ipmitool 1.8.18, kexec-tools 2.0.22, keyutils 1.5.10, libpcap 1.10.4, lzo 2.09, popt 1.16, tcpdump 4.99.4, zlib 1.2.11, busybox 1.25.1). Since the repo already keeps unused ones like lvm2-2_02_155.tar.xz.sha1, the deletions are arguably the deviation — either way it should be one rule.

3. The new packages will be uploaded to ONIE mirror.
   Two of the new sources are generated on demand, not uploaded artifacts. keyutils now comes from a git.kernel.org cgit /snapshot/ URL and ipmitool from https://github.com/ipmitool/ipmitool/archive/refs/tags. Neither host guarantees the bytes stay identical across cgit/git version changes (GitHub has broken auto-generated archive checksums before), so the pinned sha1s in upstream/ can start failing without anything in the PR changing. Both verified correct today; no action needed on your side — I'll mirror the tarballs so $(ONIE_MIRROR) is a real fallback.