- User Since
- Sep 15 2018, 11:31 PM (39 w, 4 d)
Mar 17 2019
Yep. Can confirm issue is fixed with the latest hot fix.
Feb 13 2019
Strange. I’ve seen that error a lot. Every time it’s been when I’ve forgotten to checkout current after cloning the repo.
@Merijn make sure you git checkout currenton everything.
Feb 6 2019
Can you describe the system and disks involved?
Yeah, it wasn't really a workable solution for me either and I too had to roll back. But it would be good to confirm that is the problem.
@lbv2rus There might actually be a few problems here. We might have hacked out that it's the interface-route with the custom routing table that's causing the problem.
I’ll add that I think this is happening because of the .252 and .254 addresses. The 254 address connects, but the 252 address is marked in a constant state of connecting.
Feb 1 2019
There might actually be a bit of a deeper problem here, somewhat conditional on some static interface routing. On an broken system, it does say something about staticd starting
Jan 31 2019
And more info:
I tracked down what is causing this.
Jan 30 2019
Too add, routes are present in FRR
Jan 29 2019
Jan 27 2019
Jan 26 2019
THis shows up in the logs:
Unfortunately that seems to have made the problem worse. Before, at least each host was seeing one other host. Now most of them see no hosts.
Sure. I'll set a reminder to check it out tomorrow when I have a free minute. Thanks
Jan 25 2019
Sorry. Spent the week restoring almost half a petabyte of data from backups due to a ZFS crash.
Jan 22 2019
Yeah. I remove the initial vyos user and add an admin and an ansible user. The admin is just for consistency across different devices.
@hagbard I remove/change the vyos user too. So it's definitely a breaking change.
Jan 21 2019
The latest rolling did seem to correct the base problem. That being cron scripts running breaking the ability to edit config afterwards.
@hagbard Note that a reboot does fix the ability to edit configuration again until the next time the cron script runs.
Jan 20 2019
Okay, spent the whole day messing with this and I've tracked it down so it's reproducible.
Jan 14 2019
Superseded by T1178
Seems to be a problem with just that build. I'll install a newer rolling when I get a chance and see if that corrects it.
Edit... actually I can't update anything:
Jan 13 2019
I was mistaken. Seems to have lost the route again.
As of (at least) VyOS 1.2.0-rolling+201901090739 I believe this problem to be corrected.
Jan 9 2019
@Line2 Thanks for the update.
Jan 7 2019
With VyOS as the edge:
Jan 6 2019
@syncer Just to confirm, the above pull request integrates this and can be merged. I'm not sure if there's a status change I should make to this or just leave it be. Thanks
Jan 4 2019
This is probably a duplicate of T1120, which should be fixed now.
Jan 2 2019
Unfortunately still a problem in the EPA2 release. 30 minutes hits, and I cease getting a default route on my entire OSPF infrastructure
Dec 28 2018
I can confirm that this is broken everywhere "get_response" is used, where the default should be "no". GPU signatures are ignored, disks are deleted, etc. I'll work on making up a sane replacement.
Dec 22 2018
Completed. PR: https://github.com/vyos/vyatta-cfg-system/pull/95
Dec 21 2018
Dec 20 2018
I've been using my branch for a few daily upgrades now, and it seems flawlessly, minus one thing.
@danhusan I'd be curious if an alternative of adding rootdelay=10 instead of the acpi=off works. That may or may not do anything depending on how the kernel is built though.
Yeah, I'm not familiar enough with things to understand why it would be trying to mount the bare RAID partitions, not to mention the actual bare drives
While I'm not sure if it's related, it looks like your system has a buggy ACPI implementation. Sometimes that can cause some weird behaviour.
I’ve been trying to research this a little, and I can’t duplicate. But I suspect it’s because I have fast disk. Your first output says it’s going to take over two hours for a resync.
I pulled down vyos-frr submodule and the above-mentioned commit is present.
Dec 18 2018
Maybe this isn't the same issue? Still a problem in RC11 unfortunately.
Here's a branch that makes this work on an upgrade. For now, it wouldn't cover the initial install, but only subsequent upgrades. This covers a MAJOR pain point for me where I lose my bash history on an upgrade.
Dec 14 2018
I’ve been using ospfv3 on all the RCs and definitely haven’t seen this behavior. OSPFv3 seems immune to the problem I’m seeing in T1020
Just to confirm that RC10 made this work for me too
Dec 12 2018
Would it make sense to create this as a separate partition during installation? Instead of trying to preserve? Given my recent work on the EFI stuff, I've got an idea where this might happen.
Dec 11 2018
Dec 7 2018
@c-po Thanks. Between the legit problem this task revealed early-on, some bad timing with the vyatta-config-migrate from earlier today, and a PEBKAC error, it looks like this might be resolved now.
This seems to be working now. It's working both on my normal build tree and a brand new one, so it looks like I was just attempting when some cache somewhere hadn't updated
I was building yesterday fine except for the above-mentioned vyatta-cfg-firewall problem.
Now a simple build is failing with:
Dec 6 2018
I just tested it on my 8.11 VM and it fails to build there as well for the reason you mentioned (the lack of initrd)
@max1e6 Is your build directory on NFS? I had that problem when my build directory was being stored on NFS
@max1e6 I don't think so. I was building on a Jessie VM for a while as well as Docker, and both fail
Just to confirm, still a problem with RC10
Dec 5 2018
There are definitely strange happenings.
Okay, I think I've nailed down what's going on. A fresh build with no modules (git clone, configure, make iso), works fine.
Actually I spoke too soon. The next run resulted in this, on a 100% fresh build tree.
@hagbard Thanks! I guess I was just running make clean. Removing the build directory and rerunning configure seems to have corrected it.
It's actually failing somewhere else now:
Dec 4 2018
I'll add here that I've got a reasonably complex OSPF setup with around 10 hosts. I converted it over to VyOS when the first RC came out and I haven't seen this issue at all, and I'm constantly rebooting hosts. Currently upgraded the whole setup to RC10 and not a single host crashed. It's worth adding that I've had a bunch of Mikrotiks in the mix at a time and no problem there either.
This might be related to T1079
Dec 3 2018
Dec 2 2018
Dec 1 2018
Unfortunately not corrected in RC9. After 30 minutes the default route fails to distribute.
This makes sense. As I understand it, it just installs another copy of the .efi file to a more “universal” location.
Nov 29 2018
@bswinnerton Ha, no problem. I just figured with a bit more insight maybe it would be worth breaking this out into two tasks
@bswinnerton I think the "in certain situations" should be defined "when the config on disk is invalid for whatever reason"
Nov 27 2018
Confirmed that the posted RC9 works now too
confirmed. This rolling release has a working wireguard.
Nov 26 2018
As another question, is that a bug that ipoe.ko and vlan_mon.ko are ending up under the old kernel modules?
That didn't do anything.
Umm, that's not what happened. It looks like it needs to be in the 4.19.0 directory to work
Linux route-extern.xxx.xx.xx 4.19.4-amd64-vyos #37 SMP Mon Nov 26 10:03:40 CET 2018 x86_64 GNU/Linux
Nov 16 2018
This was resolved by @UnicronNL when the dual-mode ISO was built. As of RC7, the installer now integrates this and can successfully do a UEFI install
Looks like this might be upstream and has been corrected there.
Nov 10 2018
Nov 9 2018
Just ran it on a few different machines, VMs, set up RAID/non-RAID. It worked great. Thanks!