I hacked through how to reproduce.

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.

Confirmed fix with that commit.

It definitely remains in my config:

@hagbard Confirmed your hack takes care of the issue.

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.

@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.

Seems like this is the same issue as in T1918 @Dmitry

I agree this should be killed.

A reboot seems to have fixed it.

Can confirm. Problem seems to be fixed now.

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

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)

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.

T1846 fixes this

@hagbard Confirmed fix. Migration worked perfectly.

Related to T1844, which should correct the original problem in this ticket

Trying to apply the fix manually:

Built a fresh rolling. It failed with:

Okay, so this problem just got a LOT more bizarre.

When the config was gone, the processes still seemed to be running

It actually does work, if only by accident

This should be all of the relevant configs from the ASA side

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.

PR166 should fix this.

Complete

PR: https://github.com/vyos/vyos-1x/pull/156

This eliminates the redundant interfaces.py and merges the op_mode displaying code into ifconfig.py

This pull request rewrites all the functionality of ioctl.pm and lays the framework for the rest of Interface.pm

Attached

VyOS 1.2-rolling-201910210211 boots perfectly.

Example output. Note this is all programmatically generated in Python now instead of parsing the output of wg

Superseded by T1759

PR: https://github.com/vyos/vyos-1x/pull/150

PR: https://github.com/vyos/vyos-1x/pull/149

Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).

To be fair, that’s what prompted this. The logs go to a different file already.

This PR should address those concerns

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.

Yep. Changing the priority fixes the issue completely

@runar This isn't a routing issue though.