Se tudo isso começar a não funcionar ou parar de fazer sentido, PARE e pergunte a um especialista no assunto. Este é um trabalho inseguro. Opere em imagens de disco copiadas por "dd" para arquivos em uma mídia de armazenamento grande ou diretamente para novos discos de tamanho igual ou maior para proteger seu conjunto de dados original da tolice. Você pode realizar essas operações em um único conjunto ao vivo, mas, se você errar, isso pode acontecer com seus dados.
Tudo bem. Para começar, precisamos reparar essa pilha de armazenamento metodicamente, a partir do nível básico do disco. Você executou um instalador do FreeDOS, e isso mexeu com seus discos (presumivelmente) criando uma tabela de partição em um deles.
Seus discos participam diretamente da matriz MD, nenhuma tabela de partição para falar. Isso é bastante típico. No entanto, essa também é uma estrutura de metadados de revisão 0.90 nesse array, portanto, colocar uma tabela de partições em qualquer um desses discos diretamente irá mexer com o array.
Verifique se você tem um disco (algum de sdb para sde) que tenha uma tabela de partições, na forma de / dev / sdb1, por exemplo. Se você tiver um assim, precisará considerá-lo sujo e retirá-lo de sua matriz, colocando-o novamente depois de se livrar dessa mesa.
Mesmo que não vejamos uma partição em um desses discos, uma verificação de integridade precisa ser executada em / dev / md0. O comando para fazer isso é simples:
# /usr/share/mdadm/checkarray -a /dev/mdX
Se isso ocorrer com uma contagem de correspondência maior que zero, essa matriz precisará ser reparada. Nós vamos visitá-lo, se necessário, já que atualmente não parece o problema.
Para problemas mais concretos, o testdisk coloca um GPT em / dev / md0 e uma partição nesse disco (/ dev / md0p1). Isso nunca deveria estar lá, e está corrompendo seus metadados do LVM. Seu grupo de volume é destinado a residir diretamente em / dev / md0, já que foi assim que você o criou originalmente.
Primeiro, teremos que lidar com essa GPT errante em / dev / md0. Precisa ser "zapped". O zapping de uma GPT anula todas as estruturas da GPT, retornando-as a um disco sem tabela, como deveria ser neste caso. Este artigo detalha isso de maneira excelente: " link ". Se você não fizer isso, você terá uma estrutura GPT quebrada nesse disco que os utilitários de particionamento tentarão "corrigir", causando problemas para você no futuro.
Depois de fazer isso, você pode recriar todos os seus metadados do LVM usando o arquivo que você publicou na sua pergunta. Felizmente, você me deu informações suficientes para lhe entregar um comando que funcionará. Se você quiser saber mais sobre esse processo, esse é um ótimo recurso: " link ".
O comando para recriar seu volume físico com todos os metadados originais:
# pvcreate --uuid "bKQs0l-zNhs-X4vw-NDfz-IMFs-cJxs-y0k6yG" --restorefile /etc/lvm/archive/vg0_00002-935168089.vg
Este arquivo archive descreve o / dev / md0 como sendo o disco que constitui seu grupo de volumes e o usará como deveria. Se você tiver um arquivo archive posterior no diretório de arquivos do LVM, USE THTE INSTEAD. O objetivo é trazer o grupo de volume ao seu último estado válido.
Depois disso, verificar sua integridade PV, VG e LV é a chave. Você já tentou isso, mas desta vez deve ser mais produtivo. Os comandos pvck e vgck são o que deve ser usado aqui.
Primeiro, execute pvck:
# pvck /dev/md0
Depois disso, valida, execute vgck:
# vgck vg0
Depois de validar todos os metadados, é hora de ativar seus LVs, se ainda não estiverem:
# vgchange -ay vg0
E finalmente, checando o sistema de arquivos em / dev / mapper / vg0-lv0 (que no seu caso é o XFS) para possíveis erros:
# xfs_check /dev/mapper/vg0-lv0
Isso não deve retornar nada se não houver erros. Se algo estiver errado, então o xfs_repair será necessário (NÃO FAÇA ISSO QUANDO ESTIVER MONTADO):
# xfs_repair /dev/mapper/vg0-lv0