Jan 30 2019
Jan 3 2019
Dec 21 2018
Dec 20 2018
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.
@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.
Some data I wasn't able to find in any log files:
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.