WAN client in boot loop

Beiträge: 2
Registriert: 03 Okt 2013, 15:49

WAN client in boot loop

Beitragvon petteri » 11 Jun 2020, 12:24

Hello all,

I have strange problem with some of our WAN clients. Opsi-client informs the user that cache is ready by boot request dialog and user reboots the workstation. When opsi-client tries to install packages it fails. After couple of hours the boot request dialog appears again. After second boot, same thing happens again and so on.There is no error messages in https://<client-ip>:4441/info.html. This state occurs randomly, not every time, when client tries to install new updates. Only way to solve this situation is to delete client cache and install updates by on_demand command. Usually, before on_demand, I need to restart opsi-client service.

We have 47 WAN client and this problem have occured about in 7 workstation (Windows 10). Our opsi-client-agent version is Have any of you run into the same problem? I have no idea how to solve the problem. Ideas?


Beiträge: 1909
Registriert: 28 Mai 2008, 10:53

Re: WAN client in boot loop

Beitragvon ueluekmen » 12 Jun 2020, 13:19


without logfiles is not possible to say what is happening their.

If you have a support-contract please open a support ticket. If not, you can collect your opsiclientd.logs from the client and send it to info(at)uib.de with a reference to this post. We will have a look what's wrong in your setup.
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.

Andreas T.
Beiträge: 4
Registriert: 10 Mai 2015, 17:38

Re: WAN client in boot loop

Beitragvon Andreas T. » 12 Jun 2020, 17:07


we might have had the same problem when we tested the WAN extension. We found out that the event event_net_connection was triggered when connecting to Wi-Fi, not just when connecting to VPN. This then caused to the problem that the client did not send its updated config back to the server. We solved this by disabling the event by setting the host parameter opsiclientd.event_net_connection.active to false. The updated config was then successfully sent back to the server via the event_timer event.