Vous n'êtes pas identifié.
Bonjour,
Un client nous écrit ce qui suit:
Bonjour.
Je viens d'avoir un problème assez important avec mon portable N240JU, et comme je l'ai résolu j'ai pensé que ça pouvait intéresser d'autres utilisateurs.
Une mise à jour récente d'Ubuntu 20.04 (idem avec 18.04) a fait que l'ordinateur ne démarrait plus, et en passant par le mode "recovery" après un premier démarrage avorté, il finissait par démarrer, mais en mode dégradé sur la vidéo (en particulier plus de possibilité d'afficher sur un écran externe).
La solution suit immédiatement...
Hors ligne
Le client a trouvé la solution:
C'est le pilote "intel-micrcode" qui était la source du problème, et il faut l'empêcher de se mettre à jour.
La solution se trouve sur le forum Ubuntu:
https://forum.ubuntu-fr.org/viewtopic.php?id=2058984
Cette file de discussion se conclut par:
Ça y est, c'est résolu. Grâce au sujet : https://forum.ubuntu-fr.org/viewtopic.php?id=2058753
Chez moi il a suffi de faire:
sudo apt-mark hold intel-microcode
pour bloquer la mise à jour du microcode Intel. Maintenant, les mises à jour du reste du système se font sans problème, le noyau est passé à la version 5.4.0.54 sans ennuis.
Merci à Inbox pour son aide.
Pour info, en faisant:
apt-cache policy intel-microcode
J'obtiens:
intel-microcode: Installé : 3.20200609.0ubuntu0.20.04.2 Candidat : 3.20201110.0ubuntu0.20.04.2 Table de version : 3.20201110.0ubuntu0.20.04.2 500 500 http://fr.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages *** 3.20200609.0ubuntu0.20.04.2 100 100 /var/lib/dpkg/status 3.20191115.1ubuntu3 500 500 http://fr.archive.ubuntu.com/ubuntu focal/main amd64 Packages
Comme nous avons déjà rencontré quelques cas similaires, nous reproduisons ici le problème et sa solution.
Merci à notre client!
Hors ligne
Bonsoir,
Je ne pensais pas que cette discussion me serait utile aussi rapidement!
Je me trouve sur le N240JU d'une cliente sous Ubuntu 16.04 (OK jusqu'en avril 2021). La cliente se plaignait de difficultés d'allumage (curseur blanc après l'écran violet, puis plus rien) et finalement de ne plus pouvoir démarrer du tout. En effet, même la LED du bouton power ne s'allumait plus!?!
J'ai retiré quelques instants la pile du BIOS, après quoi le bouton Power s'allumait à nouveau. En tentant de lancer BootRepair depuis une clé live-USB, je me suis aperçu que la machine était en mode UEFI. Je l'ai remise en mode Legacy (UEFI: Disabled) et lancé BootRepair sur une clé Legacy. La réparation a été faite et la machine a redémarré comme une fleur.
J'ai donc lancé les mises à jour et passé les commandes suivantes:
sudo apt update sudo apt upgrade sudo apt autoremove
et tout s'est bien passé. J'ai encore voulu lancer un:
sudo apt autoclean Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Del intel-microcode 3.20201110.0ubuntu0.16.04.1 [2'849 kB]
Et c'est là que j'ai eu un message Del intel-microcode 3.20201110.0ubuntu0.16.04.1 [2'849 kB], que j'interprète comme la suppression par autoclean du fameux intel-microcode.
Ne me reste plus qu'à faire:
sudo update-grub reboot
Hors ligne
Malheureusement, cela n'a pas fonctionné et j'ai eu toutes les peines du monde à redémarrer la machine (écran violacé, puis parfois curseur blanc en haut à gauche, etc.
Je vais donc suivre les insctructions du post #2 et faire:
sudo apt-mark hold intel-microcode
puis relancer les mises à jour...
La première instruction a donné ceci:
intel-microcode passé en figé (« hold »).
Hors ligne
Malheureusement, cela n'a rien amélioré. La machine ne démarre qu'une fois, impossible de faire apparaître le menu GRUB avec [Shift] pour lancer le système en mode recovery. La seule solution consiste à lancer Boot-Repair sur une live-USB en mode Legacy, toutefois la réparation du GRUB ne permet de démarrer qu'une seule fois et, au prochain démarrage, on aboutit de nouveau sur un écran noir.
Comme Boot-Repair m'indiquait que la partition bootable était trop éloignée du début de la partition du disque SSD de 120 GB, j'ai encore supprimé avec GParted (dans Boot-Repair) la partition SWAP, mais cela n'a rien changé: la réparation du GRUB ne fonctionne qu'une seule fois.
Comme ce matin sur une autre machine N240JU présentant le même problème, j'ai redémarré la machine une dernière fois pour sauvegarder les données, lancé Clonezilla depuis une live-USB Legacy, flasher notre build Ubuntu 20.04 UEFI, enclenché le mode UEFI dans le BIOS, redémarré la machine comme une fleur et réalisé les mises à jour avant de restaurer les données (de préférence dans un dossier créé au préalable sur le home).
C'est rageant de ne pas comprendre, mais c'est la seule solution...
Cordialement.
Hors ligne
Et voilà que les Athéniens s'atteignirent!...
Alors que je n'avais effectué aucune mise à jour depuis plusieurs jours sur mon why! N240JU-PRO, voilà que je me retrouve moi aussi piégé: tiret blanc sur fond noir, pas d'accès au menu GRUB, passage en mode terminal ([Ctrl]+[Alt]+[F2] inopérant)!!!
Alors je tente de réparer mon système Ubuntu 16.04 en créant une clé live-USB Ubuntu 20.04.
Je suis allé sur https://ubuntu.com/download/desktop/tha … ture=amd64 pour télécharger l'image ISO et ai choisi de l'ouvrir avec Brasero (graveur de DVD). Comptez 25 minutes avec une connexion Internet convenable...
Hors ligne
Je pensais avoir trouvé une solution triviale avec Brasero pour graver une image disque sur ma clé USB formatée en FAT32 avec GParted et téléchargée dans /tmp/mozilla. Mais impossible d'y parvenir...
Hors ligne
J'ai finalement réussi à graver l'image ISO de Ubuntu 20.04 à l'aide de Utilitaire de disque (gnome-disk).
J'ai inséré ma clé bootable sur mon why! N240JU-PRO, mais pour arriver sur le même petit trait blanc en haut à gauche!!!
Je suis finalement allé dans le BIOS avec [F2] au démarrage et, dans Boot, choisi de démarrer sur le SSD de 250 GB. Tout semble être rentré dans l'ordre. Mais sans l'ombre d'une idée d'explication...
Hors ligne
J'enrage, car au premier redémarrage, je me suis retrouvé devant le même problème!!!
J'ai donc redémarré en tapant [F7] (Boot select) pour choisir ensuite l'option Recovery mode, puis Root pour lancer un "update-grub", avant de reprendre le démarrage. Après quoi j'ai lancé une mise à jour enmode graphique avec le gestionnaire de mise à jour. Et tout semble à nouveau fonctionner.
Mais toujours pas l'ombre d'une idée du pourquoi et comment!!!
Hors ligne
Après un ultime redémarrage, force est de constater que tout semble rentré dans l'ordre.
J'ai juste perdu deux heures...
Mais l'essentiel est que j'ai retrouvé toutes mes données!
Cordialement.
Hors ligne
Zut alors! Rebelotte ce matin: écran violacé et rien d'autre. BootRepair n'améliore pas les choses et il faut démarrer en recovery mode. C'est incompréhensible!?!
Suite au prochain épisode...
Hors ligne
Il vaut peut-être la peine d'essayer d'enlever le paquet intel-microcode (temporairement en tout cas).
Hors ligne
Merci Claudep!
En fait, mis à part un démarrage ce matin en recovery mode, et sans rien faire d'autre, tout est rentré dans l'ordre et cela fait la 3e fois que je démarre ma machine sans encombre...
Le mystère s'épaissit, mais tout va bien!?!
Hors ligne
Mais, ce matin, il m'a à nouveau fallu démarrer via le recovery mode (sans rien faire de plus que poursuivre le démarrage)!?!
Hors ligne
Un indice: voilà trois fois, aujourd'hui comme hier, que je redémarre sans problème ma machine Ubuntu 16.04. A confirmer demain...
Tout se passe comme si le démarrage ne fonctionnait plus dès lors que la date est différente de celle de l'extinction.
Un peu comme avec mon Fairphone 3, que, durant plusieurs semaines, je devais redémarrer une fois par jour (mais pas deux)!?...
Peut-être cela donnera-t-il une idée à quelqu'un, sachant que le même problème s'est présenté sur d'autres machines, qu'elles soient sous Ubuntu 16.04 ou 18.04...
Hors ligne
Le mystère s'épaissit!!!
Ce matin, la machine a démarré comme une fleur. Comme nous avons reçu une machine (sur laquelle nous avions réinstallé avec succès Ubuntu 20.04 la semaine dernière pour régler des problèmes similaires), j'ai éteint et rallumé ma machine et, rebelote, il m'a fallu passer par le recovery mode.
C'est à en perdre son latin...
Hors ligne
La machine de la cliente réparée il y a une semaine, comme mentionné dans le post #16, il était impossible de faire que la LED power s'allume en bleu. La LED se trouvant tout à gauche sur la tranche était allumée en vert indiquant que la machine était allumée ou sous tension, mais il n'y avait pas d'alimentation branchée.
J'ai retiré la pile du BIOS durant 5 minutes et j'ai pu redémarré la machine en recovery mode. Comme au deuxième redémarrage j'avais à nouveau un écran violacé sombre, j'ai supprimé de la liste des mises à jour le Intel micro-code avec:
sudo apt-mark hold intel-microcode
puis effectué les mises à jour, y compris grub-update, autoclean et autoremove.
La partir de là la machine a déjà redémarré sans problème au moins 5 fois.
On touche du bois...
Hors ligne
Comme mon N240JU-PRO doit être régulièrement démarré en choisissant Options avancées dans le menu GRUB, puis Recovery mode, j'ai blacklisté intel-microcode comme indiqué ci-dessus.
Cela a bien fonctionné 4-5 fois, mais là le problème vient de se reposer. Après redémarrage en Recovery mode, j'ai ouvert une fenêtre terminal ([Ctrl]+[Alt]+[T]) et passé la commande suivante:
dmesg | grep microcode [ 0.000000] microcode: CPU0 microcode updated early to revision 0xe2, date = 2020-07-14 [ 0.100247] microcode: CPU1 microcode updated early to revision 0xe2, date = 2020-07-14 [ 1.366420] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0xe2 [ 1.366424] microcode: CPU1 sig=0x406e3, pf=0x80, revision=0xe2 [ 1.366439] microcode: CPU2 sig=0x406e3, pf=0x80, revision=0xe2 [ 1.366471] microcode: CPU3 sig=0x406e3, pf=0x80, revision=0xe2 [ 1.366542] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
Si je comprends bien, le blocage de la révision de intel-microcode n'a servi à rien, car il a été mis à jour avant la version 0xe2.
C'est ce que me semble confirmer la proposition de notre client au post #2:
apt-cache policy intel-microcode intel-microcode: Installé : 3.20201110.0ubuntu0.16.04.2 Candidat : 3.20201110.0ubuntu0.16.04.2 Table de version : *** 3.20201110.0ubuntu0.16.04.2 500 500 http://ch.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 3.20151106.1 500 500 http://ch.archive.ubuntu.com/ubuntu xenial/restricted amd64 Packages
J'imagine qu'il faudrait réinstaller la version 3.201511.06 pour Ubuntu 16.04 (xenial, dans mon cas), mais je ne sais pas trop comment faire. Peut-être avec Synaptic? Je n'ose pas trop essayer, de peur de ne plus rien pouvoir faire...
Merci pour toute aide!
Hors ligne
Au risque de me répéter, je pense que ça vaudrait la peine de le désinstaller, au moins pour voir si c'est bien la source du problème. Ensuite on peut toujours essayer de réinstaller une version antérieure, ou attendre un peu jusqu'à ce qu'une nouvelle version corrige le problème actuel. Je pense qu'on peut très bien "vivre" sans ce paquet.
Hors ligne
Merci claudep,
Comment le désinstaller sans risquer de tout fiche en l'air?
Cordialement.
Hors ligne
François Marthaler a écrit:
J'imagine qu'il faudrait réinstaller la version 3.201511.06 pour Ubuntu 16.04 (xenial, dans mon cas), mais je ne sais pas trop comment faire. Peut-être avec Synaptic? Je n'ose pas trop essayer, de peur de ne plus rien pouvoir faire...
Merci pour toute aide!
Via synaptic, c'est assez aisé à faire:
- Choisir le paquet en question
- Menu -> Paquet -> Choisir la version (CTRL+e) -> Forcer la version
- Appliquer
Ensuite, il faut bloquer la version installée.
- synaptic :
- Choisir le paquet en question
- Menu -> Paquet -> Bloquer la version
- dpkg:
- au terminal, taper :
sudo apt-mark hold intel-microcode
Il faut absolument faire les deux manipulations, parce que synaptic et dpkg/apt ne bloquent pas les paquets de la même façon.
Il n'y a pas grand risque à faire cette manipulation.
En l'état, de toute façon, la machine est peu utilisable.
Au pire, il faut backuper /home - depuis un live CD ou autre - réinstaller la machine et restaurer /home.
Hors ligne
Bonsoir Eggman,
Allez, je me lance!
Recherche de Synaptic sur l'ordinateur, double-clic sur l'icône et saisie du mot de passe.
Dans Synaptic, j'ai cliqué sur Rechercher et tapé "intel-microcode":
Dans le menu du haut, j'ai bien Paquet / Forcer la version et je peux choisir l'ancienne version:
Apparaît alors la fenêtre de dialogue suivante:
Après avoir cliqué sur le bouton Appliquer, j'ai bien à nouveau l'ancienne version 3.20151106.1:
Comme indiqué par Eggman, j'ai sélectionné le paquet et, dans Paquet, j'ai choisi Bloquer la version:
Enfin, suivant toujours les instructions de Eggman, j'ai ouvert une fenêtre terminal ([Ctrl]+[Alt]+[T]) et indiqué à apt de ne pas mettre à jour intel-microcode:
sudo apt-mark hold intel-microcode
Ne reste plus qu'à effetuer 2-3 redémarrage pour se convaincre que tout est rentré dans l'ordre...!
Hors ligne
Cher Eggman,
Après un redémarrage sans problème, je constate que Synaptic m'indique que j'ai toujours l'ancienne version de intel-microcode.
Un immense merci pour la solution complète à ce problème sur lequel nous et nos clients butons depuis au moins deux semaines.
Je me permets deux questions complémentaires:
- où as-tu acquis ces compétences (je pense en particulier à la gestion différenciée des mises à jour par dpkg et apt)?
- pourquoi les développeurs du noyau Linux ont-ils intégré ce nouveau microcode (propriétaire) qui fout le b...?
Cordialement.
Hors ligne
François Marthaler a écrit:
- où as-tu acquis ces compétences (je pense en particulier à la gestion différenciée des mises à jour par dpkg et apt)?
- pourquoi les développeurs du noyau Linux ont-ils intégré ce nouveau microcode (propriétaire) qui fout le b...?
En ce qui concerne l'inclusion du microcode, c'est le travail des développeurs - ici plutôt intégrateurs - d'Ubuntu, le microcode lui-même, fermé, étant développé par Intel pour patcher les erreurs des CPUs.
Quant à la différence entre dpkg/apt et synaptic, je m'en suis rendu compte il y fort longtemps après avoir bloqué un paquet à une version via synaptic, et m'être aperçu qu'il se mettait à jour en utilisant apt. Un petit tour par la documentation plus tard, j'avais la solution pour figer un paquet dans une version donnée via synaptic et dpkg/apt.
Hors ligne
Chapeau Eggman! Et encore merci!!!
Cela a même aidé un client en Suisse alémanique: https://swisslinux.org/forum/viewtopic. … 96#p31396.
Cordialement.
Hors ligne