Weft now supports Ubuntu 26.04

A Weft site can now run on Ubuntu 26.04 LTS as well as 24.04. The install wizard accepts both, and a fresh 26.04 machine enrols the same way a 24.04 one always has. Nothing changes for sites already on 24.04: they keep working, and they do not need to move.

Getting there was not just a matter of changing a version check. 26.04 brings a new major version of FRR, the routing software every Weft site runs, and testing it turned up two problems that would have hurt a live network. Both are fixed. This post covers what changed, how we tested it, what we found, and how to move an existing site when you are ready.

What changes in 26.04, for a router

Most of 26.04 does not matter to a Weft site. These parts do:

It also brings Linux kernel 7.0 and systemd 259. The FRR jump is the big one: two major versions, with changes to BGP, EVPN and the way configuration is applied. That is where both problems were.

How we tested it

We built fresh Ubuntu 26.04.1 sites in a throwaway test organisation on EC2 and ran them through the things customers use:

• LANs, VLANs and DHCP on the site's own ports.
• Who-can-reach-what policy, both allowing and denying traffic between hosts.
• Internet exit, with the 26.04 site as the organisation's way out to the internet.
• OSPF with MD5 authentication, and eBGP with a password and an import list, to a customer router running FRR 8.4 on Ubuntu 24.04. Many networks will have that mix for a while: a new FRR on one side, an older one on the other.
• An in-place upgrade of a working 24.04 site to 26.04.

All of it passed. Then we tried it on real hardware: a small home-office box, a Ryzen NUC, upgraded in place from 24.04 to 26.04.1. It is a Wi-Fi access point as well as a site, with VLANs running to a switch and access point behind it. After the reboot, all of it came back as it was.

Two FRR 10.5 problems, both fixed

Both only happen on 26.04, and both are fixed in Weft agent 0.182.0. The current release is 0.183.0. Each fix has a regression test that fails on the old code. If you run FRR on 26.04 yourself, without Weft, the first one may well affect you too.

1. systemctl reload frr can drop every session

On 26.04, systemctl reload frr returns Job for frr.service canceled. The unit is left stuck in stop-sigterm, and when its two-minute timeout runs out, systemd kills every routing daemon with SIGKILL. Every BGP and EVPN session drops and FRR starts again from scratch. A reload, which should apply a change without disturbing anything, becomes a two-minute wait followed by an outage.

We reproduced it on a plain 26.04 machine with nothing of Weft on it, so it is not something our agent does. On 24.04 the same command reloads cleanly.

The Weft agent no longer reloads through the unit. It runs FRR's own reload script directly:

/usr/lib/frr/frr-reload.py --reload /etc/frr/frr.conf

It does this through systemd-run, outside the agent's own sandbox, because the script needs to write to /var/log/frr and /run/frr. If the script is not installed, the agent falls back to the old call. If you manage FRR on 26.04 by hand or with your own tooling, calling frr-reload.py yourself avoids the problem in the same way.

2. A configuration line FRR 8.4 ignored and FRR 10.5 refuses

The agent wrote the routed EVPN identifier (the L3VNI, vni 200) in two places: under the tenant's VRF, where it belongs, and in the global EVPN address family as well. FRR 8.4 accepted the extra line and ignored it. FRR 10.5 rejects it:

Failed to create L2VNI 200, it is configured as L3VNI

That error alone would be harmless. What made it serious is what happens next: vtysh skips the rest of bgpd's part of the change. In testing, a new BGP import list reached zebra and ospfd but never reached bgpd. Meanwhile show running-config looked complete, so the change appeared to have worked.

The fix is simple: the agent no longer writes that line for the L3VNI. The lesson is broader. A configuration change that partly fails can look exactly like one that succeeded, so it is worth checking the daemon that should have taken the change, not only the summary view.

Moving an existing site to 26.04

You do not have to. 24.04 remains supported. If you want to, this is how.

The Weft installer switches off Ubuntu's release-upgrade prompt, so that a site never jumps to a new Ubuntu release by accident. Moving one is therefore a deliberate step:

1. Check the agent version. Every site in the organisation should be on agent 0.182.0 or later. The current release is 0.183.0.
2. Allow the upgrade. In /etc/update-manager/release-upgrades, set Prompt=lts.
3. Run it. Run sudo do-release-upgrade. When it asks about changed configuration files, keep the existing ones.
4. Reboot when it finishes.
5. Switch the prompt off again. Set Prompt=never in the same file.

Expect the site to be out for 20 to 40 minutes, so pick a quiet time. Other sites are not touched, but anything that passes through this one stops while it upgrades. If the site is the hub your remote devices connect to, a second hub (see a second office and hub failover) lets them carry on through another site while it upgrades.

New sites

For a new site, install either release and enrol it as usual. If you are choosing today, 26.04 gives you the newer kernel and FRR.

For the wider picture of what runs on a site, see how Weft works. To see a running organisation first, look round the demo console: no account, nothing to install.