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?