In T9246#277405, @Viacheslav wrote:

Only the comment option is available for regular users to update a task after its creation.

Reminder for myself, update initial post as soon as that is possible to:

I second that it should be at least well documented that setting this sysctl is required to allow non local binds. I had to introduce a check for it being active in my PR solving a regression with HAProxy (and other services relying on the same code path) here: https://github.com/vyos/vyos-1x/pull/5266

Created an initial pull request at https://github.com/vyos/vyos-1x/pull/5266

If somebody could explain to me what value addr (at https://github.com/vyos/vyos-1x/blob/a6ad73d72ba8d5256ff77978e63c07143787eb44/python/vyos/utils/network.py#L400) is set to when the current listen address is *, I might be able to come up with a PR to fix this.

I tried to work around the issue by leveraging VRRP transition scripts, when I’ve noticed haproxy by default listens to every interface (i.e. binds to *) when no explicit listen-address is set. However due to this behavior it is no longer possible to add a listen-address when haproxy is already running, as the on-commit check refuses to apply due to the port being occupied. For obvious reasons it should ignore the port being in use in such cases. The only solution for now is completely removing all haproxy config before reapplying all of it, which is very much suboptimal.

I found the culprit: https://github.com/vyos/vyos-1x/pull/5186 introduced a check if the address is assigned. I think this should be changed to check for an address, that is generally available (via config), not minding if it is actually configured. Open for suggestions to send in a PR.

Thank you for tackling this so fast!

Due to being unable to edit the OP (complains about policy changes I'm not actively performing), here is the link to the related forum thread: https://forum.vyos.io/t/vyos-build-failing-to-build-image-missing-dependencies/17497

In T6740#248635, @Viacheslav wrote:

PR https://github.com/vyos/vyos-1x/pull/4124

As posted in https://forum.vyos.io/t/vyos-build-failing-smoketests/16811/13 I can close this bug report as user error 😅

What about fwupd? I don't think that would be viable for ALL hardware in a system, but at least that pieces that make use of firmware (and can be updated). Not sure how relevant this is in this context, but I could imagine some higher end vendors of NICs supporting firmware distribution via fwupd.

In T7206#234671, @Bartosz-lab wrote:

Hi, It is already done.

In T6563#234214, @marvin wrote:

Thanks @Viacheslav.

FWIW, it looks like Jool's official documentation site is now https://nicmx.github.io/Jool/en/index.html (not jool.mx anymore).

I found one actually relevant/related issue, opened a task and an according PR. With that done, I'm able to get through the tests in general. They still fail for me due to those login related issues, which is probably something actually broken on upstream, but can be discussed at the forum indeed.

Unfortunately I don't get the tests to run through. I rechecked the docs, noticed I was missing the sysctl to enable (?) local ipv6, added that and re-ran the tests, just to have some less fail, but still. What also confuses me are the VPP tests. Weren't those supposed to be hidden behind a separate target, as that whole feature is still under development? Regardless, there are still other errors occurring on some login related stuff, but that could indeed be caused by something broken.

In T7215#229394, @jestabro wrote:

@MPStudyly note that tests are not run with sudo

That's odd, I really wonder what the difference between our environments is. I'm running all tests inside the build container directly calling "sudo make <target>" one after another for the targets:

Any updates on this? Just re-ran the tests to discover there are quite a lot of other/new failures. I also noticed the nightly builds workflow to be disabled since 4 months. Still there are recent nightly releases available in that repository. Did you internally switch to some other workflow that's not public (yet)? Otherwise I'd not assume you've quit running the tests yourself.

Here you go :)

Will do on Thursday, the whole procedure takes ~6h on my machine and tomorrow I'm out of town 😅

I finally got to run it again. There were indeed quite a few errors before the VRF tests. Though I'm not sure which one could actually be the curlprit. I attached the full output of the smoketest run. Hope this actually helps in sorting the issues :)

In T7159#219749, @dmbaturin wrote:

@MPStudyly Well, it's open-source, so anyone can remove the banner by editing the script. The intention of the banner is simply to explain that rolling release and stream builds offer no stability guarantees.

Is there anything else I can provide you with @c-po?

In T7215#217255, @c-po wrote:

Hi @MPStudyly,

can it be the case that your system you're running the test son already has a VRF named red?

Just to add to the argument: Using the build_type to determine if the banner gets shown or not would allow individual/custom builds to have it disabled as well (we know what we are doing). Obviously I can just speak for my use case, where we roll our own builds to get back qemu-guest-agent. I can't tell if this would go against the intention of introducing this banner in the first place.

In T7206#216891, @danielr1996 wrote:

I tried adding

[[includes_chroot]]
  path = "opt/vyatta/etc/config/config.boot"
  data = ""

to the build flavor, and now it seems to work.

I still get warning in the cloud init log, but so far I haven't noticed anything not working. This works as a workaround for me, but I still think that this is a bug.

Nothing to thank me for @HollyGurza, you're the one who fixed it! :) After all, it seems I got the issue wrong anyway. ^^"

I did not have a deeper look yet, but as some tests related to hugepages are failing, I assume they'd need to be enabled on the host running the tests and Docker should be allowed to make use of them as well? About the latter I'm unsure as a VM is spun up to perform the tests, so Docker might be irrelevant to this.

In T7080#216314, @Viacheslav wrote:

Mem_page_size test fails
...

In T6691#207172, @MPStudyly wrote:

I've just encountered the same issue upgrading from a 1.5 build from May 2024 to the most recent a few days ago. Had very little time to investigate. Next week I'll take some more time and will report back if I find anything interesting.

I've just encountered the same issue upgrading from a 1.5 build from May 2024 to the most recent a few days ago. Had very little time to investigate. Next week I'll take some more time and will report back if I find anything interesting.

Probably a duplicate of https://vyos.dev/T6679.

Probably a duplicate of https://vyos.dev/T6714.

Doesn't cloud-init fully cover this? We are provisioning our VPN endpoints fully via that and thus never need to touch the device once it is running. You need to provide an according config file + .iso at initial boot though, which might only be feasible when VyOS runs inside a VM.

In T6563#194972, @Viacheslav wrote:

Any idea for CLI?