Welcome! Thanks for beeing an early adopter / tester.

I am very happy to report that the issue id resolved. The router now boots up fully without intervention once again.

Completed!

Awesome! That's really quick turnaround! I'll give it a try when the newer build appears.

Unfortunately this is not possible with WIDE DHCPv6 client

I just started a new ISO build - should be done in 40 minutes!

I have consulted some documents of vyos about DNAT of IPv4, and I don't understand why there seems to be SNAT content in the DNAT IPv4 syntax of vyos, and what is the meaning of supporting the prefix format address setting of dsddr in DNAT syntax? Is there something wrong with me?

Use cases for sNPT testing

I can reproduce it with your supplied config on a fresh router - only on boot time. Will check it out. Thanks for the config.

Entering configure mode and then typing load and then commit brings everything up to what the config in config.boot specifies, and the running configuration shows the correct contents for eth1. It brings the router up to where it should have been at boot.

Let me spawn a fresh router and try again. The meatime, then you boot into thcomfiguration Error, please kog in, enter configure mode and type: load followed by commit and show the results. Thanks

Unfortunately, the problem does not appear to be fixed in the latest rolling build, vyos-1.3-rolling-202008031923-amd64.iso.

Thank you for the feedback, even if it was not what I was hoping for !

1.3-rolling-202008031923 Fixes this issue this can be closed. Thanks @c-po

This is the same issue as T2740

I tried the latest version 1.3-rolling-202008030118 and now I get an address on the outside interface but it doesn't delegate the prefix to the lan interface.

The main idea to add some automation logic for calculation:

vyos@vyos# set system sysctl profile 
Possible completions:
   <text>       Sysctl profile
   Profile1     
   Profile2     
   auto

Fixed in latest rollings

Fixed in latest rolling.

Hi @jack9603301 , in normal condition all scripts and files should be migrated from /config/ directory on the migration process.

Just to make this a bit clearer. A short how-to to reproduce the bug in 1.3-rolling-202008031114 with empty config:

set firewall ipv6-name WAN6_IN6
set firewall ipv6-name WAN6_LOCAL6
set interfaces tunnel tun1 6rd-prefix '2607:FA48:6ED8::/45'
set interfaces tunnel tun1 6rd-relay-prefix '24.225.128.0/17'
set interfaces tunnel tun1 address '2607:FA48:6ED8:8A50::1/60'
set interfaces tunnel tun1 description 'Videotron 6rd Tunnel'
set interfaces tunnel tun1 encapsulation 'sit'
set interfaces tunnel tun1 firewall in ipv6-name 'WAN6_IN6'
set interfaces tunnel tun1 firewall local ipv6-name 'WAN6_LOCAL6'
set interfaces tunnel tun1 mtu '1480'
set interfaces tunnel tun1 multicast 'disable'
set interfaces tunnel tun1 parameters ip ttl '255'
set interfaces tunnel tun1 remote-ip '24.225.128.1'
set interfaces tunnel tun1 local-ip '24.225.136.165'
commit

leads to the error:

Can not set "local" for tunnel sit tun1 at tunnel creation

and the same but without the local-ip option leads to the Python traceback.

That sounds hopeful! I will try it in a few hours and report back.

This could be closed in its current form, i'll open a new ticket om the missing parts

Works like a charm when commit is reverted.

Most of the services have been migrated to systemd and the configuration files have been moved to /run so they won't survive a reboot.

Wireless interface is entirely rewritte in rolling - please retest and open appropriate new bug reports when situation persists.

I guess this can be considered complete @runar ?

Fixed in latest versions

Fixed in latest versions.

@hagbard this is a great idea - I did not thought about it.

Works fine on latest rolling, thx!

Works as expected