- User Since
- Feb 7 2016, 5:00 PM (284 w, 4 d)
Sun, Jun 27
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 22.214.171.124/32[gre] ( local_ts = 126.96.36.199/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 188.8.131.52 -l 2
sudo swanctl -i -c dmvpn -S 0.0.0.0 -R 184.108.40.206 -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.
Jan 15 2019
@bjtangseng I do not know if dmvpn was in rc.10.
Can you please try the same in the last roling release?
Dec 14 2018
added the patch! thanks
Dec 12 2018
Nov 23 2018
@m.tremer added the patch, thanks... was under the impression cloud-init added the user as it is stated as default user, but clearly it does not.
Nov 13 2018
Do you also create the iso yourself or dowload it?
In 1.2 we will be using cloud-init and the ec2 init script was removed.
Nov 9 2018
@syncer i added a branch in vyos-build, after testing, do you think we can merge to current/crux and update the live-build package on the build server?
@commo @Raeven I updated the kernel to support the filesystems. But what @syncer mentioned 'win32diskimager' is a better tool for 1.2 as it is hybrid-iso which works if you directly write the iso to usb.
@syncer If we use kernel 4.19 driver version for ethernet is DRV_VERSION "5.1.0-k"
Also cpu should be supported without enabling something i guess.
Will mod the script to update rate on the fly.
vyos@vyos:~$ stty -F /dev/ttyS0 115200 cstopb
If you would like to test:
git clone https://github.com/vyos/vyos-build.git
git checkout current-uefi
docker build -t vyos-builder .
docker run -it --privileged -v /HOST_PATH_OF_VYOS_BUILD_REPO:/vyos -w="/vyos" vyos-builder bash
Nov 6 2018
@kroy what kernel is it now you use? I updated the kernel 4.14.75 and 4.19.0
Nov 5 2018
@commo How did you prepare the usb drive?
On which os, and what tools did you use?
Nov 4 2018
@vtsingaras I see it is merged in upstream, try to merge in vyos asap.