¿Recuerdas que te hablé de una computadora portátil estropeada? Bueno, vamos a elaborar, ¿de acuerdo? Estaba haciendo algunas pruebas con el software de imágenes y recuperación, y una vez que terminé, quería ver qué tan bien había ido el proceso. No muy bien, resultó. GRUB estaba allí, pero inicialmente ninguna entrada en el menú funcionó. Una vez que lo arreglé rápidamente, vi que Windows 10 no arrancaba y no se reparaba automáticamente, y la mitad de las distribuciones en el sistema (del total de ocho) en la configuración de arranque múltiple tampoco arrancaban. , entrando en modo de emergencia. Estamos hablando de todas las distribuciones, elige la que quieras.
Ahora, la recuperación de GRUB fue bastante complicada:ninguno de los métodos que se me ocurrieron funcionaron, y terminé instalando una distribución de prueba solo para configurar correctamente el gestor de arranque. Luego, inicié una de las distribuciones que SÍ funcionó y noté que no había pérdida de datos. Todo estaba allí, todas las particiones estaban sanas y completas, y los archivos estaban en su lugar correcto, incluidos Linux y Windows. En este artículo, me gustaría mostrarle cómo resolví este problema y cómo lo solucioné, y en la continuación, haremos lo mismo para Windows 10. Un ejercicio útil. Sígueme.
Problema con más detalle
Hice el siguiente ejercicio con neón como iniciador, pero se aplica a casi todas las distribuciones desde aproximadamente 2011-2012. Entonces, lo que sucede es que KDE neon comienza a arrancar y luego cae en el shell de emergencia. El sistema me dice que debo ejecutar journalctl -xb para ver el registro de inicio y averiguar qué estaba mal. Ahora, esta no es la primera vez que nos encontramos con esto. Manejé un problema similar con Fedora no hace mucho tiempo.
Pero aquí, el problema era un poco diferente. Sí, el registro de arranque mostró problemas con /boot/efi, pero la razón por la que sucedió esto se debió a otro problema. Si se pregunta cómo obtuve y copié los registros en la sesión de emergencia (si necesita algo así), puede copiar el contenido en un archivo y luego recuperarlo a través de una sesión en vivo (con redirigir> o usando el comando tee ), o una vez que haya solucionado el problema, puede volcar el último registro menos uno con journalctl -x --boot=-1. Eso es tecnología moderna para ti.
6 de diciembre 12:57:09 tester systemd[1]:Falló la dependencia para la comprobación del sistema de archivos en /dev/disk/
-- Asunto:Unidad systemd-fsck@dev-disk-by\x2duuid-641C\x2d39CE. el servicio ha fallado
-- Definido por:systemd
-- Soporte:http://www.ubuntu.com/support
--
-- Unidad systemd-fsck@ El servicio dev-disk-by\x2duuid-641C\x2d39CE ha fallado.
--
-- El resultado es RESULTADO.
6 de diciembre 12:57:09 tester systemd[1]:la dependencia falló para /boot/efi.
-- Asunto:la unidad boot-efi.mount ha fallado
-- Definido por:systemd
-- Soporte:http://www.ubuntu.com/support
--
-- La unidad boot-efi.mount ha fallado.
Solución
Me preguntaba qué podría haber salido mal. Todo el dev-disk-by fue una gran pista. ¿Recuerdas cuando te mostré cómo solucionar problemas de arranque lento cuando se cambió el UUID de la partición de intercambio? Esto parecía bastante así, excepto que /boot/efi es fundamental en el proceso de inicio del sistema.
Abrí /etc/fstab y, de hecho, el UUID indicado para la partición de intercambio (dev/sda10) NO era correcto. El archivo incluso tiene un comentario que dice que la entrada de la partición solía ser el número del dispositivo, y luego se cambió a la tontería UUID supuestamente "moderna" y "útil" que solo causa problemas.
# intercambio estaba en /dev/sda10 durante la instalación
UUID=8140c8d0-1e33-42c1-8c3c-828449adfe08 ninguno intercambio intercambio 0 0
Cambié las cosas de UUID a /dev/sda10, reinicié, ¡y todo estuvo perfecto!
Comandos que necesitará para hacer esto
Ahora, disminuyamos la velocidad un segundo. Entonces, así es como puede verificar si su sistema está utilizando los números o identificadores de dispositivo correctos. Primero, puede enumerar las particiones con fdisk -l. Este comando le dará una descripción general de todas las diferentes particiones y sus sistemas de archivos. De esta manera puede obtener una comprensión básica de su sistema. En particular, necesita la partición raíz (/), puede tener una partición /boot separada, que suele ser el caso en los sistemas UEFI, puede estar usando una partición /home separada y también puede tener una partición de intercambio separada y opcional. Estos estarán marcados con números de dispositivo, como /dev/sda2, /dev/sda8, etc.
El problema comienza en cómo las versiones más recientes de las distribuciones de Linux asignan dispositivos a /etc/fstab, un archivo que se analiza al iniciar el sistema para obtener información sobre qué dispositivos deben montarse automáticamente. En el pasado, se hacía referencia a los dispositivos como lo hace fdisk, dev/XdYZ, donde X significaría el tipo de disco (generalmente letras h o s), Y sería la letra del dispositivo (según lo ordenado por el BIOS del sistema, por ejemplo, a, b o similar), y Z sería el número de partición. Por ejemplo, /dev/sdb3 significa tercera partición en el segundo disco con el tipo de conexión SATA/SCSI/PCI-E.
De hecho, las distribuciones "modernas" usan UUID:esta es una cadena de números y letras sin sentido para los humanos, algo así como a45f-cc9a, destinada a mapear particiones de manera única, por lo que si el orden del disco cambia de alguna manera, el sistema aún puede arrancar. Tal vez tenga sentido en la empresa, pero en el entorno doméstico, esto es una tontería absoluta y completa, como casi TODAS las soluciones "modernas", como systemd, nueva convención de nomenclatura de interfaz de red, nuevas herramientas de administración de red, etc. Más sobre filosofía más adelante.
Ahora, si tiene un UUID incorrecto en /etc/fstab, el sistema no puede montar estas particiones; el mecanismo es muy inestable, porque no tiene la capacidad de verificar, buscar o reparar una configuración rota; puede terminar con una configuración que no se puede iniciar. sistema. Esta situación también es imposible de solucionar rápidamente, porque las cadenas UUID son totalmente inútiles para los humanos.
Puede verificar la lista de dispositivos UUID con el comando blkid, por ejemplo:
blkid
/dev/mapper/sda3_crypt:UUID="TpZGKB-31Lq-U1Ap-BZJCcX" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root:UUID="dcae17fd-7cfe -c0b721e" TIPO="ext4"
Necesita comparar visualmente y luego descubrir qué falta. Y luego corrija manualmente /etc/fstab.
Moderno, sigues usando esa palabra...
La simple realidad es la siguiente:Llevo más de 15 años trabajando con Linux. En algún momento de mi vida, manejaba una hermosa configuración de HPC con aproximadamente 50 000 servidores físicos distribuidos en unos 40 centros de datos. Tuve mi parte de sistemas comerciales y domésticos, con tecnologías antiguas y nuevas.
Me he encontrado con sistemas rotos principalmente desde que pasamos del antiguo BIOS + MBR + GRUB + init al nuevo UEFI + GPT + GRUB2 + systemd. No hay nada mágico, resistente o mejorado en estas soluciones. Resuelven algunas limitaciones técnicas reales en la industria, cierto. Pero también introducen una configuración mucho menos robusta que es infinitamente más difícil de depurar y solucionar por humanos. Por ejemplo, NUNCA JAMÁS he visto un sistema roto porque el orden del disco se estropeó. Pero he visto MUCHOS ejemplos de sistemas bloqueados por el uso de UUID en lugar de la simple notación de número de dispositivo.
Arreglar GRUB fue algo trivial de copiar 512 bytes de datos aquí o allá en el peor de los casos, y editar un archivo de texto. Ahora, es casi una religión científica acceder a las nuevas interfaces, trabajar con EFI y demás. Arreglar el arranque roto de Linux no fue un problema, y ahora tengo que analizar los registros binarios en texto y luego averiguar por qué mis sistemas pueden estar inestables, solo para descubrir que todo se debe a que me veo obligado a usar "soluciones". a problemas que no existen. Por ejemplo, lo del UUID. Lo de ip versus ifconfig. ¿Por qué enp0s0, o cualquiera que sea el nuevo identificador de tarjeta de red, es mejor, más inteligente o más intuitivo que eth0? Solía ser lógico, ethernet =eth.
¿Cuál es el escenario en el que los usuarios domésticos tienen que agregar o quitar discos duros con frecuencia dentro y fuera de sus cajas o jugar con la configuración del BIOS? No es. Entonces, ¿por qué los sistemas domésticos vienen con soluciones que son inadecuadas? Porque Linux no está diseñado para ser una solución casera y me siento como un idiota.
Y esto es solo el comienzo. A medida que pase el tiempo, tendremos más abstracción, abstracción, abstracción, automatización, basura optimizada para máquinas, y tendrás que confiar y depender de la misericordia de cualquier entidad que esté lanzando su último Lo que sea como servicio. Llegará un momento en que toda esta tontería explote, porque no se puede depurar. O se dejará que las máquinas lo manejen por su cuenta, usando sus horribles protocolos que los humanos nunca debieron ver o experimentar en primer lugar. Hablando de mal diseño.
Conclusión
En primer lugar, espero que encuentre útil este artículo. En la mayoría de los casos en los que un sistema Linux no arranca, es probable que tenga problemas con, bueno, algo relacionado con /boot o /boot/efi. Si eso sucede, debe tener cierta confianza al leer los registros y luego tratar de averiguar si faltan componentes o están rotos, como le mostré con los errores initrd e initramfs (vinculados arriba), o si la configuración del sistema es incorrecta. y está intentando hacer referencia a recursos no existentes. En nuestro caso, al igual que el problema del arranque lento, el culpable fue el uso de un UUID falso para las particiones.
Esto debería resolverse a nivel de sistema. Pero como he señalado muchas veces antes, la validación simplemente no existe en Linux. Los desarrolladores hacen lo suyo y siguen adelante. Nadie se molesta en pensar en el panorama general, en la filosofía. Pero eso es pensamiento de software:función -> salida. A nadie le importa lo que vive fuera de la función y encapsula la funcionalidad.
Un sistema robusto en realidad examinaría los dispositivos y sistemas de archivos existentes y trataría de averiguar si hay un problema en la configuración. Un sistema robusto tendría una copia de seguridad de los archivos críticos e intentaría hacer referencia a ellos. Un sistema robusto intentaría algo de varias maneras diferentes y correlacionaría las cosas antes de fallar de manera significativa. Nada de eso existe hoy en día, ni en Linux ni en ningún otro sistema, porque es más barato mantener una horda de malos técnicos que inventar mecanismos inteligentes de autorreparación. Y si eso te pasa en tu casa, pues solo eres una garantía. Entonces, cuando la gente habla de libertad y código abierto, está hablando de algo incorrecto. ¿Para qué sirve el código abierto si se usa para desarrollar soluciones ofuscadas? Estoy triste. Me puse a llorar.