Me doy cuenta de que ha habido varias preguntas de personas que ya han tenido problemas para iniciar, pero creo que el mío es un caso bastante particular, por lo que publicaré otra pregunta con la esperanza de abordar algunos problemas nuevos.
He estado reparando el proceso de arranque de una máquina virtual que tenía initramfs( initrd.imgy vmlinuzarchivos /boot) de núcleos que ya no estaban instalados y todavía estaba intentando arrancar desde ellos.
Estoy muy cerca de terminar, pero sigue reiniciando en systemd( emergency modedonde dice:)
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):
Arranqué desde un CD en vivo, monté las 3 particiones pertinentes en /mnt, hice chroot en /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
Hice mis reparaciones y reinicié.
Ahora fstabno estoy montando mis particiones. Pensé que estaba configurado correctamente: los UUID se copian directamente desde blkid | grep /dev/sda. No pensé que le faltara nada.
Estos son los errores que veo justo antes de acceder al mensaje del modo de emergencia:
[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
Entonces, por supuesto, miré systemctl status boot.mount, pero está activo (verde) y dice que está cargado, aunque mi /bootcarpeta está vacía a menos que monte /dev/sda2.
Parece muy extraño. ¿Por qué boot.mountdiría que está cargando /bootla partición si claramente no es así?
Respuesta1
De hecho, descubrí el problema mientras escribía la pregunta. Como puedes ver por lo que escribí al principio, fue un proceso muy largo (había estado trabajando en ello durante aproximadamente 2 días antes de llegar al punto de querer pedir ayuda).
Si miras el final de la pregunta, recibí este mensaje dmesgdurante el proceso de arranque:
[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
Entonces, por supuesto, intenté systemctl status boot.mountver lo que decía, pero decía boot.mountque está activo (verde), que está cargado y funcionando correctamente, aunque /bootestaba vacío a menos que lo haya montado manualmente /dev/sda2(que es exactamente lo contrario de lo que esperaría).
Entonces comencé a pensar que algo podría estar mal con el servicio. Lo desactivé boot.mounta pesar de quedichoestaba funcionando correctamente:
systemctl disable --now boot.mount
Intenté volver a habilitarlo, pero obtuve un error:
systemctl enable --now boot.mount
Failed to enable unit: Unit /run/systemd/generator/boot.mount is transient or generated
Bien, eso tiene sentido, se activa mediante el proceso de arranque y no se puede invocar mediante un comando de usuario. Entonces intenté volver a montar todos los dispositivos con:
mount -a
Y vi que había un error en el /etc/fstabarchivo:
error: rw,relatime is not a valid file system
(O algo por el estilo).
La clave aquí es que, si no hubiera intentado montar el sistema de archivos manualmente, nunca habría recibido esa respuesta. El mensaje de error que mount -aaparece cuando fstabcontiene una sintaxis incorrecta es increíblemente útil. Mucho más útil que:
[FAILED] Failed to mount /boot
See 'systemctl status boot.mount' for details.
... y luego ver una unidad systemd "funcionando" para boot.mountcuando /bootno se está montando (aunquehizoeventualmente llévame al lugar correcto).
Entonces edité fstabe ingresé la información del sistema de archivos para la /bootpartición que no se pudo montar, luego volví a ejecutar mount -a(lo que esencialmente hace lo mismo que boot.mount) y obtuve una respuesta positiva.
Ahora las dos particiones se están montando correctamente después de reiniciar y todo está bien en la tierra del rábano picante y la mermelada.
Si esto no soluciona ninguno de sus problemas, aquí hay algunas notas adicionales del proceso que pasé antes de llegar al punto anterior donde estaba buscando ayuda (no dude en dejar de leer después de llegar a su problema):
El problema original que tuve hace dos días fue que el sistema intentaba arrancar desde núcleos que ya no estaban en el sistema. Entonces, después de iniciar con el CD en vivo, eliminé el /bootcontenido de la carpeta (donde initrdse encuentran todos los archivos).
Pensé que simplemente volvería a crear el initramfsuso update-initramfs -c -k allde los núcleos actuales que había instalado, pero luego descubrí que no podía recrear los archivos configo solo. Esto resultó ser un poco más problemático de lo que esperaba.System.mapdepmod
Descubrí que la forma más sencilla de volver a generar o adquirir todos estos archivos es:
- eliminar todo el contenido de
/boot, - desinstalar cualquier archivo
linux-image,linux-headerylinux-modulesque no tenía intención de usar, - elimine todos los directorios residuales en
/usr/lib/modulesy luego - reinstalar
linux-imageylinux-modulesloslinux-headersarchivos que pretendía usar (las dos versiones genéricas más actuales)
Nota: reinstalar estos 3 tipos de archivostodo al mismo tiempoAsí fue como logré recuperar los archivos /boot/System.mapy /boot/config; antes, simplemente reinstalar los linux-imagearchivos no lo lograba. Es posible que estén incluidos modules(los módulos tendrían sentido) o headerspaquetes, pero esto es lo que funcionó para mí.
- Luego ejecuté
update-grubdespués de reinstalar esos archivos y confirmé/bootque se completaron correctamente. - También ejecuté
bootctl instally/etc/kernel/postinst.d/zz-udpate-systemd-boot, por lo que lo habríasystemd-bootinstalado como alternativa.
En un momento, después de reiniciar, tuve que volver a configurar system.targeten multi-user.targetlugar de graphical.target, probablemente debido a que había chroottrabajado con todos esos montajes en un CD gráfico en vivo para ejecutar el boot-repairprograma hace un par de días, lo que requiere gráficos (y creo /dev/pts /tmpque /runeran necesarios ). para llegar display :0.0al trabajo):
systemctl set-default multi-user.target
Bueno, eso es todo. Espero que esto ayude a alguien.