Communityoplossing

Problemen oplossen bij het maken van RAID in ZimaOS op hardware die niet van ZimaCube is

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.

Als ZimaOS je schijven ziet, maar het RAID-aanmaakscherm ze aan de verkeerde schijfsleuven toewijst, selecteerbare sleuven leeg laat of slechts enkele schijven toont, maak dan eerst onderscheid tussen een actueel probleem met de RAID-gezondheid en het oude probleem met schijftoewijzing op niet-ZimaCube-hardware dat in deze thread is gedocumenteerd. Pagina 2 weerspiegelt grotendeels het gedrag van ZimaOS 1.2.x en vroege 1.3.x-versies op doe-het-zelfhardware.

De huidige probleemoplossing voor ZimaOS RAID begint met het aantal schijven, de schijfgezondheid, het afzonderlijk formatteren, een leeg koppelpunt en een herstart. Pas na deze controles kun je oude oplossingen voor verkeerd toegewezen schijfsleuven overwegen, en alleen als je dezelfde toewijzingsfout in je huidige versie kunt reproduceren.

Hoe de oude fout in de schijftoewijzing eruitzag

Verschillende gebruikers van niet-ZimaCube-hardware meldden dat fysiek aangesloten schijven op onverwachte virtuele posities verschenen. De opslagpagina kon schijven in schijfsleuven 4, 5 en 6 weergeven, terwijl het RAID-dialoogvenster schijven op eerdere posities verwachtte. Daardoor bleef de knop Volgende uitgeschakeld of werd een schijf verborgen in de selectie.

Ouder ZimaOS-opslagoverzicht waarin schijven van niet-ZimaCube-hardware aan onverwachte schijfsleuven zijn toegewezen
Een oudere ZimaOS-build koppelde schijven van doe-het-zelfhardware aan onverwachte schijfsleufposities.
Ouder ZimaOS Opslagbeheer met schijven weergegeven in schijfsleuven 4, 5 en 6
De opslaginterface kon schijven herkennen, terwijl het RAID-selectiemodel ze nog steeds moeilijk bruikbaar maakte.

Herkenning en RAID-geschiktheid waren twee verschillende lagen

Ouder ZimaOS RAID-aanmaakscherm op LincStation-hardware met niet-beschikbare schijfsleuven
Een doe-het-zelfsysteem kan opslag weergeven, maar de RAID-selectieworkflow toch onvolledig laten.

Dit onderscheid blijft ook vandaag nuttig. Een schijf zien in lsblk bewijst dat de kernel een blokapparaat ziet. Als je de schijf in Bestanden of Opslagbeheer ziet, bewijst dat dat een andere laag de schijf herkent. Dat de schijf selecteerbaar is voor RAID voegt daar nog een eligibility- en UI-laag aan toe.

Als één laag faalt, leg dan vast waar de schijf verdwijnt in plaats van deze onmiddellijk te wissen. Controleer de bestandssysteemstatus, bestaande RAID-metadata, de koppelingsstatus en of de huidige interface de schijf beschikbaar acht voor een nieuwe array.

Ouder ZimaOS-paneel voor een nieuwe harde schijf uit een RAID-probleemoplossingsgeval met niet-ZimaCube-hardware
De opslaglaag kon een schijf detecteren, zelfs wanneer de RAID-workflow deze niet zoals verwacht koppelde.
Ouder ZimaOS RAID0-scherm waarop bij doe-het-zelfhardware slechts één schijfsleuf selecteerbaar is
Een andere schermafbeelding toont dezelfde mismatch vanuit het perspectief van RAID-aanmaak: de gedetecteerde opslag werd niet vertaald naar de verwachte selecteerbare schijfsleuven.

Voer de huidige RAID-controles uit voordat je de systeemconfiguratie bewerkt

De huidige officiële handleiding voor het oplossen van RAID-problemen adviseert om ten minste twee schijven te controleren, de schijfgezondheid te controleren, te bevestigen dat elke schijf succesvol kan worden geformatteerd, ervoor te zorgen dat het beoogde RAID-koppelpunt leeg is en opnieuw op te starten voordat je de aanmaak opnieuw probeert.

Actuele checklist voor het oplossen van problemen met ZimaOS RAID moet je eerste stap zijn, zelfs bij doe-het-zelfhardware, omdat je zo voorkomt dat je uitgaat van destructieve aannames.

SataStartNumber was een versiegebonden workaround uit de community

In de oude thread erkende een antwoord van het IceWhale-team dat de vroege ZimaOS-UI-logica sterk gekoppeld was aan de slotindeling van de ZimaCube. Gebruikers kregen het advies de plaatsing van schijven op de controller te controleren met lsblk -o hctl en pas voor bepaalde DIY-systemen SataStartNumber in /etc/casaos/local-storage.conf.

Sommige gebruikers bevestigden dat dit de toewijzing van virtuele bays corrigeerde; anderen meldden later dat nieuwere ZimaOS-releases hun configuratie repareerden zonder dezelfde workaround te behouden. Daardoor is deze wijziging een historische compatibiliteitstechniek en geen universele huidige vereiste.

Pas geen oude SataStartNumber waarde van een ander moederbord. De controllerindeling verschilt per systeem en het huidige ZimaOS gebruikt mogelijk niet langer dezelfde aannames.

De schermafbeeldingen laten zien waarom versies ertoe doen

Oudere ZimaOS Storage Manager nadat de schijfbaytoewijzing was gecorrigeerd
Een gebruiker liet later zien dat schijven de verwachte vroege bayposities innamen nadat het toewijzingsprobleem was verholpen.
ZimaOS-versiescherm met een vroege 1.3.1-bètabuild
Delen van de thread zijn getest op vroege 1.3.x-builds, die veel ouder zijn dan de huidige 1.7.x-interface.

ZimaOS 1.7.1 bevat ook een oplossing voor een onjuiste RAID-statusweergave in bepaalde scenario's. Dat bewijst niet dat elk probleem met bay-toewijzing bij DIY-systemen is opgelost, maar het is nog een reden om het probleem op een actuele build te reproduceren voordat je een configuratiewijziging uit 2024 volgt.

Maak van de shellworkaround voor vijf schijven geen algemeen stappenplan

Een latere deelnemer had vijf NVMe-apparaten van 8 TB. De interface toonde er slechts vier voor het aanmaken van RAID, hoewel het vijfde apparaat elders zichtbaar was, en de gebruiker breidde RAID5 uiteindelijk handmatig uit met mdadm.

Oudere ZimaOS-opslagweergave die vijf NVMe-apparaten detecteert, waarvan één een ongebruikelijk slotnummer heeft toegewezen gekregen
De vijfde NVMe was zichtbaar voor het systeem, maar werd anders toegewezen dan de eerste vier.
Oudere ZimaOS-schijvenlijst met vijf Linux RAID-lidapparaten
De schijvenlijst en de RAID-aanmaakinterface toonden niet dezelfde bruikbare set.
Ouder ZimaOS RAID5-selectiescherm uit de probleemoplossingscase met vijf NVMe-schijven
De RAID5-workflow vormde een deel van het bewijsmateriaal dat werd gebruikt om te vergelijken welke schijven zichtbaar en welke selecteerbaar waren.
Ouder ZimaOS RAID5-aanmaakscherm met slechts vier selecteerbare NVMe-schijven
Het vijfde apparaat ontbrak in de gebruikelijke RAID5-selectiestap.
Oudere ZimaOS RAID5-status terwijl een vijfde schijf werd toegevoegd
De gebruiker breidde de array uiteindelijk uit vanuit de shell, maar die procedure wordt hier niet als algemene aanbeveling weergegeven.

Het stoppen, opnieuw samenstellen of uitbreiden van een array met low-levelopdrachten kan gegevensverlies veroorzaken als de apparaatlijst of metadata-aannames niet kloppen. Maak voor een actueel systeem dat schijven herkent maar ze niet in de RAID-interface kan gebruiken een back-up van belangrijke gegevens en escaleer dit met de versie, lsblk uitvoer, controllerindeling, schermafbeeldingen en de bestaande arraystatus, in plaats van de oude shellreeks te kopiëren.