Refaire fonctionner le noyau linux-image-4.18.0-3-amd64 (abandonné, passage au noyau linux-image-4.19.0-1-amd64_4.19.12-1_amd64 )

Support Debian
, ,
Tags: #<Tag:0x00007f63f200c2a8> #<Tag:0x00007f63f200c190> #<Tag:0x00007f63f2017f40>
#1

Bonjour hier, j’ai voulu supprimer avec Synaptic un noyau surnuméraire :
le linux-image-4.18.0-2-amd64 puisque le linux-image-4.18.0-3-amd64 était arrivé.

Synaptic m’a affiché une fenêtre avec une option pré-cochée qui me dissuadait de supprimer ce noyau. Ceci avec un message du genre : « Abandonner la suppression de ce noyau », mais en anglais.

Alors je n’ai pas décochée l’option et j’ai cliqué sur Next, ce qui, je croyais aller annuler toute l’opération. Comme cela avait été le cas jusqu’ici. Mais non ! Je me suis aperçu que c’était le linux-image-4.18.0-3-amd64 qui ne voulait plus amorcer au redémarrage, tandis que le linux-image-4.18.0-2-amd64 continuait à fonctionner.

Alors, j’ai un peu cherché sur le net comment réparer, mais pour l’instant, je n’ai pas trouvé de solution.

J’ai tenté dans l’ordre :

# apt-get install --reinstall linux-image-4.18.0-3-amd64

# dpkg-reconfigure linux-image-4.18.0-3-amd64

# update-grub

# grub-install /dev/sda
Installation pour la plate-forme i386-pc.
Installation terminée, sans erreur.

# update-grub
Création du fichier de configuration GRUB…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-4.18.0-3-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.18.0-3-amd64
Image Linux trouvée : /boot/vmlinuz-4.18.0-2-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.18.0-2-amd64
fait

Mais pour l’instant rien n’a fonctionné.

/boot# ls -ail
total 66730
    2 drwxr-xr-x  4 root root     1024 déc.   4 19:20 .
    2 drwxr-xr-x 23 root root     4096 déc.   4 07:33 ..
   17 -rw-r--r--  1 root root   204289 nov.   2 21:31 config-4.18.0-2-amd64
   21 -rw-r--r--  1 root root   204256 nov.  23 20:15 config-4.18.0-3-amd64
16065 drwxr-xr-x  5 root root     1024 déc.   5 13:15 grub
   13 -rw-r--r--  1 root root 25372822 nov.  23 08:11 initrd.img-4.18.0-2-amd64
   15 -rw-r--r--  1 root root 25379927 déc.   4 19:20 initrd.img-4.18.0-3-amd64
   11 drwx------  2 root root    12288 août  21  2017 lost+found
   14 -rw-r--r--  1 root root  3310203 nov.   2 21:31 System.map-4.18.0-2-amd64
   20 -rw-r--r--  1 root root  3311600 nov.  23 20:15 System.map-4.18.0-3-amd64
   18 -rw-r--r--  1 root root  5126000 nov.   2 21:31 vmlinuz-4.18.0-2-amd64
   22 -rw-r--r--  1 root root  5126016 nov.  23 20:15 vmlinuz-4.18.0-3-amd64

J’ai ce message quand je mets à jour, voir image :

#2

ça veut simplement dire que tu as démarré sur un noyau qui n’est pas le plus récent, le 4.18.0.2 et le système te prévient

pour savoir ton noyau actif

uname -a

il faut redémarrer et sélectionner le plus récent c’est à dire

4.18.0-3-amd64
#3 
uname -a
Linux  4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) x86_64 GNU/Linux

Je sais que je n’ai pas redémarré sur le noyau le plus récent puisque si je tente de sélectionner et de redémarrer avec celui-ci, il n’y a pas de sortie vidéo, l’écran reste noir. C’est ce que je dis plus haut, synaptic m’a bizarrement esquinté ce noyau linux-image-4.18.0-3-amd64 alors que je lui demandais de supprimer l’autre le linux-image-4.18.0-2-amd64 qui était dans les paquets obsolètes.

Maintenant j’aimerais restaurer le fonctionnement du dernier noyau le 4.18.10-3 d’où les commandes que j’ai effectuées, mais cela n’a pas fonctionné, il y en a sûrement d’autres qui doivent résoudre le problème, mais je ne les pas encore trouvées d’où mon message sur ce forum.

#4

Je lis rapidement le man de update-initramfs et je lance la commande :

# update-initramfs -c -k 4.18.10-3
update-initramfs: Generating /boot/initrd.img-4.18.10-3
WARNING: missing /lib/modules/4.18.10-3
Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/4.18.10-3: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
cat: /tmp/user/0/mkinitramfs_vcQf7E/lib/modules/4.18.10-3/modules.builtin: Aucun fichier ou dossier de ce type
find: ‘/tmp/user/0/mkinitramfs_vcQf7E/lib/modules/4.18.10-3/kernel’: Aucun fichier ou dossier de ce type
depmod: WARNING: could not open /tmp/user/0/mkinitramfs_vcQf7E/lib/modules/4.18.10-3/modules.order: No such file or directory
depmod: WARNING: could not open /tmp/user/0/mkinitramfs_vcQf7E/lib/modules/4.18.10-3/modules.builtin: No such file or directory

Je trouve ceci :

mais vu que l’article en cause est suite à une compilation et que pour moi, ce n’est pas le cas, je préfère attendre vos réactions.

Message modifié pour éviter les erreurs d’interprétation

#5

si effectivement tu peux démarrer ta machine avec le kernel 4.18.0-2-amd64 alors démarre dessus et ensuite tu pourras à nouveau installer le 4.18.0-3.Quand le nouveau kernel sera installé tu fais update-grub et tu devrais à nouveau avoir le choix entre les deux noyaux.

#7

Cette information n’est pas mentionnée dans le premier message

Le pilote de la carte graphique n’a pas du être installé sur le nouveau noyau

#8

Est-tu certain d’avoir redémarré avec succès au moins une fois avec le noyau 4.18.0-3 après son installation ? Si ce n’est pas le cas, il est très risqué de supprimer le noyau précédent au cas où le dernier ne fonctionnerait pas correctement. Tu ne donnes pas la teneur complète du message dissuasif, mais je soupçonne que la raison était que c’était encore le noyau -2 qui était actif à ce moment, et que tu n’avais donc pas encore redémarré avec le -3. Et syaptic n’a effectivement rien fait, puisque le noyau -2 est toujours présent.

Commandes parfaitement inutiles n’ayant rien à voir avec le problème.

Je doute fort que synaptic ait esquinté quoi que ce soit.

Ça marcherait mieux en spécifiant la version complète du noyau : 4.18.0-3-amd64.
Mais là encore, ça ne servira à rien puisque les commandes apt-get --reinstall et dpkg-reconfigure ont déjà effectué cette action.

#9

[

Je recommence avec :

# update-initramfs -c -k 4.18.0-3-amd64
update-initramfs: Generating /boot/initrd.img-4.18.0-3-amd64

et cette fois-ci je n’ai plus le message d’erreur. Je vais redémarrer pour voir si le noyau 4.18.0-3-amd64 est réparé et amorçable.

Modification : J’ai redémarré et cela n’a rien changé, impossible de travailler avec le noyau linux-image-4.18.0-3-amd64

#10

Salut,

Pour info j’ai un laptop avec Sid qui ne démarre pas avec le noyau 4.18.0.3 : le grub s’affiche normalement et après c’est écran noir. (et ce sans rien cafouiller avec Synaptic ou apt :wink: )
En revenant sur le 4.18.0.2 tout fonctionne correctement.

#11

Merci de ce témoignage ! Mon noyau est : linux-image-4.18.0-3-amd64. Peux-tu préciser le tien ?

Il y a un bug déclaré sur ce noyau linux-image-4.18.0-3-amd64 dans sa version 4.18.20-2 :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914491

#12

Oui c’est bien le 4.18.0-3-amd64.

J’ai vu le bug mais je ne sais pas dire si il a une incidence pour mon portable (Acer d’une dizaine d’années) où le noyau pose problème.
Ce même noyau fonctionne parfaitement sur un autre portable installé avec Testing (un peu plus récent et marque Dell).

Je souhaitais surtout indiquer que la potentielle mauvaise manipulation avec Synaptic n’est peut-être pas en cause.

1 J'aime
#13

Comparons les cpu où le noyau 4.18.0-3-amd64 version 4.18.20-2 fonctionne
et ceux où 4.18.0-3-amd64 version 4.18.20-2 ne fonctionne pas
puisque dans cette version il y a un patch contre spectre Version 2.

Chez moi :

# cat /proc/cpuinfo | grep CPU
model name	: Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz

# cat /proc/cpuinfo | grep bugs
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline

Et chez toi pour chaque processeur, celui qui marche avec le nouveau noyau et celui qui ne marche pas, peux-tu nous donner les mêmes informations dans le même ordre ( pour comparer plus rapidement ) ?

Merci

#14

Les retours pour celui qui fonctionne :

$ cat /proc/cpuinfo | grep CPU
model name	: Intel(R) Core(TM) i5 CPU       M 540  @ 2.53GHz
model name	: Intel(R) Core(TM) i5 CPU       M 540  @ 2.53GHz
model name	: Intel(R) Core(TM) i5 CPU       M 540  @ 2.53GHz
model name	: Intel(R) Core(TM) i5 CPU       M 540  @ 2.53GHz

$ cat /proc/cpuinfo | grep bugs
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline

La suite dans la soirée lorsque j’aurai l’autre pc sous la main.

Edit : voici le résultat du laptop qui ne fonctionne pas avec le dernier kernel :

$ cat /proc/cpuinfo | grep CPU
model name	: Intel(R) Celeron(R) CPU          540  @ 1.86GHz

$ cat /proc/cpuinfo | grep bugs
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline

Hormis le modèle de CPU, tout est pareil :roll_eyes:

#15

Quelle surprise…

Jusqu’à preuve du contraire, il n’y a eu aucune mauvaise manipulation avec Synaptic. J’attends encore que @gilles2 confirme expressément si le système a démarré correctement au moins une fois avec le noyau 4.18.0-3.

#16

C’est pour ça que j’ai écrit “potentielle”.

Je ne comprends pas ce que gilles2 veut faire avec les infos qu’il m’a demandé mais son cpu semble être à peine plus récent que mon Céléron.
Peut-être un souci de compatibilité avec le vieux matériel (temporaire ou non) ?

#17

@noisette et @gilles2 , quand vous dites le noyau ne fonctionne pas, vous entendez par là avoir un écran noir après le boot de celui-ci ?

Déjà si le système amorce le noyau c’est déjà une bonne chose mais l’affichage d’un écran noir en fin de phase de démarrage n’indique pas que le noyau n’est pas fonctionnel mais surtout qu’il y a un souci avec l’affichage.

Avez-vous tenté au moins de repasser sur une tty afin de vérifier que ce ne soit pas simplement un souci avec le pilote d’affichage ?

#18

Je crois que oui, mais je n’en mettrais pas ma main à couper si je disais une erreur, car comme j’ignorais qu’il aurait un problème, ma concentration ne se portait pas là-dessus.

Il faut bien tester des hypothèses pour essayer de cerner le problème, c’est pourquoi j’ai pensé à la compatibilité avec les vieux matériel, mais ce n’est pas confirmé. Il faut trouver d’autres hypothèses à tester.

Pour moi, oui.

Trop habitué au graphique, je n’y ai pas pensé, mais c’est trop évident, je me sens bête ! Je vais tester !

December 8, 2018 (Europe: Paris), December 8, 2018 (America: Los Angeles)
J’ai testé, cela ne fonctionne pas, j’ai l’écran noir, mais je n’avais pas précisé que l’affichage m’avait dit et me redit :

« NE PEUT AFFICHER CE MODE VIDÉO. CHOISIR ENTRÉE D'AFFICHAGE 1280 X 1024 @ 60 Hz »
#19

Je mets :

# less /var/log/syslog | grep modeset

ici :
https://debian-facile.org/paste-AC8C08A9A4-raw

Si vous savez bien interpréter ce que dit le fichier …

#20

Pourquoi avoir posté ce fichier ?
Avec quel noyau actif a-t-il été obtenu ? Si ce n’est pas le -3, je n’en vois pas l’intérêt.

Qu’est-ce qui te fait penser que ce rapport de bug est lié au problème que tu recontres ? Il ne contient aucune descriptions des symptômes produits.

Par contre tes symptômes me font penser à un autre rapport de bug dont je n’ai plus le numéro en tête, qui affecte certains GPU Intel. Si tu as un GPU Intel, à vérifier avec lspci, tu peux essayer de démarrer en ajoutant le paramètre “nomodeset” à la fin de la ligne de commande “linux” dans l’entrée de menu du noyau -3.

#22 
# less /var/log/syslog | grep modeset

ici : less /var/log/syslog | grep modeset (64,3 Ko)

Simplement avec le linux-image-4.18.0-2-amd64 Version : 4.18.10-2+b1
puisque l’autre le linux-image-4.18.0-3-amd64 Version : 4.18.20-2 ne donne qu’un écran noir.

Je donnerai une version du fichier avec linux-image-4.18.0-3-amd64 Version : 4.18.20-2 quand j’aurais éventuellement démarré avec celui-ci.

# cat /proc/cpuinfo | grep CPU
model name	: Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz

Je vais lire la documentation contenue dans

$ info -f grub -n 'Simple configuration'

pour effectuer de manière correcte la solution que tu préconises.

J’ai lu, je pars de cette situation de /etc/default/grub :

GRUB_CMDLINE_LINUX=""

à celle-ci :

GRUB_CMDLINE_LINUX="nomodeset"

puis je mets à jour grub :

# update-grub

J’ai redémarré d’abord avec le noyau qui me donnait satisfaction le linux-image-4.18.0-2-amd64 Version : 4.18.10-2+b1 avec nomodeset, je n’avais que mode texte avec Ctrl-Alt-F3,
puis j’ai redémarré avec le linux-image-4.18.0-3-amd64 Version : 4.18.20-2 pareil, je n’avais que mode texte avec Ctrl-Alt-F3

J’ai profité que j’étais en mode texte pour récupérer ces informations :

# less /var/log/syslog | grep modeset >/home/utilisateur0/modeset-3.txt

J’hébergerai le fichier.