Meu CentOS 7 não inicializa mais

Question

Meu CentOS 7 não inicializa mais. Eu volto depois da inicialização:

Assuming drive cache: write through

Eu encontrei algumas coisas para remover o rhgb através do menu de inicialização, mas isso não funcionou. Eu removê-lo e salvei com ctrl + x, mas ainda não inicializo.

Provavelmente, alguma tabela de partições desapareceu. Eu não sei o que aconteceu, porque foi muito tempo eu reiniciei a máquina. Estou depurando toda a tarde agora com o Google, mas ainda não tenho solução. Alguém que pode ajudar?

    

Answer 1

Os erros vermelhos são averr sobre (eles aconteceriam de qualquer maneira). Você tem um trabalho / boot, mas você não está conseguindo ativar a partição LVM (provavelmente sda2).

A tabela de partições desconhecida ... Eu concordo que é suspeito. Mas você provavelmente instalou com ambos / boot e LVM no mesmo disco, sda. Nesse caso, você já está tendo problemas com o sda ...

file -s /dev/sda1

file -s /dev/sda2

descreverá as partições, por exemplo,

/dev/sda3: LVM2 PV (Linux Logical Volume Manager), UUID: 8OtrnK-xreK-CyDK-Jdcq-VayD-tbUG-tycS0L, size: 119645667328

EDIT: exceto o initramfs provavelmente não tem arquivo! Tente blkid , mas acho que é isso que o udev usa.

/dev/sda3: UUID="8OtrnK-xreK-CyDK-Jdcq-VayD-tbUG-tycS0L" TYPE="LVM2_member" PARTUUID="82bcd2d1-39af-436f-9b58-4ec8434483a2"

Você pode acionar a ativação manualmente e procurar um erro lá

pvscan -v -a ay /dev/sda1 /dev/sda2

Suponho que você também deve tentar as mesmas coisas em /dev/sdb .

Não parece que você está perdendo mensagens de erro. Isto implica que não há nenhuma tentativa de ativar a partição LVM ... (possivelmente não está sendo identificada como tal porque alguém limpou o cabeçalho ...). O registro deve realmente incluir alguns detalhes se ele encontrou algo com o LVM, por exemplo. (no Fedora, ou seja, software mais novo):

Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: Scanning devices sda3  for LVM logical volumes vg_fossil/root_2
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: File descriptor 98 (socket:[10072]) leaked on lvm invocation. Parent PID 448: /
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: File descriptor 99 (socket:[10073]) leaked on lvm invocation. Parent PID 448: /
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: inactive '/dev/vg_fossil/root' [10.00 GiB] inherit
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: inactive '/dev/vg_fossil/root_2' [92.00 GiB] inherit
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: inactive '/dev/vg_fossil/docker-pool' [5.34 GiB] inherit
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: File descriptor 98 (socket:[10072]) leaked on lvm invocation. Parent PID 448: /
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: File descriptor 99 (socket:[10073]) leaked on lvm invocation. Parent PID 448: /
Apr 15 15:59:52 localhost.localdomain dracut-initqueue[374]: /etc/lvm/profile/vg_fossil--docker-pool-extend.profile: stat failed: No such fi
Apr 15 15:59:52 localhost.localdomain systemd[1]: Found device /dev/mapper/vg_fossil-root_2.

Você precisa examinar a linha de comando passada para o kernel e dracut initramfs.

cat /proc/cmdline

porque é possível passar opções para o dracut que dizem para não procurar por LVM.

Um segundo truque seria verificar os sistemas de arquivos. Se seus LV LVM são contíguos - por exemplo, se você nunca os ampliou, o testdisk lhe dará acesso a todos os dados. Você pode instalar e executar o testdisk se inicializar em um sistema de recuperação decente. Por exemplo, isso permitiria que você investigasse os sistemas de arquivos em sda2, mesmo se alguém tivesse limpado o cabeçalho PV do LVM.