After some investigation, it can be advised, that the described issue is to do with netcomm_cli module implementation used by VyOS Ansible Galaxy - namely, the ansible_net_version is set for a connection and stays so until reconnects and re-reads the modified hostname.
As such, this is currently outside of the collection's control.
That said, the issue can be easily avoided by reading ansible_facts mid-playbook:
Example Playbook:

https://github.com/vyos/vyos.vyos/pull/400

Hello! Any news regarding this issue?

@pasik Hi mate! Were you the original reporter of this bug please?
If so, can you clarify a few questions I asked above?
thank you

I cannot see the virtual interface names are supported in 1.3-1.5 -

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

@Apachez could you please assign this task to me?

OK - a manual and specifically targetable workaround for this is possible using firewall matches for IPsec payloads, as part of T4694.

https://github.com/vyos/vyos.vyos/pull/398 - Ready

I will look into after https://github.com/vyos/vyos.vyos/pull/387

Closing this, new tasks can be opened for any issues found in new WLB.

Please re-open if this is encountered in new WLB.

This should not be an issue in new implementation

PR for new implementation: https://github.com/vyos/vyos-1x/pull/4356

Module updates (6.0.0) add support for encrypted passwords, including idempotence and tests.

Resolved with latest changes for 6.0.0

this issue doesn't reproduce on:

Hi, I'd like to get back on this task and give it a shot, but I have troubles building and testing images from scratch.
What's the recommended procedure? Installing the latest rolling release and hacking that one?

I suppose we could just add a "guesstimate" check, say, 2GB of free space. At the moment, rolling release images are about 600M, 2GB should be enough for a while, hopefully.

fix for another git commit archive related problem:
https://github.com/vyos/vyos-1x/pull/4333

looks like the problem was fixed in this task: T7048

I'm willing to work on this issue to implement solution proposed by @Viacheslav.

should be fixed by https://github.com/vyos/vyos.vyos/pull/382

This issue appears to persist. I have been trying to run QAT with 8970 cards, and I am also running into this issue. Ultimately I have two separate instances of VyOS which exhibit the same lockup issue (separate hardware and locations). The frequency of the locks ups is far more frequent than what lucasec mentioned. Anywhere in the 12 hour range after a reboot the system crashes.

This issue should have been resolved by a number of already implemented PRs - e.g. https://github.com/vyos/vyos.vyos/pull/354 or https://github.com/vyos/vyos.vyos/pull/368, therefore I am closing this ticket now. Please feel free to re-open if I am wrong

Are we closing this? Or we have some glowing example of the wrong processing?

I had a look at T5965 and several discussions on the forum.
It seems as though under certain circumstances there will be no answer from DHCP even though I can see the DISCOVER being sent out the wwan0 interface, but the connection works if I setup the parameters that can be betrieved from ModemManager.

fix for decimal DSCP values:
https://github.com/vyos/vyos-1x/pull/4302

i retested this issue:
could not reproduce the original problem on versions 1.4 and 1.5

The recent updates to vyos_user should support updating encrypted passwords, including appropriately understanding if there was a change.

@sdwilsh Unless you have an objection, I'm going to close this out as fixed by the current version in Main.

OMG. I just spent hours trying to diagnose why I was getting Sending reply: error_code 1 with output "error". The logging really needs to be improved.

Hello, I know that to debug, I have to read the tables

Raised a Draft PR https://github.com/vyos/vyos.vyos/pull/368

Fixed for 1.3+ along with test verifications

The fix is now a part of https://github.com/vyos/vyos.vyos/pull/367

https://github.com/vyos/vyos-utils/pull/28

the PR to fix this is https://github.com/vyos/vyos.vyos/pull/367

The PR tp fix this https://github.com/vyos/vyos.vyos/pull/367

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

This works!:

trae@cr01b-vyos# set pki ca IPA.TRAE32566.ORG system-install 
[edit]
trae@cr01b-vyos# commit
Archiving config...
  sftp://stor01a-rh9.int.trae32566.org/int/cr01b-vyos [edit]
trae@cr01b-vyos# run restart ntp
[edit]
trae@cr01b-vyos# run show ntp sources
.-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* ns02.ac.trae32566.org         2   6     7     0     +2ns[ -188ms] +/- 5513us
^- ns01.ac.trae32566.org         2   6     7     0   +120us[ -188ms] +/- 5598us

I prepared a service to log some network events including changing link status.
to configure service:

conf
set service monitoring network-event event addr
set service monitoring network-event event link
set service monitoring network-event event neigh
set service monitoring network-event event route
set service monitoring network-event event rule
commit

to check change status:

vyos@vyos:~$ sudo ip link set down dev eth1
vyos@vyos:~$ sudo ip link set up dev eth1
vyos@vyos:~$ show interfaces ethernet eth1 event-log link 
Dec 03 09:30:09 vyos-network-event-logger[21158]: [LINK]   3: eth1:  <BROADCAST,MULTICAST>  mtu 1500  qdisc fq_codel  state DOWN  group 0  link/ether 0c:89:0a:2e:00:01  brd ff:ff:ff:ff:ff:ff  [altname enp0s4] [altname ens4]
Dec 03 09:30:14 vyos-network-event-logger[21158]: [LINK]   3: eth1:  <BROADCAST,MULTICAST,UP,LOWER_UP>  mtu 1500  qdisc fq_codel  state UP  group 0  link/ether 0c:89:0a:2e:00:01  brd ff:ff:ff:ff:ff:ff  [altname enp0s4] [altname ens4]

Implemented in T6045

The PR# is re-submitted for review and testing

Path issues and unit tests resolved

Sounds reasonable! I'm not going to worry about it any more, unless I see any further symptoms. Thanks a lot for the fix and taking the time to respond here!

@gadams it may well have been the case that the fragile synchronization before the fix was in fact a cause of the problem, at least in some (all ?) cases. I expected however, that any other config error on boot could also trigger the complaint in vyos-configd, which would consequently drop any useful output. With the original change in T6326 and the fix in T6899, any output (error or otherwise) should now be robust and generally available (notably, through the http-api, which was the motivation to finally fix the output workaround for T6326).