- User Since
- Sep 15 2018, 11:31 PM (71 w, 1 d)
Sat, Jan 18
Fri, Jan 17
I hacked through how to reproduce.
Mon, Jan 13
I pushed a fix earlier which might fix this in UEFI mode. Can you check the rolling tomorrow (or build youself today). If you are interested, I also have a custom built ISO with the fix in it.
Also discovered during testing that 4K sector drives will fail to boot with EFI. Also fixed in the above PR
T1940 should fix this. It would be pretty trivial to add the ability to choose between EFI and BIOS when EFI is present, though this fix should make it unnecessary
PR corrects this. Buster forces secure-boot by default, which we don't support
@c-po Thanks for the fix.
Sun, Jan 12
Wed, Jan 8
Confirmed fix with that commit.
Tue, Jan 7
It definitely remains in my config:
Sat, Jan 4
@hagbard Confirmed your hack takes care of the issue.
Fri, Jan 3
I was hoping you have some input here.
My system takes 6 minutes to boot, and it only has two DHCP servers and about 12 interfaces.
I'll wait to test until the reload fix is merged
Definitely confirmed as of yesterday's rolling. Still occurs on three different VMs.
Confirmed fixed in a newer rolling.
Thu, Jan 2
Mon, Dec 30
@Dmitry Can confirm I was able to upgrade without any errors now. This problem appears to be fixed
Rolling built on 201912301711 seems to have a different issue. Same config as above.
Will confirm later this afternoon when I am on site and let you know.
Sat, Dec 28
I agree this should be killed.
Dec 23 2019
A reboot seems to have fixed it.
Can confirm. Problem seems to be fixed now.
Dec 21 2019
So I guess the key to duplication here is to:
Maybe even just the action of sudo systemctl restart radvd.service is enough to fix it? It seems to maybe be the case
It seems like maybe something doesn't exist, or permissions aren't working right on a freshly upgraded system, until you manually do something to create it?
So the problem went away until I upgraded to the latest rolling. VyOS 1.3-rolling-201912211124
Dec 20 2019
My output there basically matches yours.
And I don't know if it's relevant, but the syslog output is definitely different depending on whether I restart it, or it gets restarted on boot
Upgraded to lastest official rolling:
Maybe it's because I have multiples? Or on vlans (not that that should matter)
Dec 19 2019
After some more testing, after a reboot, a tcpdump -n -i interface icmp6 on a client machine shows nothing until restarting the radvd service on the routers.
Dec 18 2019
Dec 11 2019
T1846 fixes this
Dec 10 2019
@hagbard Confirmed fix. Migration worked perfectly.
Dec 9 2019
Related to T1844, which should correct the original problem in this ticket
Dec 6 2019
Trying to apply the fix manually:
Built a fresh rolling. It failed with:
Okay, so this problem just got a LOT more bizarre.
Dec 5 2019
When the config was gone, the processes still seemed to be running
Dec 4 2019
It actually does work, if only by accident
This should be all of the relevant configs from the ASA side
Nov 21 2019
I guess I'd ask the question of whether we have any complaints of performance type issues that perf could pinpoint? I don't know if I've ever seen any of those kind of complaints in the circles I hang out in.
Nov 18 2019
PR166 should fix this.
Oct 31 2019
Oct 30 2019
Oct 27 2019
This eliminates the redundant interfaces.py and merges the op_mode displaying code into ifconfig.py
Oct 25 2019
Oct 24 2019
This pull request rewrites all the functionality of ioctl.pm and lays the framework for the rest of Interface.pm
VyOS 1.2-rolling-201910210211 boots perfectly.
Oct 22 2019
Example output. Note this is all programmatically generated in Python now instead of parsing the output of wg
Superseded by T1759
Oct 21 2019
Oct 15 2019
Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).
Oct 14 2019
To be fair, that’s what prompted this. The logs go to a different file already.
This PR should address those concerns
Oct 1 2019
This is going to become more and more of a problem as wireguard adoption continues. Most major Wireguard VPN services provide a FQDN as their endpoint, not IP:
This should be reverted, as the change is breaking. After more testing, I found some problems due to things like static routing being applied before wireguard now. So the wireguard tunnel works, but in some cases any routing that shouldbe going over the tunnel does not work.
Sep 30 2019
Yep. Changing the priority fixes the issue completely
@runar This isn't a routing issue though.