It copies the images between updates, but it can't properly clean up the old data/garbage, even when the old VyOS images were deleted.

PR for VyOS 1.3 (equuleus) https://github.com/vyos/vyos-build/pull/290

1.4 shipps

@m1nus FRR used in VyOS gets updated frequently. Can you please try a more recent rolling release?

This manual step just got removed by f3956a5358a71 which simply exports active images as oci-image and re-imports the image after the filesystem got migrated. No manual interaction by the user required.

In T4891#139596, @Viacheslav wrote:

Which version?

Which version?

PR https://github.com/vyos/vyos-1x/pull/1725

@rob Thanks

Hello everyone,

The "incompatibility" can be resolved by running the following script prior to upgrading to a new image:

I don't think the commit comment adequately justifies why we can't pull the image from the internet when starting the container if it does not exist within the on-disk store shared between VyOS images.

the change worked for my example.

this appears to be impacting 1.4:latest, it it possible to tag that project for triage?

I did some extra test , I've missed a command , this solution works as expected . FRR backport 8.4.1

At first look, at least it works, but it requires more tests and improvements

set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 check target '192.168.122.1'
set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 check timeout '5'
set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 check type 'icmp'
set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 interface 'eth0'

Fix pushed for schema generation.

using 8.5-dev ....it doesn't work ...even is worgs than the initial case, it's not able to show any local prefix on l3vpn bgp :

PR: https://github.com/vyos/vyos-1x/pull/1718

Backport for this PR. I am not running 1.3 so YMMV.

Had a quick look at the 1.3 implementation and it seems the bug isn't present there. So no back-porting needed @c-po

After screwin up the previous PR:
https://github.com/vyos/vyos-1x/pull/1712

https://github.com/vyos/vyos-1x/pull/1711

FRR fixed it , it seems the issues were associate with next-hop tracking protocol when a prefix is imported using network command (if we used redistributed connected next-hop tracking will not be done):

yes, it's already configured , share here my full configuration on FRR :

Certbot (specifically certbot/dns-cloudflare container) is another situation where a command & argument is required. Currently, I get around it by running a task-schedule to run the podman command directly (its a task because the container runs to completion). But having a way to do this via VyOS CLI would be extra helpful.

Relevant PR:

@zsdc Yeah I see the bug now, I made the assumption that the config level by default was set to the bond (i.e. interfaces bonding bondX), good catch. Tested in a VM and I can confirm no regression in existing bonding behavior.

I agree that internal logic can be better, but I think that in this specific case the problem is much simpler: https://github.com/vyos/vyos-1x/pull/1708

I couldn't find an effective way to get all the new members added to the bond via config at commit-time without comparing the members to the running/effective config (the function leaf_node_changed() only gets the removed interfaces). Not doing so either causes runtime commit failures (where the bond fails to add/remove members) or boot failures (where the bond fails to add all it's members on boot).

Did you tried no bgp network import-check ?

FRR issues regarding this incorrect behavior ,

PR: https://github.com/vyos/vyos-1x/pull/1707

Related task IPsec syntax overhaul T4118