Brak pełnej emulacji katalogu /dev w WSL wskazuje na ograniczenia architektury WSL2 — nie wszystkie urządzenia sprzętowe Linuksa są w pełni odwzorowane w tym środowisku wirtualizacji.
Czym jest brak pełnej emulacji /dev
Brak pełnej emulacji /dev oznacza, że środowisko Linux uruchomione w Windows Subsystem for Linux nie udostępnia wszystkich urządzeń i interfejsów sprzętowych w taki sam sposób jak pełnoprawna instalacja Linuksa działająca bezpośrednio na komputerze. Katalog /dev nie jest zwykłym folderem z plikami użytkownika. Znajdują się w nim specjalne węzły urządzeń, przez które programy komunikują się między innymi z terminalami, dyskami, portami szeregowymi, urządzeniami wejściowymi, układami graficznymi oraz innymi elementami systemu.
W WSL zawartość tego katalogu jest tworzona i udostępniana zgodnie z możliwościami warstwy integrującej Linuksa z Windowsem. Nie wszystkie mechanizmy obecne w jądrze natywnego systemu Linux mają bezpośredni odpowiednik po stronie Windows. Z tego powodu aplikacja może widzieć podstawowe urządzenia potrzebne do pracy powłoki, lecz jednocześnie nie otrzyma dostępu do interfejsu wymaganego przez określone narzędzie, sterownik albo usługę systemową.
Nie jest to zazwyczaj uszkodzenie samego katalogu. Węzły urządzeń są elementem środowiska uruchomieniowego, a ich dostępność zależy od sposobu obsługi sprzętu przez WSL, konfiguracji systemu Windows, wersji używanych komponentów oraz rodzaju programu, który próbuje z nich skorzystać. Dlatego brak konkretnego wpisu w /dev może być prawidłowym ograniczeniem środowiska, a nie błędem wymagającym ręcznego utworzenia pliku.
Warto odróżnić brak emulacji od braku uprawnień. W pierwszym przypadku urządzenie nie zostało udostępnione w danym środowisku. W drugim urządzenie może istnieć, ale proces nie ma prawa odczytu lub zapisu. Samo polecenie ls /dev pokazuje jedynie dostępne węzły, natomiast nie rozstrzyga jeszcze, czy aplikacja może prawidłowo korzystać z reprezentowanego interfejsu.
Kontekst techniczny i porównanie sposobów dostępu - Brak pełnej emulacji /dev
W natywnym Linuksie katalog /dev jest powiązany z mechanizmami jądra oraz usługami odpowiedzialnymi za wykrywanie i obsługę urządzeń. Po podłączeniu sprzętu system może utworzyć odpowiedni węzeł, nadać mu właściwego właściciela i grupę, a następnie udostępnić go aplikacjom korzystającym ze standardowych interfejsów systemowych. W WSL przebieg ten nie jest identyczny, ponieważ urządzenia fizycznie należą do systemu Windows, a środowisko Linux otrzymuje tylko wybrane funkcje przekazane przez warstwę integracji.
Różnica jest szczególnie widoczna w przypadku sprzętu wymagającego bezpośredniej kontroli, własnego sterownika albo niskopoziomowych operacji. Program przeznaczony dla klasycznej instalacji Linuksa może zakładać obecność określonego pliku urządzenia, możliwość wykonania operacji wejścia i wyjścia albo dostęp do mechanizmów zarządzanych przez usługi takie jak udev. W WSL takie założenia nie zawsze są spełnione, nawet jeżeli sama aplikacja uruchamia się bez komunikatu o błędzie.
Podobne ograniczenia mogą występować w kontenerach, lecz tam przyczyną bywa zwykle odizolowanie procesu i brak przekazanego urządzenia. W WSL problem wynika z innego modelu integracji systemów. WSL1 korzysta z odmiennego mechanizmu zgodności, natomiast WSL2 uruchamia rzeczywiste środowisko Linux z własnym jądrem, jednak nadal nie oznacza to pełnego, automatycznego przekazania całego sprzętu komputera do systemu Linux.
Przy analizie należy sprawdzić, czy program rzeczywiście potrzebuje urządzenia z /dev, czy tylko oczekuje obecności określonej ścieżki. Niektóre narzędzia mogą działać przez usługę Windows, zdalny interfejs, przekierowanie portu albo dodatkowy mechanizm integracyjny. Utworzenie pustego węzła poleceniem administracyjnym nie zapewni jednak obsługi sprzętu, jeżeli za wpisem nie stoi działający interfejs jądra i odpowiedni sterownik.
Pomocne bywa porównanie wyników poleceń ls -l /dev, mount, uname -a oraz informacji o urządzeniu widocznych po stronie Windows. Należy również sprawdzić logi aplikacji i dokładny komunikat błędu. Samo sformułowanie „no such file or directory” może oznaczać brak węzła, natomiast „permission denied” wskazuje raczej na problem z uprawnieniami. Błąd komunikacji po otwarciu urządzenia może z kolei wynikać z braku obsługi funkcji, a nie z nieprawidłowej nazwy ścieżki.
Typowe problemy i błędy - Brak pełnej emulacji /dev
Jednym z częstszych problemów jest uruchamianie narzędzia oczekującego urządzenia szeregowego, interfejsu USB albo specjalnego urządzenia wejściowego, którego WSL nie udostępnia w wymaganej postaci. Program może wtedy kończyć pracę podczas inicjalizacji, zatrzymywać się na etapie wykrywania sprzętu albo zgłaszać, że wskazana ścieżka nie istnieje. W takiej sytuacji ponowne instalowanie aplikacji zazwyczaj nie rozwiązuje przyczyny.
Inny błąd polega na ręcznym tworzeniu pliku w katalogu /dev i traktowaniu go jako zamiennika urządzenia. Węzeł urządzenia nie jest zwykłym plikiem konfiguracyjnym. Musi wskazywać właściwy typ urządzenia i być powiązany z obsługą po stronie jądra. Nieprawidłowo utworzony wpis może jedynie zmienić treść komunikatu błędu, a w niektórych przypadkach utrudnić późniejszą diagnostykę.
Problemy mogą pojawiać się także po aktualizacji Windows, jądra WSL albo samej dystrybucji. Zmiana wersji może wpłynąć na sposób przekazywania urządzeń, zachowanie usług startowych, reguły uprawnień lub dostępność dodatkowych funkcji. Nie powinno się zakładać, że rozwiązanie działające w jednej dystrybucji zadziała bez zmian w innej, ponieważ znaczenie mają między innymi konfiguracja startowa, używane pakiety i sposób uruchamiania programu.
Do pomyłek prowadzi również utożsamianie katalogu /dev z pełną listą sprzętu wykrytego przez komputer. Obecność wpisu nie gwarantuje poprawnej obsługi, a jego brak nie musi oznaczać awarii. Należy ustalić, jaki protokół wykorzystuje aplikacja, gdzie faktycznie znajduje się urządzenie, czy wymagany sterownik działa po stronie Windows lub Linuksa oraz czy program został zaprojektowany do pracy w WSL.
Warto zachować pełny komunikat z terminala, wynik polecenia uruchomionego w środowisku WSL, informacje o dystrybucji i wersji WSL oraz opis czynności, po których problem wystąpił. Przydatne jest także sprawdzenie, czy ta sama funkcja działa w natywnym Linuksie albo w aplikacji uruchomionej bezpośrednio w Windows. Takie porównanie pomaga rozdzielić błąd programu od ograniczenia sposobu udostępniania urządzeń.
Kiedy warto skorzystać z pomocy serwisu - Brak pełnej emulacji /dev
Zgłoszenie do serwisu jest uzasadnione, gdy brak dostępu do /dev pojawił się nagle, towarzyszą mu inne objawy systemowe albo nie można ustalić, czy przyczyną jest konfiguracja WSL, sterownik Windows, uprawnienia czy uszkodzenie sprzętu. Szczególnej uwagi wymaga sytuacja, w której urządzenie przestało działać również w aplikacjach uruchamianych bezpośrednio w Windows. Wtedy problem może wykraczać poza samo środowisko Linux.
Przed przekazaniem komputera można przygotować nazwę używanej dystrybucji, wersję WSL, polecenie wywołujące błąd, dokładny tekst komunikatu oraz informację, czy problem występuje po ponownym uruchomieniu systemu. Nie należy usuwać logów ani wykonywać przypadkowych zmian w katalogu /dev, ponieważ utrudnia to odtworzenie pierwotnego stanu.
W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie laptopa, a diagnoza LAPTOPA jest darmowa. W ramach analizy można rozdzielić kwestie związane z konfiguracją WSL od problemów sterownikowych i sprzętowych, a następnie wskazać, czy właściwsza będzie zmiana sposobu uruchamiania programu, korekta uprawnień, aktualizacja składników systemu czy zastosowanie rozwiązania działającego poza WSL.
Jeżeli ograniczenie wynika z samego modelu integracji WSL, nie zawsze da się zapewnić pełną obsługę konkretnego urządzenia w tym środowisku. Wówczas rzetelna diagnoza powinna obejmować także możliwe rozwiązania zastępcze, na przykład uruchomienie wybranego narzędzia po stronie Windows, użycie natywnego Linuksa albo przekazanie tylko tych funkcji sprzętu, które są rzeczywiście wymagane przez aplikację.
