The provides Dockerfile lists all packages which are needed to compile VyOS on a Debian jessie host. If you do not want ro install all this on your host simply use the provided Docker image and you are ready to go.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 8 2019
Jan 7 2019
Thanks. An lsmod from rc5 would be nice, too.
Jan 6 2019
Can you share the dmesg output from RC5 please?
It also reports:
ISO is still building. You are right, a NIC is a NIC, but a NIC consists of a MAC and a PHY which does the PHYsical interface. you can have the same MAC part multiple times but with different PHY ICs. Lets wait for the ISO to compile.
According to the datasheet https://f.ipc2u.de/files/add/doc/445/3I380D-D90-Datasheet.pdf I see no PHY that is used on this board - nevertheless I saw that we do not ship every avialable PHY driver, also drivers present in 1.2.0-rc6 are no longer present like CONFIG_BCM7XXX_PHY. I will provide you with an updated ISO for testing.
Looks like a general issue here. Do you still have the old Buster ISO with Kernel 4.18 that you can install on the target HW?
- (K)ASLR is enabled with https://github.com/vyos/vyos-kernel/blob/35c51d3b30f29110aab12ade5f11f928c68951ec/arch/x86/configs/x86_64_vyos_defconfig#L405
- DEP
vyos@vyos:~$ show system kernel-messages | grep "Execute Disable" NX (Execute Disable) protection: active
- RELRO there's some info in the Debian Wiki but it reports permission denied: https://wiki.debian.org/Hardening
@rps what about changing the minimum supported MTU from "68" to "1450" which is the default that is used in VyOS.
Thanks for your contribution. It will be included in the next EPA and rolling images.
Jan 5 2019
I will approach the vendor first.
@SteveP as it works with Debian Buster it should work with our newer Kernel, too.
Anyone can provide me with a hardware?
@dongjunbo same hardware?
Where to get those MIBs? should be simply to test before adding it to the iso
@fromport there is an option in the ./configure script tomspecify the Debian mirror you use. You should be able to simply point it to your mirror.
I assume you lack some build dependencies. Please check the Dockerfile which has all required dependencies in it and install them on your native build host.
Jan 3 2019
@SteveP can you please try: https://helix.mybll.net/vyos-uefi-4eb663191c09.iso ?
I am also getting an error with sh system kernel-messages which also was not there with RC5.
Thanks for the update. May I ask which distro?
cpo@BR1:~$ dpkg --list | grep xl2tp ii xl2tpd 1.3.6+dfsg-2-vyos0 amd64 layer 2 tunneling protocol implementation
Jan 2 2019
Can you provide us with e shell output of lsmod command?
Weird, as we use the exact same network adapter configuraion as Debian Buster :/
@Line2 it will be in tomorrows rolling release. I just tested it on my Windows 10 Hyper-V with a generation 2 VM (UEFI)
THX for the update. done also on current and crux
Also cherry-picked into crux
CONFIG_FB_VGA16 has been removed from the kernel co fig and thus this should be resolved. Can you please retest with latest rolling?
@SteveP can you please test with latest rolling ISO?
Jan 1 2019
Just hit this at my site, too.
Dec 31 2018
I propose to proceed with a global change. Special case handling is always harder to test and the impact is only 5 seconds max in startup time - who cares on a 24/7 active device which is rarely rebootet?
instead of differentiating between raid and non raid installations - why not always wait 5 seconds for the discs to settle? As this is only done once on startup this is IMHO better then a special case.
I'd like to point out that the "personal appeal from the VyOS Wiki founder Daniil Baturin" at the top of the Wiki pages is fantastically defeated when we make it this difficult to contribute to the documentation. 😞
Dec 28 2018
Can you share your configuration please? I use rc11, too as l2tp/ipsec access concentrator and everything is fine here.
Dec 27 2018
Commit also cherry-picked to crux branch
Dec 26 2018
Dec 25 2018
Changes verified in commit https://github.com/vyos/vyos-kernel/commit/729bd5fafec7d2ad345ab371b04d15d2cf627229 so IMHO this one is resolved
Dec 20 2018
The shared-network-parameters is a real pain and should be used "without warranty" we should rather deprecate it and add proper CLI interface.
Does the problem occur on a virtual environment e.g. ESXi, too?
Dec 19 2018
Dec 18 2018
As the DHCP client sometimes stores its lst IP address and sends a request for it you probably should delete the lease from the DHCP server:
Dec 16 2018
Dec 13 2018
Please retest wirh latest rolling release
Dec 12 2018
- CONFIG_MMC_BLOCK already enabled
- CONFIG_MMC_SDHCI_ACPI has been enabled
+1
Dec 11 2018
Please note:
Dec 10 2018
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
Dec 9 2018
Not directly but it was added here: https://github.com/librenms/librenms/pull/351
Dec 8 2018
I see OS version in libreNMS.
Dec 7 2018
Netplugd seems to be the thing we want
In vyatta-cfg-firewall please do git checkout current prior to building it, as the submodule pointer is definately not up2date.
According to CI service build works as expected. Can you please retry?
Dec 6 2018
Dec 4 2018
Will set interface vxlan vxlan0 remote-port 12345 be appropriate? Using destination-port would also work but the remote address is called remote and also openvpn utilizes remote-port
Dec 3 2018
Setting destination port per VXLAN interface sound much more reasonable
Dec 2 2018
What about Dockerfile in vyos-build?
Dec 1 2018
I will provide a VyOS testing ISO somewhen next week, would be much appreciated if you can test.
Or drop by our slack channel for help
First you need to specify a new version of your subtree,
https://github.com/vyos/vyatta-cfg-system/commit/f68dda9d619ea74bed266122ac86604284e1a9e4