Gdy Docker odmawia uruchomienia po migracji danych ZimaOS, ostatni wiersz w logu może wprowadzać w błąd. W tym źródłowym przypadku z lutego 2026 roku Docker ostatecznie zgłosił, że sterownik pamięci masowej overlay2 jest nieobsługiwany. Kilka wcześniejszych wierszy ujawnia prawdziwą przyczynę: Docker nie mógł utworzyć plików tymczasowych ani przetestować pamięci masowej overlay, ponieważ na dysku systemowym brakowało wolnego miejsca.
Użytkownik miał dysk SSD ZimaOS o pojemności 180 GB i przypadkowo pozostawił na nim rozrastającą się bazę danych Immich. Gdy próbował rozpocząć migrację, nie było już wystarczająco dużo wolnego miejsca na bezproblemowe przeniesienie. Po kilku próbach i ręcznym usunięciu logów dane AppData najwyraźniej zostały przeniesione, ale dysk systemowy nadal osiągnął 100% zapełnienia, a Docker po ponownym uruchomieniu nie mógł się już zainicjalizować.
Immich zapełnił mały systemowy dysk SSD, zanim rozpoczęto migrację
Użytkownik źródłowy zainstalował Immich bez przeniesienia jego bazy danych z dysku systemowego. W miarę rozrastania się stosu zdjęć dysk zapełnił się, a ZimaOS zaczął zgłaszać błędy.
Jest to zgodne z aktualnymi zaleceniami IceWhale: dane aplikacji należy umieszczać na głównej przestrzeni dyskowej, a nie na małym dysku systemowym, ponieważ biblioteki zdjęć, metadane multimediów, indeksy dokumentów, bazy danych i pamięci podręczne mogą szybko rosnąć.
Sama migracja wymagała przestrzeni roboczej
Użytkownik spróbował przepływu migracji ZimaOS dopiero wtedy, gdy dysk systemowy był już krytycznie zapełniony. Powiedział, że pierwsze próby migracji zakończyły się niepowodzeniem z powodu niewystarczającej ilości wolnego miejsca potrzebnego do buforowania operacji.
To ważna lekcja operacyjna: przenieś dane AppData, zanim na dysku systemowym pozostanie zaledwie kilka gigabajtów wolnego miejsca, a nie dopiero wtedy, gdy Docker i usługi migracji będą już pozbawione przestrzeni roboczej.
Komunikat o gnieździe Dockera był tylko objawem
Zgłoszenia aplikacji:
Nie można połączyć się z demonem Dockera pod adresem unix:///var/run/docker.sock.
Czy demon Dockera działa?Ten komunikat oznacza, że demon Dockera jest niedostępny. Nie wskazuje, dlaczego demon nie uruchomił się.
Dziennik ujawnił prawdziwą przyczynę źródłową
Ważne wiersze to:
brak wolnego miejsca na urządzeniu
Nie udało się zapewnić załadowania domyślnego profilu AppArmor
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
failed to start daemon: error initializing graphdriverDocker najpierw przestał działać, ponieważ nie mógł zapisać danych tymczasowych. Późniejszy sterownik nieobsługiwany komunikat był konsekwencją nieudanej inicjalizacji sterownika pamięci masowej, a nie dowodem na to, że działające jądro nagle utraciło obsługę overlay2 po migracji.
Dlaczego ponowne uruchomienie Dockera nie rozwiązało problemu
Użytkownik spróbował ponownie uruchomić docker.service i docker.socket ręcznie i otrzymał komunikat „Odmowa dostępu”. Odpowiedź członka społeczności powiązała to z mechanizmami kontroli usług w ZimaOS, typowymi dla urządzeń appliance.
Nawet gdyby ponowne uruchomienie usługi było dozwolone, nie zwolniłoby miejsca na dysku. Demon po prostu ponownie napotkałby ten sam błąd zapisu.
Usuwanie tymczasowych plików Dockera nie odzyskało wystarczającej ilości miejsca
Społeczność zasugerowała wyczyszczenie tymczasowych plików Dockera po wcześniejszym sprawdzeniu miejsca na dysku. Oryginalny użytkownik spróbował tego i odpowiedział, że dysk systemowy nadal był zapełniony w 100%, a Docker wciąż nie chciał się uruchomić.
Ten negatywny wynik jest przydatny: niewielkie, tymczasowe czyszczenie nie może naprawić projektu pamięci masowej, w którym dysk systemowy pozostaje całkowicie zapełniony.
Użytkownik wybrał kopię zapasową i przywracanie ustawień fabrycznych
Po nieudanej próbie czyszczenia użytkownik postanowił utworzyć kopię zapasową /DATA/AppData i ponownie zainstalować/przywrócić ZimaOS. Członek społeczności zalecił zanotowanie zainstalowanych aplikacji, użycie przywracania systemu do ustawień fabrycznych, a następnie przeniesienie pamięci masowej związanej z aplikacjami na duży dysk przed ponowną instalacją aplikacji.
Publiczny wątek kończy się na wiadomości użytkownika, że to zrobi. Nie zawiera potwierdzenia po przywróceniu, dlatego strona nie powinna przedstawiać ponownej instalacji jako zweryfikowanego ostatecznego rozwiązania w przypadku tego konkretnego użytkownika.
Obecna migracja danych w ZimaOS wyraźniej określa, co można przenieść
Obecny ZimaOS udostępnia oddzielne kategorie migracji dla:
- Obrazy Dockera;
- Dane aplikacji Dockera;
- bazy danych użytkowników, takie jak Galeria, Pobrane, Dokumenty, Multimedia i Kopia zapasowa.
To ważna aktualizacja starszego wątku, w którym dyskusja czasami traktowała „migrację AppData” tak, jakby automatycznie obejmowała całą pamięć masową Dockera.
Użyj bieżących kategorii migracji danych ZimaOS, zanim mały dysk systemowy zapełni się krytycznie.
Zapobiegaj problemowi, ustawiając wcześniej lokalizację danych aplikacji
Obecna wersja ZimaOS udostępnia również lokalizację danych aplikacji w sekcji Ustawienia > Aplikacje. IceWhale zaleca od początku wskazać macierz pamięci masowej zamiast pozostawiać cały przyrost trwałych danych aplikacji na urządzeniu systemowym.
Obecne wyjaśnienie miejsca przechowywania trwałych danych aplikacji ZimaOS jest najlepszym materiałem referencyjnym dotyczącym zapobiegania temu problemowi.
Sprawdź pojemność i i-węzły
System plików może odrzucać nowe pliki, ponieważ nie ma wolnych bloków albo wyczerpał pulę i-węzłów. W ramach diagnostyki systemu źródłowego zasugerowano sprawdzenie obu wartości. W tym przypadku log wyraźnie wskazuje na zwykłe wyczerpanie pojemności, ale sprawdzenie obu wartości nadal jest przydatną diagnostyką tylko do odczytu.
Kiedy ponowna instalacja staje się uzasadniona
Jeśli dysk systemowy był zapełniony w 100%, metadane pamięci masowej Dockera są uszkodzone, demon nie może się uruchomić, a bezpieczne czyszczenie nie może zapewnić wystarczającej ilości wolnego miejsca, kontrolowane przywrócenie systemu może być szybsze i bezpieczniejsze niż ręczna edycja metadanych overlay.
Najpierw zabezpiecz dane aplikacji i dane użytkowników, sprawdź, których dysków dotknie przywracanie, i unikaj usuwania jedynej kopii baz danych aplikacji.
FAQ dotyczące Dockera po migracji
Czy overlay2 faktycznie nie był obsługiwany przez sprzęt źródłowy?
W logach najpierw widać, że Docker nie mógł utworzyć plików testowych overlay2, ponieważ dysk był pełny. Komunikat sterownika pojawił się po tym błędzie.
Czy wyczyszczenie katalogu tymczasowego Dockera naprawiło system źródłowy?
Nie. Autor oryginalnego wpisu powiedział, że dysk systemowy nadal był zapełniony w 100%.
Czy obecna wersja ZimaOS pozwala przenosić obrazy Dockera niezależnie od danych aplikacji?
Tak. Obecnie funkcja migracji danych wyświetla obrazy Dockera i dane aplikacji Dockera jako osobne kategorie możliwe do przeniesienia.
Czy w wątku potwierdzono pomyślne przywrócenie ustawień fabrycznych?
Nie. Użytkownik powiedział, że zamierza to zrobić, ale publiczny wątek kończy się przed opublikowaniem wyniku przywracania.
