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

Forgot to mention that lacking proper FS trimming has a very negative impact when running VyOS virtualised and having the filesystem sitting on a thin provisioned volume, like for instance LVM thin. The absence of discard commands coming from the virtual node does not allow the cleaning of unused blocks.

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

A PR was submitted:
https://github.com/vyos/vyos-1x/pull/5353/changes

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

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

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

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

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

@doctorpangloss any news?
Do you have steps to reproduce? If yes, provide the minimal set of commands and version.

Yes, I can confirm that it works the same with multiple users in the system:

vyos@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history
600 vyos:users
vyos@vyos1:~$ su - testuser
testuser@vyos1:~$ pwd
/home/testuser
testuser@vyos1:~$ sudo stat -c '%a %U:%G' .bash_history
600 testuser:users

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:

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?