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-10-31T09:58:29+00:00 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. 2026-10-31T09:58:29+00:00 Alex Kudentsov 43482574+alexk37@users.noreply.github.com 2026-10-14T13:46:08+00:00 urn:sha1:153dd688b327c922ec4b371db1fdd11b8ee8cf9e A Hyper-V NIC is known by its MAC alone. One deleted and created again on the same VM - an Azure NIC re-created, or a Hyper-V adapter removed and added - comes back with a new MAC, so nothing on it matched the store: its name stayed reserved, the new NIC got a new name, and its configuration was left on a name with no NIC. cloud-init does not run again on the same instance, so nothing else repairs it. At boot, a vacant name now goes to a new NIC only when the pairing is not in doubt: - exactly one recorded name has no NIC, and exactly one new Hyper-V NIC appeared. With more of either, the order the NICs come up in does not say which replaced which, so nothing is handed over and the names stay reserved, as before; - the name went missing at this pass. The store records which names were missing at the last pass, so a NIC removed for good does not hand its name to a NIC added at a later boot; - the name's own NIC was a Hyper-V one. The store records which names sat on a Hyper-V NIC; a MAC-keyed name can belong to other hardware, and a store written before this was recorded hands nothing over (the boot pass logs that when it holds a name back); - only at boot. On a running system the configuration under a name is not applied to the NIC that takes it, so the hotplug unit passes --hotplug, which names the new NIC like any other and records the vacant name as missing, so the next boot does not hand it over either. An adoption is logged as a warning, reported under 'adopted' in the status file (kept there across hotplug passes while it holds), and repeated by vyos-router, as a slot match is: verify the port before relying on its configuration. 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:57:22+00:00 urn:sha1:2c4b01409a625605009b6e6b29046723a4b2bd57 The interface naming testcases gained a second variant in vyos-build, running on a guest that presents VMware firmware - the one platform where the adapter order comes from the firmware rather than from the PCI topology, and the one the reported regression was found on. CI now runs both variants and reports them separately. The target the existing job calls was renamed along with it. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-07T17:57:17+00:00 urn:sha1:afd4574df20a1cf70607b5e7644773ce336ea095 ESXi does not lay its adapters out in PCI address order. With four or more it puts the fourth on a root port sorting ahead of the first three, so naming by address made Network adapter 4 eth0 and shifted the rest. On the vmware-vsphere OVA that moved the WAN, because cloud-init takes eth0 from the OVF properties. The firmware port label carries the adapter order, and is what the VMware udev rule this series removed matched on. Order by it, ahead of the address, for hardware the hypervisor presented - recognised by its PCI vendor, or by DMI for a model whose IDs are not known here. A physical server labels its ports too and must not be reordered. The label orders, it never identifies: a relabelled adapter is still the same card. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-07T17:57:08+00:00 urn:sha1:fb0e36092529d4d6947749009c00d7ff74b0c551 Three of the tests which write the interface map went through the check for an encrypted configuration volume, and that check asks the running system where its persistent storage is. A build host answers "nowhere", so the tests passed - but anywhere that does have such a volume the write is refused and all three fail, for a reason none of them is about. Pin the answer. What these tests cover is what the map does with a directory, not where the directory came from. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-07T17:57:01+00:00 urn:sha1:710d0a19b25262fe77a6ebd4a62a5c427a1efa6f A recorded slot was enough to claim a name, whatever turned up in it. Pull a modem and put an ordinary USB NIC in the same port and the NIC was handed wwan0 - a name 'interfaces wwan' reads, so a modem's configuration would be applied to a card which can not carry it. The reverse was already handled. Require the device to belong to the namespace the name is read under. If it does not, the name stays reserved for the hardware that earned it and the newcomer is named as what it is. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-07T17:57:00+00:00 urn:sha1:9f75f7bf6c143ee3ba7522d281f3a930634cbd83 Cards rearranged among themselves, or a map edited by hand, leave every name matched to a card the store knows - just not the one it had. That was filed as an ordinary match, indistinguishable from a machine where nothing moved, while the addresses configured under those names had quietly changed cable. Report it separately. Which name goes to which card is unchanged, the slot still decides; only the account of what happened is. 2026-10-31T09:58:29+00:00 Christian Breunig christian@breunig.cc 2026-10-07T17:56:58+00:00 urn:sha1:ccac4ac565796934fa217dbcb6f470819ffb2d36 An interface was passed over as soon as it had a master, which covers a VF datapath but also every bridge, bond and VRF member. Those are still their own card in their own slot, so the naming pass reported them as hardware which had not appeared, on any run made while they were in use. Skip only when the master is a device itself. That is what tells the accelerated path, which belongs to the interface it is enslaved to, apart from a member, which does not.