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.
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.
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.
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.
- 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é ?
- En revanche il n’y a pas d’initramfs pour le noyau 4.19.
- 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.
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
Même en mode recovery ?
Qu’entends-tu par “écran clignotant” exactement ?
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).
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.
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
Re,
Désolé pour le terme “erreur suivante”, c’était effectivement un abus de langage de ma part.
Merci beaucoup pour les explications sur ce qui se passe !
J’ai fait ce que tu as dit, et c’est ok, je peux démarrer avec “recovery” en mode single-user connecté en root en ligne de commande.
J’imagine qu’il faut commencer par faire de la place sur ma partition / ?
Mais je n’ai aucune idée de ce que je peux supprimer sans risques.
Merci.
D’abord un état des lieux.
df -hT
du -hxd1 / | sort -h
Tenter de construire l’initramfs du noyau 4.19.
update-initramfs -c -t -k 4.19.0-5-amd64
Si la commande se termine sans erreur, regénérer le menu de GRUB avec update-grub, redémarrer avec le noyau 4.19 et voir si l’interface graphique fonctionne.
Note : avec l’IGP Intel, le paramètre nomodeset peut être contre-productif.
Bonjour toutes et tous, bonjour @PascalHambourg,
#df -hT
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
udev devtmpfs 3,9G 0 3,9G 0% /dev
tmpfs tmpfs 787M 9,0M 778M 2% /run
/dev/sda5 ext4 9,1G 8,8G 0 100% /
tmpfs tmpfs 3,9G 0 3,9G 0% /dev/shm
tmpfs tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/sda7 ext4 85G 75G 5,0G 94% /home
#du -hxd1 / | sort -h
4,0K /lib64
4,0K /mnt
4,0K /srv
16K /lost+found
16K /media
36K /tmp
4,6M /root
6,1M /lib32
6,8M /libx32
8,6M /etc
12M /bin
14M /sbin
85M /boot
137M /opt
753M /lib
2,1G /var
5,8G /usr
8,8G /
update-initramfs -c -t -k 4.19.0-5-amd64
update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
(et des warnings que je n’ai pas réussi à capturer en fichier texte et que je vais ajouter après via une image)
EDIT : voici les avertissements en question, concernant les firmwares :
Je me suis arrêté là ce matin, manque de temps, mais aussi pour info et validation avant d’aller plus loin.
Merci.
En dehors des warnings, la commande s’est terminée sans erreur et l’initramfs a bien été créé dans /boot ?
Pour supprimer les warnings liés aux firmwares manquants pour i915 (pilote des GPU Intel), il faut installer le paquet firmware-misc-nonfree de la section non-free.
La racine est presque pleine, il reste moins de 5% d’espace libre donc il n’y a plus que root qui peut éventuellement écrire dedans (un utilisateur normal qui a besoin d’écrire des fichiers temporaires dans /tmp ne pourra plus le faire).
Le gros de l’espace est dans /usr qui contient les programmes installés donc à part désinstaller des paquets on ne peut pas y faire grand-chose, puis dans /var qui contient notamment le cache apt. Si pas déjà fait, vide ce cache avec
apt-get clean
et revérifie l’espace libre.
Tu peux aussi supprimer le vieux noyau 4.9.0-8, tu n’en a plus besoin puisque tu as déjà le 4.9.0-9. Cela devrait libérer entre 150 et 200 Mo.
apt-get remove linux-image-4.9.0-8-amd64
La commande suivante devrait le supprimer automatiquement ainsi que d’autre paquets devenus inutiles, mais à manier avec précaution, bien examiner la liste des paquets désinstallés avant d’accepter.
apt-get autoremoveRe,
Oui, il est bien créé et sans erreurs.
J’ai aussi un programme installé dans /opt dont je ne me sers plus, je vais l’enlever.
Pour le reste des manip’s, je regarde ce soir quand je serais à nouveau devant mon ordinateur personnel 
Alors tu peux essayer de démarrer sur le noyau 4.19 après avoir exécuté update-grub pour prendre en compte l’initramfs. Il ne devrait plus y avoir de kernel panic “unable to mount root fs”.
Re,
Impec, je vous écrit depuis mon Debian avec le noyau 4.19 Merci !
J’ai fait le nettoyage, et refait les commandes pour l’espace disque libre
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
udev devtmpfs 3,9G 0 3,9G 0% /dev
tmpfs tmpfs 787M 9,0M 778M 2% /run
/dev/sda5 ext4 9,1G 7,0G 1,7G 81% /
tmpfs tmpfs 3,9G 0 3,9G 0% /dev/shm
tmpfs tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/sda7 ext4 85G 75G 5,0G 94% /home
|4,0K|/lib64|
|---|---|
|4,0K|/mnt|
|4,0K|/opt|
|4,0K|/srv|
|16K|/lost+found|
|16K|/media|
|36K|/tmp|
|4,6M|/root|
|6,1M|/lib32|
|6,8M|/libx32|
|8,5M|/etc|
|12M|/bin|
|14M|/sbin|
|104M|/boot|
|566M|/lib|
|666M|/var|
|5,6G|/usr|
|7,0G|/|
Je vous soumets mon sources.list pour que vous puissiez me corriger avant que je refasse les commandes apt.
# deb cdrom:[Debian GNU/Linux 8.4.0 _Jessie_ - Official amd64 DVD Binary-1 20160402-14:46]/ jessie contrib main
# deb cdrom:[Debian GNU/Linux 8.4.0 _Jessie_ - Official amd64 DVD Binary-1 20160402-14:46]/ jessie main contrib
deb http://debian.proxad.net/debian/ stable main contrib non-free
deb-src http://debian.proxad.net/debian/ stable main contrib non-free
deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free
# jessie-updates, previously known as 'volatile'
deb http://debian.proxad.net/debian/ stable-updates main contrib non-free
deb-src http://debian.proxad.net/debian/ stable-updates main contrib non-free
deb http://http.debian.net/debian/ stable-backports main
Merci.
Comme déjà dit, je remplacerais “stable” par “buster” en prévision de la prochaine version mais actuellement ça ne fait aucune différence.
Est-ce que tu as fait autre chose que libérer de l’espace disque sur la racine et démarrer avec le noyau 4.19 pour que l’environnement graphique fonctionne à nouveau ?
J’ai fait le ménage avec
apt-get clean
apt-get remove linux-image-4.9.0-8-amd64
apt-get autoremove
Et j’ai supprimé le programme qui était dans /opt
Puis j’ai fait le
update-grub
Puis dans Grub, j’ai choisi le noyau 4.19, édité pour supprimer le nomodeset, puis F10 et démarrage graphique ok. (je n’ai pas essayé en laissant ce paramètre)