Hi Chris,
I couldn't reproduce it in rc3, as stated. Please retest, and if you still get the error, we'll need to figure out the reproducing steps.

The root cause is that Quagga and FRR 5.1-dev didn't mind changing settings for non-existent interfaces, but FRR 6.1-dev does. The "ip source-validation" should have always been affected though.

@Merijn I could not reproduce the issue with any of my configs, so I can only suggest two options: either you can make an anonymized version of your config with all AS and network values replaced with those from private ranges (but please make sure the issue is still reproducible with that config); or you can send the actual config to me privately under a promise not to share it with anyone or a formal NDA.

My attempt to use github's editing GUI didn't go well, sorry for the poor commit description.

Oh, sorry, I misunderstood the issue. It's the "run show bridge brN" command that is not working, while the "run show bridge" command does.

It works for me, so we need exact reproducing steps.

The bug, as stated, is not reproducible in rc1.

Pretty silly mistake on my part indeed. I've merged the pull request.

@syncer This issue is already resolved in the rc2, could you move it back to there, out of the rc3 target?

@c-po The difference is due to EdgeOS being forked from an earlier Vyatta Core version, and never picking up the post-6.4 op mode improvements.
One of the ideas was to put all commands with potentially infinite output in the "monitor" subtree. So the command that follows the log file is "run monitor log".

This issue is no longer reproducible, though it's hard to tell which commit fixed it by now. Either way, I can create GRE tunnels just fine. Closing, if it re-appears, just reopen.

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.