And FYI, just to make sure that something wasn't triggered by hanging out in GRUB.
rootdelay=0 fails
rootdelay=2 works, so just a small pause is needed on my system at least.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 30 2019
Jan 3 2019
Dec 21 2018
Dec 20 2018
@kroy you are clearly on a roll today, rootdelay=10 also did the trick.
@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
Spot on, booting with acpi=off makes it come up properly and configurations are actually saved.
Still getting some errors but not sure if they matter or not:
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.
https://forum.vyos.io/t/vyos-1-2-0rc10-raid-1-fresh-install-unable-to-save-config/3059
These users might have the same issue. I noticed one of the symptoms of having the system is in this state is that the config is lost between reboots.
I am not able to reproduce it in vmware workstation.
Does the problem occur on a virtual environment e.g. ESXi, too?
I can let it sit forever, the status wont change as the array is missing one disk. Notice how after (auto read only) raid1 is only says sdb1[0] (sda1 is missing).
Also we can see that this wont fix itself from looking at the df -h output where the system clearly has booted straight from sda1 instead of from the raid array (/dev/md127)
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 19 2018
After reboot, running from local disks:
During install (booted from ISO):
I have just re-tested this with RC11 and can confirm that it was a
configuration error. I had moved the DHCP server to a different VLAN which
was not listed under dhcp-relay {
I can confirm the error mentioned by MrXermon.
Dec 18 2018
I've confirmed that the same is true for 1.2 RC11 as for 1.1.8
Looks like the cache server is pushed into the FRR configuration multiple times if the configuration get's updated.
I can test this on Saturday. Sorry was sick last few days, couldn't test anything.
@Barrysdca Can you please test with the latest rolling release, please?
@Unicron Can you please integrate the package below into ci?
https://github.com/vyos/vyos-vmwaretools-scripts
Maybe this isn't the same issue? Still a problem in RC11 unfortunately.
Everything is still working/functioning in the latest RC (1.2.0-rc11)
I tested it on one of my border routers today and it seems to be working with IPv6 (dropping 692 routes because of invalid ROA state). Sadly i am unable to test IPv4 at the moment.
Sorry, It's my cable was broken.
I'm not sure which release you have Daniil, but in the latest RC (11) the issue still exists.
Dec 17 2018
I see maybe the same on VyOS 1.2.0-rolling+201812162050 with MMS clamping on a GRE interface.
in VyOS 1.2.0-rolling+201812162050 the bug is still existing, but I will test in next RC here.
Dec 16 2018
If we are planning firewall overhaul, the old design issues should not get in the way. It's planned for 1.3 though
That command works for me in the upcoming rc, so I assume they fixed it.
That command has been removed in rc10. "run show ipsec debug" is now mapped to "ipsec statusall", which should be detailed enough for all practical purposes.
Good catch! Fixed.
@dmbaturin this was fixed in frr master
Ah , another minor incompatibility between Quagga and FRR. I've fixed it, the fix will be in the next rc.
@hagbard I've added it to all interface templates generators now, including that for QoS.
Dec 14 2018
added the patch! thanks
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
Confirmed fixed thanks
Dec 13 2018
@runar I should have something ready tomorrow or at the weekend at the latest you could test for IPv4. I basically started implementing the 'set interfaces <intf> ip' options including the kernel vars which you can set on other interfaces since wireguard is using that interface and looks like a normal network interface to the kernel.
Dec 12 2018
After playing around with it, I think I create an extra script just for that task, it'll be easier to maintain until that parts are moved out to 'set protocol'.
Oh I see, so it would be then in /opt/vyatta/share/vyatta-cfg/templates/interfaces/wireguard/node.tag/ip/ospf/cost/node.def.
What do you mean with moving it into the protocol subtree?
I also would then handle it within the wireguard code, like I did for the firewall stuff.
(https://github.com/vyos/vyos-1x/commit/51f61991092a163f680e4ec8f122e73f4074ddf9)
Let me know what you think, would be just an extra node and leavenode to handle.
Sorry @hagbard this was completely forgotten from my part.
Hi @Barrysdca , can you please test if the issue persists with https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201812120337-amd64.iso
I tested it on the image and it appears that I can't reproduce it anymore.
@runar How do you set it on other interfaces?
the new syntax is being applied to the config file.
I've tested it successfully multiple times and pushed the fix upstream, the configured MTU is now being requested with the first PADI.
Please go direct to version 1.0.3 cause:
All right, thanks bunch. I think I found the issue but before I expose it into the image, I'd like to test with you the functionality.
Dec 11 2018
can you please test with the latest rolling if it fixes your issue?
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201812110337-amd64.iso
pending ci integration
sudo ifconfig pppoe0
pppoe0 Link encap:Point-to-Point Protocol
inet addr:86.174.92.68 P-t-P:172.16.15.188 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:39321606 errors:0 dropped:0 overruns:0 frame:0 TX packets:11454389 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:57128999317 (53.2 GiB) TX bytes:889897287 (848.6 MiB)
Dec 10 2018
can you please do the following and post the result:
All right. First of all MTU != MRU. (MTU - 8 byte IP header = MRU). I used your config example and I see a difference. The conf request has to come from your side, that happens durig the discovery pahase (PADI). I see that it is not being sent before you reconnect.
I suspect this is the same issue as T1080. if the destination ip of the l2tpv3 tunnel is unreachable(no default route) it wont load. I suspect its loading the l2tpv3 config before DHCP has installed a default route. My workaround is to install a very low metric static default route, that will get overwritten by OSPF(in my case).
We did some testing with the RC10 Version as requested by the blog.
My changes will make it into rc12 as earliest, sorry
Disabling the complete Framebuffer subsystem works with my UEFI Testboard, too. I will drop it entirely