Is this also true for multiple users so they not all end up with vyos:users?

PR: https://github.com/vyos/vyos-build/pull/1251

New PRs:

I checked it manually and it looks like the metadata was transferred after upgrade:

vyos@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history
600 vyos:users
vyos@vyos1:~$ sudo stat -c '%a %U:%G' .ssh/known_hosts
644 vyos:users
vyos@vyos1:~$ add system image vyos-999.202607231048-generic-amd64.iso
Validating image compatibility
Validating image checksums
...
Would you like to copy SSH host keys? [Y/n]
Copying SSH host keys
Would you like to save the SSH known hosts (fingerprints) from your current configuration? [Y/n]
Copying SSH known_hosts files
Would you like to copy bash history? [y/N] y
Copying bash history
...
vyos@vyos1:~$ sudo reboot now
...
vyos@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history
600 vyos:users
vyos@vyos1:~$ sudo stat -c '%a %U:%G' .ssh/known_hosts
644 vyos:users

A PR has been opened with these changes.

Will chmod and chown be preserved on the directories and files being copied?

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

@mrpops2ko Could you please test whether the fix works for you?

This issue remains in july 2026 using VyOS Stream 2026.03.

A workaround for NTP and DNS-server is to use containers and allow-host-networks in case the container itself have support for VRF (aka SO_BINDTODEVICE seen through "ss -atulpn" that the process listens to for example 192.0.2.1%PROD:123 instead of just 192.0.2.1:123).

Decision: rather than revert the validation, we'll do the backport properly — add <multi/> to ipv6-address and ipv6-prefix in dhcpv6-server-common-config.xml.i so Circinus matches rolling. With the nodes multi-value, the existing loop-based verify() works as intended and the smoketests pass.
https://vyos.dev/T8862

https://github.com/vyos/vyos-1x/pull/5337

Perhaps time for VyOS to overall move to Debian 13 (trixie) as base?

Thanks for the detailed report, @tjjh89017 --- the original walk of the directory prevented this error, and remained in vyos-configd (before refactoring) even after the include-list was auto-generated at build time in https://vyos.dev/T6510; I'll add appropriate protections.

https://github.com/vyos/vyos-1x/pull/5336

https://github.com/vyos/vyos-build/pull/1248

Sorry, typo in the title, but I have no rights to change it.

There are 2 ways a newer HAProxy can be made available in VyOS:

https://internal.confluence.vyos.com/wiki/x/HYBRPg

I ran into this with a Vyos router (VyOS 2026.06.20-0050-rolling) with an interface against a Juniper ex2300 that literally takes 5+ minutes to boot going from power on to interfaces up. Perhaps a 10 minute timeout might be better? Or is there some necessary reason for there to be a timeout at all?

First PR improving the test fixture under load https://github.com/vyos/vyos-build/pull/1247

I am facing the same issue, are there any plans to expand the DHCP configuration? I see there is a vendor specific option for Ubiquiti. Option 150 is primarily used by Cisco phones. Can it be added as a vendor specific option?

https://github.com/vyos/vyos-build/pull/1246

Closing this as the real error is T9098 SBOM should work on generated squashfs rather then unpacked rootfs

@tjjh89017 yes - we removed --allow-downgrades during the 1.4 development cycle which was hard. There is no plan to reintroduce it. Infact your patch is a better solution and we will adjust/merge this. Also once we run trixie our plan is to ditch this workaround again.

https://github.com/vyos/vyos-1x/pull/5323

https://github.com/vyos/vyos-1x/pull/5335

@bradkollmyer Hi! For the documentation, you can add PRs without a phorge task. Thanks,

Regarding (1) above: form-POST requests are preprocessed by overriding the route handler before delivery to the endpoint, hence managed by background operations as any JSON formatted request. Regarding (2), thanks for the offer to open a separate task; that would be helpful.