Źródłem problemu nie było to, że „strona pamięci masowej zapomniała pokazać cztery dyski SSD”. ZimaOS 1.6.1 potrafił wykryć kontroler Broadcom/LSI MegaRAID, ale kontroler nie przechodził inicjalizacji podczas uruchamiania sterownika Linuksa, więc żaden z czterech podłączonych dysków SSD nie pojawiał się jako urządzenie blokowe w lsblk. Dopóki dyski nie istnieją jako /dev/sdX, interfejs pamięci masowej ZimaOS nie ma niczego wiarygodnego do połączenia ani włączenia.
Najmocniejsze porównanie pojawiło się na końcu: Ubuntu 22.04.4 na tej samej maszynie widziało HBA i podłączone dyski, podczas gdy ZimaOS 1.6.1 nadal sobie z tym nie radził. To znacznie bardziej wskazywało na problem ze zgodnością sterownika kontrolera i kernela niż na uszkodzone dyski SSD lub ustawienia pamięci masowej użytkownika. Aktualna dokumentacja IceWhale wymienia teraz adaptery RAID LSI, LSI Logic MegaRAID SAS RAID oraz obsługę HBA LSI jako zaimplementowane sterowniki zgłoszone przez społeczność, ale autor oryginalnego wpisu nigdy nie zweryfikował tego konkretnego modelu M1210 w nowszej wersji ZimaOS.
lsblk pokazywało tylko systemowy dysk NVMe
Dane wyjściowe użytkownika źródłowego lsblk Dane wyjściowe zawierały dysk systemowy NVMe o pojemności 512 GB, ale nie zawierały /dev/sdX urządzenia dla czterech dysków SSD o pojemności 4 TB.
To od razu przenosi diagnostykę poniżej interfejsu pamięci masowej ZimaOS.
lspci potwierdziło wykrycie samego HBA
Kontroler pojawiał się jako:
Broadcom / LSI MegaRAID SAS-3 3008 [Fury]
Urządzenie PCIe było więc widoczne. Brakującym elementem była pomyślna inicjalizacja sterownika i oprogramowania układowego oraz udostępnienie urządzeń SCSI/blokowych.
dmesg przechwycił krytyczny błąd sterownika
Wczesne logi zawierały:
Oprogramowanie układowe w stanie AWARIA
Nie udało się przełączyć kontrolera w stan gotowości
Błąd z megasas_init_fw
Po pracach nad oprogramowaniem układowym i kontrolerem karta osiągnęła stan Oprogramowanie układowe jest teraz w stanie Gotowy ale nadal nie udawało się wykonać polecenia inicjalizacji dla hosta SCSI 0. Cztery dyski SSD nadal nigdy nie osiągnęły stanu lsblk.
BIOS kontrolera widział wszystkie cztery dyski JBOD
Ubuntu Live było rozstrzygającym porównaniem sprzętowym
Ten sam HBA i dyski SSD były widoczne w Ubuntu 22.04.4 LTS. Oznacza to, że ścieżka sprzętowa była zasadniczo sprawna, a stwierdzenie „wszystkie cztery dyski są uszkodzone” było bardzo mało prawdopodobne.
Gdy jedna dystrybucja Linuksa widzi dyski, a inna widzi tylko kontroler, przed ponownym formatowaniem dysków należy porównać obsługę kernela, modułów i oprogramowania układowego.
Stare metadane TrueNAS nie były ostatecznym wyjaśnieniem
Użytkownik wcześniej korzystał z TrueNAS i utworzył wolumin RAID, więc słusznie wzięto pod uwagę pozostałości starych partycji/metadanych. Jednak stare metadane systemu plików zwykle nadal pozostawiłyby widoczne dyski fizyczne w lsblkTutaj w ZimaOS w ogóle nie było urządzeń blokowych SSD.
Aktualna dokumentacja IceWhale wymienia obsługę LSI/MegaRAID/HBA jako zaimplementowaną
Na aktualnej stronie wkładu firmy IceWhale widnieją teraz:
- adapter RAID LSI;
- LSI Logic MegaRAID SAS RAID;
- HBA LSI
w ramach zaimplementowanych zgłoszeń dotyczących sterowników.
Zobacz aktualną listę sterowników zgłoszonych do ZimaOS.
Ponownie przetestuj dokładny model M1210 w aktualnym ZimaOS, zanim uznasz go za nieobsługiwany
Aktualna wersja ZimaOS to 1.7.1. Właściwe bieżące sprawdzenie polega na uruchomieniu lub zaktualizowaniu systemu, a następnie porównaniu:
lspci -nnk
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINT
dmesg | grep -i -E "megaraid|mpt3sas|sas|scsi|error|fail"
Jeśli dyski są teraz widoczne, przejdź do sekcji Pamięć masowa. Jeśli ta sama awaria inicjalizacji nadal występuje, zgłoś firmie IceWhale dokładny identyfikator PCI, wersję oprogramowania układowego, bieżące jądro oraz porównanie z Ubuntu.
Interfejs pamięci masowej może zarządzać tylko dyskami udostępnianymi przez jądro
Jednym z mylących szczegółów w źródle było to, że interfejs pamięci masowej ZimaOS wydawał się pokazywać pojedynczy wpis przypominający dysk, mimo że lsblk nadal nie wykazywało żadnych dysków SSD za HBA. Dlatego dowody z wiersza poleceń były ważniejsze niż wizualny symbol zastępczy. Dopóki Linux nie udostępni dysków jako urządzeń blokowych, kliknięcie „Połącz/Włącz” nie może utworzyć niezawodnej macierzy.
Tryb kontrolera nadal ma znaczenie, nawet gdy zgłaszany jest JBOD
BIOS M1210 zgłosił cztery dyski JBOD i zero dysków wirtualnych, co zasadniczo wskazuje właściwy kierunek dla pamięci masowej definiowanej programowo. Jednak oprogramowanie układowe kontrolera, buforowana obca konfiguracja, tryb osobowości/tryb pracy oraz oczekiwania sterownika nadal mogą uniemożliwić systemowi Linux otrzymywanie zwykłych dysków. Traktuj „JBOD widoczny w BIOS-ie” jako niezbędny dowód, a nie absolutne potwierdzenie przekazywania dysków do systemu operacyjnego.
Zmiana oprogramowania układowego zmieniła błąd, ale nie zakończyła inicjalizacji
Po tym, jak użytkownik pracował nad oprogramowaniem układowym kontrolera, dmesg przeszło od jednoznacznej awarii oprogramowania układowego do komunikatu „FW jest teraz w stanie Ready”. Następne polecenie inicjalizacji nadal się nie powiodło. Ta zmiana jest cenna, ponieważ pokazuje, że karta nie była całkowicie martwa, a jednocześnie dowodzi, że sama aktualizacja oprogramowania układowego nie rozwiązała problemu zgodności z ZimaOS 1.6.1.
Nie inicjalizuj ponownie starych dysków TrueNAS, dopóki warstwa HBA nie będzie stabilna
Cztery dyski SSD należały wcześniej do konfiguracji pamięci masowej TrueNAS. Jeśli jakiekolwiek dane nadal mają znaczenie, unikaj tworzenia nowych macierzy, usuwania metadanych lub formatowania dysków wyłącznie po to, aby pojawiły się w ZimaOS. Najpierw uzyskaj spójną widoczność urządzeń blokowych w bieżącym systemie operacyjnym, a następnie zdecyduj, czy stare dane należy zaimportować, utworzyć ich kopię zapasową czy usunąć.
FAQ dotyczące wykrywania HBA LSI
Czy źródło dowodziło, że same dyski SSD były uszkodzone?
Nie. BIOS HBA i Ubuntu wykrywały podłączone dyski.
Czy był to przede wszystkim problem interfejsu pamięci masowej ZimaOS?
Nie. Dyski nie istniały w lsblk, więc awaria występowała poniżej warstwy interfejsu użytkownika.
Czy autor pierwotnego posta potwierdził, że dokładny model M1210 działa z aktualnym ZimaOS?
Nie. Wątek zakończył się na wersji 1.6.1, zanim uzyskano to potwierdzenie.
