기존 커뮤니티 RAID 체크리스트에서는 사용 가능한 드라이브가 두 개 이상인지 확인하고, 디스크 상태를 점검하며, 각 디스크를 포맷할 수 있는지 확인하고, 사용할 마운트 지점을 비워 두고, 재부팅한 후 어레이 생성을 다시 시도하도록 안내합니다.
답변을 보면 이 체크리스트가 단지 시작점에 불과했던 이유를 알 수 있습니다. ZimaOS 1.2.1부터 1.3.0 사이에 사용자들은 RAID 인터페이스가 사라지는 문제, 읽기 전용 파일 시스템 오류, ZimaCube가 아닌 하드웨어에서 드라이브 슬롯 매핑이 잘못되는 문제도 겪었습니다. 이는 과거 사례이며 현재 ZimaOS 인터페이스에 대한 주장이 아닙니다.
기존의 다섯 가지 확인 항목부터 시작하세요
사용 가능한 드라이브가 두 개 이상인지 확인하세요
가이드는 최소 드라이브 수 요구 사항을 확인하는 것부터 시작합니다. 이미 별도의 스토리지로 활성화된 드라이브는 기존 RAID 구성 도구에서 사용 가능한 구성원으로 표시되지 않는 경우가 있었습니다.
디스크 상태 및 개별 포맷 확인
다음 확인 단계에서는 기본적인 디스크 문제와 어레이 생성 문제를 구분합니다. 가이드에서는 상태를 검토하고 각 드라이브가 오류 없이 개별 포맷을 완료할 수 있는지 확인할 것을 권장합니다.
마운트 지점을 비워 두고 재부팅 후 다시 시도하세요
가이드에 따르면 RAID에 사용할 마운트 지점에 파일이 이미 있어서는 안 됩니다. 마운트 지점을 비우기 전에 기존 데이터를 백업해야 합니다. 확인을 완료한 후 원래 순서는 시스템을 재시작하고 어레이 생성을 다시 시도하는 것으로 끝납니다.
기존 UI에서는 할당되지 않았거나 비활성화된 디스크가 필요했습니다
여러 사용자가 드라이브를 개별적으로 포맷하고 활성화한 후 RAID 진입점이 사라지거나 선택할 수 있는 디스크가 전혀 없다는 사실을 발견했습니다. 팀의 답변에 따르면 RAID 작업 흐름에서 사용 가능한 디스크로 다시 표시되도록 드라이브를 개별 스토리지로 비활성화해야 했습니다. 어레이를 생성하는 동안 포맷이 진행되었습니다.
이 방법으로 모든 사례가 해결된 것은 아닙니다. ZimaOS 1.2.2에는 단일 디스크 비활성화와 관련된 수정 사항이 포함되었고, 이후 답변에서는 1.2.4까지 추가적인 디스크 선택 버그가 보고되었습니다. 한 사용자는 나중에 1.3.0에서 원래 문제가 해결되었다고 확인했지만, 여전히 RAID 인터페이스를 찾기 어렵다고 느꼈습니다.
읽기 전용 파일 시스템으로 인해 다른 오류가 발생함
한 사용자의 스토리지 로그에는 ZimaOS가 다음을 생성할 수 없다고 표시되었습니다. /media/Files 파일 시스템이 읽기 전용이었기 때문입니다. 팀원은 이를 버튼 누락 문제와 구분하고 사용자에게 다음 명령으로 마운트 상태를 확인하도록 요청했습니다.
mount -l | grep "/ "
mount -l | grep /media
lsblk요청된 확인 사항은 관련 마운트가 다음과 같이 표시되는지 여부였습니다. ro 대신 rw. 해당 스레드에는 마운트 실패, 파일 시스템 오류, 권한 또는 기타 구성 문제가 가능한 원인으로 나열되어 있지만, 해당 읽기 전용 사례에 대한 최종 해결 방법은 기록되어 있지 않습니다.
ZimaCube가 아닌 하드웨어에서 드라이브 슬롯 매핑 버그가 드러남
여러 SATA 컨트롤러 또는 NVMe 장치가 있는 타사 시스템에서 ZimaOS를 실행하는 사용자들로부터 또 다른 답변 그룹이 나왔습니다. 디스크는 표시되고 포맷할 수 있었지만, RAID 다이어그램에는 빈 베이, 예상치 못한 베이 번호 또는 운영 체제에서 감지한 것보다 적은 수의 선택 가능한 드라이브가 표시되었습니다.
이후 팀은 ZimaCube가 아닌 장치의 디스크 표시 절차를 게시했습니다. ZimaOS 1.2.5 사용자는 해당 절차를 따른 결과 표시되는 드라이브가 올바르게 수정되고 RAID를 생성할 수 있었다고 보고했습니다. 또 다른 사용자는 같은 절차로 문제가 즉시 해결되었다고 확인했습니다.
명령줄 어레이 변경은 일반적인 해결 방법이 아니었습니다
이후 한 참가자는 UI를 통해 4개 디스크 RAID 5를 생성하고, 다음이 포함된 다섯 번째 NVMe 장치를 추가했습니다. mdadm사용자는 그 결과가 이상적이지 않다고 설명했습니다. 해당 명령은 활성 어레이를 변경하고 특정 시스템에 맞춰져 있었으므로, 이 커뮤니티 요약에서는 재사용 가능한 복구 절차로 제시하지 않습니다.
2025년 5월의 최종 팀 답변에서는 또 다른 베이 누락 보고를 타사 하드웨어 문제로 분류하고, 엔지니어가 스크린샷과 녹화 영상을 검토할 수 있도록 별도의 토픽을 열어 달라고 요청했습니다. 이는 핵심적인 경계를 다시 보여 줍니다. 운영 체제에서 드라이브가 표시된다고 해서 하드웨어별 슬롯 맵이 오래된 RAID UI에 올바르게 표시된다는 보장은 없습니다.
FAQ
디스크를 포맷한 후 RAID 옵션이 사라진 이유는 무엇인가요?
과거 1.2.x의 여러 사례에서 개별 스토리지로 활성화된 디스크는 RAID 작업 흐름에서 더 이상 사용 가능한 것으로 간주되지 않았습니다. 해당 디스크를 비활성화하면 RAID 경로가 다시 표시되었지만, 일부 시스템에서는 별도의 UI 및 슬롯 매핑 버그가 여전히 영향을 미쳤습니다.
ZimaOS를 업그레이드하면 드라이브가 표시되지 않는 모든 문제가 해결되었나요?
아니요. 일부 사용자는 이후 릴리스나 클린 설치 후 문제가 해결되었다고 보고했지만, 다른 사용자는 여전히 ZimaCube가 아닌 장치의 드라이브 표시 절차가 필요했습니다. 원인이 과거 UI인지, 읽기 전용 파일 시스템인지, 타사 하드웨어 매핑인지에 따라 결과가 달랐습니다.
