Plus de boot après mise à jour de /etc/apt/sources.list

Support Debian
Tags: #<Tag:0x00007f63fb9afdd8>
#1

Bonjour toutes et tous,

En m’appuyant sur https://wiki.debian.org/fr/SourcesList, hier soir, j’ai mis à jour mon fichier sources.list de mon Debian 9.9 à jour pour remplacer la mention “stretch” par “stable” afin de suivre les versions stables au fur et à mesure de leur publication et ainsi passer à Buster.

Suite à cette mise à jour, j’ai fait

sudo apt update
sudo apt ugrade

J’ai ensuite redémarré (pour info, dual-boot avec MS Windows, mais grub est toujours ok), mais mon Debian ne démarre plus. J’ai l’erreur suivante :

[Firmware Bug] : ISC_DEADLINE disabled due to Erradata ; please update microcode to version: 0x22 (or later)
Kernal panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[...]
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unkwown-block(0,0) ]---

J’ai tenté un démarrage avec l’option du menu Grub (recovery mode) mais j’obtiens la même erreur.

Comment puis-je réparer mon erreur ?
Merci d’avance pour vos pistes.

Pour info, les copies écrans :
image
image

#2

j’utiliserais un live cd pour chrooter ta partition linux et faire la commande root:

update-initramfs -u

et ensuite la commande

update-grub

suivie de

grub-install  /dev/sda

(en supposant que tu n’as qu’un seul disque dur)

#3

Ce n’est pas un dist-upgrade plutôt qu’il fallait faire ?

2019-07-26T06:37:00Z
https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.fr.html#minimal-upgrade

#4

les trois commandes sont nécessaires pour mettre à jour; je pense que le mieux pour régler ton problème est de chrooter ta partition linux.
Pour chrooter une partition:

https://wiki.debian-fr.xyz/Réinstaller_Grub2#Solution_avec_un_chroot

une fois arrivé dans le chroot tu fais les commandes

update-initramfs -u
et
update-grub
grub-install /dev/sda (en supposant toujours que tu n’aies qu’un seul hdd)

#5

Bonjour toutes et tous,
Merci pour vos retours @anon44391915 et @anonyme2 !

Je vais tester ça, mais sans doute pas avant demain soir.

J’ai du mal à comprendre pourquoi il faut faire une mise à jour de grub ? :slight_smile:
J’ai plusieurs disques durs, 3 pour être précis :
sda : SSD 240 Go dual-boot Windows/Debian
sdb : disque dur 1To, data
sdc : disque dur 2To, data

Merci !

#6

donc il faut installer grub sur sda.

#7

Ok, mais Grub est déjà installé et fonctionne.
Pourquoi devoir le réinstaller ? Merci.

#8

ça ne mange jamais de pain de reinstaller grub.

#9

Ok, merci.
Je vous redis quand j’aurai fait les manip’s

#10

C’est une mauvaise idée. Il vaut mieux mettre le nom de la nouvelle version comme “buster” et faire la mise à niveau au moment que tu choisis plutôt que de subir une mise à niveau forcée dès la publication d’une nouvelle version stable.

L’intuition de @anonyme2 est bonne, mais il va un peu trop vite à mon goût, et surtout il assène les commandes censées réparer sans aucune explication ni méthode pour vérifier leur pertinence.

En effet je pense que réinstaller GRUB (grub-install) est inutile puisqu’il démarre correctement et charge le noyau. Je pense que le premier message “Firmware bug” n’a rien à voir avec le problème, il se produit bien plus tôt. Le message d’erreur

Kernel panic - not syncing: VFS: Unable to mount root fs on unkwown-block(0,0) ]

indique que le noyau a essayé de monter lui-même la racine. Or il ne devrait pas, car le noyau modulaire de Debian en est incapable et doit déléguer cette tâche à l’initramfs (anciennement initrd). J’en déduis donc que

  • soit l’initramfs est corrompu (mais il devrait y avoir un message du noyau le signalant),
  • soit l’initramfs est manquant (n’a pas été généré, peut-être par manque d’espace disque dans /boot ou à cause d’une erreur lors de sa construction),
  • soit l’entrée de menu du fichier de configuration de GRUB (/boot/grub/grub.cfg, généré par update-grub) ne contient pas d’instruction initrd pour le charger (c’est également le cas quand l’initramfs n’existe pas).

Dans les deux premiers cas, il faut reconstruire l’initramfs avec update-initramfs -u. Dans les deux derniers, il faut reconstruire grub.cfg avec update-grub.
Donc avant d’exécuter la moindre commande je serais d’avis de vérifier la présence d’un initrd pour la version du noyau et d’une commande initrd dans les entrées de menu du noyau de grub.cfg.

Note : des entrées de menu pour l’ancien noyau 4.9 de Stretch sont toujours présentes, est-ce que l’erreur se produit aussi avec elles ? Si oui, ce sera beaucoup plus confortable pour investiguer.

1 J'aime
#11

c’est que je suis loin d’avoir le niveau et la précision de tes connaissances, te lire est donc toujours très instructif; j’ai appris sur le tas pour me sortir des embrouilles en cherchant sur les différents forums et sur le net.

#12

Bonsoir tout le monde,

Ok, je note ça.

C’est possible, ma partition Debian est hyper serrée en espace disque à cause du dual-boot.

J’ai testé les autres entrées, en mode recovery, et ça ne démarre pas non plus.
Je ne sais pas comment reprendre la main sur mon Debian du coup.

#13

Tu peux afficher le contenu d’une entrée de menu de Debian dans GRUB en appuyant sur la touche “e”, et vérifier la presence d’une instruction “initrd”.
Si tu peux démarrer Ubuntu, tu peux monter la partition racine de Debian (ou la partition boot si séparée) pour examiner les fichiers initrd* présents dans son répertoire /boot.

#14

Bonjour à toutes et tous, bonjour @PascalHambourg,

J’ai démarré mon PC avec Tails (distribution live basée sur GNU/Linux), et j’ai pu vérifier les points suivants :

  • Partition racine : 10Go / 168Mo libres (98,4% occupé)
  • Le contenu du dossier /boot
    ** boot$ ls -l initrd*
    ** -rw-r–r-- 1 root root 18444998 avril 9 06:49 initrd.img-4.9.0-8-amd64
    ** -rw-r–r-- 1 root root 34399938 juil. 20 06:48 initrd.img-4.9.0-9-amd64

Merci.

#15
  1. Le répertoire /boot contient bien les initramfs des deux noyaux 4.9 disponibles dans le sous-menu d’options avancées de GRUB, et ils datent d’avant la mise à niveau donc on peut supposer qu’ils n’ont pas été altérés. Donc le démarrage avec un de ces noyaux ne devrait pas provoquer la même erreur qu’avec le noyau 4.19. Peux-tu vérifier le contenu de l’entrée de menu de GRUB pour un de ces noyau avec la touche “e” après l’avoir sélectionné ?
  1. En revanche il n’y a pas d’initramfs pour le noyau 4.19.
  1. La racine a vraiment très peu d’espace libre. Cela pourrait expliquer pourquoi l’initramfs du nouveau noyau 4.19 n’a pas été construit.
#16

Re,

Oui, quand je démarre les autres noyaux, je n’ai pas la même erreur, mais le démarrage reste bloqué avec un écran clignotant (allumé/éteint en continu). Je ne peux pas aller plus loin. Je peux essayer de faire une vidéo postée quelque part pour montrer à quoi ça ressemble ?
EDIT : Ce problème d’affichage est peut-être lié à mon précédent problème sur cette machine ?

J’ai donc fait e sur le menu Grub pour le noyau 4.9.0-9, et j’obtiens ça (extrait) :

  • load video
  • insmod gzio
    […]
  • echo ‘Chargement de Lunix 4.9.0-9-amd64…’
  • linux /boot/vmlinuz-4.9.-9-amd64 root=UUID=aa41xx[crunch] ro quiet nomodeset
  • echo ‘Chargement du disque mémoire initial…’
  • initrd /boot/initrd.img-4.9.0-9-amd64
#17

Même en mode recovery ?
Qu’entends-tu par “écran clignotant” exactement ?

#18

Bonjour tout le monde, bonjour @PascalHambourg,

Oui, même en mode recovery, ça ne marche pas.

Par “écran clignotant”, je veux dire que lors du boot, je vois les messages s’afficher, puis l’écran s’éteint (écran noir), se rallume (avec toujours les lignes des messages du boot), s’éteint, se rallume, de manière continue et très rapide, et cela ne s’arrête pas. D’où le côté “clignotant”.

La nuit portant conseil, je prévois de refaire un test en enlevant ma carte graphique AMD Radeon RX590 et en utilisant uniquement l’IGP intégrée (Intel je crois), afin de ne pas cumuler les difficultés dans le diagnostic. Je vous redis ça bientôt (ce soir peut-être).

#19

Re,

J’ai donc enlever ma carte graphique AMD RX590, mais pour autant, le boot n’aboutit pas, que ce soit en mode normal ou recovery avec les noyaux 4.9.0-9 ou 4.9.0-8.

J’ai noté l’erreur suivante :

You are in rescue mode. After loggin in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Impossible d'ouvrir l'accès à la console, le compte root est verrouillé. Consultez la page man de sulogin(8) pour plus de détails.
Appuyez sur Entrée pour continuer.

Après la touche Entrée, l’écran devient noir (aucun affichage) plusieurs minutes, puis affiche les lignes suivantes, jusqu’à

IPv6: eth0: link becomes ready.

Et je reste bloqué là (j’ai testé pendant 15mn), les touches claviers numlock et capslock ne répondent pas, j’en déduis un plantage complet du système.

#20

La première phrase n’est pas une erreur, c’est l’invite normale de connexion du mode rescue. Le problème, c’est la phrase qui suit : “le compte root est verrouillé”, qui résulte probablement du choix de ne pas avoir défini de mot de passe root à l’installation et d’utiliser sudo pour exécuter des commandes en tant que root. Le défaut est que cela empêche de se connecter directement en root.

L’appui sur la touche Entrée arrête le mode rescue et poursuit un démarrage normal. Le message “eth0…” est normal aussi, il indique que l’interface réseau ethernet est activée et connnectée. L’écran noir et le blocage proviennent probablement d’un problème lors du démarrage de l’interface graphique.

En tout cas tu as l’affichage en console. Puisque tu ne peux pas utiliser le mode rescue sans mot de passe root, tu dois démarrer le système en mode normal mais sans interface graphique et ouvrir une session utilisateur en console. Pour cela, édite l’entrée de menu avec la touche “e”, ajoute “2” à la fin de la ligne qui commence par “linux” puis lance le démarrage avec F10.

Après l’ouverture de session, la première chose à faire sera de définir un mot de passe root avec sudo passwd.

1 J'aime