Isso é causado por uma configuração estranha, bem como por uma alteração nos scripts de inicialização.
Primeiro, o dispositivo espelhado, / dev / md0, não possui uma tabela de partição. Ele é tratado como um dispositivo de bloco bruto com um sistema de arquivos diretamente sobre ele. Em casos de emergência, isso permite que o dispositivo de backup (/ dev / sda2 ou / dev / sdb2) seja inicializado diretamente. Anteriormente, havia uma instalação de curta duração do LVM nesta partição, mas isso foi considerado desnecessário, portanto, o dispositivo foi reinicializado como um dispositivo ext3 bruto. Isso não removeu com êxito todos os traços de LMV. Isso resulta no utilitário wait-to-root retornando 'LVM2_member' como o tipo de dispositivo. Ele fez isso o tempo todo.
Em segundo lugar, as atualizações no script de inicialização 'scripts / local' alteraram o comando mount de:
mount ${roflag} ${ROOTFLAGS} ${ROOT} ${rootmnt}
para:
mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
A montagem agora falha porque estamos forçando o tipo de sistema de arquivos no comando mount. Neste caso, o tipo 'LVM2_member' não funciona de todo - precisamos de ext3. A versão antiga funcionava porque o mount era facilmente capaz de determinar que este era um sistema de arquivos ext3.
A solução alternativa para isso é passar em rootfstype = ext3 na linha de inicialização do kernel. Isso ignora o tipo incorreto de sistema de arquivos detectado automaticamente e especifica o ext3 para montar.