I've created a PR for this: https://github.com/vyos/vyos-1x/pull/3655

I've created a PR with a very simple fix: https://github.com/vyos/vyos-1x/pull/3654

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

I can now reproduce the issue. The reason I was unable to reproduce this was I missed out that you use an ACME certificate

This is not the latest image. Please use 1.5-rolling-202406130020

The only reason I see why this can happen is that the config.boot format can be unexpected. But this should not happen anymore, because now Cloud-init always runs migrations before doing any work, which should always add required metadata if the original file is a valid VyOS config.

For 1.5-rolling-202406120020 it doesnt work even without having a vrf:

vyos@vyos-a# run update geoip 
Downloaded GeoIP database
Error: GeoIP failed to update firewall
[edit]
vyos@vyos-a#

Unfortunately there is no explaining logging (at least I didn't found any).

In upgrade process

Can you please retest with the latest ISO as additional fixes got added to the code.

@a.apostoliuk this one should be resolved in the current rolling release, if you're able to check it out?

I have https://github.com/vyos/vyos-1x/pull/3616 and https://github.com/vyos/vyos-1x/pull/3637 as works in progress.

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

Please share the output of dpkg -l | grep vyos-1x

Please share your full ipsec configuration

This was merged Thu May 30 16:35:43 2024 +0200 and your image is from 2024-05-30.

I may have figured something out in https://vyos.dev/T4694.

It looks like outbound encap can be matched via routing expressions:

In T6448#191159, @Viacheslav wrote:

In T6448#191156, @HappyShr00m wrote:

I have not used it since I thought it would delete even running instances or stop them. if it doesn't, then may I suggest adding a description to the command to indicate that it will not impact the running containers. thanks

It should not affect running container images.
Try it on some test instance.

I don't know how to solve this problem. I suggest rejecting the problem.

In T6448#191156, @HappyShr00m wrote:

I have not used it since I thought it would delete even running instances or stop them. if it doesn't, then may I suggest adding a description to the command to indicate that it will not impact the running containers. thanks

In T6448#191124, @Viacheslav wrote:

It will delete all unused images
Did you try this command, as the command does not work?

Which original podman command are you expecting?

It will delete all unused images
Did you try this command, as the command does not work?

If you add this config after the server is configured, it works as it requires a restart of the service

sudo systemctl restart accel-ppp@pppoe.service

Or reconfigure the service again

Add the set of commands to reproduce.

I've created a PR for this that fixed a mistake with my original patch: https://github.com/vyos/vyos-1x/pull/3570

In https://github.com/vyos/vyos-rolling-nightly-builds/releases/tag/1.5-rolling-202405301617 wrote

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

Apple IOS now recognizes multiple CAs inside the profile

With this change all CAs in the list are rendered into the template.

Tested as working in: VyOS 1.5-rolling-202405280020

@mersl thanks for confirm.

just some show commands with test results on my lab

very cool! I just rebuild a 1.5-rolling and upgraded my lab router and voila - works as expected ;-)

we've added this ability to configure the topology on isis :

Are you sure your DHCP server honors the no-default-route option?
I may be wrong, but I think the no-default-route just sets an option in the DHCP request, asking the DHCP server to not send back the default route.
I have the same issue with my ISP, and they told me they will always send a default route via DHCP.
I have solved the issue using DHCP hooks.

We will bind the code to a new command in operating mode (for example show ports). This will allow you to use the nmap command from operating mode. Just a convenient feature.