Précision importante :
j’utilise le miroir allemand de Debian :
[pastacode provider= »manual » lang= »markup »]
deb http://ftp.de.debian.org/debian/ sid main contrib non-free
deb-src http://ftp.de.debian.org/debian/ sid main contrib non-free[/pastacode]
Au lieu du miroir Français (qui n’est donc pas à mettre en cause) :
[pastacode provider= »manual » lang= »bash »]
deb http://ftp2.fr.debian.org/debian/ wheezy main
deb-src http://ftp2.fr.debian.org/debian/ wheezy main[/pastacode]
parce que le premier comporte des mises à jour plus régulières (mais aussi des bogues plus récents ^^).
Je vous tiens à jour de mes avancées sur cette 2nde news que je compléterais.
Je peux à présent poursuivre la mise à jour du Bottin de manière provisoire via un chroot à partir de ma clé USB :
A partir de ma clé USB créée précédemment (voir la série d’articles « Mise à jour du Bottin provisoirement suspendue« ) j’ouvre une console et saisi (sur ma clé USB j’avais précédemment créé plusieurs répertoires vides aux noms évocateurs des « périphériques » de mes différents disques durs : sda1, sdb5, sdb6, sdb7 et sdb8, dont l’adresse est /mnt/sda1, /mnt/sdb5, etc … de manière à ne pas devoir me poser la question « c’est quoi déjà le nom des périphériques de mes disques ? »):
[pastacode provider= »manual » lang= »bash »]
# mount -t ext3 /dev/sda1 /mnt/sda1
# chroot /mnt/sda1
# mount -a ([/pastacode]
la ligne 2 me servira – uniquement via cette console « chrootée », à effectuer des corrections ultérieures du système avec apt ou dpkg)
Tiens – c’est étonnant, en me relisant et en complétant cette doc je m’aperçois – après test, que je peux monter /dev/sda1 aussi bien en ext4 qu’en ext3. Je vérifie via GParted (précédemment installé) et celui-ci m’indique que /dev/sda1 est formaté en ext3 (information confirmée par mon /mnt/sda1/etc/fstab, plus fiable que ma mémoire). Préférant ne pas prendre de risque, je reste en ext3. Après réflexion, je crois me rappeler que je l’avais formaté en ext3 pour avoir lu sur Internet qu’il valait mieux formater un SSD en ext3 (mes autres disques – non SSD, sont en ext4, confirmé par Gparted).
Je relance Dolphin (sinon il ne parvient pas à accéder aux nouveaux répertoires, même avec le même nom d’utilisateur et le même groupe).
Puis je retrouve le répertoire du Bottin et le lance (dolphin n’étant pas chrooté, les données système utilisées sont celles de la clé USB).
Ca fonctionne (au moins de manière provisoire je retrouve mes marques :)
Je me démène avec Dselect.
Très franchement, cette interface ne remplace absolument pas Synaptic.
C’est brouillon, on ne se rend pas compte de ce que l’on fait.
Même après 10 ans d’utilisation de Linux, je rame avec cette interface – en dépit des efforts qui ont été consentis sous forme d’aide contextuelle. On ne rend pas un outil convivial en l’abreuvant d’aide contextuelle que personne n’a envie de lire, on le rend convivial en concevant son interface avec le regard de l’utilisateur.
Les mises à jour à 3 octets sont affichées pelle-mêle avec les refontes complètes, les paquets complètement bugués et/ou impossibles à installer côtoient les paquets stables et sérieusement testés.
A titre d’exemple, si je sélectionne l’option suicidaire de mises à jour de tous les paquets, Dselect me propose 1902 mises à jour, 93 nouvellement installés et 15 paquets à enlever. Je dis suicidaire car je sais qu’un certain nombre de paquets sont tagués avec un truc du genre « serious bug », du type gdm3 qui ne démarre plus et autres joyeusetés. Ces tags ne sont pas gérés par dselect/apt, il ne peut pas me proposer une mise à jour viable et saine en laquelle je puisse avoir confiance.
Il manque aussi l’option « Nouvelle version amont du logiciel » que j’utilise tout le temps sous Synaptic, et l’option permettant de voir l’historique récent des paquets installés, l’histoire de voir quel paquet récemment installé aurait pu planter mon installation.
Bref, il me semble que cet outil est devenu obsolète/inadapté pour une mise à jour décente d’un système d’exploitation récent.
J’ai du mal à croire que l’on ne peut pas faire quelque-chose ressemblant à Synaptic (voir mieux) en mode texte.
J’imagine un débutant qui n’a pas encore d’interface graphique ou perd celle-ci après une mise à jour.
Il faut une sacré dose de perspicacité pour ne pas avoir envie de tout laisser tomber.
C’est très certainement un frein à l’adhésion de notre OS.
Il n’y a vraiment personne qui saurait faire un synaptic en mode texte avec des pavés graphiques ?
Bon, pour l’historique des installations, çà se trouve dans var/log/history.log et var/log/term.log du disque monté (pas celui de la clé USB évidemment, je dis çà parce que j’ai commencé par là ^^).
De mieux en mieux …
Un pas en avant, 3 pas en arrière ^^
J’ai changé de PC pour cette News.
J’ai planté ma clé de dépannage ^^
Vive Linux !
En prévision de la mise à jour (probable) de paquets plus ou moins nombreux, j’ai essayé de monter NFS.
Il me fallait pour cela configurer NFS sur ma clé USB (j’utilise NFS sur le PC hôte pour échanger des fichiers d’un PC à l’autre et pour partager le cache des paquets afin de ne pas avoir à les retélécharger si je veux mettre à jour mon autre PC – ce que je n’ai pas fais depuis très longtemps et heureusement pour moi, j’ai ainsi un PC de secours lorsqu’il m’arrive de planter l’autre après une mise à jour comme celle-ci), et donc reprendre le paramétrage du réseau, ce que j’ai fais en repompant la configuration réalisée sur l’installation plantée.
En relisant ma doc perso, je lis que j’avais eut précédemment un souci avec le paquet network-manager. A l’époque j’avais noté qu’il valait mieux le désinstaller (je ne sais plus pour quelle raison obscure). J’ai donc désinstallé network-manager.
Je reboot : plus de réseau. Les fichiers de configuration me paraissent bons.
Je tente de réinstaller network-manager mais Synaptic ne peux plus le réinstaller.
Je regarde dans le cache, celui-ci ne contient aucun paquet car j’avais sélectionné l’option de ne pas conserver le cache sous Synaptic (ma clé USB commençant à être limite en taille). Donc plus de réseau et impossible d’installer un paquet de manière simple.
Je tente d’utiliser le cache du système planté en installant à coups de dpkg network-manager et ses nombreuses dépendances.
Sauf que je fini par casser des paquets par le jeu des dépendances non résolues et l’absence de réseau pour débloquer tout çà. Super.
Je tente un redémarrage sur le système planté sur lequel il me reste du réseau. Sauf que je butte sur cette saloperie de console en affichage 4/3 sur lequel je ne vois pas le retour instantané de ce que je saisi.
Il semble que cette résolution se règle sous Grub (je l’ai déjà fais mais il y a longtemps maintenant).
J’essaie plein de trucs mais çà ne fonctionne pas. Quel merdier.
Un pas en avant, 0 en arrière.
J’ai trouvé pour la configuration de l’affichage de la console.
C’est bien dans Grub, mais j’oubliais de faire un
[pastacode provider= »manual » lang= »bash »]
# update-grub[/pastacode]
une fois ma modif de grub via la commande :
[pastacode provider= »manual » lang= »bash »]
# nano /etc/default/grub[/pastacode]
La ligne à ajouter / décommenter dans ce fichier était :
[pastacode provider= »manual » lang= »markup »]
GRUB_CMDLINE_LINUX="vga=791 quiet"[/pastacode]
Bon, j’avance (un peu), c’est déjà çà.
Maintenant il faut que je trouve comment monter ma clé USB en console sur mon disque hôte (sans gestionnaire graphique – celui-ci étant planté), pour cela je dois trouver le nom du périphérique correspondant (çà n’est pas /dev/sda1 puisque j’ai déjà plusieurs disques de ce type), Google me donne la réponse :
[pastacode provider= »manual » lang= »bash »]
# df[/pastacode]
Dans la liste affiché je retrouve ma clé USB – facilement identifiable par la taille de stockage, c’est /dev/sdf1.
Je jette un oeil dans le répertoire media pour voir les répertoires disponibles pour m’y raccorder :
[pastacode provider= »manual » lang= »bash »]
# ls /media[/pastacode]
Je trouve notamment un répertoire « usb » qui me parait pas mal.
Allons-y, je le monte, chroot dessus et tente une mise à jour des paquets :
[pastacode provider= »manual » lang= »bash »]
# mount /dev/sdf1 /media/usb
# chroot /media/usb
# mount -a
# apt-get update[/pastacode]
(Étonnant là aussi : je n’ai pas besoin de préciser le type de formatage de ma clé par l’option « -t ext4 » – une nouvelle possibilité de la commande « mount » de mon disque hôte avec un OS plus récent ?)
Ca marche ! J’avais quelques craintes que la mise à jour des paquets en chroot ne fonctionne pas du fait de mes paramétrages et plantages précédents.
Un autre petit pas pour moi, un grand pour la résolution de mes soucis.
Etape suivante : essayer de rétablir le réseau sur ma clé USB.
je tente un :
[pastacode provider= »manual » lang= »bash »]
# apt-get install network-manager[/pastacode]
çà ne fonctionne pas à cause des paquets cassés, mais il me suggère un :
[pastacode provider= »manual » lang= »bash »]
# apt-get -f install[/pastacode]
Je lance cette commande, puis relance la commande précédente qui fonctionne à présent puis quitte mon chroot par :
[pastacode provider= »manual » lang= »bash »]
# umount -a
# exit[/pastacode]
et redémarre sur ma clé USB (modif préalable sous le BIOS pour ce démarrage).
Arf, toujours pas de réseau :(
La bonne nouvelle, c’est que je n’ai plus de paquets cassés et les paquets network-manager apparaissent bien installés sous Synaptic (de la clé USB).
Bizarre, le
[pastacode provider= »manual » lang= »markup »]
$ ping localhost[/pastacode]
fonctionne bien, mais pas le
[pastacode provider= »manual » lang= »bash »]
$ ping goup2net[/pastacode]
qui est le nom de réseau de ma clé USB (défini/écrit dans /etc/hostname).
Je regarde mon fichier /etc/network/interfaces et je vois que les noms des interfaces sont eth2 (pour la connexion vers mon PC internet) et eth3 (pour une connexion ponctuelle vers mon portable via l’autre port réseau de mon PC hôte).
Étonnant, je ne me souviens plus pourquoi je ne commençais pas en eth0 et eth1 sur mon PC planté (la configuration réseau fonctionne sur ce PC).
Pour voir les interfaces actuellement disponibles (Google remplace ma mémoire défectueuse ^^), je lance :
[pastacode provider= »manual » lang= »bash »]
# ifconfig -a[/pastacode]
et il me trouve eth0 et eth1. Ca se précise.
Dans mon fichier /etc/network/interfaces je remplace les occurrences eth2 par eth0 et eth3 par eth1.
J’essaie un :
[pastacode provider= »manual » lang= »markup »]
# /etc/init.d/networking restart[/pastacode]
Mais la commande me retourne qu’elle est elle-même « deprecated » (le problème des OS « vivants » et donc en constante évolution) et le ping goup2net ne fonctionne toujours pas, donc je reboot pour voir.
Ca marche ! Pfiou …
Je vais pouvoir reprendre la rédaction de cette News sur ma clé USB.
Retour à ma situation de ce matin ^^
Cerise sur le gâteau, le :
[pastacode provider= »manual » lang= »bash »]
# mount /var/cache/apt/archives[/pastacode]
sur ma clé USB fonctionne à présent (NFS est opérationnel), Nickel, Synaptic pourra enregistrer ses paquets sur le cache commun de mes PC via ma clé USB (ce qui me permettra à la fois de conserver/récupérer les paquets téléchargés pour le PC hôte et le PC internet et évitera de remplir ma clé USB – qui commence à être limite en taille de stockage).
A la différence que cette fois-ci j’ai sélectionné l’option sous Synaptic de ne pas effacer le cache des paquets :).
Donc, il y a du mieux par rapport à ce matin ^^
Étape suivante : essayer de lancer une application graphique (Synaptic) à partir d’un chroot
Dselect ne me semblant pas adapté pour réparer mon système, j’ai eut l’idée de voir si l’on pouvait utiliser Synaptic en chroot.
Un petit coup de Google et je tombe sur ce forum, qui m’amène à celui-ci (génial).
Je creuserai çà demain.
Dans l’attente j’ai installé sur ma clé USB : IceWm et xnest.
Voilà, j’ai passé un peu de temps à reprendre les tournures de phrases et imprécisions de cette documentation, maintenant je reprend la suite de mes investigations.
Ce matin au démarrage sur ma clé USB j’ai testé IceWm.
C’est super moche, ultra minimaliste (j’ai le même affichage sur les 2 écrans, les jeux proposés sont « Clock » – une horloge très moche et assez peu divertissante ou xeyes dont je n’oserai pas parler ici), mais c’est fonctionnel (en cherchant un peu on y trouve synaptic). La console (xterm) bug un peu (il faut aller dans le menu de configuration pour modifier les couleurs par défaut, valider puis faire ENTRER 1 ou 2 fois sur la console pour voir le curseur et une invite fonctionnelle) mais elle est fonctionnelle après cette manip. L’éditeur proposé est aussi d’un autre âge mais en cherchant dans les menus je retrouve mon nano favori et Konqueror est fonctionnel ainsi que Iceweasel. Ca fera l’affaire si je n’ai que cela.
Je reprend donc mon :
[pastacode provider= »manual » lang= »bash »]
# mount -t ext3 /dev/sda1 /mnt/sda1
# chroot /mnt/sda1
# mount -a
# export LC_ALL=C
# su goupildb
goupildb@goup2net:~$[/pastacode]
(j’ai ajouté les lignes 4 et 5 après avoir lu le forum)
Je tente un :
[pastacode provider= »manual » lang= »markup »]
goupildb@goup2net:~$ env DISPLAY=":2" icewm-session &
[1] 6449
goupildb@goup2net:~$ icewm-session: using /home/goupildb/.icewm for private configuration files
IceWM: using /home/goupildb/.icewm for private configuration files
icewmbg: Can't open display: :2. X must be running and $DISPLAY set.
icewmtray: Can't open display: :2. X must be running and $DISPLAY set.
IceWM: Can't open display: :2. X must be running and $DISPLAY set.
icewmbg: Can't open display: :2. X must be running and $DISPLAY set.
^C
[1]+ Done env DISPLAY=":2" icewm-session[/pastacode]
Ca ne fonctionne pas, j’ai dû faire un Ctrl C pour sortir.
Plusieurs tentatives infructueuses. Je fini par planter la console, donc je la quitte, et recommence.
Autre tentative :
[pastacode provider= »manual » lang= »bash »]
goupildb@goup2net:~$ su root
Mot de passe :
root@goup2net:/home/goupildb# Xnest -ac :2 &
(une fenêtre noir s'ouvre)
goup2net:/# chroot /mnt/sda1
goup2net:/# export LC_ALL=C
goup2net:/# mount -a
goup2net:/# export DISPLAY=127.0.0.1:2
goup2net:/# icewm-session &
[1] 6942
goup2net:/# bash: icewm-session: command not found[/pastacode]
J’avais oublié que le paquet icewm était installé sur ma clé USB, mais pas sur le PC hôte.
[pastacode provider= »manual » lang= »bash »]
goup2net:/# apt-get install icewm icewm-gnome-support
goup2net:/# icewm-session &[/pastacode]
Ca marche !
Le gestionnaire de fenêtre IceWm s’affiche dans la fenêtre Xnest.
Une autre étape importante franchie :)
Sous IceWm du PC hôte via Xnest :
– je teste le navigateur Iceweasel : çà marche, j’accède à internet avec Iceweasel (sauf que je n’ai pas mes onglets habituels).
– Je teste la console xterm. Elle ne fonctionne pas (arf) : « unnamed app(11450): KUniqueApplication: Pipe closed unexpectedly. »
– je teste metacity (proposé dans les menus de IceWm) : bravo, j’ai planté IceWm (je vous passe les messages reçus en console).
Je quitte par un « # exit » en console et je ferme la fenêtre de Xnest à la souris.
Je recommence :
[pastacode provider= »manual » lang= »markup »]
# Xnest -ac :2 &
# chroot /mnt/sda1
# mount -a
# export LC_ALL=C
# export DISPLAY=127.0.0.1:2
# icewm-session &[/pastacode]
Me voilà de retour sous IceWm du PC hôte via Xnest :
– je teste le « Terminal » : plein de messages en console me faisant penser qu’elle va démarrer, mais non elle ne démarre pas.
– je cherche Synaptic, je le trouve dans Programs>Applications>System>Package Management. Je le lance : rien ne s’affiche. En console je reçois les messages :
[pastacode provider= »manual » lang= »bash »]
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
unnamed app(22004): KUniqueApplication: Cannot find the D-Bus session server: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
unnamed app(21999): KUniqueApplication: Pipe closed unexpectedly.[/pastacode]
Arf, c’est pas gagné, en résumé : pas de console dispo et Synaptic plante.
J’effectue un autre test sur une autre console, celui de lancer IceWm via Xnest sur la session de la clé USB :
[pastacode provider= »manual » lang= »bash »]
$ Xnest -ac :3 &
$ export DISPLAY=127.0.0.1:3
$ icewm-session &[/pastacode]
Sur cette session le terminal fonctionne et je peux lancer synaptic (après avoir quitté l’autre Synaptic resté ouvert hors de Xnest) par un :
[pastacode provider= »manual » lang= »bash »]
$ gksu synaptic[/pastacode]
Sauf qu’il faut éviter de quitter IceWm sous Xnest en quittant : çà m’a fermé également ma session actuelle ^^…
J’essaie de nouveau IceWm sous le PC hôte mais avec une variante : lancer xnest, l’export DISPLAY et et IceWm en utilisateur normal au lieu de root :
[pastacode provider= »manual » lang= »bash »]
$ Xnest -ac :2 &
$ su root
# chroot /mnt/sda1
# mount -a
# export LC_ALL=C
# su goupildb
$ export DISPLAY=127.0.0.1:2
$ icewm-session &[/pastacode]
Ca démarre aussi. Mais le terminal refuse toujours de se lancer.
En console j’ai plein de lignes du type « »KConfigIni: In file /status, line 118969: » Invalid entry (missing ‘=’) » ainsi que d’autres messages du type « »KConfigIni: In file /boot/initrd.img-3.14-1-686-pae, line 19958: » Invalid entry (missing ‘=’) « .
Par contre j’ai accès aux autres applications.
J’essaie Kapman : après plein de messages du même type (KConfig et noyau linux), il fini par démarrer.
Super, je peux jouer à Pacman sur mon PC hôte :).
Autre test avec Xnest sans gestionnaire de fenêtre :
[pastacode provider= »manual » lang= »bash »]
$ Xnest -ac :3 &[/pastacode]
J’utilise le 3 car suite à un plantage, le 2 semble être resté en tâche de fond sans fenêtre.
Je récupère ma session précédente chrootée et en utilisateur normal, et lance :
[pastacode provider= »manual » lang= »bash »]
$ export DISPLAY=127.0.0.1:3
$ xeyes[/pastacode]
Ca marche, xeyes se lance dans la fenêtre xnest.
Je quitte xeyes (Ctr C dans la console) et lance kapman :
[pastacode provider= »manual » lang= »bash »]
$ kapman[/pastacode]
ca marche aussi.
Je teste xterm :
[pastacode provider= »manual » lang= »bash »]
$ xterm
xterm: Error 32, errno 2: Aucun fichier ou dossier de ce type
Reason: get_pty: not enough ptys[/pastacode]
Je modifie donc le fichier /etc/fstab du PC hôte et lui ajoute les lignes manquantes :
[pastacode provider= »manual » lang= »bash »]
devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0[/pastacode]
Je quitte et redémarre complètement le PC (pour être sûr que tout soit pris en compte).
Je relance une session à partir de ma clé USB :
Sur une console je lance :
[pastacode provider= »manual » lang= »bash »]
$ Xnest -ac :1 &[/pastacode]
Sur une autre console :
[pastacode provider= »manual » lang= »bash »]
$ su root
Mot de passe :
# mount -t ext3 /dev/sda1 /mnt/sda1
# chroot /mnt/sda1
# mount -a
warning: failed to read mtab
# export DISPLAY=127.0.0.1:1
# su goupil2
bash: data/zeitgeist-daemon.bash_completion: Aucun fichier ou dossier de ce type
$ xterm
xterm: cannot load font '-trad-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'[/pastacode]
Et là xterm fonctionne !
Je tente un :
[pastacode provider= »manual » lang= »bash »]
# gdm stop
# DISPLAY=:2 gnome-session
gnome-session-is-accelerated: No composite extension.
gnome-session-check-accelerated: Helper exited with code 256
gnome-session-is-accelerated: No composite extension.
gnome-session-check-accelerated: Helper exited with code 256
** (process:4848): WARNING **: software acceleration check failed: Child process exited with code 1
Avec un clignotement de la fenêtre Xnest puis un fond d'écran gris avec le message "Oh no! Something has gone wrong. A problem has occured and the system can't recover. PLease log out and try again.[/pastacode](et bouton « Log out ») ». Je clique sur « Log out » et effectivement je reviens à mon écran noir sous Xnest.
Ca ne marche pas mais l’on progresse.
Je tente à nouveau :
[pastacode provider= »manual » lang= »markup »]
# export DISPLAY=127.0.0.1:2
# icewm-session &[/pastacode]
Et là mon xterm fonctionne !
Par contre le « Terminal » sous IceWm ne fonctionne toujours pas, me renvoyant les mêmes erreurs sous la console de ma clé USB.
Sous xterm je lance synaptic : çà marche !
J’ai enfin une configuration qui me permette qui me permette d’installer / désinstaller des paquets plus sereinement sur mon PC hôte (en évitant Dselect).
J’en profite pour poursuivre la mise à jour de mon PC hôte (notamment les paquets en rapport avec l’accélération graphique), en espérant que ds nouvelles mises à jour viennent corriger les bogues précédents …
Résultat : çà ne change rien, même plantage de KDE et Gnome
Testé :
– avec un autre noyau
– en démarrant avec le driver Nouveau et vesa (modif du fichier de configuration de Xorg)
Je redémarre sous la clé USB, j’essaie :
[pastacode provider= »manual » lang= »bash »]
goup2net:/# DISPLAY=:1 gnome-session
gnome-session-is-accelerated: No composite extension.
gnome-session-check-accelerated: Helper exited with code 256
gnome-session-is-accelerated: No composite extension.
gnome-session-check-accelerated: Helper exited with code 256
** (process:4426): WARNING **: software acceleration check failed: Child process exited with code 1
** (gnome-session-quit:4496): WARNING **: Couldn't connect to session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Could not connect to the session manager[/pastacode]
Serait-ce l’accélération graphique qui serait cassée ?
Je remonte l’historique d’installation des paquets et trouve un autre bug :
L’installation des paquets dans une même version donnée est listé plusieurs fois et dans la même veine, des paquets non installés sont signalés comme installés, exemple :
evolution-data-server (3.8.5-3) to 3.12.1-1
evolution-data-server-common (3.8.5-3) to 3.12.1-1
J’ai tenté d’installer ces paquets mais j’ai du y renoncer car ils sont signalés comme ayant des bogues de gravité « grave ».
Lorsqu’arrive cette situation et que vous refusez l’installation, l’historique de Synaptic les a déjà enregistré comme installés avant même d’attendre la fin de l’installation. De ce fait l’historique est erroné.
Ca ne facilite pas l’interprétation des résultats : pas facile de savoir ce qui avait été réellement installé à la date du plantage.
En creusant la piste de l’accélération graphique plantée ou des paquets susceptibles de m’offrir ces réjouissances dans la période j’obtiens la petite liste suivante :[pastacode provider= »manual » lang= »bash »]
dbus (1.8.0-1) to 1.8.2-1
dbus-x11 (1.8.0-1) to 1.8.2-1
libdbus-1-3 (1.8.0-1) to 1.8.2-1
libdbus-1-dev (1.8.0-1) to 1.8.2-1
linux-headers-3.14-1-686-pae (3.14.2-1)
linux-headers-3.14-1-common (3.14.2-1)
linux-image-3.14-1-686-pae (3.14.2-1)
linux-kbuild-3.14 (3.14-1)
nvidia-kernel-3.14-1-686-pae (331.67+1+1+3.14.2-1)
nvidia-kernel-686-pae (331.67+3.13+1) to 331.67+3.14+1
module-init-tools (16-1) to 17-1[/pastacode]
J’ai bien envie de commencer par nvidia-kernel-686-pae.
Néanmoins avant cela, çà me donne une idée, je teste le lancement de glxgears dans la console xterm :
[pastacode provider= »manual » lang= »bash »]
# glxgears[/pastacode]
(pas besoin de le lancer en root, mais comme j’y étais déjà …)
glxgears fonctionne de manière saccadée (via Xnest tout de même) mais il fonctionne avec en moyenne 1200 FPS, il semble donc y avoir de l’accélération graphique.
Sauf que :
[pastacode provider= »manual » lang= »bash »]
# glxinfo
name of display: localhost:1
display: localhost:1 screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event,
GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
(...)[/pastacode]
Je vous passe le reste des messages. Donc « direct rendering: No ».
Donc, finalement « nvidia-kernel-686-pae » me parait être un bon candidat au retour dans une version antérieure :)
Je reprend ma ligne : nvidia-kernel-686-pae (331.67+3.13+1) to 331.67+3.14+1
L’ancien paquet (331.67+3.13+1) n’étant plus dans mon cache d’apt, je le télécharge ici et le copie dans ce même cache et lance sur ma console chrooté :
[pastacode provider= »manual » lang= »bash »]
# cd /var/cache/apt/archives
# dpkg -i --force-overwrite nvidia-kernel-686-pae_331.67+3.13+1_i386.deb
dpkg : avertissement : dégradation (« downgrade ») de nvidia-kernel-686-pae depuis 331.67+3.14+1 vers 331.67+3.13+1
(Lecture de la base de données... 761354 fichiers et répertoires déjà installés.)
Preparing to unpack nvidia-kernel-686-pae_331.67+3.13+1_i386.deb ...
Unpacking nvidia-kernel-686-pae (331.67+3.13+1) over (331.67+3.14+1) ...
Paramétrage de nvidia-kernel-686-pae (331.67+3.13+1) ...[/pastacode]
Puis je reboot pour voir …
Ca ne marche pas davantage. :(
En console chrootée – je précise, je lance :
[pastacode provider= »manual » lang= »bash »]
# modprobe nvidia
modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/3.2.0-4-686-pae/modules.dep.bin'
modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/3.2.0-4-686-pae/modules.dep.bin'
modprobe: ERROR: ../libkmod/libkmod-module.c:814 kmod_module_insert_module() could not find module by name='nvidia_current'
modprobe: ERROR: could not insert 'nvidia_current': Function not implemented
/# uname -a
Linux goup2net 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1 i686 GNU/Linux[/pastacode]
Je ne sais pas si ces infos sont vraiment viable en chroot. J’ai effectivement un noyau 3.2.0, mais le dernier installé est un 3.14. Précisons que le noyau actif de ma clé USB est un 3.2.0.
Je suis pourtant bien chrooté, mais on dirait qu’il se référence au noyau de ma clé USB.
A suivre …
2 jours de perte de production. Merci les gars, et bravo pour moi, une fois de plus.
Au programme, 2 choses à voir : l’accélération graphique à rétablir (le problème semble venir de là) et comment marche vraiment le chroot (quand on fait un chroot : qu’est-ce qu’il utilise comme base de noyau : ce n’est pas très clair pour moi).
Étonnant tout de même (raison pour laquelle je n’avais pas pensé à cela) que sans accélération graphique ni KDE ni Gnome ne démarrent (autrefois ils démarraient sans les effets de bureau).
Chroot :
Un coup de Google et j’ai ma réponse sur un forum Debian fr, que je reprend ici : « Un chroot permet d’isoler les différents systèmes de fichiers (et donc tous les services qui utilisent les sockets Unix pour communiquer) mais ça n’isole pas le noyau, le réseau, ou encore les périphériques physiques (/dev/). Si tu veux plus d’isolation il va falloir faire de la virtualisation, pas du chroot… »
Donc si je poursuis la logique (à vérifier à l’utilisation), je ne « pourrais » avoir de l’accélération graphique en chroot que si je dispose sur ma clé USB d’un noyau identique disponible sur mon PC hôte, puisqu’il tentera d’utiliser le driver (nvidia pour mon cas) correspondant au noyau de ma clé.
Si je poursuis encore cette logique, pas/plus de KDE ni Gnome en chroot si un noyau identique n’est pas disponible. Heureusement il reste encore des petits trucs basiques (et moches, mais pour un dépannage, sa valeur est inestimable) comme IceWm pour accéder à Synaptic.
Reste que dans mon cas actuel, j’ai aussi sur mon PC hôte un noyau 3.2.0, donc en théorie çà devrait marcher. Je vais fouiller un peu.
FAUX, ce n’est pas le même noyau :) Sur mon PC hôte le noyau 3.2.0 est en fait un (/mnt/sda1/lib/modules/)3.2.0-2-686-pae alors que sur ma clé USB j’ai un 3.2.0-4 :
[pastacode provider= »manual » lang= »bash »]
$ uname -a
Linux goup2net 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1 i686 GNU/Linux[/pastacode]
Ces sous-versions de noyaux ne sont pas disponibles très longtemps dans les dépôts Debian Sid.
Si j’applique la logique précédente, pour pouvoir pousser le dépannage dans ses « derniers retranchements graphiques », il faut donc veiller à conserver un noyau identique à la fois sur votre PC susceptible de tomber en panne et sur votre clé USB de dépannage.
Reste que je pourrais installer le dernier noyau sur ma clé USB, mais pour l’instant je ne prendrai pas le risque de planter celle-ci, tant que je n’aurais pas réparé mon système hôte.
Autre possibilité : installer le noyau 3.2.0-4-686-pae sur mon système hôte : il est encore disponible sur le site de Debian :)
N’ayant peur de rien (planté pour planté) j’ai bien envie de tenter l’expérience de l’installer en chroot pour le fun :).
Bon, d’après le site il a 4 dépendances de niveau 1 (elles-mêmes ont probablement des dépendances) : debconf, initramfs-tools (>= 0.99~), kmod (ex module-init-tools) et linux-base (>= 3~). Avec un peu de chance elles seront satisfaites avec mon installation existante.
Allons-y :
[pastacode provider= »manual » lang= »bash »]
# mount -t ext3 /dev/sda1 /mnt/sda1
# chroot /mnt/sda1 # mount -a # mount /var/cache/apt/archives[/pastacode]
Je copie (via konqueror en root) le paquet du noyau (linux-image-3.2.0-4-686-pae_3.2.57-3_i386.deb) dans le cache des paquets /var/cache/apt/archives.
Puis :
[pastacode provider= »manual » lang= »bash »]
# cd /var/cache/apt/archives
# dpkg -i linux-image-3.2.0-4-686-pae_3.2.57-3_i386.deb
Sélection du paquet linux-image-3.2.0-4-686-pae précédemment désélectionné.
(Lecture de la base de données... 761354 fichiers et répertoires déjà installés.)
Preparing to unpack linux-image-3.2.0-4-686-pae_3.2.57-3_i386.deb ...
Unpacking linux-image-3.2.0-4-686-pae (3.2.57-3) ...
Paramétrage de linux-image-3.2.0-4-686-pae (3.2.57-3) ...
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/dkms 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
Error! Your kernel headers for kernel 3.2.0-4-686-pae cannot be found.
Please install the linux-headers-3.2.0-4-686-pae package,
or use the --kernelsourcedir option to tell DKMS where it's located
Error! Your kernel headers for kernel 3.2.0-4-686-pae cannot be found.
Please install the linux-headers-3.2.0-4-686-pae package,
or use the --kernelsourcedir option to tell DKMS where it's located
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
update-initramfs: Generating /boot/initrd.img-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/pm-utils 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/update-notifier 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/zz-extlinux 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
P: Checking for EXTLINUX directory... found.
P: Writing config for /boot/vmlinuz-3.2.0-4-686-pae...
P: Writing config for /boot/vmlinuz-3.2.0-2-686-pae...
P: Writing config for /boot/vmlinuz-3.2.0-1-686-pae...
P: Writing config for /boot/vmlinuz-3.14-1-686-pae...
P: Writing config for /boot/vmlinuz-3.13-1-686-pae...
P: Writing config for /boot/vmlinuz-3.10-3-rt-686-pae...
P: Writing config for /boot/vmlinuz-3.1.0-1-686-pae...
P: Writing config for /boot/vmlinuz-2.6.37-1-686-bigmem...
P: Updating /boot/extlinux/linux.cfg...
Cannot find list of partitions! (Try mounting /sys.)
P: Installing debian theme... done.
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
/usr/sbin/grub-probe : erreur : impossible d'obtenir le chemin canonique de /dev/sda1.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.2.0-4-686-pae.postinst line 696.
dpkg: error processing package linux-image-3.2.0-4-686-pae (--install):
le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
linux-image-3.2.0-4-686-pae[/pastacode]
Arf, oui : il me manque le kernel-header.
Je recommence la manip en copiant celui-ci au même endroit.
:) Il dépend de linux-headers-3.2.0-4-common (lien au même endroit). J’installe donc d’abord celui-là via dpkg puis linux-headers-3.2.0-4-686-pae après les avoir copié dans le cache des paquets :
[pastacode provider= »manual » lang= »bash »]
# dpkg -i linux-headers-3.2.0-4-common_3.2.57-3_i386.deb
Sélection du paquet linux-headers-3.2.0-4-common précédemment désélectionné.
(Lecture de la base de données... 770945 fichiers et répertoires déjà installés.)
Preparing to unpack linux-headers-3.2.0-4-common_3.2.57-3_i386.deb ...
Unpacking linux-headers-3.2.0-4-common (3.2.57-3) ...
Paramétrage de linux-headers-3.2.0-4-common (3.2.57-3) ...
# dpkg -i linux-headers-3.2.0-4-686-pae_3.2.57-3_i386.deb
(Lecture de la base de données... 774062 fichiers et répertoires déjà installés.)
Preparing to unpack linux-headers-3.2.0-4-686-pae_3.2.57-3_i386.deb ...
Unpacking linux-headers-3.2.0-4-686-pae (3.2.57-3) over (3.2.57-3) ...
Paramétrage de linux-headers-3.2.0-4-686-pae (3.2.57-3) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.2.0-4-686-pae
Error! Bad return status for module build on kernel: 3.2.0-4-686-pae (i686)
Consult /var/lib/dkms/nvidia/195.36.24/build/make.log for more information.[/pastacode]
Encore une erreur, je vais voir (c’est quand même plus pratique avec une clé USB de dépannage avec un gestionnaire graphique opérationnel et surtout un gestionnaire de fichier, en console c’est plutôt fastidieux de se rendre dans ces sous-répertoires) dans /var/lib/dkms/nvidia/195.36.24/build/make.log
D’ailleurs j’en profite pour lister ici l’arborescence de ce répertoire dkms que je trouve intéressant :
[pastacode provider= »manual » lang= »bash »]
/mnt/sda1/var/lib/dkms/
>/nvidia
-->195.36.24
---->/2.6.32-3-686-bigmem
------->i686
--------->/log
------------>make.log
--------->/module
------------>nvidia.ko
---->/2.6.32-5-686-bigmem
------->i686
--------->/log
------------>make.log
--------->/module
------------>nvidia.ko
---->/build
------->(une liste de fichiers de construction et de configuration)
---->source
>/nvidia-current
---->/331.67
------->/3.2.0-4-686-pae
---------->i686
------------>/log
--------------->make.log
------------>/module
--------------->nvidia-current.ko
------->/3.13-1-686-pae
---------->i686
------------>/log
--------------->make.log
------------>/module
--------------->nvidia-current.ko
------->/3.14-1-686-pae
---------->i686
------------>/log
--------------->make.log
------------>/module
--------------->nvidia-current.ko
------->/build
------->source
---->/kernel-3.2.0-4-686-pae-i686
------->/log
---------->make.log
------->/module
---------->nvidia-current.ko
---->/kernel-3.13-1-686-pae-i686
------->/log
---------->make.log
------->/module
---------->nvidia-current.ko
---->/kernel-3.14-1-686-pae-i686
------->/log
---------->make.log
------->/module
---------->nvidia-current.ko[/pastacode]
Donc qu’y a t il dans ce fichier /var/lib/dkms/nvidia/195.36.24/build/make.log :
[pastacode provider= »manual » lang= »bash »]
DKMS make.log for nvidia-195.36.24 for kernel 3.2.0-4-686-pae (i686)
mardi 6 mai 2014, 11:09:34 (UTC+0200)
make: Entering directory '/var/lib/dkms/nvidia/195.36.24/build'
make -C /lib/modules/3.2.0-4-686-pae/build M=`/bin/pwd` modules
make[1]: Entering directory '/usr/src/linux-headers-3.2.0-4-686-pae'
Makefile:10: *** mixed implicit and normal rules: deprecated syntax
/var/lib/dkms/nvidia/195.36.24/build/Makefile:162: *** Only 2.6.x and later kernels are supported (3.2.57). Arrêt.
/usr/src/linux-headers-3.2.0-4-common/Makefile:1373: recipe for target '_module_/var/lib/dkms/nvidia/195.36.24/build' failed
make[3]: *** [_module_/var/lib/dkms/nvidia/195.36.24/build] Error 2
Makefile:130: recipe for target 'sub-make' failed
make[2]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-3.2.0-4-686-pae'
Makefile:105: recipe for target 'modules' failed
make: *** [modules] Error 2
make: Leaving directory '/var/lib/dkms/nvidia/195.36.24/build'[/pastacode]
La réponse est « *** Only 2.6.x and later kernels are supported (3.2.57). Arrêt. »
Mon noyau est un 3.2.0 donc il devrait satisfaire à ce pré-requis. Mettons cela sur le compte du chroot.
Observations étonnantes (remarqué le lendemain):
– en dépit de l’erreur affichée, dans /nvidia-current/ j’ai bien un répertoire kernel-3.2.0-4-686-pae-i686 (voir l’arborescence ci-dessus, que j’avais eut la bonne idée de lister) avec un module nvidia-current.ko construit.
– le répertoire nvidia/195.36.24/ ne contient que des modules d’anciens noyaux que je n’utilise plus, tandis que le répertoire nvidia-current/331.67/ contient les nouveaux noyaux (dont le 3.13-1-686-pae avec un module nvidia que je sais être fonctionnel)
Je vais retenter ma chance en rebootant sur le PC hôte lui-même (hors chroot).
A présent, au lancement de Synaptic, j’ai un message :
[pastacode provider= »manual » lang= »bash »]
/user/bin/deborphan: Le fichier statut est dans un état impropre.
Un ou plusieurs paquets sont marqués half-installed, half-configured, unpacked, triggers-awaited ou triggers-pending. Fin du programme.
[/pastacode]
Ce qui est normal suite à ma précédente opération.
En console je lance (toujours en chroot) :
[pastacode provider= »manual » lang= »markup »]
# apt-get -f install
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
fonts-lmodern fp-ide-2.6.2 fp-units-db-2.6.2 fp-units-fv-2.6.2 fp-units-gfx-2.6.2 fp-units-math-2.6.2 fp-units-misc-2.6.2 fp-units-multimedia-2.6.2
fp-units-net-2.6.2 lazarus-1.0.10 lazarus-doc-1.0.10 lazarus-ide-1.0.10 lazarus-ide-gtk2-1.0.10 lazarus-src-1.0.10 lcl-1.0.10 lcl-gtk2-1.0.10
lcl-units-1.0.10 lcl-utils-1.0.10 liballegro-dialog5.0 libart-2.0-dev libatk-bridge2.0-dev libbonobo2-dev libcanberra-gtk-common-dev libdts-dev
libforms-dev libforms2 libgd-dev libgnome2-dev libgnomevfs2-dev libgraphviz-dev libhd16 libjim0debian2 liblsmash0 libmodemmanagerqt0 libmodplug-dev
libnetworkmanagerqt0 liborbit2-dev libpoppler37 libqscintilla2-9 libselinux1-dev libsepol1-dev libvpx-dev libx265-7 libxaw7-dev libxkbcommon-dev
libzeitgeist-1.0-1 lmodern orbit2
Veuillez utiliser « apt-get autoremove » pour les supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1838 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Paramétrage de linux-image-3.2.0-4-686-pae (3.2.57-3) ...
Running depmod.
vmlinuz(/boot/vmlinuz-3.2.0-4-686-pae
) points to /boot/vmlinuz-3.2.0-4-686-pae
(/boot/vmlinuz-3.2.0-4-686-pae) -- doing nothing at /var/lib/dpkg/info/linux-image-3.2.0-4-686-pae.postinst line 268.
initrd.img(/boot/initrd.img-3.2.0-4-686-pae
) points to /boot/initrd.img-3.2.0-4-686-pae
(/boot/initrd.img-3.2.0-4-686-pae) -- doing nothing at /var/lib/dpkg/info/linux-image-3.2.0-4-686-pae.postinst line 268.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/dkms 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
Error! Bad return status for module build on kernel: 3.2.0-4-686-pae (i686)
Consult /var/lib/dkms/nvidia/195.36.24/build/make.log for more information.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
update-initramfs: Generating /boot/initrd.img-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/pm-utils 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/update-notifier 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
run-parts: executing /etc/kernel/postinst.d/zz-extlinux 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
P: Checking for EXTLINUX directory... found.
P: Writing config for /boot/vmlinuz-3.2.0-4-686-pae...
P: Writing config for /boot/vmlinuz-3.2.0-2-686-pae...
P: Writing config for /boot/vmlinuz-3.2.0-1-686-pae...
P: Writing config for /boot/vmlinuz-3.14-1-686-pae...
P: Writing config for /boot/vmlinuz-3.13-1-686-pae...
P: Writing config for /boot/vmlinuz-3.10-3-rt-686-pae...
P: Writing config for /boot/vmlinuz-3.1.0-1-686-pae...
P: Writing config for /boot/vmlinuz-2.6.37-1-686-bigmem...
Cannot find list of partitions! (Try mounting /sys.)
P: Installing debian theme... done.
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.2.0-4-686-pae /boot/vmlinuz-3.2.0-4-686-pae
/usr/sbin/grub-probe : erreur : impossible d'obtenir le chemin canonique de /dev/sda1.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.2.0-4-686-pae.postinst line 696.
dpkg: error processing package linux-image-3.2.0-4-686-pae (--configure):
le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
linux-image-3.2.0-4-686-pae
E: Sub-process /usr/bin/dpkg returned an error code (1)[/pastacode]
Pour résoudre le problème, il faudra que je recommence la manip hors du chroot sur le PC hôte lui-même.
Le message « /usr/sbin/grub-probe : erreur : impossible d’obtenir le chemin canonique de /dev/sda1. » semble vouloir signifier qu’il n’est pas possible (actuellement) d’installer un noyau Linux en chroot du fait que grup-probe tente d’accéder au périphérique du disque de démarrage et qu’il n’y parvient pas en chroot.
Je redémarre hors chroot et reprend cela.
Redémarrage du PC.
J’ai relançé mon :
[pastacode provider= »manual » lang= »markup »]
# apt-get -f install[/pastacode]
Et il est parvenu à achever l’installation du noyau 3.2.0-4 sans erreur.
Ce qui semble confirmer une fois de plus l’impossibilité (actuelle) d’installer un noyau en chroot.
C’est bien dommage – notamment si le noyau de votre clé USB ne correspond à aucun des noyaux du noyau à dépanner : vous ne pourrez pas faire de tests graphiques.
J’en ai aussi profité pour lancer :
[pastacode provider= »manual » lang= »markup »]
# apt-get -autoremove[/pastacode]
Pour retirer les paquets inutiles ou que je n’utilise que peu (j’avais installé précédemment fp et lazarus, pour rédiger les fiches correspondantes dans le Bottin).
Et puis çà réduit la taille des messages affichés en console lors d’un apt-get.
De retour sur ma clé USB, je teste via mon chroot (voir ci-avant pour la méthode) un glxinfo sous Icewm : même chose, pas de rendu fonctionnel avec mon noyau 3.2.0 (« direct rendreing: No »).
Je regarde dans /mnt/sda1/var/lib/dkms/nvidia/195.36.24/ je n’ai toujours que d’anciens noyaux, tandis que dans /mnt/sda1/var/lib/dkms/nvidia-current/331.67/, j’ai toujours mon répertoire 3.2.0-4-686-pae/
Je regarde le fichier /mnt/sda1/var/lib/dkms/nvidia/195.36.24/build/make.log :
[pastacode provider= »manual » lang= »bash »]
DKMS make.log for nvidia-195.36.24 for kernel 3.2.0-4-686-pae (i686)
mercredi 7 mai 2014, 09:21:44 (UTC+0200)
make: Entering directory '/var/lib/dkms/nvidia/195.36.24/build'
make -C /lib/modules/3.2.0-4-686-pae/build M=`/bin/pwd` modules
make[1]: Entering directory '/usr/src/linux-headers-3.2.0-4-686-pae'
Makefile:10: *** mixed implicit and normal rules: deprecated syntax
/var/lib/dkms/nvidia/195.36.24/build/Makefile:162: *** Only 2.6.x and later kernels are supported (3.2.57). Arrêt.
/usr/src/linux-headers-3.2.0-4-common/Makefile:1373: recipe for target '_module_/var/lib/dkms/nvidia/195.36.24/build' failed
make[3]: *** [_module_/var/lib/dkms/nvidia/195.36.24/build] Error 2
Makefile:130: recipe for target 'sub-make' failed
make[2]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-3.2.0-4-686-pae'
Makefile:105: recipe for target 'modules' failed
make: *** [modules] Error 2
make: Leaving directory '/var/lib/dkms/nvidia/195.36.24/build'[/pastacode]
Je suis plutôt étonné d’y trouver le même type d’erreur alors que l’installation du noyau ne l’a pas signalé.
Je retourne sur mon PC hôte vérifier que ce noyau 3.2.0-4 et le module nvidia fonctionnent (avec un modprobe nvidia).
Réponse :
Le noyau 3.2.0-4 fonctionne, le module nvidia est chargé (lsmod l’affiche), un modprobe nvidia ne signale aucune erreur
Curieusement – j’ai certainement raté des épisodes notamment avec l’arrivée de dkms, d’après mes recherches dans /lib/modules/, le module nvidia n’y est plus stocké.
Je viens de m’apercevoir – je ne m’en rappelais plus, que ma clé USB n’utilise pas le driver nvidia mais le driver nouveau (avec une accélération graphique fonctionnelle), et pas de fichier /etc/X11/xorg.conf, mais des scripts (tout fonctionne y compris l’affichage double écrans).
Pour rappel : »Un chroot permet d’isoler les différents systèmes de fichiers (et donc tous les services qui utilisent les sockets Unix pour communiquer) mais ça n’isole pas le noyau, le réseau, ou encore les périphériques physiques (/dev/). Si tu veux plus d’isolation il va falloir faire de la virtualisation, pas du chroot… ».
Je comprend mieux pourquoi l’accélération graphique ne peut pas fonctionner sur mon PC hôte en chroot à partir de ma clé USB : utilisant le driver Nouveau, le PC hôte ne peut pas trouver le driver nvidia spécifié dans son fichier /etc/X11/xorg.conf.
Nouveau test : changer le driver « nvidia » par « nouveau » dans /mnt/sda1/etc/X11/xorg.conf (j’avais déjà prévu l’option dans ce fichier, il me suffit de commenter et décommenter les lignes correspondantes + commenter les options en rapport avec nvidia).
Je tente un :
[pastacode provider= »manual » lang= »markup »]
# startx
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
(EE)
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
No protocol specified
xinit: giving up
xinit: unable to connect to X server: Resource temporarily unavailable
xinit: server error
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
[/pastacode]
Bon , çà ne marche pas pour un problème soit d’autorisation soit de conflit avec le server X extérieur au chroot.
Visiblement il tente d’utiliser le serveur X extérieur au chroot, car j’ai bien un /tmp/kde-goupildb/xauth-1000-_0 mais pas de /mnt/sda1/tmp/kde-goupildb/.
Une piste intéressante (trouvée sur le net) à suivre pour le chroot :
[pastacode provider= »manual » lang= »markup »]
# mount --bind /dev /mnt/sda1/dev/
# mount --bind /sys /mnt/sda1/sys/
# mount --bind /proc /mnt/sda1/proc/
# chroot /mnt/sda1
# mount -a
# export DISPLAY=localhost:1
# startx : --1
mktemp: impossible de créer le fichier à partir du modèle « /tmp/serverauth.XXXXXXXXXX »: Système de fichiers accessible en lecture seulement
xauth: error in locking authority file
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
xauth: error in locking authority file /tmp/kde-goupildb/xauth-1000-_0
[/pastacode]
Ca ne marche pas mieux, mais il me semble que je n’ai n’ai plus certaines erreurs.
J’ai tenté aussi :
[pastacode provider= »manual » lang= »markup »]
$ Xnest -ac :2 &
# export DISPLAY=localhost:2
# DISPLAY=:2 gnome-session
gnome-session-is-accelerated: No composite extension.
gnome-session-check-accelerated: Helper exited with code 256
gnome-session-is-accelerated: No composite extension.
gnome-session-check-accelerated: Helper exited with code 256
** (process:30839): WARNING **: software acceleration check failed: Child process exited with code 1[/pastacode]
Même message avec gnome : çà ne marche pas.
Une bonne doc sur Debian fr : Chroot, trouvée en passant.
Il semble nécessaire d’avoir sur le système chrooté les lignes suivantes dans /etc/fstab :
[pastacode provider= »manual » lang= »bash »]
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
devpts /dev/pts devpts defaults 0 0[/pastacode]
Les commandes bind sont également confirmées, ce qui nous donne une procédure de chroot semblable à celle-ci :
[pastacode provider= »manual » lang= »bash »]
$ Xnest -ac :1 &
# mount -t ext3 /dev/sda1 /mnt/sda1
# mount --bind /dev /mnt/sda1/dev/
# mount --bind /sys /mnt/sda1/sys/
# mount --bind /proc /mnt/sda1/proc/
# chroot /mnt/sda1
# mount -a
# export DISPLAY=localhost:1
[/pastacode]
Néanmoins pour l’instant, je n’arrive pas à lancer le serveur X sur le chroot, j’ai essayé les commandes :
[pastacode provider= »manual » lang= »bash »]
# xhost +
# startx : --1[/pastacode]
Si l’on insiste un peu trop avec startx, il finit par planter la console et par bloquer /mnt/sda1 en lecture seule.
Donc j’abandonne provisoirement l’idée d’un démarrage du serveur X en chroot à partir de ma clé de dépannage, d’autant que IceWm répond de façon minimaliste mais fonctionnelle à mes besoins.
J’avais déjà testé avec succès plusieurs sessions X via Xnest sur un même système d’exploitation, mais à partir d’un chroot d’une clé USB de dépannage ne semble pas à ma portée.
Retour à mon chroot et Synaptic (voir ci-avant pour la méthode) pour voir si des paquets en rapport avec le noyau ou l’accélération graphique ne sont pas disponibles. Avant l’autre étape envisagée : celle de désinstaller presque tout ce qui a un rapport avec nvidia et de réinstaller tout çà dans l’ordre.
J’essaie l’installation de paquets, il ne parvient pas à télécharger les informations de bogues, je vais faire un tour sur l’adresse indiquée et je trouve cette page : Système de suivi des bogues Debian. Punaise, va falloir être patient : on approche les 80000 bugs, en augmentation régulière. C’est comme partout, il y a plus de gens à se plaindre (comme moi) que de gens à les corriger.
Néanmoins je pense que ces 80 000 bugs doivent être une valeur cumulée des rapports reçus, sinon Debian ne sortirait pas une version stable tous les ans.
Bon rien de probant à mettre à jour. Je passe à l’étape suivante.
Accélération graphique :
Étape suivante : je désinstalle à peu près tout ce qui s’appelle nvidia et veut bien se désinstaller sans me désinstaller la moitié de ma distribution et réinstalle le minimum nécessaire.
Ca me fais une belle petite liste :
nvidia-kernel-common
glx-alternative-nvidia
nvidia-alternative
nvidia-vdpau-driver
nvidia-installer-cleanup
nvidia-kernel-source
nvidia-support
nvidia-settings
nvidia-xconfig
nvidia-driver
libnvidia-ml1
libgl1-nvidia-glx
nvidia-glx
libnvtt2
libvdpau1
libvdpau-dev
libxnvctrl0
nvidia-kernel-3.14-1-686-pae
nvidia-kernel-dkms
Synaptic semblant avoir quelques soucis (plantage avec la liste), je le fais à la main à coup de « apt-get remove –purge nomdupaquet
Voilà, c’est fait, de ma liste il ne me reste que : libnvtt2 et libvdpau1 (dépendances externes et je ne pense pas qu’ils me créent des soucis ceux-là).
Je réinstalle nvidia :
J’ai déjà :
linux-headers-3.14-1-common
linux-headers-3.14-1-686-pae
dkms
J’installe :
nvidia-kernel-dkms
Par ses dépendances il m’installe :
glx-alternative-mesa
glx-alternative-nvidia
glx-diversions
libgl1-nvidia-glx
libnvidia-ml1
libxnvctrl0
nvidia-alternative
nvidia-driver
nvidia-installer-cleanup
nvidia-kernel-common
nvidia-modprobe
nvidia-settings
nvidia-support
nvidia-vdpau-driver
xserver-xorg-video-nvidia
Soit à peu près tous les précédents plus d’autres :)).
Mais pour éviter tout souci avec la compilation, je vais installer nvidia-kernel-dkms sans chroot en redémarrant le système hôte.
Allons-y.
Ca ne marche toujours pô :).
Résumé des manips :
Après avoir redémarré sur le système hôte (en direct), j’ai lancé un :
[pastacode provider= »manual » lang= »bash »]
# apt-get install nvidia-kernel-dkms[/pastacode]
Il a tout réinstallé sous soucis en recompilant sans erreur affichée un driver nvidia pour le noyau 3.14 et m’a proposé de redémarrer (détectant le driver nouveau en mémoire), ce que j’ai fais.
Au redémarrage, même plantage de KDE ou Gnome.
J’ai eut ensuite l’idée de tester le renommage de /etc/X11 en /etc/X11-sv (pour vérifier s’il n’y aurait pas un souci avec mon ancien paramétrage qui ne fonctionnerait plus avec les nouvelles versions).
Je tente, X11 ne redémarre pas. Je lance un :
[pastacode provider= »manual » lang= »bash »]
# apt-get install --reinstall xserver-xorg[/pastacode]
et redémarre : j’ai l’écran de gdm puis pareil, aucune session kde ou gdm icewm ne fonctionne.
Donc à priori ce n’est pas non plus mon fichier xorg.conf le fautif.
Du coup j’ai emis en place son répertoire /etc/X11
Je teste aussi le démarrage à partir d’un autre noyau en recompilant un nouveau driver adapté via la même commande ;
[pastacode provider= »manual » lang= »bash »]
# apt-get install nvidia-kernel-dkms[/pastacode]
Ne marche pas non plus : même plantage de KDE.
J’essaie de voir si j’ai de l’accélération graphique, mais la commande glxinfo nécessite un serveur X.
Mon système d’exploitation (Xorg + KDE ou Gnome) nécessite de l’accélération graphique pour fonctionner (le gnome safe ne fonctionne pas davantage) mais s’il ne démarre pas j’ai besoin de vérifier si l’accélération graphique fonctionne, mais il faudrait pour cela un système d’exploitation, etc… C’est balo non ? :)) (vaut mieux en rire)
Peut-être une piste ici : Bugzilla – Bug 75723
Un bug apparu à partir du noyau 3.14 avec Mesa.
Quoi qu’il en soit chez moi çà ne fonctionne pas davantage avec mes autres noyaux.
J’ai aussi testé une nouvelle fois la désinstallation complète des paquets nvidia pour tenter ma chance avec le driver Nouveau (j’ai aussi changé xorg.conf). Comme çà ne fonctionnait pas j’ai aussi tenté une nouvelle fois le renommage de /etc/X11 et de réinstaller xserver-xorg et xserver-xorg-nouveau : après un redémarrage j’arrive à une nouvelle mire gdm que je ne connaissais pas (assez sympa) mais çà plante aussi avec KDE.
J’ai réinstaller nvidia et tenté de renommer ~.kde au cas où la nouvelle version aurait un souci avec les précédents fichiers de configuration de kde : pas d’amélioration.
Je commence à sécher.
Je reprend ma petite liste précédente :[pastacode provider= »manual » lang= »bash »]
dbus (1.8.0-1) to 1.8.2-1
dbus-x11 (1.8.0-1) to 1.8.2-1
libdbus-1-3 (1.8.0-1) to 1.8.2-1
libdbus-1-dev (1.8.0-1) to 1.8.2-1
linux-headers-3.14-1-686-pae (3.14.2-1)
linux-headers-3.14-1-common (3.14.2-1)
linux-image-3.14-1-686-pae (3.14.2-1)
linux-kbuild-3.14 (3.14-1)
nvidia-kernel-3.14-1-686-pae (331.67+1+1+3.14.2-1)
nvidia-kernel-686-pae (331.67+3.13+1) to 331.67+3.14+1
module-init-tools (16-1) to 17-1[/pastacode]
Prochain candidat probable : dbus
A suivre …
A priori dbus 1.8.2 ne semble pas être le bon candidat, car lorsque je vais sur le site de Debian, je constate qu’il a déjà rejoint la prochaine version Jessie (testing).
Ce matin j’ai plutôt envie de mettre à jour le maximum de paquets en versions intermédiaires. Avec un peu de chance, l’un d’entre eux débloquera la situation.
J’ai tenté de lancer dolphin en chroot via xterm, le système se met à biper sans arrêt et manque de planter le système. Finalement je parviens à fermer xterm et çà s’arrête. Je reçois alors un mesage KDialog « Le fichier de configuration ~.kde/share/config/dolphinrc » n’est pas inscriptible. Veuillez contacter votre administrateur système ». Ca tombe bien c’est moi, commandant bitchel, mon système est enrhumé ! :)
Je tape Ok et Dolphin démarre mais il ne parvient à lire aucun répertoire et un message dans Dolphin affiche « Le processus traitant le protocole files s’est arrêté de façon inattendue ».
Il semble il y a voir un problème de communication des application. Ca fait vraiment penser à un souci avec Dbus.
Je vais quand même tester une ancienne version de celui-ci.
Dans un premier temps, sous Synaptic en chroot je sélectionne – via le filtre dbus, tous les paquets déjà installé en rapport avec dbus et je demande soit leur mise à jour soit leur réinstallation.
A la mise à jour j’ai un message « Gconf-WARNING **: Client failed to connect to the D-BUS daemon : Did not recieve a reply. Possible cause include: the remote application did not send e reply, … ».
Tout çà sent vraiment le souci avec D-BUS.
La mise à jour du paquet soit pa r Synaptic soit par un :
[pastacode provider= »manual » lang= »bash »]
# apt-get install libpam-systemd[/pastacode]
(toujours en chroot impliquant aussi l’installation de systemd-sysv et la mise à jour de systemd , sysvinit et d’autres plante sur une Erreur de segmentation. Je vais tenter de mettre çà à jour en redémarrant sur le système hôte.
Arf, çà plante aussi à partir du système hôte. Ca ne sent pas bon.
L’installation de :
[pastacode provider= »manual » lang= »bash »]
# apt-get install systemd-sysv[/pastacode]
plante aussi sur une Erreur de segmentation.
Ca pue :)
Bonne nouvelle (enfin j’espère) :
[pastacode provider= »manual » lang= »bash »]
# apt-get remove libpam-systemd[/pastacode]
ne plante pas.
Il m’enlève aussi network-manager, plasma-nm et plasma-widget-networkmanagement.
J’espère que je vais encore avoir du réseau. Je vais redémarrer pour vérifier çà (je voulais déjà virer network-manager précédemment mais l’avais remis car plus de réseau mais j’avais aussi un problème de configuration du réseau).
Je redémarre.
Au redémarrage avec un :
[pastacode provider= »manual » lang= »bash »]
# apt-get update systemd-sysv[/pastacode]
me confirme (que le système démarre, que KDE ne marche toujours pas et) que j’ai encore du réseau, donc network-manager ne m’est pas indispensable j’en ai la confirmation.
J’essaie de réinstaller libpam-systemd pour voir, mais même plantage sur une erreur de segmentation.
Idem pour systemd-sysv.
Ce dernier proposant la mise à jour de libsystemd-daemon0, libsystemd-journal0, libsystemd-login0 et systemd, je tente de mettre à jour manuellement systemd avec apt-get.
Ca marche, et en plus il me met les autres (libsystemd-daemon0, libsystemd-journal0, libsystemd-login0) à jour également.
Je tente à nouveau avec systemd-sysv : il me propose la mise à jour de sysvinit mais plante sur l’erreur de segmentation.
Je tente ma chance avec sysvinit : çà marche, et il m’installe aussi sysvinit-core.
Je retente systemd-sysv : cette fois-ci il m’enlève sysvinit-core (faudrait savoir :), mais il s’installe sans planter sur son erreur de segmentation :).
Je retente libpam-systemd : çà marche ! :)
Je redémarre pour voir.
Mon KDE est toujours planté.
A tout hazard, j’ai l’idée de lancer startx au lieu d’un « # /etc/init.d/gdm restart » et je passe sous Gnome !
Tout à l’air de fonctionner (libreoffice, shotwell, le gestionnaire de fichiers de Gnome). Même si l’odre d’affichage des écrans n’est pas le bon (ce n’est pas bien méchant à corriger).
Un net progrès !
Par contre si je lance gnome via gdm par mon « # /etc/init.d/gdm restart » j’ai le même symptôme (écrans gris-noir vides avec le curseur de souris fonctionnel sur les 2 écrans mais rien n’est accessible.
Ce pourrait-il que ce soit une saloperie de bug avec gdm3 ? J’avais bien vu qu’il y avait un bug signalé mais ne l’avait pas mis à jour.
Quoi qu’il en soit il y avait aussi un bug avec sysvinit (les erreurs de segmentation çà n’est pas normal).
J’essaie :
[pastacode provider= »manual » lang= »bash »]
# /etc/init.d/gdm stop
# /etc/init.d/kdm restart[/pastacode]
J’ai le même écran que si j’étais sous gdm, pourtant un Ctrl Alt F1 m’affiche la console avec le message « Restarting kdm (via systemctl): kdm.service. »
Bizarre comme comportement.
Je découvre systemctl sur cette doc du site linuxcore.fr.
J’essaie :
[pastacode provider= »manual » lang= »bash »]
# systemctl start gdm[/pastacode]
çà ne marche pas, mais :
[pastacode provider= »manual » lang= »bash »]
# systemctl restart gdm[/pastacode]
démarre gdm mais gnome plante comme avec /etc/init.d/gdm.
J’installe aussi xdm, un autre gestionnaire de démarrage.
Il me propose de choisir mon système de démarrage parmi gdm gdm3 kdm ou xdm
Je choisi kdm pour voir puis lance :
[pastacode provider= »manual » lang= »markup »]
# systemctl restart kdm[/pastacode]
mais il ne se passe rien et pas de message. En fait il est déjà ouvert sur gdm sur la console Ctrl Alt F7. je ferme par :
[pastacode provider= »manual » lang= »bash »]
# /etc/init.d/gdm stop[/pastacode]
Puis relance :
[pastacode provider= »manual » lang= »markup »]
# /etc/init.d/kdm restart[/pastacode]
Cette fois-ci j’ai une jolie mire de Kdm.
Je saisi mon mot de passe et me connecte : cette fois-ci j’ai le splashscreen de KDE mais elle semble rester bloquée. Je clique et obtient le message « Le fichier de configuration ~.kde/share/config/knotifyrc n’est pas inscriptible. Veuillez etc… ».
Gros gros progrès. A priori ce n’est pas méchant, je vais redémarrer et si ce n’est pas résolu je vais aller voir le répertoire (lors de mes manips de copies en root j’ai peut-être passé le répertoire avec les droits root).
Au reboot même message de kde avec son splashscreen.
J’ai un autre compte (que je n’ai pas modifié) je tente avec ce second compte :
Il met un peu de temps puis m’affiche une fenêtre de migration et enfin m’affiche KDE !!!! Yeeees !
Ca commence à être bon :).
Je lance une console avec glxinfo : « direct rendering : Yes »
Yes
Ca sent meilleur :)
Via Konqueror en root je jette un oeil dans mon ~ et vois .kde avec le propriétaire root, donc pas de souci, je change çà en console avec un :
# chown -R goupil2:gpgoup .kde
et quitte ma cession pour tenter celle de goupil2 (mais je suis plutôt confiant).
Je passe à mon compte :
Même attente (près de 40 secondes interminables) pas de fenêtre de migration apparente mais tout remarche !!!
Encore Yeeees !
Allez j’me lache un peu : « Put…, j’en aurai ch… ! » (avec un poil d’auto-censure, c’est un site à vocation publique quand même :)
Je reprend la rédaction sur mon ex-PC planté :)
Je viens de tester un reboot suivi d’un démarrage avec gdm3 (après avoir lancé un « # dpkg -reconfigure gdm » pour sélectionner gdm3). : çà marche aussi.
Je viens de tester un reboot suivi d’un démarrage avec gdm : il est toujours planté (affichage du bureau et curseur de souris, c’est tout) : ce qui m’avait induit en erreur !
Quelques observations :
- après mise à jour de sysvinit et consorts, le système semble légèrement plus rapide à démarrer jusqu’à une brève invit de saisie (console), puis passe par un écran noir suivi de la mire nvidia, un écran noir, et enfin gdm3 ou kdm.
- néanmoins après saisie du mot de passe de connexion (sous gdm3 ou kdm), KDE est beaucoup plus long à démarrer et même après son splashscreen, le bureau met plus de temps à s’afficher (laissant penser – qu’à la manière de windows, une partie des services sont démarrés plus tard en tâche de fond). Au total, après saisie du mot de passe de connexion sous gdm3 ou kdm, KDE n’est opérationnel qu’après près d’une minute (testé sur plusieurs démarrages).
Résumé pendant que c’est frais (en faisant abstraction de mes erreurs personnelles) :
- A la mise à jour de Debian Sid (grosse mise à jour fin de semaine dernière), gdm – le gestionnaire de démarrage que j’utilisais par défaut, ne fonctionne plus. Le bug est d’autant plus pernicieux que gdm semble fonctionner mais visiblement il ne parvient pas à lancer correctement ni gnome ni KDE qui plantent tous deux. Gdm n’ayant pas été mis à jour, il semble que ce soit des mises à jour effectuées sur KDE et GNOME qui induisent ce dysfonctionnement. Pour contourner ce bug il suffit d’activer (par un « # dpkg reconfigure gdm » qui propose alors de choisir le gestionnaire de démarrage par défaut parmi les gestionnaires que vous aviez installé) par exemple gdm3 (gdm3 ne peut être installé actuellement – suite à un bug important, mais si vous l’aviez déjà installé et non mis à jour, il fonctionne) ou kdm (à installer par un « # apt-get install kdm »)
- Toujours dans cette même mise à jour de Debian Sid, un bug (d’apt-get ?) à la mise à jour de paquets importants comme systemd-sysv, sysvinit, systemd et libpam-systemd. Ce bug se manifeste à la mise à jour de l’un de ces paquets par un plantage sur une Erreur de segmentation (visiblement un dysfonctionnement d’apt-get qui ne parvient pas à ordonner la mise à jour de ces paquets). La résolution s’effectue en installant manuellement (« # apt-get install nomdupaquet ») un à un les paquets dont ils dépendent (opération assez rapide, les dépendances à mettre à jour étant peu nombreuses et indiquées lors de l’apt-get des paquets pré-cités).
J’aurais bien galéré sur ce coup là.