It looks working on VyOS 1.5-rolling-202404260019
set system domain-name 'vyos.local' set system host-name 'r4' set system static-host-mapping host-name r4.vyos.local inet '100.64.0.14'
It looks working on VyOS 1.5-rolling-202404260019
set system domain-name 'vyos.local' set system host-name 'r4' set system static-host-mapping host-name r4.vyos.local inet '100.64.0.14'
So if all packages needed are in fact the vyos-build/packages then this should be fairly simple to build and make your own APT repo off of.
If all of this would be done by the build script (download sources, apply patches, build binary packages and copy them to a local filesystem) there would be no problem.
I can't even see the list of packages in that 403 Forbidden repo - all of it blocked completely, not just access to binary packages.
Good.
So, all code is in github.
you need to spend bit of time and learn how to build packages and make them into repo
after you point vyos-build to that repo and good to go
it's time consuming, but once you have set it up, after it will not require that much time
OK, so where can I find the source (without the artwork) with the necessary patches and working build scripts? No problem to use my own CPU cycles and bandwidth and disk space, I can wait longer for the build to finish, sometimes (on sunny days) I even have some free electricity :) - in fact I would even prefer to build the binaries myself (of any packages not directly copied from Debian) rather than trust an external repo. And no problem, you've just got the 868th star from me, I simply didn't know this is something that matters. I have never distributed the LTS images to third parties, just using them internally. Yes, for some small scale production use (single-person business, running a very small local ISP for a few hundreds of customers) as a BGP router and PPPoE server (the latter replacing MikroTik because of their unfinished IPv6 support), not big enough to be able to afford a subscription.
When we say build from the source, we mean build from the source
see https://blog.vyos.io/community-contributors-userbase-and-lts-builds
Stay tuned; check our blog post.
Sorry about the priority, but it may be quite serious for those who will lose access due to end of program "images from donations" on May 1, and would like to be able to build stable images from source.
Meanwhile, trying to build 1.4 fails for a different reason - Debian 12 (bookworm) is still where it was, but sagitta-packages.vyos.net gives a 403 error:
What happens if another value occupies the index?
For example, PPPoE-server and PPP interface can generate thousands of interfaces
@Viacheslav or another of the Maintainers:
Just as another data-point - I have found that leaving the DHCP lease to auto-renew itself (not me doing it manually) that it doesn't then add it to the routing table.
i.e. at the moment my DHCP client is still connected, but there's no default via the DHCP session at the moment.
I just built and tested with the latest sagitta commits, and it is preventing it now as expected.
So I would say it can be closed as fixed, since it has been fixed some time between November and now.
This is the result of buster-backports being removed from the main repository server: https://backports.debian.org/news/Removal_of_buster-backports_from_the_debian_archive/
Hi,
I was playing around with VyOS and thought i'd build myself an iso and hit this issue. Not sure if its the correct way to solve it, but this is what I did:
Test addresses have to be different
Provide the set of the commands to reproduce
Without subtasks, it is going to be dead.
@Apachez It is not clear what you want to fix exactly. Fix all and do all working well could be related to any task.
Not reproduced on VyOS 1.5-rolling-202404141045
vyos@r-left# set pki ca "my test ca name" certificate 'MIIDnTCCAoWgAwIBAgIUFvyB2rY0V1V6AaIpPWHCftGRwN8wDQYJKoZIhvcNAQELBQAwVzELMAkGA0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcMCVNvbWUtQ2l0eTENMAsGA1UECgwEVnlPUzEQMA4GA1UEAwwHdnlvcy5pbzAeFw0yNDA0MTgxMTM3MzZaFw0yOTA0MzZaMFcxCzAJBgNVBAYTAkdCMRMwEQYDVQQIDApTb21lLVN0YXRlMRIwEAYDVQQHDAlTb21lLUNpdHkxDTALBgNVBAoMBFZ5T1MxEDAOBgNVBAMMB3Z5b3MuaW8wggEiMA0GCQEBAQUAA4IBDwAwggEKAoIBAQCKEVxs7gdzmnN4iMinvXN1vdGaT+v3TOnHSXbBkWHnt9YdWmo8UoqFpVqyVM3E8xmoT+3HOXJeWkKArEpMkGo93kWaGo0f25KGEFWbS2ttgNA9cqH9PGa42XTKyTY+5ZoIWaQQzNNiUSaIoslRrMSV4V2yQs90ECxR37ezlV2RAIHEhZ6mizUkMkuSmdjqRolh2tpF1MoisyhspFPXBC6lJ8d0jFZEi1tP3tlQjqVEWPjTvtddy34iOLFeUjBF5cOwfmpVLzWBVLbIxJr5ZHamGeQIabn36Jg1u0+/6p7hb8avqBW4dT0K8UykWVqgjQ4W4rM7AgMBAAGjYTBfMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4EFgQUxEx+IVaoLb7M/SW9AkCVRaXCNTUwDQYJKoZIhvcNAQELBQADggEBAGjV6WiH4Z+hfdANG8oWgY0xsHmUZg8dCjwqO5GMwjBVIuu8GuoZu0JobtLa097behWcgCkwjvKBffuwCu542WbFkxdXzBLZjSAc+K3itegZIuy4jqRO5z6Q0IbPSaFUhR4HhfwejwlyXgjNCFzEMzwoDL2/3PXjWyilkqthYyFcx092tgwiXtnfO9z9Xm/YQHQmRG2VWzLEwucOhV698xnqFgRJk3uKqcDN9KjF+5v32OQ0eis7GHn1aJim5aUee1nnCRFdQO0llNJRwF6fIaICzKLwa7zzMjF7HhRehh5kpwY8omcQX7xYz7GJag4='
@SquirePug re-check please with the latest rolling image.
@jmaslak can you check the latest rolling image?
@kroy can you re-test this case?
Just checked with the current rolling release 1.5-rolling-202404141045. After committing set high-availability disable, keepalived is successfully stopped and the logs show that the transition script seems to be executed:
Updates have been applied on 1.4 and 1.5.
This can probably be closed.
The regression causing 'image cannot be found" was fixed in https://vyos.dev/T6186.
A docker container usually has issues with loop devices:
Use the VM or attach dev
PR https://github.com/vyos/vyos-1x/pull/3313
set interfaces ethernet eth0 vif 10 address '10.20.30.1/32' set protocols static route 10.20.30.0/32 interface eth0.10
It is more of a feature request than a bug due to specific kernel routes.
Feature to add onlink option
Seems like its either fixed or was a quirk in that specific version.