1 votos

El arranque falla con "Cargando ramdisk inicial ..."

Necesito ayuda urgente con esto

Servidor de 4 años.
Servidor Ubuntu 14.04 i686.
Linux 3.13.0-149-generic fue la última versión que funcionó sin problemas.
Hace 10 días actualicé a la versión 3.13.0.151.
El servidor se bloquea al arrancar.

La pantalla muestra ...

Loading Linux 3.13.0-151-generic ...
Loading initial ramdisk ...

1 segundo después... reinicio.

Lo mismo con el modo de recuperación 3.13.0-151.
Lo mismo con la 3.13.0-153 (la más reciente a fecha de hoy, modo normal y recovery).

¿Cómo puedo saber después del subsiguiente arranque con éxito de la versión 3.13.0-149, qué genera exactamente el choque ?

Gracias.

----- más tarde -----

@heynnema intentó ayudarme diciéndome cómo construir un nuevo initrd.img-* para 151 ( update-initramfs -c -k 3.13.0-151-generic ). Véase más abajo. Esto no funcionó. El 151 seguía sin hacer arrancar el sistema. Mi error fatal fue entonces decir update-initramfs -c -k 3.13.0-149-generic (el único núcleo que funciona). Después de eso, me quedé atascado. Ya no había kernel desde el que arrancar. El mismo problema con el ramdisk que con 151 y 153.

Después de eso, empecé un Live DVD ( ubuntu-14.04.5-desktop-i386.iso ) en el sistema atascado, monté una vieja máquina virtual 14.05.5 con núcleos 3.13 en otro ordenador, actualicé estos ( apt-get dist-upgrade ), copiaba el initrd.img-3.13.0-153-generic (último kernel) al sistema atascado ('/boot') y ¡arrancó de nuevo (con 153)! Esto fue para mi gran sorpresa, sin saber que el initrd.img-* ¡de una VM funcionaría en un hardware real! Sin embargo, seguía sin poder arrancar desde 149 y 151 (lo cual tiene sentido).

Todo lo anterior fue para que el sistema volviera a funcionar. El problema en sí no está resuelto.

Conclusión: update-initramfs utiliza datos (archivos) del sistema para construir initrd.img-* . En mi equipo, esto hace que sea imposible ir más allá de "Cargando ramdisk inicial ...".

Preguntas:
Qué archivos utiliza update-initramfs ?
¿Puedo (?!) hacer algo para crear una construcción de nuevo un trabajo initrd.img-3.13.0-153-generic ?

Mientras no se resuelva este problema, las futuras construcciones initrd-img-* también se bloquearán.

1 votos

Arranque en -149 y en terminal tipo sudo update-initramfs -c -k 3.13.0-151 luego reinicie a -151, y vea si eso soluciona el problema. Informe a @heynnema.

0 votos

Gracias por la respuesta, pero me siento más seguro de esperar hasta 4.15.0-24 tiene una solución, con la esperanza de que se implementará también en 3.13.0-151. Mientras tanto, he cambiado Grub que se mantiene en el arranque desde 3.13.0-149.

0 votos

Estás ejecutando 3.13... no 4.15. Mi comando no hará ningún daño, y podría fácilmente solucionar tu problema con -151 y -153. Por favor, comience los comentarios a mí con @heynnema o puedo perderlos.

1voto

geohei Puntos 16

De nuevo una idea de @heynnema (¡gracias!)

lsinitramfs no funcionó en los 3 no funcionó initrd.img (149, 151, 153).

root@gan:~# lsinitramfs /boot/initrd.img-3.13.0-153
/boot/initrd.img-3.13.0-153

gzip: /boot/initrd.img-3.13.0-153: not in gzip format
cpio: premature end of archive

Entonces esto aquí esta mañana ...

root@gan:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  linux-headers-3.13.0-151 linux-headers-3.13.0-151-generic
  linux-image-3.13.0-151-generic linux-image-extra-3.13.0-151-generic
Use 'apt-get autoremove' to remove them.
The following packages will be upgraded:
  amd64-microcode
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 26.3 kB of archives.
After this operation, 2,048 B disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 http://xx.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64-microcode i386 3.20180524.1~ubuntu0.14.04.2+really20130710.1 [26.3 kB]
Fetched 26.3 kB in 0s (387 kB/s)
(Reading database ... 132952 files and directories currently installed.)
Preparing to unpack .../amd64-microcode_3.20180524.1~ubuntu0.14.04.2+really20130710.1_i386.deb ...
Unpacking amd64-microcode (3.20180524.1~ubuntu0.14.04.2+really20130710.1) over (3.20180524.1~ubuntu0.14.04.1) ...
Setting up amd64-microcode (3.20180524.1~ubuntu0.14.04.2+really20130710.1) ...
Updating microcode on all online processors...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.103ubuntu4.11) ...
update-initramfs: Generating /boot/initrd.img-3.13.0-153-generic

¡¡¡El arranque ha vuelto a funcionar !!!

lsinitramfs ¡ahora también!

root@gan:~# lsinitramfs /boot/initrd.img-3.13.0-153-generic
/boot/initrd.img-3.13.0-153-generic
.
sbin
sbin/biosdevname
...

Otros actualizados initrd.img (149 y 151).

root@gan:/boot# update-initramfs -c -k 3.13.0-151-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-151-generic
root@gan:/boot# update-initramfs -c -k 3.13.0-149-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-149-generic

Los 3 fueron aceptados ahora por lsinitranfs .
Los 3 podrían usarse para arrancar.

Por lo tanto, el origen de la cuestión era amd64-microcode . La solución tardó 2 semanas en aparecer.

Para las pruebas, he creado manualmente initrd.img-3.13.0-153-generic utilizando update-initramfs . El resultado no fue exactamente el mismo que el construido por apt-get update pero también funcionó.

Gracias por toda la ayuda.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X