Page MenuHomeVyOS Platform

Error in migrating configuration from VyOS 1.4
Closed, ResolvedPublicBUG

Description

Hello,

I have tried to upgrade from 1.4-rolling-202304290647 to the last 1.5 rolling release, but the process fails bacause of some error in migrating my configuration. Unfortunately I do not have any detail about the specific error, after the upgrade I could not even log in. I attach the full config.

Thanks,
Giuseppe.

{F3891049}

Details

Difficulty level
Unknown (require assessment)
Version
1.5-rolling-202311020022
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

I have tried to migrate to one of the last nightlies and now the situation is much better: vyos reboots, does not hang and I can ssh.
There is still an error in the migration script:

Dec 09 23:53:59 vyos vyos-router[1345]: Starting VyOS router: migrate
Dec 09 23:53:59 vyos vyos-router[1749]: Migration script error: /opt/vyatta/etc/config-migrate/migrate/dns-dynamic/2-to-3: [Errno 1] failed to run command: ['/opt/vyatta/etc/config-migrate/migrate/dns-dynamic/2-to-3', '/opt/vyatta/etc/config/config.boot']
Dec 09 23:53:59 vyos vyos-router[1749]: returned: - op: set path: ['service', 'dns', 'dynamic', 'name'] value: None replace: True
Dec 09 23:53:59 vyos vyos-router[1749]: - op: set path: ['service', 'dns', 'dynamic', 'address', 'eth0', 'service', 'ovh', 'address'] value: eth0 replace: True
Dec 09 23:53:59 vyos vyos-router[1749]: - op: copy old_path: ['service', 'dns', 'dynamic', 'address', 'eth0', 'service', 'ovh'] new_path: ['service', 'dns', 'dynamic', 'name', 'ovh']
Dec 09 23:53:59 vyos vyos-router[1749]: - op: copy old_path: ['service', 'dns', 'dynamic', 'address', 'web', 'web-options'] new_path: ['service', 'dns', 'dynamic', 'address', 'web', 'service', 'ovh', 'web-options']
Dec 09 23:53:59 vyos vyos-router[1749]: - op: delete path: ['service', 'dns', 'dynamic', 'address', 'web', 'web-options']
Dec 09 23:53:59 vyos vyos-router[1749]: - op: set path: ['service', 'dns', 'dynamic', 'address', 'web', 'service', 'ovh', 'address'] value: web replace: True
Dec 09 23:53:59 vyos vyos-router[1749]: exit code: 1.

Here is my dynamic DNS configuration:

vyos@vyos# show service dns dynamic
 interface eth0 {
     service ovh {
         host-name xxxxxxxxxx
         login xxxxxxxxxxx
         password xxxxxxxxxxx
         protocol dyndns2
         server www.ovh.com
     }
 }
 interface eth1.11 {
     service ovh {
         host-name xxxxxxxxxxxx
         login xxxxxxxxxxxx
         password xxxxxxxxxxxx
         protocol dyndns2
         server www.ovh.com
     }
     use-web {
         url checkip.dyndns.com
     }
 }

I have tried with the rolling release vyos-1.5-rolling-202312080024.

SrividyaA changed the task status from Open to Confirmed.Dec 11 2023, 7:09 AM
SrividyaA added a subscriber: SrividyaA.

@giuavo , can you please test in latest rolling release

Sure, I will do that and report here the outcome.

I have tried to move to the rolling version vyos-1.5-rolling-202312231415-amd64.

Unfortunately, I can observe a step back to the situation I had when I opened this case: the configuration migration fails and I cannot even login.

The only errors appearing during the boot are the following:

[   28.859422] vyos-router[1053]: Mounting VyOS Config...done.
[   42.462559] vyos-router[1053]: Starting VyOS router: migrate configure failed!
[   43.279522] vyos-config[1058]: Configuration error

Not being able to login, I do not have access to any additional information.

I guess the error due to the ddns configuration has been fixed and the "old" error appears again.

Is there a way to run the migration scripts directly on my configuration (attached to this issue)? That would make much easier the debugging, without trying a full system update.

On the newest system you can use load /path/to/config

That means I should create a new VyOS instance and then load my current configuration in order to spot any migration error. I can try that.

At the same time, it would be really useful to have a kind of standalone application allowing to verify the current configuration before an upgrade, with the goal to detect problems as soon as possible.

I have followed your suggestion: a fresh VyOS install in a VM and tried to load the current configuration. Here are the errors I get:

[ service dns dynamic name service-ovh-eth1-11-web web-options url checkip.dyndns.com ]
"checkip.dyndns.com" is not a valid URL


[ service dns dynamic name service-ovh-eth1-11-web web-options url checkip.dyndns.com ]
Invalid HTTP(S) URL format

[[]] failed

[[protocols static]] failed
[[protocols failover]] failed
[ service snmp ]
SNMP listen address "<IPv6 address>" not configured in default
vrf!

[[service snmp]] failed
[[service dns forwarding]] failed

I have then added the http protocol to the checkip URL and removed the IPv6 address from the snmp listen-address entry (that IP is not available in the new test VM). Only then the commit of the configuration was successful.
It looks like the other errors were caused by previous failures.

Whenever I can have a downtime in my home network, I will try again to load the configuration on the working system after fixing the checkip URL.

@indrajitr Could you take a look? As I remember you are working on it.

I have followed your suggestion: a fresh VyOS install in a VM and tried to load the current configuration. Here are the errors I get:

[ service dns dynamic name service-ovh-eth1-11-web web-options url checkip.dyndns.com ]
"checkip.dyndns.com" is not a valid URL


[ service dns dynamic name service-ovh-eth1-11-web web-options url checkip.dyndns.com ]
Invalid HTTP(S) URL format

[[]] failed

Will have to make the migration accommodate URLs without a protocol specifier. Will address this.

protocols static failed
protocols failover failed
[ service snmp ]
SNMP listen address "<IPv6 address>" not configured in default
vrf!

This is probably something else going on with SNMP. I don't have a setup with SNMP configured at the moment.

service snmp failed
service dns forwarding failed

I have then added the `http` protocol to the `checkip` URL and removed the IPv6 address from the `snmp listen-address` entry (that IP is not available in the new test VM). Only then the commit of the configuration was successful.
It looks like the other errors were caused by previous failures.

Whenever I can have a downtime in my home network, I will try again to load the configuration on the working system after fixing the `checkip` URL.

Thanks @giuavo! But can I request you to keep the old config around and retest the migration after web-options URL migration is fixed? I don't have those old installations and configurations anymore to validate :)

Happy new year!

I have just tried version 1.5-rolling-202401030023 and the dynamic DNS configuration migration is not causing any error anymore. Here is how the migrated configuration looks like:

dynamic {
    name service-ovh-eth0 {
        address eth0
        host-name xxxxxxx
        password xxxxxxx
        protocol dyndns2
        server www.ovh.com
        username xxxxxxx
    }
    name service-ovh-eth1-11-web {
        address web
        host-name xxxxxxx
        password xxxxxxx
        protocol dyndns2
        server www.ovh.com
        username xxxxxxx
        web-options {
            url https://checkip.dyndns.com
        }
    }

The starting configuration was:

dynamic {
    interface eth0 {
        service ovh {
            host-name xxxxxxx
            login xxxxxxx
            password xxxxxxx
            protocol dyndns2
            server www.ovh.com
        }
    }
    interface eth1.11 {
        service ovh {
            host-name xxxxxxx
            login xxxxxxx
            password xxxxxxx
            protocol dyndns2
            server www.ovh.com
        }
        use-web {
            url checkip.dyndns.com
        }
    }
}

At the same time, I had anyway to remove the not-existing listening address from the snmp configuration (that is an IPv6 address that is not available in my test VM). Is that a good reason for the configuration migration to fail? Would just a warning be enough? Just asking, maybe that is just the behavior that you expect to see in such a scenario.

Viacheslav claimed this task.