Rozwiązanie społecznościowe

Rozwiązywanie problemów z tworzeniem macierzy RAID w systemie ZimaOS na sprzęcie innym niż ZimaCube

Page 2 of a long RAID troubleshooting thread documented old ZimaOS 1.2.x/1.3.x disk-slot mapping problems on non-ZimaCube systems, community config edits, and later reports that newer builds resolved some cases.

Jeśli ZimaOS widzi Twoje dyski, ale ekran tworzenia macierzy RAID przypisuje je do niewłaściwych zatok, pozostawia puste zatoki możliwe do wybrania lub pokazuje tylko niektóre dyski, najpierw oddziel bieżący problem ze stanem macierzy RAID od opisanego w tym wątku starego problemu z mapowaniem dysków na sprzęcie innym niż ZimaCube. Strona 2 w dużej mierze odzwierciedla działanie ZimaOS 1.2.x i wczesnych wersji 1.3.x na sprzęcie DIY.

Aktualne rozwiązywanie problemów z macierzą RAID w ZimaOS zaczyna się od sprawdzenia liczby dysków, ich stanu, możliwości sformatowania każdego z nich, pustego punktu montowania oraz ponownego uruchomienia systemu. Dopiero po wykonaniu tych kontroli należy rozważyć stare obejścia problemu z mapowaniem zatok — i tylko wtedy, gdy można odtworzyć tę samą usterkę mapowania w bieżącej wersji.

Jak wyglądał dawny błąd mapowania dysków

Kilku użytkowników sprzętu innego niż ZimaCube zgłosiło, że fizycznie podłączone dyski pojawiały się w nieoczekiwanych pozycjach wirtualnych. Strona pamięci masowej mogła wyświetlać dyski w zatokach 4, 5 i 6, podczas gdy okno dialogowe RAID oczekiwało dysków na wcześniejszych pozycjach, przez co przycisk Dalej był niedostępny lub dysk nie pojawiał się na liście wyboru.

Starszy widok pamięci masowej ZimaOS pokazujący dyski inne niż ZimaCube przypisane do nieoczekiwanych zatok
Starsza kompilacja ZimaOS mapowała dyski sprzętu DIY do nieoczekiwanych pozycji zatok.
Starszy Menedżer pamięci masowej ZimaOS z dyskami wyświetlanymi w zatokach 4, 5 i 6
Interfejs pamięci masowej mógł rozpoznawać dyski, podczas gdy model wyboru dysków do macierzy RAID nadal utrudniał ich użycie.

Rozpoznawanie i kwalifikowanie do RAID to były dwie różne warstwy

Starszy ekran tworzenia macierzy RAID w ZimaOS na sprzęcie LincStation z niedostępnymi zatokami dysków
System DIY może wyświetlać pamięć masową, a mimo to pozostawiać proces wyboru dysków do macierzy RAID nieukończony.

To rozróżnienie pozostaje przydatne także dziś. Samo wyświetlanie dysku w lsblk Potwierdza to, że jądro widzi urządzenie blokowe. Jego widoczność w aplikacji Pliki lub Menedżerze pamięci masowej potwierdza, że rozpoznaje je kolejna warstwa. Możliwość wybrania go do macierzy RAID oznacza dodatkową warstwę kwalifikacji i interfejsu użytkownika.

Jeśli jedna z warstw zawiedzie, zarejestruj miejsce, w którym dysk znika, zamiast od razu go wymazywać. Sprawdź stan systemu plików, istniejące metadane RAID, stan montowania oraz to, czy bieżący interfejs uznaje dysk za dostępny do utworzenia nowej macierzy.

Starszy panel „Nowy dysk twardy” w ZimaOS ze sprawy dotyczącej rozwiązywania problemów z macierzą RAID na sprzęcie innym niż ZimaCube
Warstwa pamięci masowej mogła wykrywać dysk, nawet gdy proces tworzenia macierzy RAID nie mapował go zgodnie z oczekiwaniami.
Starszy ekran RAID0 w ZimaOS, na którym w przypadku sprzętu DIY można było wybrać tylko jedną zatokę dysku
Inny zrzut ekranu pokazuje tę samą niezgodność od strony tworzenia macierzy RAID: wykryta pamięć masowa nie została przełożona na oczekiwane zatoki możliwe do wybrania.

Wykonaj bieżące kontrole RAID przed edycją konfiguracji systemu

Aktualny oficjalny przewodnik rozwiązywania problemów z macierzą RAID zaleca sprawdzenie co najmniej dwóch dysków, kontrolę ich stanu, potwierdzenie, że każdy dysk można pomyślnie sformatować, upewnienie się, że zamierzony punkt montowania macierzy RAID jest pusty, oraz ponowne uruchomienie systemu przed ponowieniem próby utworzenia macierzy.

Aktualna lista kontrolna rozwiązywania problemów z macierzą RAID w ZimaOS powinna być pierwszym krokiem także w przypadku sprzętu DIY, ponieważ pozwala uniknąć destrukcyjnych założeń.

SataStartNumber było zależnym od wersji obejściem stosowanym przez społeczność

W starym wątku odpowiedź zespołu IceWhale potwierdzała, że wczesna logika interfejsu ZimaOS była silnie powiązana z układem gniazd ZimaCube. Użytkownikom polecono sprawdzić rozmieszczenie dysków względem kontrolera za pomocą lsblk -o hctl oraz w przypadku niektórych systemów DIY dostosować SataStartNumber w /etc/casaos/local-storage.conf.

Niektórzy użytkownicy potwierdzili, że skorygowało to mapowanie wirtualnych zatok; inni później zgłaszali, że nowsze wydania ZimaOS naprawiły ich konfigurację bez zachowywania tego samego obejścia. Oznacza to, że edycja ta jest historyczną techniką zapewniającą zgodność, a nie uniwersalnym wymaganiem na dziś.

Nie stosuj starej SataStartNumber wartość z innej płyty głównej. Topologia kontrolera różni się w zależności od systemu, a obecny ZimaOS może już nie stosować tych samych założeń.

Zrzuty ekranu pokazują, dlaczego granice wersji mają znaczenie

Starszy Menedżer pamięci masowej ZimaOS po skorygowaniu mapowania zatok dysków
Jeden z użytkowników pokazał później dyski zajmujące oczekiwane pozycje wczesnych zatok po rozwiązaniu problemu z mapowaniem.
Ekran wersji ZimaOS pokazujący wczesną wersję beta 1.3.1
Część wątku przetestowano we wczesnych wersjach 1.3.x, znacznie starszych od obecnego interfejsu 1.7.x.

ZimaOS 1.7.1 zawiera również poprawkę nieprawidłowego wyświetlania stanu RAID w niektórych scenariuszach. Nie dowodzi to, że rozwiązano każdy przypadek mapowania zatok w systemach DIY, ale jest kolejnym powodem, aby odtworzyć problem w aktualnej wersji przed zastosowaniem edycji konfiguracji z 2024 roku.

Nie zamieniaj obejścia problemu z pięcioma dyskami, wykonywanego z poziomu powłoki, w ogólną instrukcję

Późniejszy uczestnik miał pięć dysków NVMe o pojemności 8 TB. Interfejs udostępniał tylko cztery do tworzenia RAID, mimo że piąty dysk był widoczny w innym miejscu, a użytkownik ostatecznie ręcznie powiększył RAID5 za pomocą mdadm.

Starszy widok pamięci masowej w ZimaOS wykrywający pięć urządzeń NVMe, z jednym przypisanym nietypowym numerem gniazda
Piąty dysk NVMe był widoczny dla systemu, ale miał inne mapowanie niż pierwsze cztery.
Starsza lista dysków w ZimaOS pokazująca pięć urządzeń będących członkami Linux RAID
Lista dysków i interfejs tworzenia macierzy RAID nie udostępniały tego samego zestawu użytecznych dysków.
Starszy ekran wyboru RAID5 w ZimaOS z przypadku rozwiązywania problemu z pięcioma dyskami NVMe
Proces tworzenia RAID5 był częścią materiału dowodowego użytego do porównania, które dyski były widoczne, a które można było wybrać.
Starszy ekran tworzenia RAID5 w ZimaOS, pokazujący tylko cztery dostępne dyski NVMe
Piąte urządzenie nie było dostępne w standardowym kroku wyboru RAID5.
Starszy status RAID5 w ZimaOS podczas dołączania piątego dysku
Użytkownik ostatecznie powiększył macierz z poziomu powłoki, ale tej procedury nie przedstawiono tutaj jako ogólnej rekomendacji.

Zatrzymywanie, ponowne składanie lub powiększanie macierzy za pomocą poleceń niskiego poziomu może prowadzić do utraty danych, jeśli lista urządzeń lub założenia dotyczące metadanych są nieprawidłowe. W przypadku bieżącego systemu, który rozpoznaje dyski, ale nie pozwala używać ich w interfejsie RAID, wykonaj kopię zapasową ważnych danych i przekaż sprawę wraz z wersją, lsblk dane wyjściowe, topologia kontrolera, zrzuty ekranu oraz bieżący stan macierzy zamiast kopiowania starej sekwencji poleceń powłoki.