Se um SSD NVMe for detetado pelo Linux, mas aparecer no compartimento errado do ZimaCube — ou não for apresentado corretamente na interface de armazenamento — o problema pode estar nos metadados de mapeamento dos compartimentos do ZimaOS, e não no próprio SSD. Verifique primeiro a deteção PCIe e, em seguida, utilize a reposição de local-storage.conf apenas no hardware para o qual a IceWhale tenha documentado ou recomendado essa solução alternativa.
O tópico de origem estabelece um limite importante entre modelos: eliminar a NVME=... linha e reiniciar zimaos-local-storage.service corrigiu o caso original do ZimaCube, mas a IceWhale afirmou posteriormente que o método se aplicava ao ZimaCube e não funcionava da mesma forma num Intel NUC genérico.
Passo 1: Confirme que o NVMe existe ao nível do PCIe
Execute:
lspci | grep -i -E 'non-volatile|nvme'
lsblk -o NAME,SIZE,MODEL,SERIALSe o SSD não aparecer em nenhuma das vistas de hardware, o problema não é apenas o gráfico dos compartimentos do ZimaOS.
O guia de resolução de problemas de armazenamento é útil quando o NVMe está em falta ao nível do hardware, e não apenas representado incorretamente na interface Web.
Passo 2: Verifique o mapeamento dos compartimentos do ZimaCube
No ZimaCube afetado, a IceWhale solicitou:
sudo -i
cat /etc/casaos/local-storage.confA configuração continha uma NVME=... mapeamento que já não correspondia à localização do SSD.
Passo 3: Utilize a reposição apenas no modelo pretendido
A IceWhale instruiu o utilizador do ZimaCube a remover a NVME=... linha e, em seguida, execute:
systemctl restart zimaos-local-storage.serviceO utilizador original confirmou que isto corrigiu a interface.
Por que razão mover o SSD pode recriar o problema
Mais tarde, um utilizador mudou o SSD de um compartimento para outro e o mapeamento incorreto voltou a aparecer. Isto faz sentido se o mapa de compartimentos em cache/personalizado já não corresponder à nova ranhura física.
Não aplique isto cegamente a hardware genérico
Um utilizador de um Intel NUC tentou a mesma edição e a linha NVMe voltou a aparecer sem corrigir a interface. A IceWhale afirmou explicitamente que o método se aplicava ao ZimaCube e que o comportamento mais abrangente dos compartimentos de unidades personalizados para outros modelos ainda estava a ser desenvolvido.
Verifique primeiro a interface de armazenamento atual
O guia atual de configuração do armazenamento do ZimaOS documenta a deteção atual dos discos e a configuração do armazenamento. Se o SSD estiver visível como armazenamento normal, mas o gráfico da baia estiver incorreto, trate a situação como um problema de apresentação/mapeamento.
Utilize os privilégios de root com cuidado
O tópico original também esclareceu que a edição de /etc/casaos/local-storage.conf requer privilégios de root. Não force a escrita do ficheiro a partir de uma sessão de utilizador normal.
Separe a deteção física da apresentação das baias
A página Armazenamento do ZimaCube tenta mapear os controladores NVMe detetados para etiquetas de ranhuras físicas. Essa camada adicional de apresentação explica por que razão um disco pode estar perfeitamente visível no Linux e, ainda assim, aparecer sob a letra errada ou com um gráfico de baia estranho.
Antes de editar a configuração, registe o modelo do SSD, o endereço PCI e a ranhura física. Isto fornece um mapa antes/depois e reduz a possibilidade de “corrigir” o dispositivo errado.
Faça uma cópia de segurança de local-storage.conf antes de editar
Se o suporte da IceWhale lhe indicar que deve modificar o ficheiro, faça primeiro uma cópia:
sudo -i
cp /etc/casaos/local-storage.conf /etc/casaos/local-storage.conf.bakEm seguida, efetue apenas a alteração solicitada. Evite reescrever definições de armazenamento não relacionadas, pois o ficheiro contém mais do que o mapeamento NVMe.
Reinicie primeiro o serviço de armazenamento, não todo o servidor
A solução verificada para o ZimaCube reiniciou o zimaos-local-storage.service depois de limpar o mapeamento obsoleto. Este é um teste mais específico do que reiniciar todo o NAS e facilita determinar se o serviço de armazenamento local reconstruiu corretamente o mapa das baias.
Se o mapeamento continuar a reaparecer
Quando o mesmo mapeamento obsoleto reaparece após cada reinício, pare de editar repetidamente o ficheiro. Capture a configuração gerada, lspci, lsblk, a ranhura física e a versão atual do ZimaOS para obter suporte. A regeneração persistente significa que outro componente está a escrever o mapeamento.
O {ilink("https://shop.zimaspace.com/pages/zimaos-installation-troubleshooting-guide","guia de resolução de problemas de armazenamento","Recolha informações sobre a deteção do hardware e os metadados de armazenamento antes de efetuar repetidamente alterações ao sistema")} proporciona uma estrutura de escalamento mais segura.
Perguntas frequentes
A eliminação da linha NVME apaga o SSD?
A solução original alterou a configuração de mapeamento das baias, não o conteúdo do disco. Ainda assim, faça uma cópia de segurança dos dados importantes antes de efetuar alterações ao armazenamento ao nível do sistema.
Porque é que o SSD aparece no lspci, mas não corretamente na interface?
Isso aponta para metadados de armazenamento do ZimaOS ou para o mapeamento das baias, e não para a deteção básica de PCIe.
Posso usar esta solução num Intel NUC?
Não como regra geral. A IceWhale afirmou especificamente que a solução se aplicava ao ZimaCube.
E se o SSD não aparecer no lspci?
Em seguida, investigue primeiro a ranhura de hardware, o SSD, as definições da BIOS/PCIe e a ligação física.
