Неочевидные проблемы WSL2 и как с ними жить

WSL2 — удобный инструмент, но, как и любая технология, он не идеален. В этой статье я хочу рассказать о нескольких подводных камнях, с которыми столкнулся сам, и о том, как их можно обойти (или хотя бы минимизировать их влияние на рабочий процесс). Также поговорим, как можно использовать графические приложения, и немного о том, как работать с контейнерами.

1. Проблемы с сетью (и странные решения)

Первая и самая раздражающая проблема — нестабильная работа сети. Возможно, у меня просто уникальный случай, но, судя по обсуждениям на GitHub, я не один такой "удачливый". Надеюсь, в комментариях подскажут простое решение, но пока что я не нашел способа это исправить.

Иногда WSL2 начинает работать медленно с сетью, и единственный рабочий вариант — выполнить в PowerShell (от администратора) команды, которые я в итоге сохранил в .bat-файл для быстрого запуска.

# Проверяем, запущен ли скрипт от имени администратора
if (-not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    # Если нет, перезапускаем скрипт с правами администратора
    Start-Process pwsh -Verb RunAs "-NoProfile -ExecutionPolicy Bypass -File `"$($MyInvocation.MyCommand.Path)`""
    exit
}

# Ваш код ниже этого комментария
Write-Host "Скрипт выполняется с правами администратора!"

Restart-NetAdapter -Name "vEthernet (WSL (Hyper-V firewall))" -IncludeHidden
Set-NetAdapterAdvancedProperty -Name "vEthernet (WSL (Hyper-V firewall))" -DisplayName "Large Send Offload Version 2 (IPv4)" -DisplayValue Disabled -IncludeHidden
Set-NetAdapterAdvancedProperty -Name "vEthernet (WSL (Hyper-V firewall))" -DisplayName "Large Send Offload Version 2 (IPv6)" -DisplayValue Disabled -IncludeHidden

2. Неконтролируемый рост диска

Многие в комментариях к прошлой статье упоминали эту проблему, и я тоже с ней столкнулся. Сначала всё казалось решаемым: команда оптимизации диска работала отлично… пока мне не понадобилось перенести данные на другой диск.

Я решил просто скопировать файлы (ведь на Windows флешки я всегда извлекал без "безопасного извлечения" — и ничего же не ломалось!). Остановить WSL2? "Да зачем, авось пронесет!"

В итоге скопировалось 10 ГБ полезных данных и 100 ГБ… пустоты. То ли оптимизация создала "дыры", то ли копирование пошло криво — но факт остаётся фактом. Мораль: если копируете WSL2-диск, сначала останавливайте его и проверяйте содержимое.

Работа с Git в WSL: быстрый старт с нюансами

Установка Git (если вдруг нет)

В большинстве Linux-дистрибутивов Git уже предустановлен. Но если по какой-то мистической причине его нет — исправляем ситуацию парой команд:

sudo apt update  
sudo apt install git -y

Настройка пользователя

Git обязательно потребует указать ваши имя и email. Если этого не сделать, при первом коммите он недвусмысленно намекнёт об ошибке. Чтобы не тратить время, сразу выполните:

git config --global user.name "John Doe"
git config --global user.email "your_email@example.com"

Примечание:

• Подставьте реальные данные (если, конечно, не хотите, чтобы коммиты светились под именем "John Doe").

• Для первого теста сойдёт и условный email. Git не проверяет его существование.

Доступ к репозиториям

Идеальный вариант. Для каждого репозитория — отдельный SSH-ключ. Так рекомендуют все мануалы, и это действительно самый безопасный подход. Но если бы все следовали правилам, самый популярный пароль в мире не был бы "123456". Поэтому рассмотрим "ленивый" (но менее безопасный!) способ — один ключ для всех репозиториев. Более подробный процесс описан в официальной документации GitHub: по этой ссылке можно посмотреть и почитать, как правильно настроить доступ.

Но важно учитывать: если вам понадобится использовать несколько аккаунтов (а рано или поздно это случится), нужно сразу грамотно настроить конфигурацию. Мой вариант может вам понравиться, а может и нет — судите сами.

Давайте обсудим это в комментариях: интересно узнать, как разные разработчики организуют работу с ключами. Лично я знаю несколько рабочих подходов, но всегда открыт для новых идей. Как вы решаете этот вопрос? Делитесь опытом!

Генерация SSH-ключа:

ssh-keygen -t ed25519 -C "work_email@company.com" -f ~/.ssh/id_ed25519_work
ssh-keygen -t ed25519 -C "personal_email@gmail.com" -f ~/.ssh/id_ed25519_personal

Просто жмите Enter на все вопросы (парольную фразу можно пропустить).

Убедимся, что все сделано правильно:

ls -la .ssh/

Правим nano ~/.ssh/config (если файла нет — создаем):

# Рабочий аккаунт (GitHub)
Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work

# Личный аккаунт (GitHub)
Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal

Для сохранения нажимаем ctrl + x, затем Y и Enter

Добавление ключа в GitHub:

cat ~/.ssh/id_ed25519_personal.pub

Скопируйте ключ: 

Вставьте его в настройках GitHub: Settings → SSH and GPG keys → New SSH key.

Важно: приватный ключ — это как мастер-ключ от всех дверей. Если его утерять, злоумышленник получит доступ ко всем репозиториям.

Для примера работы давайте создадим любой приватный репозиторий и попробуем его клонировать.

Клонируем репозитории с учетом хоста (меняем на свой — r-revel/git-demo.git):

git clone git@github.com-personal:r-revel/git-demo.git

Всё отлично! Мы можем начать работать сразу с данным репозиторием через VS Code, написав в терминале:

code ./git-demo/.

P. S. О безопасности

Да, я знаю, что это не идеально. Но иногда "работает уже сейчас" важнее "идеально по стандартам". Главное, не используйте этот подход для корпоративных проектов с критичными данными.

Разворачивание проекта в Docker с использованием GPU-ускорения

В прошлой статье мы запустили простой Node.js-проект, но это можно было сделать и без WSL2 — давайте наконец используем Docker по назначению. Мы же не просто так выбрали WSL2 с поддержкой GPU! Сегодня я покажу, как запустить контейнер с ускорением для нейросетей — например, для генерации изображений в Stable Diffusion. Хотя это и не совсем типичная задача для разработки, зато очень наглядно демонстрирует возможности WSL2 и Docker.

WSL2 обеспечивает базовую поддержку GPU без дополнительных настроек, однако для работы с CUDA (платформой, обеспечивающей ускорение вычислений для нейронных сетей) потребуется выполнить дополнительные шаги по конфигурации. Рекомендую сразу использовать docker-compose.yml. Хотя для одиночного контейнера это может показаться излишним, в реальных проектах, где одновременно работают несколько сервисов (СУБД, backend-приложение, системы очередей), такой подход существенно упрощает управление инфраструктурой.

Пример:

Проверяем, что GPU виден в WSL2:

nvidia-smi

Устанавливаем инструменты для работы с docker и cuda:\

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

Для удобства создадим отдельную папку для проекта:

mkdir stable_diffusion
cd stable_diffusion
nano docker-compose.yml

version: '3.8'

volumes:
  models-data:
  outputs-data:
  extensions-data:
  embeddings-data:

services:
  download-models:
    image: busybox
    container_name: sdxl-downloader
    network_mode: host
    volumes:
      - models-data:/data
    command: >
      sh -c "
      wget -O /data/Stable-diffusion/sd_xl_base_1.0.safetensors https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors &&
      wget -O /data/Stable-diffusion/sd_xl_refiner_1.0.safetensors https://huggingface.co/stabilityai/stable-diffusion-xl-refiner-1.0/resolve/main/sd_xl_refiner_1.0.safetensors
      "
    restart: on-failure

  sd-webui:
    image: universonic/stable-diffusion-webui:latest
    container_name: sd-webui
    ports:
      - "8080:8080"
    volumes:
      - models-data:/app/stable-diffusion-webui/models
      - outputs-data:/app/stable-diffusion-webui/outputs
      - extensions-data:/app/stable-diffusion-webui/extensions
      - embeddings-data:/app/stable-diffusion-webui/embeddings
    environment:
      - CLI_ARGS=--medvram --xformers --listen --skip-version-check --no-download-sd-model --disable-safe-unpickle
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    depends_on:
      - download-models
    restart: unless-stopped

Для сохранения нажимаем ctrl + x, затем Y и Enter

Запускаем Stable Diffusion:

docker compose up -d

Теперь ваши нейросетевые модели будут работать с аппаратным ускорением, почти как на профессиональном серверном оборудовании. Важно иметь в виду, что скачивание моделей и их настройка могут занять достаточно большое количество времени

Важно: если nvidia-smi не работает, проверьте, что установлены драйверы WSL2 для GPU.

Графика и Android в WSL2: зачем это нужно?

В прошлом материале я рассказывал про настройку WSL2 для обычной разработки. Но что, если нужно работать с графическими приложениями или Android-эмулятором?

Почему не Android Studio на Windows?

Для меня программирование — не только работа, но и хобби. Постоянно появляются новые фреймворки, и сразу хочется попробовать их в деле. В момент создания всё работает идеально… но проходит год, два, пять — и собрать старое приложение становится почти невозможно.

С WSL2 другая история: среда остаётся неизменной. Да, Google Play не примет приложение на устаревшем SDK, но хотя бы можно собрать его и посмотреть, как оно работало. Бизнес-логику потом можно перенести на современный стек (спасибо LLM, это теперь не так сложно), но сам факт, что проект не превратился в "кирпич", уже радует.

Запуск Android Studio в WSL2 и начало работы с Flutter-приложением

В целом можно просто установить и запустить графическое приложение в WSL2 — и оно даже будет работать. Но использовать полноценную IDE в таком окружении не совсем удобно из-за проблем с отображением. Поэтому мы пойдём, как всегда, самым сложным путём: развернём Android Studio прямо в WSL2, настроим эмулятор, а работать будем через VS Code.

Да, я полностью осознаю, что это выглядит как сомнительное приключение и изобретение велосипеда. Но лично мне так удобно — возможно, кому-то ещё этот способ окажется полезен. Ещё раз подчеркну: это не призыв к действию и не единственный вариант. Если я запускал macOS в WSL2, это уже говорит о моих... специфичных предпочтениях.

Для начала проверим работу графических приложений. Всё просто:

sudo apt install x11-apps

После установки можно запустить, например, калькулятор:

xcalc

Если он отобразился, значит, базовая графическая подсистема работает.

Установка Android Studio

sudo apt update
sudo apt install default-jdk

Затем нам необходимо зайти на страницу сайта https://developer.android.com/studio/archive

По-хорошему нам нужно зайти на официальный сайт разработчиков developer.android.com/studio/archive, найти там последнюю версию и скачать Linux-версию в формате tar.gz. Но я для удобства подготовил команду для скачивания:

curl -L -O https://redirector.gvt1.com/edgedl/android/studio/ide-zips/2025.1.1.13/android-studio-2025.1.1.13-linux.tar.gz

Распаковываем и переносим:

tar -xzf android-studio-2025.1.1.13-linux.tar.gz
sudo mv android-studio /opt/

После мы можем просто запустить Android Studio и следовать инструкциям.

sh /opt/android-studio/bin/studio.sh

После первичной установки и настройки мы увидим экран приветствия. Я рекомендую создать какое-нибудь Android-приложение для тестирования среды и для того, чтобы убедиться в работоспособности всех компонентов.

Этот способ по-настоящему удобен по нескольким причинам. Во-первых, он позволяет чётко разграничивать среды для разных проектов разработки — никаких конфликтов зависимостей или версий. Во-вторых, перенос готового WSL-образа на другую машину становится делом пяти минут, что особенно актуально при неизбежной переустановке системы.

Мы все знаем, как Microsoft регулярно обещает выпустить последнюю версию ОС и больше её не обновлять, но на практике эти обещания так и остаются обещаниями. Рано или поздно появляется новая ОС, и здесь наш подход становится спасением: у вас всегда будет под рукой готовый, настроенный образ для мобильной разработки.

И самое приятное: когда образ не запущен, можно быть на 100% уверенным, что никакие фоновые утилиты или службы не работают и не нагружают основную операционную систему. Это как иметь под рукой "спящую" лабораторию: запустил и сразу работаешь.