WSL instalation fail waiting for node ready

[cyberbol]

Jasne, Arek. Oto profesjonalnie sformułowana wiadomość po angielsku, gotowa do wklejenia jako "Issue" (problem) na GitHubie projektu Olares. Zawiera wszystkie kluczowe informacje o naszym środowisku i napotkanych błędach.

Subject: Installation fails on WSL 2 (Ubuntu 22.04) with "Operation not permitted" errors
Hi Olares Team,

I'm trying to install Olares on a Windows 11 machine using WSL 2 (Ubuntu 22.04), but the installation script consistently fails.

Steps to Reproduce:

Set up a fresh Ubuntu 22.04 environment in WSL 2.

Ensure Docker Desktop for Windows is running and properly integrated with the WSL 2 distro.

Enable systemd by adding [boot]\nsystemd=true to /etc/wsl.conf and restarting WSL (wsl --shutdown).

Run the official installation command as a regular user: curl -fsSL https://olares.sh | bash -

Provide the sudo password when prompted.

Actual Behavior:
The script proceeds through downloading packages and pre-checks, but during the "Install the System" phase, it encounters permission errors when trying to modify system files. The log shows:

sed: cannot rename /etc/sedKsPBtv: Operation not permitted
sed: cannot rename /etc/sedEoKuwK: Operation not permitted
/usr/local/bin/kube-scripts/initOS.sh: line 108: /etc/hosts: Operation not permitted
After these errors, the installation continues but eventually gets stuck in an infinite loop, repeatedly printing:
cyberaro-pc waiting for node ready

The installation never completes. The same issue occurs when running the installation script directly as the root user.

Expected Behavior:
The installation should complete successfully, and the Olares service should start, allowing access via http://localhost:5001.

My Environment:

OS: Windows 11

WSL Version: 2

Linux Distribution: Ubuntu 22.04.5 LTS

Docker: Docker Desktop for Windows 4.x with WSL 2 integration enabled.

GPU: NVIDIA RTX 4090

NVIDIA Driver (in WSL): 581.42

CUDA Version (in WSL): 13.0

Additional Context:
It seems the installation script is not fully compatible with the specific permissions model of WSL 2, particularly regarding the modification of auto-generated files like /etc/hosts. The script's inability to modify these critical files likely prevents the underlying k3s cluster from initializing correctly, leading to the "waiting for node ready" loop.

Happy to provide more logs or run any diagnostic commands if needed. Thanks for your work on this project!

2025-10-11T17:35:56.229+0100 cyberaro-pc waiting for node ready
2025-10-11T17:36:05.622+0100 cyberaro-pc waiting for node ready
2025-10-11T17:36:15.732+0100 cyberaro-pc waiting for node ready
2025-10-11T17:36:25.832+0100 cyberaro-pc waiting for node ready
2025-10-11T17:36:35.215+0100 cyberaro-pc waiting for node ready
2025-10-11T17:36:45.322+0100 cyberaro-pc waiting for node ready

loop and nothing else

[dkeven]

Hi @cyberbol, when installing Olares on WSL, the /etc/hosts will be modified to add an "i" attr , to prevent WSL from auto reverting some changes back, normally, this does not need to be updated unless the WSL's IP changed, which is rare unless manually configured its network (in which case you need to execute chattr -i /etc/hosts for Olares to update address binding configs of related services)

However, in this case, it's likely there're some other issues preventing the k3s server to start and initialize, which need to be identified by looking at the k3s' logs by sudo journalctl -u k3s

Also, Olares' CLI has a built-in wrapper for gathering relevant logs: sudo olares-cli logs, the generated tar.gz archive is also helpful for us to dig into the root cause.