let me try to put a quick patch for you.

we can fix it in two ways: undo the commit which check the return code of the program, hiding the issue and add a first BIG PRINT warning stage or find the root cause and fix it (harder).

Can you send me your previous config.boot file prior of the upgrade? I'm happy to take a look

Please add r8169 as well. The config failed to load at boot after upgrading to latest rolling because of this error. The script should check if the interface supports pause and silently continue if it doesn't, otherwise maintaining a list of all pause-unsupported interfaces is going to be next to impossible. I suspect a lot more of them don't.

I'll open a new task for it.

Oh, I see my changes were already pulled in, missed that!

I suspect the driver blacklist won't be enough for a lot of users. A lot of very common ethernet cards don't support setting pause frames.

In T2158#56542, @jjakob wrote:

Please add r8169 as well. The config failed to load at boot after upgrading to latest rolling because of this error. The script should check if the interface supports pause and silently continue if it doesn't, otherwise maintaining a list of all pause-unsupported interfaces is going to be next to impossible. I suspect a lot more of them don't.

Please add r8169 as well. The config failed to load at boot after upgrading to latest rolling because of this error. The script should check if the interface supports pause and silently continue if it doesn't, otherwise maintaining a list of all pause-unsupported interfaces is going to be next to impossible. I suspect a lot more of them don't.

Closing, 1.3 has rewritten the perl code from scratch in python, but the functionality should be the same.

We could make compat-names a configurable option that defaults to disabled, e.g. "set interfaces openvpn vtunX tls compat-names {no-remapping}"

The implementation mostly works, but still behaves unexpectedly when keys don't have a BEGIN EC PRIVATE KEY or BEGIN RSA PRIVATE KEY, but have just a plain BEGIN PRIVATE KEY, which is valid for both EC and RSA (and is the default output format for openssl ec -out, for example when removing a passphrase from the key). We need to switch to checking the key type by actually trying to read it with openssl and checking its error status.

I'm not expecting a persisted-across-reboots FRR config — hence suggesting tmpfs — so when the system boots there is nothing there. Obviously something would need to create the (empty) FRR config files in tmpfs before running FRR, otherwise I expect all the FRR daemons will fail to start.

A router reboot last week reminded me to never to write mem in vtysh (but after looking it was automatic bij me :( )
The router booted with the configuration in FRR already loaded, and then Vyos tried to populate FRR based on the Vyos configuration and everything was broken :-)
It didn't help that the configuration i saved in FRR was a couple of months old.

We've seen this recently on bleeding-edge (yesterday's version) of 1.3. I'm currently investigating what tripped ospf6d, but I suspect it's going to be some Ubiquiti routers spewing their nasty OSPFv3 implementation.

ok, thanks! I can test on xen aswell, when the fix is in 1.3/rolling.

This fix is for 1.3 rolling only and should not be a problem on 1.2 as long as users do not explicitly set speed/duplex.

does this also affect vyos 1.2, or only 1.3/rolling?

The code should be in the op-mode script rather than the class.But the PR was merged in, so I suppose it's ok.

https://github.com/vyos/vyos-1x/pull/263
https://github.com/vyos/vyatta-cfg-system/pull/121

PR262 should fix that last one @alien

I believe your default settings are not bad as, in our case, we are part of the ntp pool and our kit will use our own NTP servers :-)

Hello,
It's been a long time since the last comment.
Are there any real plans to add NETFLOW module to the next version (rolling release) ?
@mickvav Are you still using VyOS and this module? Would you be able to send me a version for 4.19.112-amd64-vyos ?

Deletion should be possible with tomorrows rolling release.

PR260 should fix this

PR259 fixes this

Another bug:

Same issue for me (1.3-rolling-202003221506). I needed to add this to the script "/usr/lib/python3/dist-packages/vyos/ifconfig/wireguard.py":

@wornet-mwo in 1.2.5 and rolling

Can confirm that this can be closed now.

@dmbaturin can you look 2 PR for implement option with ignore old transaction-script states?
https://github.com/vyos/vyos-1x/pull/255
https://github.com/vyos/vyos-replace/pull/7
Can we add this in 1.2.6?

Thanks for testing @jjakob

Couldn't reproduce in 1.3-rolling-20200319