vyos-1x.git/debian, branch rolling

debian: T9455: drop exfat-fuse in favour of in-kernel exFAT driver

2026-10-11T07:43:36+00:00

The VyOS kernel ships the native exFAT driver (CONFIG_EXFAT_FS=m), so the userspace FUSE implementation is no longer needed. The exfatprogs tools for creating and checking filesystems are kept. The kernel options smoketest now verifies CONFIG_EXFAT_FS is enabled.

wwan: T9350: query ModemManager instead of the QMI control port

2026-09-24T15:28:39+00:00

show_wwan.py drove qmicli against /dev/cdc-wdmN, which assumes the modem exposes a QMI control port. An MBIM modem does not, so every subcommand of "show interfaces wwan wwanN" failed on one - after waiting out a five second transaction timeout, twice over for "signal": $ show interfaces wwan wwan0 signal Command not supported by Modem (10.6s) $ qmicli --device=/dev/cdc-wdm0 --device-open-proxy --nas-get-signal-info error: couldn't create client for the 'nas' service: CID allocation failed in the CTL client: Transaction timed out ports: cdc-wdm0 (mbim), ttyUSB0 (at), wwan0 (net) ModemManager has already probed the modem and speaks whichever protocol it exposes - QMI, MBIM or plain AT. It is a hard dependency of "interfaces wwan" anyway, as conf_mode cannot dial without it, and it answers from its own cache over D-Bus without touching the device: $ show interfaces wwan wwan0 signal Access technology: lte (0.2s) Signal quality: 58% Operator: Telekom.de Registration: home Packet service: attached State: connected

openvpn: T8264: require OpenVPN 2.7

2026-09-12T21:53:49+00:00

Only 2.7 and later can drive the in-tree "ovpn" module. Without a bound, a mirror carrying 2.6 silently reinstates a build where "offload dco" loads the module but nothing uses it.

smoketest: T9014: make configtest serial console image flavor agnostic

2026-09-07T16:35:55+00:00

The configuration tests hardcoded "system console device ttyS0 speed 115200", which only holds for amd64, whereas arm64 images expose the UART as ttyAMA0, so loading these configs produced a diff against the assert data and the tests failed. Replace the hardcoded values in all config test inputs and their assert counterparts with the @SERIAL_DEVICE@ and @SERIAL_SPEED@ placeholders. The vyos-1x-smoketest postinst queries the image flavor and implants the real values once at install time, so the test runner needs no runtime patching. Migration script 31-to-32 now derives the serial device from the flavor, too, instead of assuming ttyS0. This can be observed during vyos-1x package installation while building the ISO image Setting up vyos-1x-smoketest (999.0-14834-g16f1cf457-dirty) ... ... I: Implanted serial console ttyS0,115200 into /usr/libexec/vyos/tests/configs

debian: T9261: warn when byte-compilation fails instead of hiding it

2026-08-30T11:43:37+00:00

The compileall call for the XML reference cache ended in '|| true', so a real failure left no trace at all. Report it on stderr instead, and give py3compile the same treatment so the two adjacent calls behave alike. Deliberately not fatal. Bytecode is an optimisation: if it cannot be built the CLI is slower but entirely correct, so aborting the installation - and with it any image build - would be a worse outcome than a slow shell. This postinst has no 'set -e' and contains no exit statements, so a failing command here has never been treated as fatal; adding one now would make byte-compilation the single exception in the file. Note that compileall exits 0 for a missing directory and only returns nonzero on an actual compilation error, so the warning fires on the case worth knowing about and stays quiet otherwise.

debian: T9261: byte-compile the Python library on install

2026-08-30T11:40:44+00:00

The package ships 188 .py files and zero .pyc. dh_python3 runs and its py3clean counterpart is present in the generated prerm, but the postinst half is silently dropped: debhelper only injects autoscripts where its substitution token appears, and debian/vyos-1x.postinst does not carry one. The package therefore cleans up bytecode that nothing ever creates. Call py3compile directly rather than adding the token, which would also inject the dh_installsystemd enable/start snippets for vyos-router.service and vyos.target and change service enablement at install time. vyos/xml_ref/cache.py needs a second pass. It is generated by update_cache.py from the postinst itself, so it does not exist yet when py3compile walks the package. It is a multi-megabyte dict literal and by far the most expensive single file in the tree to parse. Measured on a fast build host, per interpreter start: vyos/xml_ref/cache.py 216.1 -> 32.1 ms (-85%) import vyos.ifconfig 66.8 -> 29.0 ms (-57%) import vyos.config 31.0 -> 20.4 ms (-34%) Since dist-packages is writable on an installed image, a root-run script would eventually populate __pycache__ by itself; this makes it deterministic and covers live boot, where the overlay is tmpfs and the cost is paid every boot.

kdump: T8868: Implement kernel crash dump support

2026-08-20T13:35:07+00:00

Add new CLI subtree 'system option kdump' with memory reservation and local dump path configuration. Also add 'show system kdump' and 'show system kdump dumps' operation mode commands to get status of the configuration and list of dumps. Extend 'show tech-support report' and 'generate tech-support archive' with kdump service status, active config files and the recently kernel dump file.

Debian: T9216: drop build time dependency on python3-vici

2026-08-16T06:02:20+00:00

python3-vici was installed from the VyOS binary repository and the build time dependency. The sole purpose was only to satisfy the pylint runs - no more, no less. WWith an updated pyproject.toml, the vici import can be ignored from pylint runs - removing a circilar dependency for the Docker image.

container: T7736: pin aardvark-dns to the same minimum version as netavark

2026-08-04T18:36:28+00:00

aardvark-dns ships in lockstep with netavark (both 1.14.0 on the box this was verified against), so pin it to the same >=1.14.0 minimum required for Podman's "host_interface_name" network option to actually take effect.

container: T7736: give container veths a deterministic host_interface_name

2026-08-04T18:36:28+00:00

Podman's default "vethN" auto-naming for a container's host-side veth can collide with VyOS's own "virtual-ethernet vethN" interfaces. Bump the minimum Podman dependency to 5.8 (which supports "host_interface_name" network connect option) and use it to name every non-macvlan container network attachment "veth-" instead, eliminating the collision by construction. Container names too long to fit are shortened to a recognizable prefix plus a short hash of the full name; verify() rejects the rare case where two containers still generate the same interface name. Add "show container interface" to display the resulting name-to-container mapping.