Depois de atualizar um servidor rhel 5 hoje eu reiniciei o novo kernel: curr = 2.6.18-371.el5PAE prev = 2.6.18-348.18.1.el5PAE.
Na sequência de inicialização, vi uma mensagem indicando que o Gerenciamento de Volume Lógico estava iniciando e, em seguida, quase imediatamente vi isso e recebi um shell de recuperação:
Found duplicate PV BPF...ayV: using /dev/sdc1 not /dev/md3.
Nota: / dev / sdc1 e / dev / sdb1 são membros da matriz raid1 / dev / md3.
A partir disso, eu assumi que o software lvm2 acha que / dev / sdc1 e / dev / md3 são pv com o mesmo UUID e que o software lvm2 estava escolhendo ignorar / dev / md3 e usar / dev / sdc1. / p>
Eu desliguei e desconectei a unidade do sdc e reiniciei. Inesperadamente, o sistema inicializou sem que eu percebesse nenhum problema. Naturalmente, o md3 foi degradado.
Eu desliguei, liguei a unidade que desconectei, reiniciei e o sistema reiniciou sem que eu percebesse nenhum problema. É claro que o md3 ainda estava degradado, mas algo inesperado aconteceu.
O sistema de arquivos dentro do volume lógico conturbado foi montado.
Eu executei pvdisplay e vi o mesmo erro acima. É claro que, quando tentei adicionar o sdc1 de volta ao md3, ele não me deixava porque estava em uso pelo software lvm2.
Eu desmontei o sistema de arquivos e executei o e2fsck no caminho do dispositivo lv. Não há problemas lá (mas deveria ter havido problemas).
Existem realmente quatro questões relacionadas (desculpe). Supondo que a resposta de 3 seja "sim ou sorta", a resposta a 4 é o que eu preciso. Eu perguntei aos dois primeiros porque eu estou supondo que eu preciso entender suas respostas para dar sentido a qualquer resposta para os dois últimos.
Por que o sistema de arquivos está ok se o volume lógico foi originalmente composto de um pv de / dev / md3 em vez de / dev / sdc1?
O / dev / sdc1 não deve ser diferente de / dev / md3 para evitar que o volume lógico seja consistente em relação aos volumes físicos dentro de? Isso pode ser respondido pela pergunta 1.
Posso corrigir meu problema removendo as informações do pv do / dev / sdc1 e adicionando / dev / sdc1 de volta ao / dev / md3?
Se a resposta para o nº 3 for sim, então como faço isso sem eliminar o volume lógico e seu sistema de arquivos?
Alguma história:
Eu nunca executei "pvcreate / dev / sdc1", então não tenho idéia do porquê isso deveria estar acontecendo. É verdade, no entanto, que o / dev / sdc tem me incomodado ultimamente, pois o smartmon (sp?) Me dirá que não consegue ler os dados inteligentes ou que nem consegue ver o dispositivo. Eu vou consertar o problema (a) reinicializando, (b) reinicialização + bios travar + desligar + resetar o cabo sata + ligar, ou a sequência b mas substitua o cabo sata em vez de apenas recolocá-lo.
Não tenho certeza se você fez a pergunta que acha que fez, mas / dev / md3 é o mesmo que / dev / sdb1 e / dev / sdc1, já que é um conjunto de espelhos.
Não, não deveria.
Não, isso criará perda de dados para você.
N / A
Você provavelmente pode se livrar dessa mensagem de erro modificando seu arquivo /etc/lvm.conf para alterar o filtro para rejeitar dispositivos sdb * e scd *, regenrar seu initrd e reinicializar.
O problema fundamental é que o array foi criado com um superbloco MD no final, o que significa que os superblocos no início ainda são reconhecíveis em seus deslocamentos esperados. A única coisa que impede o superbloco fotovoltaico de ser analisado é que o subsistema MD agarra os dispositivos primeiro; usualmente. Às vezes, as camadas superiores tomam cuidado para produzir quando outro superbloco também é detectável, mas isso pode ser frágil.
Existem duas maneiras de evitar isso.
--type=raidXX a lvcreate ou lvconvert . O LVM não expõe dispositivos não montados. Normalmente, essas precauções são tomadas no momento da criação, mas no seu caso (raid1 com metadados no final, contendo um PV), é possível converter em um MD integrado ao LVM sem muitos problemas.
Uma vez que você tenha certeza de que o array está sincronizado e o sistema de arquivos é basicamente sã, você pode desmontá-lo, desbloquear os superblocos de raid em ambos os discos (leia o wipefs manpage com cuidado, você não quer erro), nuke o superbloco PV em apenas um membro, estenda seu VG para isso, e converta seus volumes lógicos para --type=raid1 --mirrors=1 . Finalmente, execute novamente o grub-install nos dois discos.