- User Since
- Feb 7 2016, 5:00 PM (298 w, 2 d)
Thu, Oct 14
Is a double task, it looks like the package is not update upstream.
Sep 26 2021
Sep 17 2021
Sep 5 2021
Sep 4 2021
Updated default response to "No"
Sep 3 2021
It is working with the dashes, so for now we will not change this, it may break something else.
Aug 11 2021
Aug 9 2021
Back-ported the dhcp ip check loop to 1.3
Aug 8 2021
Checks the grub config rule by rule if ttyS/ttyUSB is used then updates the newly to be included grub template to the same.
Aug 6 2021
Aug 2 2021
Jun 27 2021
Jun 7 2021
Jun 6 2021
Jun 1 2021
May 28 2021
May 27 2021
Mar 29 2021
Mar 26 2021
Mar 25 2021
Oct 17 2020
Apr 6 2020
Jan 10 2020
@bmhughes For me an issue was that cpio is missing from the docker image
@bmhughes I tested this on the downloaded lts 1.2.4 iso and it seems to work fine...
Jan 9 2020
Created new Azure image
Jan 8 2020
Jan 2 2020
Dec 24 2019
Updated the link files.
Jul 3 2019
@mb300sd do you know how long it takes for the config to load for you? because the /etc/resolv.conf file is persistent. but on loading the config it should do the 'set system nameserver 2001:470:20::2' and overwrite the resolv.conf file.
Jul 2 2019
@mb300sd i just created this one https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201907022116-amd64.iso did you already test with it?
could you please retest it with:
I was able to reproduce your first issue...
@mb300sd can you share your config maybe?
@mb300sd do you mean after a fresh boot you get:
Jul 1 2019
@mb300sd is the ipv6 address provided via dhcp?
@mb300sd what is the dhcp server you are using?
Could you also please share the content of the files:
/etc/resolv.conf.dhclient-new-eth0 (or other interface if you use an other)
/etc/resolv.conf.dhclient-old-eth0 (or other interface if you use an other)
@c-po @mb300sd found the issue 'Nameservers are not propagated into resolv.conf' (no script in node def) , also the issue with the split ipv6 does not seem to be in host_name.py, will look a bit further for that.
Jun 20 2019
@bmtauer I have made a fix in the rolloing release and also backpurted to crux. so should be in 1.2.2
Jun 18 2019
Jun 17 2019
Jun 6 2019
@etfeet you also get
mdadm: WARNING /dev/sda3 and /dev/sda appear to have very similar superblocks. If they are really different, please --zero the superblock on one If they are the same or overlap, please remove one from the DEVICE list in mdadm.conf.
maybe you can try my post above also then?
@jmlccdmd Strange is the superblock on /dev/sda, without uefi we use sda1 for raid and with uefi sda3.
Could you clear the superblock from sda and sdb and maybe try again?
Jun 5 2019
It looks like the check that determines if 'mdadm --zero-superblock' is needed does not work.
Also ill try to get the config in with update-initramfs so that it does not go to md127.
Jun 4 2019
All items should be fixed.
May 23 2019
@joshua we do not use the ssh and the ssh-import-id as the ssh keys need to be set by vyos config.
Apr 16 2019
@yun What is the exact frr command you tried?
the command you tried manually.
@hagbard that commit sets a kernel route. that is not good.
Apr 10 2019
Mar 14 2019
@Line2 I will look at it!
@Line2 What do you mean?
This is only for dhcp ip renewals or disconnected interfaces.
Jan 27 2019
If you manually partition you need to keep in mind 2 things.
the filesystem label needs to be "persistence" (mkfs.ext4 < device > -L persistence)
and in the root of the filesystem you must create a persistence.conf file containing "/ union"
(echo "/ union" > /persistence.conf) on your partition meat for vyos.
Jan 23 2019
@bjtangseng so changing that remote_ts = 0.0.0.0/0[gre] fixed it right?
On the HUB, can you change in /etc/swanctl/swanctl.conf
remote_ts = dynamic[gre] to remote_ts = 0.0.0.0/0[gre]
can you do:
sudo swanctl --list-sas
@bjtangseng, Ah that is the problem. I do not know if there is an option allow any network, have to do some research.
Does your nat address change everytime?
can you put log from hub?
I think you replaced the wrong ip in the swanctl.conf
@bjtangseng Can you post the output, than i can maybe look and mod things.
Jan 22 2019
@bjtangseng The spoke, and do not reboot.
make sure hub is up and do changes mentioned in previous post on the spoke (no reboot)
and post the output of:
Jan 21 2019
can you please edit your swanctl.conf file and put the local_ts to 184.108.40.206/32[gre] ( local_ts = 220.127.116.11/32[gre] )
after editing swanctl please run:
sudo swanctl -q
then please check if you can connect with:
sudo swanctl -i -c dmvpn -S 100.64.161.96 -R 18.104.22.168 -l 2
sudo swanctl -i -c dmvpn -S 0.0.0.0 -R 22.214.171.124 -l 2
Jan 20 2019
@bjtangseng could you try with IKEv2 on both hub and spoke?
set vpn ipsec ike-group IKE-HUB key-exchange ikev2 for hub
set vpn ipsec ike-group IKE-SPOKE key-exchange ikev2 for spoke.
@bjtangseng This is definitely a NAT issue, if i change the local_ts = dynamic[gre] in /etc/swanctl/swanctl.conf to local_ts = *.*.*.*/32[gre] i can replicate the error you get.