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-03T18:15:04+00:00 2026-11-03T18:15:04+00:00 Christian Breunig christian@breunig.cc 2026-11-03T18:15:04+00:00 urn:sha1:6ea85bda82cc50809d73c6b422308dd4bc52fb6b serial: T9567: honor booted serial console during 31 -> 32 migration 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-03T13:31:49+00:00 John Estabrook jestabro@vyos.io 2026-11-02T16:31:00+00:00 urn:sha1:4ca0e76fc452aed8c0cb65dc983ba7cd91f10e96 A typo led to passing the function itself, instead of its value. 2026-11-02T18:20:50+00:00 Christian Breunig christian@breunig.cc 2026-11-02T18:20:50+00:00 urn:sha1:98598dfc18f403916678cc532f5c1ae02cd0ec0b op-mode: T9496: verify secure-boot signature when using "add system image" 2026-11-01T18:58:49+00:00 Christian Breunig christian@breunig.cc 2026-11-01T18:53:09+00:00 urn:sha1:f819e149290ea56583b3a4b1cef3c5f86a01ab37 The default route of a DHCP or PPPoE interface changes with an interface-only commit or a lease event, without a commit of the static routes. If it gets the same prefix and distance as a blackhole or reject route, FRR refuses the reload and every static route added with it is lost. The rendered FRR configuration is now checked for a blackhole or reject route next to any other route of the same prefix and distance, per VRF and table. Such a blackhole or reject route is not rendered, and an error naming it is logged to the journal. Prefixes are compared in their normalized form, as FRR stores them. 2026-10-31T10:51:09+00:00 Christian Breunig christian@breunig.cc 2026-10-31T10:51:09+00:00 urn:sha1:dfd2b46ff41af4edf2fd4a2a1b9fae1efe48c145 T3871: bind interface names to hardware slots instead of hw-id 2026-10-31T10:15:26+00:00 Christian Breunig christian@breunig.cc 2026-10-31T10:15:26+00:00 urn:sha1:c15665309e2991e6de5f99bf375de83d167c4248 frrender: T9442: cache the FRR configuration only after it was applied 2026-10-31T10:10:19+00:00 Christian Breunig christian@breunig.cc 2026-10-31T10:10:19+00:00 urn:sha1:8338931cf435761c12e923d98b857d124e74ceab A failed reload only dropped the in-memory cache. The record of the configuration FRR runs still held the previous one, so the DHCP render helper skipped a return to it while FRR kept a part of the failed configuration. After a rejected reload test, the rendered file also kept the rejected configuration. Change detection now also requires the rendered file to match the applied one, and a failed reload removes that record. The next commit then renders and reloads FRR again, even when it returns to the previous configuration. A smoketest stops FRR during a commit and verifies that committing again brings the configuration into FRR. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-28T21:17:13+00:00 urn:sha1:6bef88ed9c11210855689bd78a39ee032fb27731 Only the first matching link file is applied, and ours sets just the name, so the address policy shipped with the system never ran on any interface. Hardware with a permanent address was unaffected - there was nothing to apply - but a modem, which has none, was left on whatever random address its driver had picked that boot, a different one every time. Spell the policy out again. A permanent address is still kept where there is one, and a device without one is given an address derived from the machine and the device, which is the same on every boot of that machine. An address set through the CLI is applied later and is unaffected. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-28T21:16:59+00:00 urn:sha1:015663a3188727e2a16900cf5496c931770979a2 A modem that reports no permanent address is given a random one by its driver at every probe. That address was read as if it identified the hardware, so it never matched what was recorded and the modem was taken for a different card in the same socket on each boot, warning the operator to check a port nobody had touched. The map also kept being rewritten with the address of the boot before, so it could never settle. Keep no address for a modem, and compare one only where there is one. An address recorded by an earlier version is dropped on the next pass, so a machine already carrying one needs nothing done to it. A card whose address really did change is still reported.