My attempt to use github's editing GUI didn't go well, sorry for the poor commit description.
Thu, Oct 18
Wed, Oct 17
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.
Mon, Oct 15
The bug, as stated, is not reproducible in rc1.
Sun, Oct 14
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.
Sat, Oct 13
Fri, Oct 12
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).
Tue, Oct 9
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.
Mon, Oct 8
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.
Sun, Oct 7
Wed, Oct 3
Ok, I'm going to build the official driver for the 4.18.11 kernel then.
It all works now, right? Closing then.
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.