O tutorial de origem de 2024 abordava um problema de compatibilidade de apresentação/mapeamento em hardware que não era ZimaCube. Partia do princípio de que o dispositivo SATA ou NVMe já podia ser detetado pelas ferramentas do Linux, como lsblk ou lspci, mas a prateleira de armazenamento do ZimaOS não mapeava corretamente a disposição do controlador de terceiros.
Esta distinção é importante atualmente, porque o ZimaOS recebeu entretanto várias correções para o armazenamento de terceiros. O ZimaOS 1.4.4 corrigiu explicitamente os discos NVMe de terceiros que apareciam como em falta no Armazenamento, e a versão 1.6.1 otimizou a lógica de apresentação da prateleira de discos para máquinas de terceiros com muitos discos. Atualize primeiro antes de editar o ficheiro de configuração histórico.
A correção histórica para SATA utilizava SataStartNumber
A fonte oficial indicava aos utilizadores de SATA que inspecionassem o endereçamento do controlador com:
lsblk -o hctle depois edite /etc/casaos/local-storage.conf assim SataStartNumber correspondia à numeração HCTL esperada pela máquina.
A correção histórica para NVMe utilizava endereços PCI
Para dispositivos NVMe, a fonte utilizou lspci para identificar os endereços PCI e inseri-los no NVME campo do mesmo ficheiro de configuração antes de reiniciar zimaos-local-storage.
O tópico contém uma divergência real quanto ao separador
O texto oficial de 2024 indica que os vários endereços NVMe devem ser separados por vírgulas. Em outubro de 2025, um utilizador da comunidade relatou que as vírgulas não funcionavam no seu sistema e que os espaços funcionavam.
Esta contradição deve permanecer visível. É uma evidência de que o formato do ficheiro manual ou o comportamento do analisador sintático mudou, ou diferia, entre versões; não é motivo para declarar que um separador é universalmente correto no ZimaOS atual.
O ZimaOS 1.4.4 adicionou uma correção ao nível do produto para NVMe de terceiros
As notas de lançamento da IceWhale da versão 1.4.4 indicam explicitamente que foi corrigido o problema dos discos NVMe de dispositivos de terceiros que apareciam como em falta no Armazenamento.
Consulte a correção oficial da apresentação de NVMe de terceiros.
O ZimaOS 1.6.1 otimizou ainda mais as prateleiras de discos de terceiros de grande dimensão
Mais tarde, a IceWhale otimizou a apresentação das prateleiras de discos quando os dispositivos de terceiros têm demasiados discos. Isto está diretamente relacionado com o antigo problema de mapeamento da interface e é outra razão para os utilizadores atuais não começarem por editar uma configuração de 2024.
Primeiro, determine se o disco está em falta no Linux ou apenas na interface
- Se
lspci/lsblknão conseguir detetar o dispositivo, investigue o hardware, o modo do controlador, a alimentação, o encaixe e o suporte dos controladores. - Se o Linux detetar o dispositivo, mas o Armazenamento não, recolha a versão atual do ZimaOS e informações da interface/serviço de armazenamento.
Trate as edições de local-storage.conf como históricas/avançadas
Atualmente, o ZimaOS é um sistema operativo-appliance mais imutável do que muitas distribuições Linux gerais. As edições manuais em /etc pode depender da versão e ser substituído por atualizações posteriores. Guarde uma cópia do ficheiro original e siga as orientações do suporte atual se a interface moderna continuar a identificar incorretamente os discos.
Um mosaico de disco em falta não é o mesmo que um disco em falta
O tutorial da fonte explicava principalmente como os discos de terceiros eram organizados e apresentados na interface de Armazenamento do ZimaOS. Se lsblk e os registos do kernel veem uma unidade, mas a página Armazenamento não a apresenta corretamente, o problema é diferente do de um controlador/driver que não consegue detetar o disco de todo.
Faça uma cópia de segurança de local-storage.conf antes de o editar
O método histórico modifica um ficheiro de configuração nativo do ZimaOS. Guarde primeiro o ficheiro original e registe a versão atual do ZimaOS, para poder reverter a alteração caso o armário de discos fique pior depois da alteração.
Como as versões OTA alteraram entretanto o tratamento dos discos de terceiros, um valor antigo editado manualmente também pode ficar obsoleto após uma atualização.
Os endereços PCI podem mudar quando a topologia do hardware muda
Mudar uma placa NVMe para outra ranhura, alterar uma definição de bifurcação PCIe ou atualizar o firmware da plataforma pode alterar a forma como os dispositivos são enumerados. Por isso, uma lista de endereços codificada pertence a essa topologia de hardware, não ao próprio modelo do SSD.
Preservar a divergência relativa ao separador da fonte
As instruções oficiais de 2024 descrevem endereços NVMe separados por vírgulas, enquanto um utilizador posterior da comunidade afirmou que os espaços funcionavam no seu sistema e que as vírgulas não funcionavam. Não existem provas suficientes na fonte para substituir universalmente a sintaxe oficial pela variante da comunidade.
Numa versão atual, atualize primeiro e utilize o comportamento exato do analisador atual antes de editar o campo.
Os grandes armários de discos de terceiros receberam posteriormente melhorias ao nível do produto
O ZimaOS 1.6.1 melhorou especificamente o comportamento de apresentação de dispositivos de terceiros com um maior número de discos. Por isso, os utilizadores com placas HBA, caixas com vários compartimentos ou mais de seis discos devem reproduzir o problema na versão atual antes de alterarem definições antigas relacionadas com o número de compartimentos.
Perguntas frequentes sobre a apresentação de discos de terceiros
A ausência de um disco no armário do ZimaOS significa que o Linux não o consegue detetar?
Não. O tutorial original abordava especificamente os casos em que o hardware existia, mas o mapeamento na interface estava incorreto.
O ZimaOS adicionou posteriormente correções oficiais?
Sim. A versão 1.4.4 corrigiu a ausência aparente de discos NVMe de terceiros, e a versão 1.6.1 otimizou a apresentação de armários de discos de terceiros.
Os utilizadores atuais devem editar cegamente SataStartNumber ou NVME?
Não. Atualize e confirme primeiro a camada atual da falha.
