Aterrissando no prompt de emergência do systemd após um longo processo de reparo de inicialização. Problema: FS ausente no arquivo fstab

Question

Sei que já houve várias perguntas de pessoas que já tiveram problemas para inicializar, mas acho que o meu é um caso bastante particular, por isso estou postando mais uma pergunta na esperança de abordar alguns novos problemas.

Eu estive reparando o processo de inicialização de uma VM que tinha um initramfs( initrd.imge vmlinuzarquivos /boot) de kernels que não estavam mais instalados e ainda estava tentando inicializar a partir deles.

Estou muito perto de terminar, mas ele continua reiniciando em systemd( emergency modeonde diz:)

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Inicializei a partir de um live CD, montei as 3 partições pertinentes em /mnt, fiz chroot em /mnt:

mount /dev/sda3 /mnt
mount /dev/sda2 /mnt/boot
mount /dev/sda1 /mnt/boot/efi
for i in proc dev dev/pts sys tmp run; do mount --bind /$i /mnt/$i; done
chroot /mnt

Fiz meus reparos e reiniciei.

Agora fstabnão estou montando minhas partições. Achei que estava configurado corretamente - os UUIDs são copiados diretamente do arquivo blkid | grep /dev/sda. Achei que não estava faltando nada.

Aqui estão os erros que estou vendo antes de chegar ao prompt do modo de emergência:

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
[DEPEND] Dependency failed for Local File Systems
[DEPEND] Dependency failed for Unattended Upgrades Shutdown
[DEPEND] Dependency failed for /boot/efi

Então, é claro que olhei systemctl status boot.mount, mas está ativo (verde) e diz que está carregado, mesmo que minha /bootpasta esteja vazia, a menos que eu monte manualmente /dev/sda2.

Parece muito estranho. Por que boot.mountdiria que está carregando /boota partição se claramente não está?

Answer 1

Então, na verdade, descobri o problema enquanto escrevia a pergunta. Como você pode ver pelo que escrevi no início, foi um processo muito longo (eu estava trabalhando nisso há cerca de 2 dias antes de chegar ao ponto de querer pedir ajuda).

Se você olhar bem no final do Q, recebi esta mensagem dmesgdurante o processo de inicialização:

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.

Então, é claro que tentei systemctl status boot.mountver o que dizia, mas dizia boot.mountque está ativo (verde), está carregado e funcionando corretamente, embora /bootestivesse vazio, a menos que eu montasse manualmente /dev/sda2(o que é exatamente o oposto do que eu esperaria).

Então comecei a pensar que algo poderia estar errado com o serviço. Eu desativei boot.mountmesmo quedisseestava funcionando corretamente:

systemctl disable --now boot.mount

Tentei reativá-lo, mas ocorreu um erro:

systemctl enable --now boot.mount
Failed to enable unit: Unit /run/systemd/generator/boot.mount is transient or generated

OK, isso faz sentido, é acionado durante o processo de inicialização e não pode ser invocado por meio de um comando do usuário. Então tentei remontar todos os dispositivos com:

mount -a

E vi que havia um erro no /etc/fstabarquivo:

error: rw,relatime is not a valid file system

(ou algo nesse sentido).

A chave aqui é que se eu não tivesse tentado montar o sistema de arquivos manualmente, nunca teria recebido esse feedback. A mensagem de erro mount -arecebida quando fstabcontém sintaxe inadequada é extremamente útil. Muito mais útil do que:

[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.

... e então ver uma unidade systemd "funcional" para boot.mountquando /bootnão estiver montada (mesmo quefezeventualmente, leve-me ao lugar certo).

Então editei fstabe inseri as informações do sistema de arquivos da /bootpartição que falhou na montagem, executei novamente mount -a(que essencialmente faz a mesma coisa que boot.mount) e obtive uma resposta positiva.

Agora as duas partições estão sendo montadas corretamente após a reinicialização e tudo está bem na terra da raiz-forte e da marmelada.

Se isso não resolver nenhum dos seus problemas, aqui estão algumas notas adicionais do processo que passei antes de chegar ao ponto acima, onde estava procurando ajuda (sinta-se à vontade para parar de ler depois de resolver o seu problema):

O problema original que tive há dois dias era o sistema tentando inicializar a partir de kernels que não estavam mais no sistema. Então, após inicializar com o live CD, apaguei o /bootconteúdo da pasta (onde initrdestão todos os arquivos).

Achei que deveria apenas recriar o initramfsusing update-initramfs -c -k alla partir dos kernels atuais que havia instalado, mas depois descobri que não poderia recriar os arquivos configou sozinho. Isso acabou sendo um pouco mais problemático do que eu esperava.System.mapdepmod

Descobri que a maneira mais fácil de gerar novamente ou adquirir todos esses arquivos é:

1. exclua todo o conteúdo de /boot,
2. desinstalar qualquer arquivo linux-image, linux-headere linux-modulesarquivos que eu não tinha intenção de usar,
3. exclua todos os diretórios residuais em /usr/lib/modulese, em seguida,
4. re-install linux-imagee linux-modulesarquivos linux-headersque pretendo usar (as duas versões genéricas mais atuais)

Nota: Reinstalando esses 3 tipos de arquivosTudo ao mesmo tempofoi como consegui recuperar os arquivos /boot/System.mape /boot/config- antes de apenas reinstalar os linux-imagearquivos não consegui. É possível que eles estejam incluídos modules(módulos fariam sentido) ou headerspacotes, mas foi isso que funcionou para mim.

5. Então corri update-grubdepois de reinstalar esses arquivos e confirmar que /bootforam preenchidos corretamente.
6. Eu também executei bootctl installand /etc/kernel/postinst.d/zz-udpate-systemd-boot, então teria systemd-bootinstalado como substituto.

Em um ponto após uma reinicialização, tive que reconfigurar system.targetpara multi-user.targetem vez de graphical.target, provavelmente devido a ter chrootfeito todas aquelas montagens em um live CD gráfico para executar o boot-repairprograma alguns dias atrás, o que requer gráficos (e acredito /dev/pts /tmpe /runforam necessários para começar display :0.0a trabalhar):

systemctl set-default multi-user.target

Ok, é isso. Espero que isso ajude alguém.