If this is a duplicate of something, go ahead and close it

PR289 should fix this.

PR262 should fix that last one @alien

PR260 should fix this

PR259 fixes this

Can confirm that this can be closed now.

Personally this is behavior I agree with.

@hagbard This problem is back on a rolling built on the 14th. Fix again was to run

PR88 should add this.

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