Hello,
This configuration is not my entire configuration, I just spun up a VM with interface and firewall configuration to replicate this bug. I am also not using the same pre-netfilter syntax version on my production as this VM, however both exhibits the same behavior.
This is what I had before upgrading to vyos-1.4-rolling-202308240020-amd64.
The new config.boot are identical to the pre-migration one which is odd since this is not the new syntax.
The actual running config only contains firewall groups and nothing else.
If I enter the configuration mode and execute load, I get the follow error message:
vyos@vyos# load Loading configuration from 'config.boot' Traceback (most recent call last): File "/usr/libexec/vyos/vyos-load-config.py", line 86, in <module> virtual_migration.run() File "/usr/lib/python3/dist-packages/vyos/migrator.py", line 213, in run cfg_versions = self.read_config_file_versions() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/vyos/migrator.py", line 65, in read_config_file_versions cfg_versions = component_version.from_file(cfg_file, vintage='vyos') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/vyos/component_version.py", line 80, in from_file version_dict = from_string(line_in_config, vintage=vintage) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/vyos/component_version.py", line 57, in from_string raise ValueError(f"malformed configuration string: {string_line}") ValueError: malformed configuration string: // vyos-config-version: "bgp@4:broadcast-relay@1:cluster@1:config-management@1:conntrack@3:conntrack-sync@2:container@1:dhcp-relay@2:dhcp-server@6:dhcpv6-server@1:dns-dynamic@1:dns-forwarding@4:firewall@10:flow-accounting@1:https@4:ids@1:interfaces@30:ipoe-server@1:ipsec@12:isis@3:l2tp@4:lldp@1:mdns@1:monitoring@1:nat@5:nat66@1:ntp@3:openconnect@2:ospf@2:policy@5:pppoe-server@6:pptp@2:qos@2:quagga@11:rip@1:rpki@1:salt@1:snmp@3:ssh@2:sstp@4:system@26:vrf@3:vrrp@ [edit]
I went from version 1.4-rolling-202308111749 to 1.4-rolling-202308240020 on the test VM.
On my production system I went from 1.4-rolling-202307060317 to 1.4-rolling-202308180646 with the exact same outcome.