Echec du démarrage avec "Chargement du disque virtuel initial ..."
J'ai un besoin urgent d'aide avec ceci ici!
Serveur âgé de 4 ans.
Ubuntu 14.04 serveur i686.
Linux 3.13.0-149-generic était la dernière version à fonctionner parfaitement.
Il y a 10 jours, je suis passé à 3.13.0.151.
Le serveur plante alors au démarrage.
L'écran montre ...
Loading Linux 3.13.0-151-generic ...
Loading initial ramdisk ...
1 seconde plus tard ... redémarrez.
Idem avec le mode de récupération 3.13.0-151.
Idem avec 3.13.0-153 (le plus récent en date d'aujourd'hui, mode normal et mode de récupération).
Comment puis-je savoir, après un démarrage réussi 3.13.0-149, ce qui génère exactement le crash?
Merci!
----- plus tard -----
@heynnema a essayé de m'aider en me disant comment construire un nouveau initrd.img-* pour 151 (update-initramfs -c -k 3.13.0-151-generic). Voir ci-dessous. Cela n'a pas fonctionné. 151 n'a toujours pas fait le démarrage du système. Mon erreur fatale a alors été de dire update-initramfs -c -k 3.13.0-149-generic (le seul noyau fonctionnel). Après cela, j'étais coincé. Plus de noyau à partir duquel démarrer! Même problème avec ramdisk que pour 151 et 153.
Après cela, j’ai démarré un DVD en direct (ubuntu-14.04.5-desktop-i386.iso) sur le système bloqué, monté un ancien 14.05.5 VM avec des noyaux 3.13 sur un autre ordinateur, mis à jour ceux-ci (apt-get dist-upgrade), copié le initrd.img-3.13.0-153-generic résultant (dernier noyau) résultant sur le système bloqué ('/ boot') et le redémarre (avec 153)! Ce fut à ma grande surprise, de ne pas savoir que le initrd.img-* d'un VM fonctionnerait sur un vrai matériel! Cependant, je ne pouvais toujours pas démarrer à partir de 149 et 151 (ce qui est logique).
Tout ce qui précède était juste pour que le système soit à nouveau opérationnel. Le problème lui-même n'est pas résolu!
Ligne de fond: update-initramfs utilise les données (fichiers) du système pour créer initrd.img-*. Sur ma boîte, cela rend impossible d'aller plus loin que "Chargement du disque virtuel initial ...".
Des questions:
Quels fichiers sont utilisés par update-initramfs?
Puis-je (?!) Faire quelque chose pour créer à nouveau un initrd.img-3.13.0-153-generic de travail?
Tant que ce problème n'est pas résolu, les fichiers initrd-img-* générés ultérieurement se planteront presque aussi!
Encore une idée de @heynnema (merci!)
lsinitramfs n'a pas fonctionné sur les 3 fichiers initrd.img non fonctionnels (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
Puis ceci ici ce matin ...
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
Le démarrage a de nouveau fonctionné !!!
lsinitramfs maintenant aussi!
root@gan:~# lsinitramfs /boot/initrd.img-3.13.0-153-generic
/boot/initrd.img-3.13.0-153-generic
.
sbin
sbin/biosdevname
...
Mis à jour les autres fichiers initrd.img (149 et 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
Les 3 ont maintenant été acceptés par lsinitranfs.
Tous les 3 pourraient être utilisés pour le démarrage.
Par conséquent, la source du problème était AMD64-microcode. Cela a pris 2 semaines pour qu'un correctif apparaisse.
À des fins de test, j'ai construit manuellement initrd.img-3.13.0-153-generic en utilisant update-initramfs. Le résultat n'était pas exactement le même que celui construit par apt-get update, mais cela a également fonctionné.
Merci pour votre aide!