Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

: boot impossible après mise à jour

NicoApi73

Bonsoir,

Ceci est un partage d'expérience. Ca peut concerner certaines machines (en architecture skylake, probablement les processeurs de la famille Ix nnnnU pour les portables) sous xenial, bionic, eoan et focal. https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1882890 Le bug est corrigé, mais le paquet défectueux (intel-microcode) concerné est toujours dans les dépôts en version non-corrigée (la version défectueuse est 3.20200609.0ubuntu0.18.04.0), donc en cas de mise à jour (à l'heure où j'écris ce post), il sera installé...

Symptômes :
- le système ne boote pas (il plante dès le début, donc l'écran reste noir). Si vous avez un problème de boot, mais que la machine commence le boot (genre écran violet), ça ne correspond pas au symptôme du bug concerné
- Le noyau précédent ne boot probablement pas

Sur ma machine, le noyau 4.15.0-106 faichement installé ne bootait pas (même pas en recovery), de même pour le 4.15.0-101. Seul le 4.15.0-99 bootait. En fait tous les noyaux pour lesquels il y a eu un update-initramfs étaient touchés.

Solution temporaire :
- booter sur le dernier noyau bootable
- faire un down-grade du package. Pour Bionic :

sudo apt install intel-microcode=3.20180312.0~ubuntu18.04.1

Si il n'y a aucun noyau qui boote, il faut booter sur une session live et chrooter pour faire l'update. Je ne suis pas familier de cette procédure.

Par la suite (probablement dans les prochaines heures), vérifier la mise à disponibilité du paquet corrigé, qui doit être en version 3.20200609.0ubuntu0.18.04.1

pour xenial, eoan et focal, ce sont respectivement les paquets 3.20200609.0ubuntu0.16.04.1 3.20200609.0ubuntu0.19.10.1 et 3.20200609.0ubuntu0.20.04.1 (les versions bugguées en .0)

PS : Les symptômes sont vraiment très spécifiques. Si on regarde le contenu de kern.log, le boot n'apparaît même pas : rien ne démarre. Si vous avez un problème de boot mais que quelque chose s'affiche, vous n'êtes fort probablement pas concerné!

EDIT : Il y a plus simple que chrooter : il suffit d'ajouter dis_ucode_ldr dans les options lors du boot

kernel-parameters.txt a écritdis_ucode_ldr [X86] Disable the microcode loader.

source : https://askubuntu.com/questions/1248769/intel-microcode-3-20200609-0ubuntu0-20-04-0-update-crashes-computer-unable-to-b

EDIT2 : la correction est maintenant dans les dépôts...

LukePerp

Bonjour merci pour le retour. J'ai exactement les mêmes symptômes sur la machine d'une tante. Je vais dépanner ce samedi alors j'utiliserai ces conseils.

NicoApi73

Comme le package vient d'être mis à jour (il a été poussé dans les dépôts hier soir), il suffit de refaire une mise à jour. Je viens de le faire ce matin sur la machine concernée et je confirme que la correction est valide.

Dans l'ordre, si le noyau est dispo essaie de booter sur le 4.15.0-99. S'il n'est pas dispo, l'option à passer à grub est dis_ucode_ldr
Une fois booté,

sudo apt update && sudo apt upgrade -y

Bon courage

LukePerp

Ce bug est littéralement catastrophique. Les utilisateurs de Linux ne maîtrisant pas l'informatique seront incapable de diagnostiquer et de dépanner. Je vous parie qu'on va en entendre parler dans l'actu numérique du Web. Lorsque tous les précédents noyaux ne bootent pas, impossible d'aider à distance la victime. Sur la machine de ma tante, sous 18.04, seule les noyaux 4.15.0.106 et 4.15.0.101 sont disponibles au GRUB et rien ne boote. Apparaît seulement le curseur qui clignote.

NicoApi73

Je peux te dire que ça m'a fait tout drôle quand ça s'est produit, surtout quand ça ne boote plus sur le noyau précédent.
Je fais toujours les mises à jour à la main et ne fais l'autoremove manuellement que lorsque le boot sur les mises à jour est opérationnel. C'est pour ça que dans ce cas j'ai réussi à booter sur le noyau -99

J'ai dû aller chercher dans /var/log/apt/history.log pour voir ce qui a été mis à jour, puis j'ai constaté qu'il n'y avait aucune trace dans kern.log de la tentative de boot sur les -106 et -101. A ce moment j'ai soupçonné intel-microcode car c'est la première chose qui apparaît dans les logs lors du boot. Ca a été confirmé lorsque j'ai downgradé. Par la suite, les recherches que j'ai faite ont fini par confirmer mon diagnostique et la solution.

Effectivement, c'est une grosse bourde, car dans mon cas, même le mode recovery ne fonctionnait pas.... Après, seule les machines qui ont été mises à jour hier (en gros pendant 24h) et qui ont les caractéristiques qui engendre le problème sont touchées. Le bug est corrigé maintenant. On peut souligner la réactivité.

Je n'ai pas la prétention d'être un expert, néanmoins, je me débrouille un peu et je te confirme que pour un utilisateur lambda c'est une situation difficile. J'ai découvert par la suite le paramètre grub permettant de ne pas charger le microcode, ce qui est plus simple à mettre en oeuvre pour un utilisateur lambda que chrooter (Je n'ai jamais eu à chrooter, donc je ne sais pas faire)