The root cause was in the script trying to call "brctl setpathcost $bridge $port 0", but newer bridge-utils version removed that (there's no cost of zero in STP really, so it would be a rather bad way to set the default anyway).

@aopdal Please check out the rc2 (https://downloads.vyos.io/?dir=testing/1.2.0-rc2), should be fixed now.

According to https://www.icann.org/dns-resolvers-checking-current-trust-anchors , we should be fine indeed:

I don't think we should support restricted boot. As per MS's own specification, all x86 boards should allow the user to disable it, and to my knowledge, they all do.

I suppose we can simply delete all those jobs at boot time. Since nothing else uses atd, and old jobs likely should not survive reboots, I think it's the simplest solution.

Oddly, I couldn't reproduce the issue on my latest image. Perhaps there is more to it. We are preparing a release candidate now, please re-test when it's out.

Ok, I'm going to build the official driver for the 4.18.11 kernel then.

It all works now, right? Closing then.

@c-po

So VyOS is heavily dependant on this one, no need to remove.

This is not just wrong, but, as anyone who tried to go beyond the native CLI on EdgeOS can attest, almost slanderous. ;)
VyOS uses real coreutils (ip-utils-ng etc.) for those ones. Some VyOS packages list busybox but I believe it's a legacy. The only thing that probably truly depends on it is initramfs-tools, but with image upgrades, I think having initramfs-tools in VyOS is an artifact that is not needed.

Oops. I forgot to add the actual package to our repos. Should be fixed now.

Is there any work being done? If not, I'll move it to VyOS 1.3.x target, since 1.2.0 is about to get a feature freeze.

Is it reproducible in latest 1.2.0?

I guess we should consider it complete by now.

Moving this out of 1.2.0, at least until we decide what to do when domain is not configured.

I've tested it and it seemed to work. Closing this, if you see the issue reappear, please reopen.

Yes, should be fixed now. Feel free to reopen if it reappears.

Looks like libvyosconfig is not connected to phabricator so the commit wasn't picked up.

Should work after that commit, please test.

I've tested the default configuration in 1.1.8, and it looks like with preempt-delay not set it was also 0. Not sure where 300 came from.

Yes, quite an embarassing mistake. I'm working on it.

I've fixed it by adjusting the syntax for new StrongSWAN. The new way to do it is arguably better than it used to be, but I still wonder why the old syntax had to break. The fix is in 0.12.45+vyos2+current2 and should be in tomorrow's nightly build.

I think it's best done at the same time with IPsec CLI rewrite.