Jeśli Dysk Google znika z interfejsu Pliki w ZimaOS po kilku godzinach działania, najpierw ustal, czy system plików w chmurze rzeczywiście został odmontowany. W opisanym przypadku późniejsza diagnostyka nadal wykazywała punkty montowania fuse.rclone oraz aktywny proces rclone rcd, mimo że dysk zniknął z interfejsu.
Te dowody odróżniają pierwotny incydent od zwykłego awaryjnego zakończenia procesu rclone lub problemu z autoryzacją. Jeden z uczestników społeczności uznał, że prawdopodobną przyczyną jest desynchronizacja stanu aplikacji Pliki i interfejsu, jednak IceWhale nie opublikowało w tym wątku potwierdzonej przyczyny źródłowej. Późniejsze zgłoszenia całkowitego zawieszania systemu wskazywały na osobny, poważniejszy objaw, którego nie należy łączyć z pierwszą diagnozą.
Dysk w chmurze działał, a następnie aplikacja Pliki zgłosiła, że nie jest zamontowany
Pierwotny użytkownik korzystał z ZimaOS 1.5.3 na urządzeniu ZimaBoard 832. Dysk Google został pomyślnie połączony i pojawił się w aplikacji Pliki, lecz następnego ranka interfejs informował, że pamięć masowa nie jest zamontowana. Próby odłączenia lub odmontowania jej z poziomu interfejsu również kończyły się niepowodzeniem.
Sprawdź warstwę montowania niezależnie od aplikacji Pliki
Najbardziej przydatne informacje uzupełniające w tym wątku zebrano bezpośrednio po tym, jak dysk „zniknął”. Polecenie mount | grep -i google nadal zwracało wiele punktów montowania fuse.rclone, a lista procesów nadal zawierała główny proces zdalnego sterowania rclone.
Jeśli możesz odtworzyć problem, zbierz te same informacje przed ponownym uruchomieniem systemu lub ponownym połączeniem dysku:
mount | grep -i google
ps aux | grep -i rcloneJeśli punkt montowania FUSE i proces rclone nadal działają, należy skupić się na śledzeniu stanu przez ZimaOS, integracji z aplikacją Pliki lub widoczności punktu montowania, zamiast po prostu uznawać, że „Dysk Google został odłączony”. Jeśli oba elementy zniknęły, sprawdź uwierzytelnianie, łączność sieciową, dzienniki rclone oraz cykl życia montowania.
Jednocześnie zbierz błędy jądra i usług
Dziennik jądra systemu źródłowego użytkownika zawierał również powtarzające się pułapki invalid-opcode dotyczące libjpeg.so.8.2.2. Wątek nie dowiódł, że te błędy spowodowały zniknięcie dysku w chmurze, dlatego należy traktować je jako równoległe informacje, a nie jako potwierdzoną przyczynę źródłową.
Użyj znaczników czasu, aby powiązać komunikaty rclone, FUSE, usługi Pliki, jądra lub awarii z dokładnym momentem zniknięcia dysku. Wpis, który występuje jedynie gdzieś w historii uruchamiania systemu, jest znacznie słabszym dowodem niż komunikat powtarzający się w chwili awarii.
Obecne ZimaOS nadal obsługuje Dysk Google bezpośrednio w aplikacji Pliki
Aktualna dokumentacja ZimaOS nadal opisuje bezpośrednie montowanie Dysku Google, Dropboxa i OneDrive'a z poziomu aplikacji Pliki. Obsługuje również wiele kont oraz usuwanie połączonego dysku w chmurze z listy pamięci masowej.
Aktualny przewodnik ZimaOS dotyczący dysków w chmurze powinien być używany do wykonywania czynności związanych z połączeniem i autoryzacją zamiast starszego interfejsu wersji 1.5.3.
ZimaOS 1.7.1 nie deklaruje usunięcia tego konkretnego problemu
Dziennik zmian ZimaOS 1.7.1 z 24 sierpnia 2026 r. wymienia usprawnienia dotyczące bezpieczeństwa, pamięci, kopii zapasowych, USB, RAID, danych aplikacji, Dockera i YAML. Nie wymienia jednak Dysku Google, rclone, FUSE, montowania dysków w chmurze ani obsługi pliku wymiany jako konkretnych naprawionych problemów.
Brak takiej informacji oznacza, że starego wątku nie można zamknąć prostym stwierdzeniem: „zaktualizuj do wersji 1.7.1, a problem będzie rozwiązany”. Aktualizacja do bieżącej stabilnej wersji nadal jest rozsądnym pierwszym krokiem przed próbą odtworzenia historycznego błędu, ale należy zweryfikować działanie i zebrać nowe dowody.
Pełny dziennik zmian ZimaOS 1.7.1 wyznacza granicę aktualnego wydania.
Późniejsze zgłoszenie zawieszania całego systemu dotyczyło innej awarii
Jeden z uczestników później zgłosił znacznie szersze zawieszanie się systemu i udostępnił dzienniki dotyczące odmontowywania rclone oraz zależności od pliku /DATA/.swapfile. Użytkownik ten wysunął hipotezę, że umieszczenie pliku wymiany w /DATA może przyczyniać się do zakleszczenia podczas odmontowywania.
Jest to uzasadniona hipoteza społeczności, a nie potwierdzona przez IceWhale wada architektury. Nie usuwaj, nie przenoś ani nie wyłączaj pliku wymiany ZimaOS wyłącznie na podstawie tej teorii. Zmiana ustawień pliku wymiany podczas diagnozowania pamięci masowej może spowodować odrębny problem ze stabilnością.
Co zapisać przed ponownym połączeniem dysku
Gdy wystąpi problem, zapisz wersję ZimaOS, zrzut ekranu aplikacji Pliki, wynik polecenia dotyczącego punktów montowania, stan procesu rclone, najnowsze dzienniki oraz informację, czy inne lokalne i chmurowe pozycje pamięci masowej nadal działają. Zanotuj również, czy system pozostaje dostępny przez SSH i czy tylko aplikacja Pliki traci dostęp do dysku.
Te informacje pozwalają odróżnić problem ze stanem interfejsu od rzeczywistego odmontowania dysku w chmurze lub awarii całego systemu. Ponowne połączenie może natychmiast przywrócić dostęp, ale jednocześnie usuwa najcenniejsze dowody potrzebne do ustalenia, która warstwa uległa awarii.
