sudo: a password is required, printed by a script you ran from Windows with wsl -- bash -c, means the script reached a sudo with no terminal to ask on. Run it as root with wsl -u root, or grant the WSL user passwordless sudo; do not try to pipe a password in.

The quickest fix for a one-off install is wsl -d Ubuntu-24.04 -u root -e sh -c "…": WSL switches user without asking for anything, the script's own sudo calls become no-ops because it is already root, and everything it creates is owned by root as it would be on a real server.

The error

>>> Installing ollama to /usr/local
sudo: unable to restore terminal settings: Illegal seek
sudo: a password is required

Why it happens

Inside an interactive WSL terminal, sudo prompts for the user's password and you type it. When Windows runs a command through wsl -- bash -c, or a background job does, there is no interactive terminal: standard input is a pipe or nothing. sudo tries to prompt, cannot, and gives up with exactly this pair of lines. The "Illegal seek" line is sudo failing to read terminal settings from a non-terminal; the second line is the real message. Install scripts that call sudo internally, like Ollama's, hit it on their first privileged step, and if the caller only reads the last line of the log, the failure looks like something else entirely.

The fix

wsl -d Ubuntu-24.04 -u root -e sh -c "curl -fsSL https://ollama.com/install.sh | sh"

Run as root explicitly for the install, then go back to the normal user. If a script must run unattended as the normal user repeatedly, add a sudoers rule instead: echo "deploy ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/deploy from an interactive shell, once. That mirrors what a cloud image's deploy user usually has. What not to do: echo password | sudo -S in a script, which puts the password in your command history and your logs.

What the AI got wrong: it launched the installer in the background, waited twenty minutes for output that never came, and only then looked at the log. The hang was sudo waiting on a prompt nobody could see. A non-interactive command that produces no output for a minute is not working; it is waiting.

Where it bit us

Season four, Part 4, installing the model runtime on Ubuntu under WSL2. The distribution's default user needed a sudo password, the automation could not type one, and the first install attempt sat silent until it was killed. The second attempt ran as root and finished in a minute, once the missing zstd package was also dealt with.

Frequently asked

How do I run a command as root in WSL without a password?
Use wsl -d <distro> -u root -- <command>. WSL switches to root without prompting because the Windows user already owns the distribution. Use it for installs and administration, not as the default user.
Why does sudo say a password is required only when I run WSL from Windows?
Because there is no interactive terminal attached. In a WSL window sudo can prompt you; from wsl -- bash -c or a background job it cannot, so it fails immediately with this message.
Is it safe to give the WSL user passwordless sudo?
For a development distribution on your own machine it is the common setup and matches cloud deploy users. Add a file under /etc/sudoers.d for that one user rather than editing the main sudoers file.

More decoded errors in the Fixes category, or start the season that produced this one at Part 1.