VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=rolling 2026-11-03T16:12:15+00:00 2026-11-03T16:12:15+00:00 Christian Breunig christian@breunig.cc 2026-11-03T15:36:31+00:00 urn:sha1:44d929a1b973d3f4131d25d7f9cd7b69c3cf3514 An installation that still carries a legacy 1.3.x image keeps GRUB in compat mode. The GRUB structure update then rewrites the GRUB vars on every boot, before the config migration runs. The migration relied on these vars to detect a serial boot console and silently skipped setting "system console device ttyS0 kernel" after an upgrade from 1.4. The console code then fell back to tty0, so the next boot lost all serial output. On compat GRUB installs, the migration now uses the console the kernel booted with (the last console= argument). Installs using the current GRUB layout keep reading the GRUB vars, so a one-off console choice from the GRUB boot options menu is not persisted into the config. 2026-11-03T05:00:16+00:00 Christian Breunig christian@breunig.cc 2026-11-03T05:00:16+00:00 urn:sha1:85fb049e83f0a5d6842bc18efcd02ffd35172934 Commit ed8f5cf44 ("T9477: remove no longer needed executable bit from migration scripts") removed the executable bit from all migration scripts, as the migration runner loads them as modules, and made the build abort if any is executable. The 34-to-35 script added in e12776075 ("interfaces: T3871: remove the hw-id node and migrate its bindings") was developed in parallel and not covered, so it still carried mode 755. It now carries mode 644 like the rest. 2026-11-02T18:45:25+00:00 Christian Breunig christian@breunig.cc 2026-11-02T18:45:25+00:00 urn:sha1:f063cab4af3196fb6a81cc35837bfffcd6b8cfd6 T9477: remove no longer needed executable bit from conf_mode/migration scripts 2026-11-01T18:58:49+00:00 Christian Breunig christian@breunig.cc 2026-11-01T18:50:48+00:00 urn:sha1:39f31b58157d89edc077392d436c12a42ab1d726 Verification also refused a blackhole or reject default route next to the default route of a PPPoE interface, or of a DHCP interface once its lease had a router. Those routes change without a commit of the static routes, by an interface-only commit or a lease event. The check missed those cases, depended on the lease, and was not covered by the migration, so a PPPoE configuration with a plain blackhole default route failed to load after the upgrade. Only conflicts between static routes are refused now, the renderer handles the interface default routes. The default distance is looked up only for a route without a distance. The migration comment claimed FRR keeps the route configured first. A conflict makes frr-reload lose every static route of that reload. A unit test covers the migration, and the config test asserts which route was disabled. 2026-11-01T18:58:49+00:00 Ruben Herold ruben@puettmann.net 2026-10-29T14:22:24+00:00 urn:sha1:39507a51f9ec0b22796d1ddb591812fc4c6ac903 FRR staticd refuses a blackhole or reject route next to a next-hop or interface route of the same prefix and distance. VyOS accepted the combination, the commit failed later in frr-reload and on some FRR versions the config manager stalled. Add a disable node to blackhole and reject. Verification refuses an enabled blackhole or reject route next to a next-hop, interface or dhcp-interface route of the same distance, and blackhole together with reject, in routes, tables and VRFs. The same applies to the default route of a PPPoE interface and of a DHCP interface that has a gateway. A commit that changes only such an interface does not run the check, frr-reload refuses it and the commit is rolled back. A config migration sets disable on the route FRR did not apply, so existing configurations keep loading and route as before. 2026-10-31T09:58:29+00:00 Alex Kudentsov 43482574+alexk37@users.noreply.github.com 2026-10-14T13:45:45+00:00 urn:sha1:639d575ad258f6f6ba629a0c50a710b736e4911d On Azure every Hyper-V NIC shares one ID_PATH and has no slot, so it is keyed on its MAC. Its accelerated-networking VF carries the same MAC and matched the NIC's .link file, so udev tried to give the VF the NIC's name. The .link file of a Hyper-V NIC now also matches Driver=hv_netvsc, so the VF cannot match it. This holds for a lone NIC keyed on the VMBus path too. A NIC absent at a pass cannot say what it is, so its file keeps the pin it already carries. NICs that are not Hyper-V ones get no Driver line, and their files do not change. The 34-to-35 migration passes the hardware it found, so the pin is written on the first boot of an upgrade too. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-07T17:56:39+00:00 urn:sha1:e12776075f2dde8026f523e0d86f327bac7d398c The node decides nothing now that the mapping store owns naming, and keeping it would leave two sources of truth free to disagree. Existing bindings are carried into the store by matching each hw-id against the permanent address of the hardware present, so a box named by an older release keeps exactly the names it had. Entries whose hardware is absent are skipped - the configuration may well originate from another machine. The hardware address of an interface is now read off the device rather than from the configuration. 2026-10-28T13:39:00+00:00 Nawer Kezal nawer@kezal.fr 2026-10-22T19:30:43+00:00 urn:sha1:035a82fa93d1d9b79584e8902205d0da9d8da6e6 2026-10-24T07:04:43+00:00 Christian Breunig christian@breunig.cc 2026-10-18T07:11:50+00:00 urn:sha1:ed8f5cf44b2e6002c849fcdabe7373d8d17dfdf4 Migration scripts are loaded as modules by the migration runner and are no longer executed individually. Drop the executable bit and make the build abort if any migration script is executable. 2026-10-18T09:34:21+00:00 Alex Kudentsov 43482574+alexk37@users.noreply.github.com 2026-10-08T15:27:36+00:00 urn:sha1:60aabdc9587700a326c8e9df06f09ba0c60c5435 "protocols ospf parameters opaque-lsa" and "protocols ospf capability opaque" are two CLI nodes for one FRR setting, FRR's "capability opaque". Keep "capability opaque" only. The migration script ospf/2-to-3 sets "capability opaque" where "parameters opaque-lsa" exists in the default VRF, and deletes the old node (and the "parameters" node when it is left empty). FRR refuses opaque LSAs outside the default VRF, so in a VRF instance the option never took effect: for a VRF the migration drops both "parameters opaque-lsa" and a plain "capability opaque" instead of moving the value into a node FRR would refuse at the next commit. The template renders the line from "capability opaque" only; it rendered the alias form "ospf opaque-lsa" for the old node, which frr-reload found missing in the running config on every reload: while only the old node was set, every commit that reloads FRR reset all adjacencies of that OSPF instance. Tests: a migration unit test (global instance, VRF instance, a VRF with "capability opaque" set directly, both nodes set together in a VRF, and global+VRF independence), the vrf-ospf config test (now carries "parameters opaque-lsa" in both the default instance and a VRF instance; the VRF instance is expected to lose it with no replacement), test_ospf_02 uses the new node, and test_ospf_21 checks the generated FRR config.