Mais LINUX vient d’UNIX qui rime avec PHENIX :)
Toujours là, mais encore sur ma clé USB :))
Encore ! Penserons certains …
Non, cette fois-ci ce n’est pas mon PC habituel de rédaction du Bottin qui est planté, mais l’autre – celui qui lui fourni internet.
Tout a commencé vendredi quand Louis a voulu l’utiliser pour aller sur Youtube : un petit souci en apparence anodin avec Youtube, une clé de chiffrage non valide. Youtube signalait aussi que nous devions utiliser un navigateur internet compatible avec ses nouvelles fonctionnalités.
Tout cela semblait censé, j’utilise iceweasel mais dans une version antédiluvienne puisque ce PC sous Linux Debian n’avait pas été mis à jour depuis des lustres (5 ans, 6 ans, 7 ans ?).
Sur mon autre PC à jour, Youtube fonctionne bien.
J’ai essayé tout ce qui me passait par la tête :
– accepter l’exception de sécurité (au début il ne proposait pas l’option et puis il a fini par l’accepter, mais çà ne m’a permis que d’arriver sur une page blanche toute moche de Youtube, sans vidéo avec des liens et un message me demandant de passer à un navigateur compatible),
– quitter iceweasel, renommer mon répertoire ~.mozilla, et redémarrer le navigateur (même résultat)
– tester d’autres navigateurs (arora, chromium) : même résultat
– installer la dernière version de firefox directement depuis leur site : c’est plus beau, çà démarre mais toujours pas de vidéo.
Bref, visiblement ce n’était pas tant le navigateur que les bibliothèques qu’il allait falloir rafraîchir.
Ce que je craignais depuis un bout de temps.
En même temps l’expérience est plutôt intéressante : tenter de mettre à jour une très vieille distrib sans tout reformater (ce qui serait vraisemblablement plus rapide).
Sous Synaptic çà donne un truc comme : je clique sur la mise à jour de ce paquet, et il me propose la désinstallation de KDE, Gnome et tout un tas de paquets. Bof. Pas très enthousiaste à cette proposition.
Il faut donc y aller par petites touches, trouver les points faibles de ce rempart (les paquets qui non seulement acceptent de se mettre à jour, mais permettent la mise à jour d’autres paquets sans désinstaller la moitié de la distrib), accepter la désinstallation temporaire de certains, tout en essayant de préserver au maximum l’intégrité du système.
La difficulté sur une telle distribution (ancienne) est qu’aptitude (qui lui aussi est dans une ancienne version avec des dépendances qui ne me permette pas de le mettre à jour dans l’immédiat) ne parvient généralement pas à résoudre ces dépendances (après quelques minutes il s’arrête sur un dépassement de délai, je valide pour une nouvelle tentative et puis après quelques essais je laisse tomber). Et quand il y arrive, dans la moitié des cas ses propositions ne sont pas acceptables (trop de trucs à désinstaller).
Finalement synaptic m’aura été plus utile sur cet ancien système, d’autant qu’il n’aura que très peu planté (sur mon autre PC dont la distrib est à jour en Sid, dès que çà devient un peu compliqué pour lui, il casse (virtuellement) le paquet – son icône devient rouge, et il ne reste plus qu’à relancer synaptic).
Concernant la mise à jour : J’y suis presque parvenu.
# apt-get -f install ne me donne plus d’erreurs
j’ai un système qui démarre jusqu’à l’invit de mot de passe
Ni Xorg, ni Gdm3, ni kdm ne démarrent (c’est donc tristoune, et surtout fastidieux) mais je peux lancer des commandes
Plus critique : je n’ai plus d’accès à internet :(
Un PC Linux sans internet (d’autant s’il est incomplètement installé), c’est mort – d’où mon titre :)
J’ai vérifié les fichiers de config, je ne trouve pas d’erreur pour l’instant (en même temps il y a peu de raison puisque çà fonctionnait avant, mais je redoutais qu’un script validé un peu vite ait remplacé un fichier de config réseau.
Heureusement ma clé USB fonctionne aussi sur ce PC avec – cerise sur le gâteau, l’accès à internet : génial.
Par contre pour cette clé USB aussi, youtube ne fonctionne pas, çà n’est pas important, mais çà confirme qu’il y a donc bien eut une nouvelle version de Youtube qui génère des incompatibilités, avec les précédentes versions Linux, car cette clé à tout au plus 6 mois – 1 an.
Pour le problème réseau, j’ai aussi suspecté mon firewall, car guarddog n’existe plus dans les dépôts Debian (il a cessé d’être mis à jour depuis 2007 sur le site de l’auteur – c’est dire l’ancienneté de mon installation). J’ai renommé le fichier /etc/rc.firewall mais toujours pas de réseau
j’ai testé le routage (# route) et les interfaces (# ifconfig) et constate que l’interface reliée à ma Freebox n’est pas activée par défaut (un # ifconfig eth1 inet up m’affiche l’interface eth1 via # ifconfig et fait clignoter la box, mais toujours pas d’internet). J’avais biensûr dès le début vérifié les adresses DNS : elles étaient correctes.
J’ai d’autres pistes en tête : tenter de poursuivre la mise à jour en chroot (il y a peut-être un paquet dans une ancienne version qui pose problème avec le réseau). Faut juste que je déverrouille un peu /etc/securetty de l’autre côté, car pour l’instant le chroot ne fonctionne pas :).
J’ai aussi beaucoup de messages d’anomalies affichés avec udev au démarrage. A voir si ce n’est pas lui qui pose problème.
Bon voilà ce matin j’en suis là.
A suivre …
J’avance bien, je suis assez optimiste sur la suite.
Comme d’habitude avec ce type de manip, j’ai encore appris des choses : sur le chroot pour cet exercice.
Jusqu’ici je montais la partition root cible, puis je chrootais dessus et ce n’est qu’après cette étape que je montais les autres partitions dessus.
Mais ici çà ne marchais pas (il n’y avait quasiment rien dans /dev, et le montage des partitions via un # mount -a ne fonctionnait pas). J’ai effectué une petite recherche sur le net (vive la clé USB) et suis tombé sur cette doc : Chroot From Installation Media (merci aux gens de Slackware !).
J’ai donc révisé ma méthode :
Je créé le répertoire /mnt/sda1 pour y monter ma clé (bizarrement le chroot n’a pas fonctionné sur /media/usb0)
Je monte ma cible dessus (/dev/sda1 contient le « / » du disque à réparer) : # mount -t ext3 /dev/sda1 /mnt/sda1
Je chroot dessus : # chroot /dev/sda1
Je monte le /usr sur mon arborescence root déportée (/dev/sda6 contient le « /usr » du disque à réparer) :
# mount -t ext3 /dev/sda6 /mnt/sda1/usr
Idem pour le /home : # mount /dev/sda5 /mnt/sda1/home
J’oubliais, le remontage des périphériques systèmes en cours de fonctionnement :
le remontage de /dev, le répertoire des périphériques, /proc, celui des process et /sys celui des fichiers du noyau et autres :
# mount -o bind /dev /mnt/sda1/dev
# mount -o bind /proc /mnt/sda1/proc
# mount -o bind /sys /mnt/sda1/sys
(très honnêtement je les ai oublié les premières fois et çà fonctionnait quand même)
Et ce n’est qu’à ce moment que je chroot dessus : # chroot /dev/sda1
Puis je monte /dev/pts (m’évite d’avoir des erreurs lors de l’installation des paquets) : # mount /dev/pts
Ensuite çà fonctionne nickel : # apt-get update me télécharge la liste des paquets, FAUX (nota à posteriori) : ce qui m’indique que ma config réseau était bonne.
Nota à posteriori : =>J’avais oublié, mais en chroot on utilise les périphériques du système source et non pas ceux du système à dépanner. Donc si on a du réseau, çà ne veux pas dire que la configuration du système à dépanner est bonne (si la clé USB fourni du réseau, çà fonctionnera sur le PC à dépanner même si la config réseau n’est pas bonne).
Je poursuis donc l’installation.
Seule erreur : en reprenant l’installation des paquets, j’ai installé le paquet network-manager qui m’a effacé le contenu de /etc/resolv.conf
J’ai donc désinstallé network-manager (je me demande à quoi il sert celui-là) et ai réinitialisé les 2 lignes nameserver (adresse des serveurs DNS de Free) :
nameserver 212.27.40.240
nameserver 212.27.40.241
Indices importants je pense :
les paquets avahidaemon, dnsmasq-base, dnsutils, libavahi-client3, libavahi-common-data n’étaient pas/plus installés.
Or je pense qu’avahi est nécessaire pour la connexion en DHCP avec la box, en tout cas c’est ainsi que je l’avais paramétré sous /etc/network/interfaces :
auto eth1
allow-hotplug eth1
iface eth1 inet dhcp
(…) (mes 2 autres interfaces réseaux sont en IP fixe)
Et udev ainsi que gdm3 étaient restés dans une ancienne version
Je suis entrain de mettre tout cela à jour à partir de ma clé USB
A suivre …
Je suis parvenu à mettre à jour aptitude, udev, gdm3, dolphin avec kde, j’ai installé mate, je vais tenter gnome.
Ca y est, c’est déverrouillé, j’ai trouvé le sésame :)
Restera à voir si tout cela démarre tout à l’heure.
Ca y est, gnome est aussi dans la boite. En cela c’est mieux que sur mon autre PC : je suis parvenu à faire cohabiter (enfin je pense) : GNOME, KDE et MATE.
Sur mon autre PC l’installation de l’un (MATE) m’empêche d’installer les autres.
La solution à mon avis est d’autoriser la désinstallation de MATE (au moins provisoirement) pour installer KDE puis GNOME et ensuite de réinstaller MATE (c’est en gros ce que j’ai fais ici).
Reste à finir l’installation et à redémarrer (j’en profite pour écrire pendant que çà s’installe)
Suite …
Excès d’optimisme de ma part.
Récapitulatif :
– Après toutes ces mises à jour, j’ai redémarré. Ca redémarre.
– mais toujours pas de réseau
– ni gdm3 ni kdm ne parvient à démarrer Xorg
– nvidia, nouveau et vesa ne fonctionnent pas plus l’un que l’autre
Arf :(
J’ai quelques pistes / indices :
Côté graphisme : au démarrage j’arrive à lire dans les messages : un problème d’insertion du module nvidia. Je pense qu’il faudrait que je recompile un module nvidia (vu toutes les bibliothèques mises à jour, c’est peut-être un souci de compatibilité, voir des bibliothèques à installer)
Côté réseau : au démarrage j’ai aussi un message du type « Network is unreachable ». J’ai essayé un :
# /etc/init.d/networking restart
(il me dit que c’est deprecated, mais ne me propose pas d’alternative)
qui m’indique :
RTNETLINK answers: No such process
failed to bring up eth1
J’ai aussi tenté d’ajouter une route à la mano avec un : # route add -net …
Je reçois le message : SIOCADDRT: le réseau n’est pas accessible.
De même que précédemment : # ifconfig
affiche les 2 autres interfaces réseau (eth0 et eth2) mais pas celle de la box : eth1
Et # ifconfig eth1 inet up
suivi d’un # ifconfig
affiche l’interface eth1 (et le voyant de la box clignote) mais toujours pas de réseau fonctionnel.
Je poursuis mes recherches …
Quelques indices intéressants :
J’avais paramétré ma clé USB avec les paramètres réseau de mon autre PC, donc j’étais un peu étonné que le réseau fonctionne. J’ai donc regardé par curiosité comment elle était paramétrée et relevé quelques infos en passant :
effectivement, c’est un peu n’importe quoi mais çà marche :)
Un # route me donne :
default 192.168.0.254 0.0.0.0 … eth3
192.168.0.0 * 255.255.255.0 eth3
alors que /etc/network/interfaces ne défini pas eth3
Ca semble se configurer en IP fixe quand même.
Un # ifconfig sur la clé USB me donne :
eth2 (plein de paramètres mais pas d’IP fixe)
eth3 inet adr:192.168.0.10 masque : 255.255.255.0
eth4 (plein de paramètres mais pas d’IP fixe)
Retour sur mon disque en chroot (je ne ré-écrit pas la procédure ci-dessus).
Un # apt-get update fonctionne
# route
/proc/net/route: Aucun fichier ou dossier de ce type
INET (IPv4) pas configuré sur ce système.
(il me semblait que j’étais en ipv6, c’est ce qui est indiqué dans /etc/hosts :
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
Surprenant que la route ne fonctionne pas alors que j’ai du réseau lorsque je suis en chroot
=> j’ai compris : je n’avais pas suivi à la lettre la doc slackware (corrigé ci-dessus) en ne montant pas les périphériques virtuels de /dev, /sys et /proc.
Du coup une fois remonté :
# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 192.168.0.254 0.0.0.0 UG 0 0 0 eth3
192.168.0.0 * 255.255.255.0 U 0 0 0 eth3
Et ifconfig me donne à présent les mêmes résultats en chroot qu’avec la clé USB.
Donc toujours en IP fixe :)
J’avais oublié, mais en chroot on utilise les périphériques du système source et non pas ceux du système à dépanner.
Côté graphisme, pour ma carte nvidia, j’ai lancé la commande : # m-a a-i nvidia-kernel-source
qui me met à jour quelques paquets (binutils build-essential cpp dpkg-dev g++ gcc libdpkg-perl libgcc1 libitm1 libquadmath0 patch) et en installe quelques autres (cpp-5 g++-5 gcc-5 libasan2 libcc1-0 libcilkrts5 libgcc-5-dev libisl15 libmpx0 libstdc++-5-dev libubsan0).
(pour mémo, il m’a suggéré nvidia-driver mais je ne l’ai pas installé, j’en n’ai jamais eut besoin à ma connaissance)
La 1ere fois il échoue parce que j’avais oublié le # mount /dev/pts
Je le monte et relance la commande : il a réussi sa compilation du module.
Il y a des chances que çà marche mieux la prochaine fois côté Xorg.
Mais je n’ai toujours pas résolu mon problème de réseau.
Recherche problème réseau.
Une recherche sur le net m’indique que le message « RTNETLINK answers: No such process » est un message type indiquant -si j’ai bien compris, que le réseau n’est pas trouvé. Ca ne fait pas avancer le shmili :)
Je vais tester le graphisme pour voir :)
————————————————————————————
Suite le 25 janvier (après le boulot) :
Je n’ai pas beaucoup progressé.
Côté graphisme :
le module créé n’a pas fonctionné
J’ai installé un autre noyau (le dernier en dépôt Sid : 4.3.0-1-686-pae, il fonctionne bien) et recompilé un module nvidia toujours avec la commande :
# m-a a-i nvidia-kernel-source
J’obtiens un message « Le paquet nvidia-kernel source n’a pas pu être construit, voir /var/cache/modass/nvidia-kernel-source*buildlog* pour plus de détail »
J’ai examiné le fichier (assez pénible au clavier de se retaper toute l’arborescence à la main, de surcroît avec un nom de fichier à rallonge)
Je n’ai pas appris grand-chose de plus. J’ai l’impression que la compilation s’est bien passée mais qu’il y a un truc qui empêche le module de se charger.
Un # modprobe nvidia
me donne : « modprobe:ERROR could not insert ‘nvidia’: operation not permitted »
Il me semble avoir eut un message de choix lors de la mise à jour des paquets me donnant le choix entre les drivers libres ou nvidia. J’ai dû vraisemblablement sélectionner libre. C’est balo je ne me souviens plus quel était le titre de la fenêtre de choix (faut dire que cette fenêtre s’est ouverte parmi d’autres lors du déroulement des mises à jour).
J’ai aussi relevé au démarrage « (…) nvidia_current:Error(…) » ou un truc comme çà
Et je n’ai pas installé nvidia-driver il me semble. A voir aussi s’il n’y a pas d’autres paquets nécessaires pour nvidia qui auraient été désinstallés.
Encore des tas de trucs à creuser.
Voilà c’est fait :
A partir de ma clé USB j’ai installé le fameux paquet nvidia-driver (+ les paquets qu’il m’a suggéré, en lancant plusieurs fois l’apt-get) :
# apt-get install nvidia-driver nvidia-settings libgles1-nvidia libgles2-nvidia nvidia-persistenced nvidia-settings
(l’avantage du démarrage avec la clé USB c’est que je suis sous KDE et peut donc recopier facilement les commandes à la souris en les surlignant, au lieu de devoir les taper une à une. Dommage que la souris ne fonctionne pas avec les consoles texte sans Xorg. C’est pourtant possible, je l’ai déjà testé quand je programmais autrefois)
En console j’obtiens les messages (fenêtre bleu) :
Conflit avec le module « nouveau »
Le pilote graphique actuellement utilisé est le module libre « nouveau ». Il entre en conflit avec le module non libre « nvidia ».
La manière la plus simple pour corriger cela est de redémarrer la machine une fois l’installation terminée.
A ben voilà, on y arrive :)
(pourtant j’ai aussi testé le driver nouveau via ma config /etc/X11/xorg.conf et il ne fonctionnait pas)
C’est le driver nouveau qui mettait la zone :)
Côté réseau :
Ca ne marche pas davantage (de manière classique).
J’ai du réseau sur ce PC si je commente les lignes sous /etc/network/interfaces :
#auto eth1
#allow-hotplug eth1
#iface eth1 inet dhcp
Au démarrage suivant je me retrouve avec du réseau et une interface en eth3 il me semble. Vous allez dire : mais voilà c’est çà ! Et non çà ne me conviens pas. C’est moche comme méthode et çà ne me donne pas de réseau sur mon PC avec le Bottin.
J’ai aussi eut l’idée de changer le nom du fichier /etc/network/interfaces et de redémarrer pour le laisser choisir ses interfaces et ensuite les écrire dans ce même fichier.
Ca ne marche pas. Il ne prend pas eth3 pour interface de la box comme avec la clé USB, il prend eth1, rien que pour m’emmerder :)
Il me reste à creuser la config de DHCP.
Je ne comprend pas pourquoi çà ne marche plus alors que je n’ai pas changé la config de ce PC.
Je vais creuser de ce côté là.
Après quelques lectures sur le net, je pense que le souci réseau pourrais venir du fait que j’ai installé un dhcp de trop :)
La box fourni elle-même le DHCP, je n’avais pas besoin d’installer de DHCP supplémentaire (je ne me souvenais en effet pas d’avoir installé et configuré un serveur DHCP sous Linux, en dehors du paramètre du fichier /etc/network/interfaces je n’avais donc rien touché). Ce qui expliquerai le message d’anomalie du serveur DHCP au démarrage.
Je désinstalle donc ce serveur DHCP (il est vraisemblable que ce 2nd serveur DHCP non configuré génère des soucis) via :
# apt-get remove –purge dhcp3-common
# apt-get remove –purge dhcp3-client
Voilà j’ai terminé mes commandes sous ma clé USB. Je m’en vais tester tout çà en redémarrant depuis le disque dur.
Je vous tiendrai au courant demain.
————————————————————————————
Le 26 Janvier
En résumé : de gros progrès, mais encore beaucoup de zones sombres.
J’écris depuis MATE sous l’ex PC en panne, sous Debian Sid avec la dernière version dispo, et sous la dernière version de Iceweasel sous laquelle Youtube fonctionne.
Grande victoire pour moi, je suis assez satisfait.
Mais,
je n’ai plus de son sur ce PC, je n’ai plus de réseau sur le PC d’à côté (sur lequel je rédige Le Bottin), et le driver nvidia ne fonctionne toujours pas.
Et je ne suis pas super satisfait du paramétrage de mon réseau.
En résumé :
J’ai commencé par le réseau.
La manip d’hier ne fonctionne toujours pas.
Pour avancer, j’ai provisoirement commenté – comme précédemment, les lignes relatives à l’interface eth1 sur laquelle se trouve ma box. C’est moche, c’est du provisoire, çà ne permet visiblement pas d’avoir du réseau sur mon autre PC (pour l’instant je ne sais fichtrement pas pourquoi) mais sans réseau c’est difficile d’avancer. Un problème après l’autre.
Donc voilà j’ai du réseau moche sur ce PC (à résoudre dans un 2ème temps).
Ensuite côté graphisme :
En allant voir si ce n’était pas le driver nouveau qui empêchait le driver nvidia de se charger, j’ai involontairement trouvé comment faire marcher le driver nouveau. C’est balo mais c’est comme çà.
Un # lsmod
ne m’affichait pas le driver nouveau
Du coup j’ai eut l’idée de lancer un : # modeprobe nouveau
Et là le graphisme est passé de 80 caractères à plus (160 ?, je n’en sais rien).
Du coup j’ai changé le paramétrage du serveur Xorg pour qu’il utilise le driver nouveau (dans /etc/X11/xorg.conf) à la place de nvidia.
J’ai redémarré avec kdm : # /etc/init.d/kdm restart
(il me semble que j’ai essayé avec gdm3 aussi mais n’en suis pas sûr, et du coup j’ai changé avec un # dpkg-reconfigure kdm pour changer de gdm3 à kdm que j’avais précédemment installé)
Ca n’a pas marché : j’avais kdm mais pas de clavier ni de souris, tout était bloqué
J’ai redémarré puis tenté ma chance en installant xdm et même manip pour le changement de kdm à xdm et démarrage : idem c’était bloqué.
Là je me suis dit que c’était peut-être un souci de périphérique clavier non installé / désinstallé sous Xorg. Coup de bol, je me souvenais de son nom : evdev.
Un # apt-cache search -n evdev
m’a fourni son petit nom de scène, j’ai donc lancé un :
# apt-get install xserver-xorg-input-evdev
Bingo, le paquet s’installe, donc c’est qu’il avait bien été dés-installé lors du processus de mise à jour (via des soucis de dépendances entre paquets).
xdm étant super moche et pas pratique, je remet kdm et lance (# /etc/init.d/kdm restart), choisi MATE (parce qu’il me dit qu’il y a des soucis avec un KDE incomplet) : re-bingo, me voilà sous MATE.
J’ai lancé iceweasel 43.0.4 avec Youtube : çà marche mais pas de son. Ca ne doit pas être trop compliqué, je pense que je vais faire comme sur mon autre PC : installer Pulseaudio.
Donc en résumé : j’ai un réseau moche, et j’utilise nouveau au lieu de nvidia.
Pas vraiment ce que j’avais prévu, mais je progresse bien. Pfiouuuu …
N’empêche : le module nouveau ne se charge pas tout seul, c’est pas trop normal (à creuser aussi éventuellement).
Si je lançais un : # /etc/init.d/kdm restart
en ayant sélectionné le driver nouveau dans /etc/X11/xorg.conf, çà ne lançait pas Xorg.
Par contre en chargeant au préalable le module (par # modeprobe nouveau) çà marche.
A vérifier si çà le fait toujours en redémarrant ou si il faut à chaque fois charger ce module (ce qui serait pénible).
Tiens, encore de l’occupation en perspective (je suis maudit, c’est pas possible) :
j’avais hâte de retrouver mon synaptic, j’ai tenté de le lancer mais il fini par planter.
J’ai donc essayé de le réinstaller (ou du moins la dernière version, l’autre est peut-être ancienne et n’est plus compatible), j’obtiens :
# apt-get install synaptic
Lecture des listes de paquets… Erreur !
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/ftp2.fr.debian.org_debian_dists_sid_main_binary-i386_Packages
E: Les listes de paquets ou le fichier « status » ne peuvent être analysés ou lus.
Super :)
A suivre : ne manquez pas le prochain épisode de mon épopée Linuxienne :)
————————————————————————————
Le 27 Janvier
J’ai fini plus tard au boulot (19h chez moi), la soirée va être courte, et mes pérégrinations Linuxiennes aussi.
Bon, je me suis inquiété pour pas grand chose avec les messages ci-dessus (« Lecture des listes de paquets… Erreur ! »).
J’ai bien cru qu’il s’agissait du fichier des paquets installés.
Mais non. Il aura suffit de copier tout le contenu de /var/lib/apt/lists/ dans un répertoire séparé (sauvegarde au cas où) et de relancer Synaptic, pour que tout rentre dans l’ordre.
Tout va bien : synaptic démarre maintenant sans message d’anomalie.
Par contre vous allez rire : ce soir quand je lance DuckDuckGo, Google ou Youtube : j’ai un message du type « Cette connexion n’est pas certifiée » :)
Tout çà pour en revenir au point de départ ou presque (çà marche moins bien maintenant, mais c’est plus à jour).
Bon, je plaisante, je préfère la situation actuelle même si elle est encore un peu bancale.
J’avais de toute façon l’intention d’en passer par là même si çà ne résoudra peut-être pas le problème : réinitialiser complètement les comptes utilisateurs en créant de nouveaux répertoires de comptes manuellement.
Je pense en effet que l’on peut récupérer une ancienne installation Linux pour la mettre à jour (c’était aussi un peu mon intention de vous en faire la démonstration ici) sans devoir tout reformater, par contre il me semble judicieux de réinitialiser les répertoires de comptes utilisateurs qui finissent par être encombrés de fichiers obsolètes de configuration d’applications qui peuvent nuire au bon fonctionnement de ces mêmes applications une fois mises à jour.
STOP : la manip ci-dessous n’a pas fonctionné ! Prudence :)
Il suffit simplement de créer des répertoires vierges dans le /home avec les mêmes noms et droits en lecture/écriture que précédemment. A chaque nouveau démarrage d’une application, celle-ci viendra y copier ses fichiers de configuration.
Mode opératoire :
Je quitte Xorg
Je me connecte en root
Je me place dans le /home
Je sauvegarde provisoirement (1 mois ou 2) les anciens comptes que je renomme nom_du_compte-sv (pour venir y récupérer éventuellement d’anciennes sauvegardes – tel que les bookmarks dans ~.mozilla/)
Je créé les répertoires vierges avec les mêmes noms que précédemment (noms d’utilisateurs)
Je leur donne les mêmes droits en lecture/écriture et la même appartenance au groupe/utilisateur
Je redémarre Xorg : c’est prêt (enfin, en principe).
Je viens de tester ce soir : çà ne marche plus :(
Je l’ai déjà fait et çà marchait. Mais force est de constater que ce soir çà ne fonctionne pas.
Je vais creuser le sujet.
Nota en passant :
Je viens d’effectuer la vérif sous Synaptic : xserver-xorg-video-nouveau est bien installé et dans sa dernière version. J’avais pensé que peut-être il ne l’était pas et que çà aurait été la raison pour laquelle le driver nouveau ne se chargeait pas automatiquement au lancement de Xorg.
Dans l’immédiat je n’ai donc pas d’explication pour le non chargement automatique de nouveau.
Je reprend ici ma manip sur les répertoires de comptes utilisateurs :
J’ai quitté Xorg (Ctrl Alt F1 puis # /etc/init.d/kdm stop)
J’ai sauvegardé l’ancien compte : # mv monnom monnom-sv
J’ai créé un répertoire vierge avec le nom de l’utilisateur : # mkdir monnom
Je lui ai donné la même appartenance : chown monnom:mongroupe monnom
Et les mêmes droits (lecture/écriture pour l’utilisateur, rien pour les autres) : chmod 700 monnom
Je redémarre : # /etc/init.d/kdm restart
Je me connecte avec le compte monnom
Et il plante :) Zut
J’ai essayé de voir des différences en me connectant avec un autre compte : je n’en vois pas. De plus il a initialisé quelques répertoires.
————————————————————————————
Le 28 Janvier
Petite surprise en redémarrant manuellement ce soir : kdm + nouveau ne redémarrait plus. Gloups.
En fait çà s’est résolu rapidement :
# apt-get update
# apt-get install xserver-xorg-video-nouveau
Et effectivement il m’a proposé la mise à jour de plusieurs paquets en rapport avec Xorg.
Une fois la mise à jour terminée, j’ai lançé un : # /etc/init.d/kdm restart
Et hop, çà a marché, me revoilà sous Xorg.
Hier en toute fin de session j’avais en effet tenté de résoudre les soucis de certificats en filtrant les paquets sous Synaptic mentionnant le terme « certificate » pour les mettre à jour. J’ai mis à jour ces paquets et installé 3 ou 4 autres qui me semblaient en rapport. Mais ça na pas résolu mon souci (de certificats) (je précise parce que la liste des p’tits trucs qui ne marchent pas commence à s’allonger, je risque de vous perdre en chemin ^^).
J’en avais aussi profité pour mettre à jour / installer quelques paquets en rapport avec xorg (-joystick, …) sans me douter que çà ne démarrerait plus ce soir. Bon voilà Xorg est à nouveau opérationnel.
Ce soir je m’attaque à la mise à jour de tous les paquets de la section « nouvelle version amont du logiciel » sous Synaptic. Maintenant que ce dernier est lui aussi opérationnel, çà devrait aller nettement plus vite.
Le constat provisoire est qu’il me restait encore une sacré quantité de paquets à mettre à jour.
L’autre constat est que le système de paquets est totalement déverrouillé : lorsque je sélectionne de gros batchs de paquets à mettre à jour, il ne me propose plus de désinstaller de grosses quantités de paquets en contre-partie. Ca c’est super agréable.
Pas trop étonnant qu’il y ait encore des trucs plus ou moins bizarres qui se passent : des versions antédiluviennes de paquets discutent avec des versions très récentes : ils ne doivent pas toujours se comprendre :)
Par contre je risque aussi d’avoir quelques surprises au prochain redémarrage.
A suivre …
————————————————————————————
Le 29 Janvier
Effectivement, la surprise n’est pas très bonne, au redémarrage voici le message laconique reçu :
Welcome to GRUB!
error: symbol ‘grub_term_highlight_color’ not found
Entering rescue mode
grub rescue>
En gros, il ne trouve pas la variable ‘couleur de surlignage de grub’, donc il se met en mode sauvegarde
aka démerdes-toi pour la suite, j’attends tes commandes :)
Direction ma clé USB pour tenter un # apt-get -f install
puis un : # apt-get install grub2
La 1ere commande n’annonce pas de souci particulier
La 2nde installe la dernière version de grub2
Dépaquetage de grub2 (2.02~beta2-35)
J’ai testé l’installation des autres paquets grub (grub2-common, grub-pc-bin, grub-pc) : ils étaient déjà dans la dernière version.
A noter que la toute récente version de grub2 installée sur mon autre PC est la 2.02~beta2-33.
Il y a donc eut encore une nouvelle version.
Redémarrage …
Idem : même message.
Retour à la clé USB.
Je vais tenter de trouver sur Debian la 2.02~beta2-33 et l’installer en remplacement de la 2.02~beta2-35.
Voilà, la 2.02~beta2-33 n’étant pas disponible, j’ai jeté mon dévolu sur la version 2.02~beta2-22 (la version stable du moment, aka Jessie). Ca me donne les paquets :
grub2_2.02~beta2-22+deb8u1_i386.deb
grub2-common_2.02~beta2-22+deb8u1_i386.deb
grub-common_2.02~beta2-22+deb8u1_i386.deb
grub-pc-bin_2.02~beta2-22+deb8u1_i386.deb
grub-pc_2.02~beta2-22+deb8u1_i386.deb
Pas sûr qu’ils soient tous indispensables, mais ils sont installés sur mon autre PC, je fais pareil.
Je les copie (avec nautilus monté en root via gksu nautilus, c’est plus pratique) de ma clé USB vers le /var/cache/apt/archives/ du disque dur à réparer (pas indispensable de les copier là, mais tant qu’à les mettre quelque-part, autant qu’ils soient avec les autres).
Reste à trouver dans quel ordre ça s’installe, dpkg va nous le dire.
Une fois le chroot effectué (voir ci-avant, je ne re-détaille pas) :
# cd /var/cache/apt/archives/
# dpkg -i –force-overwrite grub2_2.02~beta2-22+deb8u1_i386.deb
dpkg : avertissement : dégradation (« downgrade ») de grub2 depuis 2.02~beta2-35 vers 2.02~beta2-22+deb8u1
(Lecture de la base de données… 920722 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de grub2_2.02~beta2-22+deb8u1_i386.deb …
Dépaquetage de grub2 (2.02~beta2-22+deb8u1) sur (2.02~beta2-35) …
dpkg: des problèmes de dépendances empêchent la configuration de grub2 :
grub2 dépend de grub-pc (= 2.02~beta2-22+deb8u1) ; cependant :
La version de grub-pc sur le système est 2.02~beta2-35.
grub2 dépend de grub-common (= 2.02~beta2-22+deb8u1) ; cependant :
La version de grub-common sur le système est 2.02~beta2-35.
dpkg: erreur de traitement du paquet grub2 (–install) :
problèmes de dépendances – laissé non configuré
Des erreurs ont été rencontrées pendant l’exécution :
grub2
Bon, c’était pas celui-là le 1er :)
# dpkg -i –force-overwrite grub-pc-bin_2.02~beta2-22+deb8u1_i386.deb
dpkg : avertissement : dégradation (« downgrade ») de grub-pc-bin depuis 2.02~beta2-35 vers 2.02~beta2-22+deb8u1
(Lecture de la base de données… 920722 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de grub-pc-bin_2.02~beta2-22+deb8u1_i386.deb …
Dépaquetage de grub-pc-bin (2.02~beta2-22+deb8u1) sur (2.02~beta2-35) …
dpkg: des problèmes de dépendances empêchent la configuration de grub-pc-bin :
grub-pc-bin dépend de grub-common (= 2.02~beta2-22+deb8u1) ; cependant :
La version de grub-common sur le système est 2.02~beta2-35.
dpkg: erreur de traitement du paquet grub-pc-bin (–install) :
problèmes de dépendances – laissé non configuré
Des erreurs ont été rencontrées pendant l’exécution :
grub-pc-bin
Pas celui-là non plus :)
# dpkg -i –force-overwrite grub-common_2.02~beta2-22+deb8u1_i386.deb
dpkg : avertissement : dégradation (« downgrade ») de grub-common depuis 2.02~beta2-35 vers 2.02~beta2-22+deb8u1
(Lecture de la base de données… 920722 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de grub-common_2.02~beta2-22+deb8u1_i386.deb …
Dépaquetage de grub-common (2.02~beta2-22+deb8u1) sur (2.02~beta2-35) …
Paramétrage de grub-common (2.02~beta2-22+deb8u1) …
Installation de la nouvelle version du fichier de configuration /etc/grub.d/00_header …
Installation de la nouvelle version du fichier de configuration /etc/grub.d/05_debian_theme …
Installation de la nouvelle version du fichier de configuration /etc/grub.d/30_uefi-firmware …
Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) …
Voilà le 1er …
# dpkg -i –force-overwrite grub-pc-bin_2.02~beta2-22+deb8u1_i386.deb
(Lecture de la base de données… 920722 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de grub-pc-bin_2.02~beta2-22+deb8u1_i386.deb …
Dépaquetage de grub-pc-bin (2.02~beta2-22+deb8u1) sur (2.02~beta2-22+deb8u1) …
Paramétrage de grub-pc-bin (2.02~beta2-22+deb8u1) …
Et de 2 …
# dpkg -i –force-overwrite grub-pc_2.02~beta2-22+deb8u1_i386.deb
dpkg : avertissement : dégradation (« downgrade ») de grub-pc depuis 2.02~beta2-35 vers 2.02~beta2-22+deb8u1
(Lecture de la base de données… 920722 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de grub-pc_2.02~beta2-22+deb8u1_i386.deb …
Dépaquetage de grub-pc (2.02~beta2-22+deb8u1) sur (2.02~beta2-35) …
dpkg: des problèmes de dépendances empêchent la configuration de grub-pc :
grub-pc dépend de grub2-common (= 2.02~beta2-22+deb8u1) ; cependant :
La version de grub2-common sur le système est 2.02~beta2-35.
dpkg: erreur de traitement du paquet grub-pc (–install) :
problèmes de dépendances – laissé non configuré
Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) …
Des erreurs ont été rencontrées pendant l’exécution :
grub-pc
Bon voilà, j’ai ma réponse : il les faut tous :)
# dpkg -i –force-overwrite grub2-common_2.02~beta2-22+deb8u1_i386.deb
dpkg : avertissement : dégradation (« downgrade ») de grub2-common depuis 2.02~beta2-35 vers 2.02~beta2-22+deb8u1
(Lecture de la base de données… 920722 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de grub2-common_2.02~beta2-22+deb8u1_i386.deb …
Dépaquetage de grub2-common (2.02~beta2-22+deb8u1) sur (2.02~beta2-35) …
Paramétrage de grub2-common (2.02~beta2-22+deb8u1) …
Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) …
Traitement des actions différées (« triggers ») pour install-info (6.0.0.dfsg.1-4) …
Et de 3 …
# dpkg -i –force-overwrite grub-pc_2.02~beta2-22+deb8u1_i386.deb
# dpkg -i –force-overwrite grub2_2.02~beta2-22+deb8u1_i386.deb
Bon, j’espère que je n’ai rien oublié : je redémarre, non sans avoir au préalable quitté à peu près proprement ma clé USB :
# sync
# exit
Pour le reste, je m’en remet au boot qui doit normalement fermer le reste proprement.
A suivre …
Ca marche pas.
C’est peut-être pas grub le fautif.
Internet est normalement ton ami …
… sauf si t’es le 1er :)
Je suis tombé sur l’excellent site UBUNTU-fr (j’adore), et plus exactement sur leur forum.
J’ai commencé à lire le début du post, et il m’est venu du coup l’idée de lancer (en chroot) un :
# 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.3.0-1-686-pae
Image mémoire initiale trouvée : /boot/initrd.img-4.3.0-1-686-pae
Image Linux trouvée : /boot/vmlinuz-3.8-2-686-pae
Image mémoire initiale trouvée : /boot/initrd.img-3.8-2-686-pae
Image Linux trouvée : /boot/vmlinuz-3.2.0-4-686-pae
Image mémoire initiale trouvée : /boot/initrd.img-3.2.0-4-686-pae
Image Linux trouvée : /boot/vmlinuz-3.1.0-1-686-pae
Image mémoire initiale trouvée : /boot/initrd.img-3.1.0-1-686-pae
Image Linux trouvée : /boot/vmlinuz-2.6.39-bpo.2-686-pae
Image mémoire initiale trouvée : /boot/initrd.img-2.6.39-bpo.2-686-pae
Image Linux trouvée : /boot/vmlinuz-2.6.39-2-686-pae
Image mémoire initiale trouvée : /boot/initrd.img-2.6.39-2-686-pae
Image Linux trouvée : /boot/vmlinuz-2.6.39-1-686-pae
Image mémoire initiale trouvée : /boot/initrd.img-2.6.39-1-686-pae
Image Linux trouvée : /boot/vmlinuz-2.6.38-2-686
Image mémoire initiale trouvée : /boot/initrd.img-2.6.38-2-686
Image Linux trouvée : /boot/vmlinuz-2.6.37-2-686-bigmem
Image mémoire initiale trouvée : /boot/initrd.img-2.6.37-2-686-bigmem
Image Linux trouvée : /boot/vmlinuz-2.6.37-2-686
Image mémoire initiale trouvée : /boot/initrd.img-2.6.37-2-686
Image Linux trouvée : /boot/vmlinuz-2.6.32-5-xen-686
Image mémoire initiale trouvée : /boot/initrd.img-2.6.32-5-xen-686
Image Linux trouvée : /boot/vmlinuz-2.6.32-5-686-bigmem
Image mémoire initiale trouvée : /boot/initrd.img-2.6.32-5-686-bigmem
Image Linux trouvée : /boot/vmlinuz-2.6.32-5-686
Image mémoire initiale trouvée : /boot/initrd.img-2.6.32-5-686
Image Linux trouvée : /boot/vmlinuz-2.6.32-5-486
Image mémoire initiale trouvée : /boot/initrd.img-2.6.32-5-486
Image Linux trouvée : /boot/vmlinuz-2.6.32-3-686
Image mémoire initiale trouvée : /boot/initrd.img-2.6.32-3-686
Image Linux trouvée : /boot/vmlinuz-2.6.32-2-686
Image mémoire initiale trouvée : /boot/initrd.img-2.6.32-2-686
Image Linux trouvée : /boot/vmlinuz-2.6.30-2-686
Image mémoire initiale trouvée : /boot/initrd.img-2.6.30-2-686
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
fait
Oui, je sais, il y en a un paquet de noyaux, vu l’âge canonique de cette installation, faudrait que je fasse du ménage à l’occasion.
Je vais redémarrer pour voir.
Trop impatient. C’est pas çà non plus. RTFM
Je ne connaissais pas cet utilitaire (cité sur le forum UBUNTU-fr). Je l’installe pour voir (en chroot) :
# apt-get install efibootmgr
Il s’installe et me renvoi un tas de messages.
Je teste :
# efibootmgr -v
efibootmgr: EFI variables are not supported on this system.
Super :)
Visiblement, le message « error: symbol ‘grub_term_highlight_color’ not found » est lié au fait que Grub ne trouve plus le secteur d’amorçage du disque. Probablement un souci de configuration lors des mises à jour.
Il va falloir que je regarde son paramétrage.
Je tente – toujours en chroot, un :
# grub-install /dev/sda
Installing for i386-pc platform.
Installation terminée, sans erreur.
Allons voir çà …
A suivre …
————————————————————————————
Le 30 Janvier
Ca marche pas.
Va falloir fouiller dans les entrailles de grub. Beurk
Allons voir çà :
Nouveau chroot à partir de ma clé USB.
Dans /etc/defaut/grub : rien qui permette de lui préciser où se trouve le MBR. Plus très utile ce fichier
Dans /boot/grub je trouve des trucs plus intéressants :
Sur ma clé USB, le fichier device.map contient :
(hd0) /dev/disk/by-id/usb-_USB_DISK_2.0_079410013A4D010A-0:0
(hd1) /dev/disk/by-id/ata-INTEL_SSDSA2M080G2GC_CVPO9313015J080BGN
Le 1er disque trouvé (hd0) (codification des systèmes de démarrage pour les disques) est visiblement ma clé USB
Le 2nd disque trouvé (hd1) semble être un disque Intel de type SSD
Vous allez rire, je ne savais même pas qu’il y avait un disque SSD sur ce PC (acheté en promo dans un supermarché il y a quelques années)
Sur le disque foireux contenant le /, le fichier device.map contient :
(hd0) /dev/disk/by-id/ata-ST3320820AS_9QF92K9V
(hd1) /dev/disk/by-id/ata-ST3320820AS_9QFBT6DD
Ceux là je les connaissaient.
Je m’en vais m’enquérir de ce qu’il y a réellement sous le capot avec un :
# fdisk -l
Disque /dev/sda : 320.1 Go, 320072933376 octets
255 têtes, 63 secteurs/piste, 38913 cylindres, total 625142448 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x65ddb3ca
Périphérique Amorce Début Fin Blocs Id Système
/dev/sda1 * 63 19535039 9767488+ 83 Linux
/dev/sda2 19535040 156264254 68364607+ 5 Étendue
/dev/sda3 156264255 167975639 5855692+ 82 partition d’échange Linux / Solaris
/dev/sda4 167975640 625137344 228580852+ 83 Linux
/dev/sda5 19535103 39070079 9767488+ 83 Linux
/dev/sda6 39070143 156264254 58597056 83 Linux
Disque /dev/sdb : 320.1 Go, 320072933376 octets
255 têtes, 63 secteurs/piste, 38913 cylindres, total 625142448 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x000a9ba0
Périphérique Amorce Début Fin Blocs Id Système
/dev/sdb1 63 312576704 156288321 83 Linux
/dev/sdb2 312576705 625137344 156280320 83 Linux
Disque /dev/sdc : 1500.3 Go, 1500301910016 octets
255 têtes, 63 secteurs/piste, 182401 cylindres, total 2930277168 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00000000
Le disque /dev/sdc ne contient pas une table de partitions valable
Disque /dev/sdh : 8011 Mo, 8011120640 octets
247 têtes, 62 secteurs/piste, 1021 cylindres, total 15646720 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x0007316a
Périphérique Amorce Début Fin Blocs Id Système
/dev/sdh1 * 2048 14905343 7451648 83 Linux
/dev/sdh2 14907390 15644671 368641 5 Étendue
/dev/sdh5 14907392 15644671 368640 82 partition d’échange Linux / Solaris
Oui, eh bien c’est bien ce que je pensais / avait en tête :
– 2 disques durs de 320Go (d’origine, c’est tout petit et vite rempli, + 1 carte nvidia à 30€ suite au changement de la précédente, mais elle commence elle-aussi à me donner des signes de faiblesse avec un affichage foireux sur le côté droit de l’écran, raison pour laquelle je n’utilise ce PC qu’en distributeur d’internet pour mon autre PC / le portable de Louis, et en dépannage quand j’ai réussi à planter l’autre)
– il me semble que la petite étoile (*) précise la partition d’amorçage, ce qui est cohérent pour /dev/sda1 et /dev/sdh1
– 1 disque /dev/sdc de 1.5To très mal utilisé (en plus Linux me dit avec tacte, qu’il n’a même pas une partition valable, oui je sais). Il y a quelques temps (années ?) j’avais ajouté un rack de disque dur sur ce PC (il suffit d’y insérer un disque brut de fonderie). Le truc est resté dans l’oubli. Là aussi faudra que je m’en occupe un de ces jours :)
– ma clé USB de 8Go en /dev/sdh sur laquelle je vous écris.
Bon alors, quid du mystérieux ata-INTEL_SSDSA2M080G2GC_CVPO9313015J080BGN ?
Dans /dev/disk/by-id/ de ma clé USB je trouve :
ata-Optiarc_DVD_RW_AD-7200S (le lecteur/graveur de CD-ROM)
ata-SAMSUNG_HD154UI_S1Y6J1KS739171 (mon disque « pas valable » de 1.5To, honte sur moi de le sous-utiliser :) )
ata-ST3320820AS_9QF92K9V (le 1er disque de 320Go, celui qui contient /, aka (hd0) pour Grub, aka /dev/sda pour les autres)
ata-ST3320820AS_9QFBT6DD (le 2nd disque de 320G0, contenant le gros des données, que je ne met pas dans le /home de manière à pouvoir changer celui-ci facilement, aka (hd1) pour Grub, aka /dev/sdb pour les autres)
usb-Generic-_Compact_Flash_20021111153705700 et usb-_USB_DISK_2.0_079410013A4D010A (ma clé USB, aka /dev/sdh lorsqu’elle est vue par mon disque à réparer).
wwn-0x50024e9001cf66dc : là je ne sais pas ce que c’est (?)
En tout cas point de ata-INTEL_SSDSA2M080G2GC_CVPO9313015J080BGN, le mystère s’épaissit mon cher Watson :)
Ca y est, le fait de me relire (ne vous inquiétez pas, je ne me prend pas pour Sherlock, mais çà a quelque-chose d’amusant de chercher) …
(d’où l’intérêt pour moi d’écrire, et puis je me dis que çà pourra peut-être servir à un débutant passant par hasard par là)
ata-INTEL_SSDSA2M080G2GC_CVPO9313015J080BGN est le disque SSD de mon autre PC (le PC du Bottin, je viens d’aller vérifier).
Le système Debian de la clé USB a conservé dans ce fichier le paramétrage de l’autre PC sur lequel se trouve le / (sur le SSD) et l’a mis automatiquement en 2nd disque de démarrage. Ouaah, étonnant.
Poursuivons :
Sur le disque à réparer contenant le / j’ai bien le fichier /boot/grub/default contenant « default ».
De mémoire, çà lui précise que le disque sur lequel se trouve ce fichier est le disque à démarrer.
Pas sûr qu’il soit super utile ce fichier, car il y a aussi un fichier :
/boot/grub/load.cfg contenant :
search.fs_uuid 0f3cbe1b-9ab7-43e5-851f-289ebab66bea root
set prefix=($root)/boot/grub
Donc à priori il se base sur l’UUID du disque, pour trouver le disque root, ce qui ferait double emploi.
Allons faire un tour dans /etc/fstab (celui du disque à dépanner biensûr) pour voir quel est l’UUID du disque /dev/sda :
#
# /dev/sda1 / ext3 errors=remount-ro 0 1
UUID=0f3cbe1b-9ab7-43e5-851f-289ebab66bea / ext3 users,exec,dev,suid 0 1
# /dev/sda5 /home ext3 defaults 0 2
UUID=2409bbc0-90dd-42cc-af2f-bb1060cf2b40 /home ext3 defaults 0 2
# /dev/sda4 /mnt/DDprc ext3 defaults 0 2
UUID=dd71d0c5-e828-44d3-93fc-d77e2bfb4554 /mnt/DDprc ext3 defaults 0 2
# /dev/sdb1 /mnt/DDsec ext3 defaults 0 2
UUID=f9dccdd1-fe14-4ea2-b8c7-8b25cd54929f /mnt/DDsec ext3 defaults 0 2
# /dev/sdb2 /mnt/DDter ext3 defaults 0 2
UUID=7c1342cc-edc3-4e3a-9a3f-40efccbd1d63 /mnt/DDter ext3 defaults 0 2
# /dev/sda6 /usr ext3 defaults 0 2
UUID=f5cb3c3a-bba7-44ee-a718-9b9f2f7794d8 /usr ext3 defaults 0 2
# /dev/sda3 none swap sw 0 0
UUID=1ff8a1a8-a214-42a9-be67-7cd883c935b4 none swap sw 0 0
Bon visiblement c’est bien le même.
Ben alors, pourquoi il me fait un caca nerveux mon p’tit grub ?
A suivre …
Visiblement les paramétrages du fichier /boot/grub/grub.cfg du disque dur ont pas mal évolués.
Exemple :
Quand sur ma clé USB j’ai : set root='(hd0,msdos1)’
Sur le disque dur j’ai : set root=’hd0,msdos6′
Les parenthèses ont disparues et l’étiquette msdos n’est plus la même non plus.
Je serais bien tenté de copier l’un sur l’autre (comme précédemment) en changeant ensuite les sections des noyaux et les périphériques de démarrage, mais c’est un peu scabreux.
Je ne vois rien qui me choque dans le fichier.
Je suis retourné sur le net à la recherche d’autres renseignements.
Je suis tombé sur ce rapport de bugs sur Launchpad relatif à l’erreur :
Ubuntu 14.04 Update breaks grub, resulting in « error: symbol ‘grub_term_highlight_color’ not found »
J’ai suivi la préconisation et lancé un :
# dpkg-reconfigure grub-pc
Installation finished. No error reported.
Installation finished. No error reported.
Generating grub.cfg …
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.2.0-4-686-pae
Found initrd image: /boot/initrd.img-3.2.0-4-686-pae
Found Debian GNU/Linux (stretch/sid) on /dev/sda1
done
Effectivement, c’est assez ergonomique, je ne connaissais pas, on choisi via un menu le ou les disques sur lesquels on souhaite que grub puisse s’implanter. La méthode étant plus pérenne que les autres commandes (« You should use dpkg-reconfigure grub-pc instead, so that the system can remember which drive(s) you have grub installed on and automatically reinstall it when grub is upgraded ».).
Dans le menu, seul la clé USB était sélectionnée (via une « * »), j’ai donc aussi sélectionné /dev/sda (mais l’on peut en mettre sur tous les disques).
C’est donc fait.
Je redémarre pour voir si çà change quelque-chose.
————————————————————————————
Le 31 Janvier
Bon voilà, je me suis créé un petit script qui me lance automatiquement le chroot, je pense qu’il va m’être bien utile, de ce côté là je progresse.
J’envisage d’en créer un autre qui écrira ici : çà marche pô :)
Plus sérieusement, poursuivons :
Je relis le rapport de bug sur Launchpad et découvre des commandes que je ne connaissais pas / avait oublié (ce qui revient au même) :
# debconf-show grub-pc
grub-pc/timeout: 5
grub2/kfreebsd_cmdline:
grub-pc/hidden_timeout: false
grub-pc/install_devices_failed_upgrade: true
* grub2/device_map_regenerated:
grub2/kfreebsd_cmdline_default: quiet
* grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-ST3320820AS_9QF92K9V, /dev/disk/by-id/ata-ST3320820AS_9QFBT6DD
grub-pc/partition_description:
* grub-pc/install_devices: /dev/disk/by-id/ata-ST3320820AS_9QF92K9V, /dev/disk/by-id/ata-ST3320820AS_9QF92K9V-part1
grub-pc/disk_description:
* grub2/linux_cmdline_default: quiet
grub-pc/postrm_purge_boot_grub: false
* grub-pc/chainload_from_menu.lst: true
grub2/force_efi_extra_removable: false
* grub2/linux_cmdline: splash=silent splash vga=789
grub-pc/install_devices_failed: false
grub-pc/install_devices_empty: false
grub-pc/kopt_extracted: true
grub-pc/mixed_legacy_and_grub2: true
root@goup2net:/etc# parted -l
Modèle: ATA ST3320820AS (scsi)
Disque /dev/sda : 320GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:
Numéro Début Fin Taille Type Système de fichiers Fanions
1 32,3kB 10,0GB 10,0GB primary ext3 démarrage
2 10,0GB 80,0GB 70,0GB extended
5 10,0GB 20,0GB 10,0GB logical ext3
6 20,0GB 80,0GB 60,0GB logical ext3
3 80,0GB 86,0GB 5996MB primary linux-swap(v1)
4 86,0GB 320GB 234GB primary ext3
Modèle: ATA ST3320820AS (scsi)
Disque /dev/sdb : 320GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:
Numéro Début Fin Taille Type Système de fichiers Fanions
1 32,3kB 160GB 160GB primary ext3
2 160GB 320GB 160GB primary ext3
Erreur: Impossible d’ouvrir /dev/sdc – étiquette de disque non reconnue.
Modèle: ATA SAMSUNG HD154UI (scsi)
Disque /dev/sdc : 1500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : unknown
Disk Flags:
Modèle: USB DISK 2.0 (scsi)
Disque /dev/sdh : 8011MB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags:
Numéro Début Fin Taille Type Système de fichiers Fanions
1 1049kB 7632MB 7630MB primary ext4 démarrage
2 7633MB 8010MB 377MB extended
5 7633MB 8010MB 377MB logical linux-swap(v1)
parted -l donne sensiblement le même niveau d’informations que fdisk -l, en étant plus concis.
Par contre la conclusion à laquelle arrive Phillip Susi sur Launchpad ne me laisse qu’un mot à la bouche : balaise (le gars) :)
Dommage qu’il ne soit pas plus loquace en argumentant ses affirmations (« tel affichage nous signale qu’il y a un souci sur tel truc »). Mais je comprend bien que c’est du forum de dépannage, pas du tuto.
D’où l’intérêt de se donner un peu de mal pour dépanner son système plutôt que de choisir la facilitée en le reformatant purement et simplement : on en apprend bien plus, même si l’on y passe plus de temps (et que l’on galère davantage, il faut bien le reconnaître).
Donc, la commande magique « debconf-show nomdupaquet » est utile en situation de bogue / de dépannage car elle interroge la base de données des paquets et nous révèle si des mises à jour se sont mal passées pour un paquet donné.
Si j’ai bien compris, « grub-pc/install_devices_failed_upgrade: true » me signale que la mise à jour s’est mal passée, et « grub-pc/install_devices: /dev/disk/by-id/ata-ST3320820AS_9QF92K9V, /dev/disk/by-id/ata-ST3320820AS_9QF92K9V-part1″ que grub est à la fois installé en début de disque et sur la partition 1.
Au vu de ce que j’ai lu sur le net et des infos ci-dessus, j’ai l’impression que le bug tient davantage d’un problème sur mon installation que d’un bug de Grub 2 (même si quelque-part c’est quand-même mon système qui décide de ce qu’il installe et que je suis passé d’un système qui démarre à un système qui ne démarre plus par la simple mise à jour des paquets).
Je me décide donc à remettre la dernière version de grub 2, et j’en profite pour mettre à jour les dernières versions de dmsetup (114-1 à 115-1), libdevmapper-event1.02.1, libdevmapper1.02.1 et liblvm2app2.2 (qui me semblent avoir des liens plus ou moins proches).
En ré-installant la dernière version de grub2 j’ai les messages :
(…)
Installing for i386-pc platform.
Installation terminée, sans erreur.
Installing for i386-pc platform.
grub-install : attention : Le système de fichiers « ext2 » ne prend pas en charge l’embarquage.
grub-install : attention : L’embarquage est impossible. GRUB ne peut être installé sur cette configuration qu’en utilisant les listes de blocs. Cependant, les listes de blocs ne sont PAS fiables et leur utilisation est déconseillée..
Installation terminée, sans erreur.
Création du fichier de configuration GRUB…
(…)
J’en profite pour virer efibootmgr et consorts qui visiblement ne me servent à rien :
# apt-get remove –purge efibootmgr
# apt autoremove
je reteste un : # dpkg-reconfigure grub-pc
je vire les paramètres : splash=silent splash vga=789
(pas la peine d’en rajouter pour l’instant)
ainsi que : quiet
pour espérer avoir un peu plus de messages (provisoirement, pour le débuggage).
Ensuite :
Périphériques où installer GRUB :
[*] /dev/sda (320072 Mo;???)
[*] – /dev/sda1 (10001 Mo; /)
[ ] /dev/sdb (320072 Mo; ???)
[ ] /dev/sdc (1500301 Mo; ???)
[ ] /dev/sdh (8011 Mo; ???)
Je décoche /dev/sda1 :
Périphériques où installer GRUB :
[*] /dev/sda (320072 Mo;???)
[ ] – /dev/sda1 (10001 Mo; /)
[ ] /dev/sdb (320072 Mo; ???)
[ ] /dev/sdc (1500301 Mo; ???)
[ ] /dev/sdh (8011 Mo; ???)
J’obtiens :
Replacing config file /etc/default/grub with new version
Installing for i386-pc platform.
Installation terminée, sans erreur.
Création du fichier de configuration GRUB…
(…) (je ne remet pas la longue liste de noyaux)
Et là je teste à nouveau un redémarrage …
(soupir lassé / blasé :) )
Et … çà ne marche pas.
Bon là, çà commence à faire, on va y aller au bistouri :
En regardant dans le menu de grub, je vois qu’il contient tout un tas de fichiers dont :
grub.cfg : le fichier de paramétrage de grub 2
menu.lst : l’ancien fichier de paramétrage de grub 1
Le souci vient peut-être de là : une interférence entre les anciens fichiers et les nouveaux.
Je renomme le répertoire complet : # mv grub grubsv
Et ré-initialise le contenu par :
# dpkg-reconfigure grub-pc (recréé le répertoire /boot/grub/ avec un fichier unicode.pf2 dont je ne connais pas l’utilité)
# update-grub me recréé le fichier de configuration grub.cfg à partir des scripts d’installation.
Je vais redémarrer et si çà ne fonctionne pas, je m’en vais lui concocter un nouveau fichier grub.cfg à ma façon (traduisez : un truc dérivé de celui qui fonctionne sur ma clé USB avec le nom du disque dur à la place de celui de la clé).
Redémarrage.
Grub plante sur : error: file ‘/boot/grub/i386-pc/normal.mod’ not found
Au moins çà change :)
Ok, du coup j’en profite pour y copier les répertoires (avec leur contenu) fonts/, i386-pc/ et locale/ récupérés dans grubsv/ en espérant que dans i386-pc/ (qui contient beaucoup de fichiers) il n’y ait pas trop de mélanges de versions de grub.
Redémarrage.
Retour à mon message : error: symbol ‘grub_term_highlight_color’ not found
Du coup çà me donne une idée : la structure du répertoire /boot/grub/ de ma clé USB est différente : il y a seulement un répertoire locale/ contenant une série de fichiers de localisation, les autres fichiers sont en vrac dans /boot/grub/
Sur mon disque en réparation je sauvegarde mon fichier grub.cfg, efface les autres fichiers et remplace tout le reste par celui de ma clé USB.
L’idée est de vérifier si ‘grub_term_highlight_color’ ne se trouve pas dans l’un des nombreux fichiers qui accompagnent grub.cfg.
Redémarrage.
Message : error: file ‘/boot/grub/i386-pc/normal.mod’ not found
Je créé un répertoire /boot/grub/i386-pc/, y déplace tout le contenu de /boot/grub/ en ne conservant dans /boot/grub/ que les fichiers : device.map, grub.cfg, grub.cfg~, grubenv et unicode.pf2
Redémarrage.
Message : error: symbol ‘grub_divmod64_full’ not found
Au moins çà change :)
Bon, je ne voulais pas en arriver là (parce que ce n’est pas pérenne), mais je vais tester ceci :
je copie le grub.cfg de ma clé USB sur ce disque dur récalcitrant et y remplace l’occurence 7de7b067-df10-4cad-a7ee-728992f9b649 (l’UUID de ma clé USB) par 0f3cbe1b-9ab7-43e5-851f-289ebab66bea (l’UUID de mon DD)
et reprend aussi la section par défaut pour charger le bon noyau (tant qu’à faire), ie 4.3.0-1-686-pae (vs 3.2.0-4-686-pae) :
echo ‘Chargement de Linux 3.2.0-4-686-pae …’
linux /boot/vmlinuz-3.2.0-4-686-pae root=UUID=7de7b067-df10-4cad-a7ee-728992f9b649 ro quiet
echo ‘Chargement du disque mémoire initial …’
initrd /boot/initrd.img-3.2.0-4-686-pae
par :
echo ‘Chargement de Linux 4.3.0-1-686-pae…’
linux /boot/vmlinuz-4.3.0-1-686-pae root=UUID=0f3cbe1b-9ab7-43e5-851f-289ebab66bea ro
echo ‘Chargement du disque mémoire initial…’
initrd /boot/initrd.img-4.3.0-1-686-pae
Le test ne portera que sur le 1er noyau (je ne me fais pas suer à reprendre toutes les sections des autres noyaux, d’autant que ce n’est qu’un bricolage de fortune).
Redémarrage.
Message : error: symbol ‘grub_divmod64_full’ not found
Restons Zen :)
Je me créé un nouveau réperoire de grub à partir de ma précédente sauvegarde de grubsv, efface le menu.lst et remplace grub.cfg par celui que je viens de me concocter.
Redémarrage.
Message : error: symbol ‘grub_term_highlight_color’ not found
Bon je teste d’autres trucs sous grub.cfg (notamment commenter la section
### if background_image /usr/share/images/desktop-base/joy-grub.png; then
### set color_normal=white/black
### set color_highlight=black/white
### else
### set menu_color_normal=cyan/blue
### set menu_color_highlight=white/blue
mais : idem
Je commence à sécher là …
j’ai aussi testé un : # dpkg-reconfigure grub-pc
avec :
[ ] /dev/sda (320072 Mo;???)
[*] – /dev/sda1 (10001 Mo; /)
Vous devinez le résultat.
Retour à la config initiale de /boot/grub (en utilisant ma sauvegarde /boot/grubsv/)
Je teste l’installation de grub via # dpkg-reconfigure grub-pc
sur :
Périphériques où installer GRUB :
[*] /dev/sda (320072 Mo;???)
[*] – /dev/sda1 (10001 Mo; /)
[*] /dev/sdb (320072 Mo; ???)
Redémarrage (sans trop y croire).
A priori, çà ne marchera pas. Mais j’arrête là pour cette journée.
Pfiouu … 1 semaine de perdue.
Je pense qu’il reste encore du boulot sous Linux pour rendre cet outil simple et fiable.
Je suis conscient que la manip ci-dessus n’était pas triviale, et je m’y suis cassé les dents. Pour l’instant.
Lilo était une daube. Il est abandonné.
Grub en cela était un gros progrès, était relativement simple et il fonctionnait bien.
Aujourd’hui il a été compliqué à loisir et ne me semble plus fiable (ce qui me semble être un euphémisme), et cerise sur le gâteau, n’est visiblement plus maintenu depuis 2012.
Je pense qu’il faudrait faire quelque-chose, mais y a t-il encore un pilote dans l’avion ?
Bon voilà, il suffit que je dise cela pour que çà marche (mon installation démarre à présent – avec un système qui me semble nettement plus véloce, sans clé USB de dépannage).
Visiblement il lui fallait une installation de Grub sur toutes les partitions / disques (sauf ma clé USB).
Mais je ne retire pas mon commentaire. Je pense qu’il manque un outil simple et fiable pour démarrer notre système d’exploitation.
Me revoilà de retour avec ma précédente liste de bugs à résoudre.
Mais c’est tout pour ce soir.
La suite demain, pas de bonne heure, mais de meilleure humeur :)
————————————————————————————
Le 1er Février
Debriefing « rapide » sur Grub 2 :
Si j’interprète correctement ce qui précède,
1er point, grub2 était planté parce qu’il tentait un démarrage sur un disque ou une partition sur laquelle il n’était pas installé.
Le fait de sélectionner l’installation de grub2 sur toutes les partitions est là aussi – de mon point de vue, un bricolage permettant de le faire démarrer.
Le disque de démarrage n’a pas changé depuis le début, c’est /dev/sda, dont l’UUID est 0f3cbe1b-9ab7-43e5-851f-289ebab66bea.
Visiblement la grosse mise à jour des paquets semble avoir modifié quelque-chose qui lui fait à présent rechercher les paramètres de démarrage sur l’un des autres disques / partitions
Un extrait de la version actuelle de grub.cfg (la section principale définissant le noyau à démarrer par défaut) :
(…)
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload= »${1} »
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry ‘Debian GNU/Linux’ –class debian –class gnu-linux –class gnu –class os $menuentry_id_option ‘gnulinux-simple-0f3cbe1b-9ab7-43e5-851f-289ebab66bea’ {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root=’hd0,msdos1′
if [ x$feature_platform_search_hint = xy ]; then
search –no-floppy –fs-uuid –set=root –hint-bios=hd0,msdos1 –hint-efi=hd0,msdos1 –hint-baremetal=ahci0,msdos1 –hint=’hd0,msdos1′ 0f3cbe1b-9ab7-43e5-851f-289ebab66bea
else
search –no-floppy –fs-uuid –set=root 0f3cbe1b-9ab7-43e5-851f-289ebab66bea
fi
echo ‘Chargement de Linux 4.3.0-1-686-pae…’
linux /boot/vmlinuz-4.3.0-1-686-pae root=UUID=0f3cbe1b-9ab7-43e5-851f-289ebab66bea ro splash=silent splash vga=789 quiet
echo ‘Chargement du disque mémoire initial…’
initrd /boot/initrd.img-4.3.0-1-686-pae
}
(…)
2nd point : il est possible et relativement facile d’installer grub2 (voir le man de grub2 en ligne) sur n’importe quelle partition / disque, mais rien ne semble prévu pour le désinstaller. C’est balo :)
La manip du : # dpkg-reconfigure grub-pc avec désélection du/des disques ne semble pas fonctionner correctement.
Mais peut-être n’est-ce qu’un bug provisoire.
Il y a bien des manips plus ou moins scabreuses (à coup de # dd if=/dev/sdx of=/(…)) pour aller nettoyer les 1er secteurs de vos disques – au risque de nettoyer également et définitivement votre table de partition si vous faites une erreur :), mais personnellement je ne m’y risquerait qu’en dernier recours (et une fois les données du disque sauvegardées sur un autre disque).
Et j’ai l’impression / visiblement / selon le constat ci-avant (je peux me tromper), que tant que le nettoyage n’est pas fait on n’est pas à l’abri qu’il continue à chercher grub sur ces autres disques.
Fin de ce retour sur Grub2.
Je passe à autre chose. J’y reviendrai éventuellement si j’apprend quelque-chose de neuf qui puisse faire avancer le shmilblick.
Je passe au driver graphique nvidia.
Je préférerai de loin – comme tout le monde, le driver nouveau, mais :
1. pour l’instant il est loin d’égaler nvidia du fait de la réticence de ces derniers à filer leurs infos / voir à donner un coup de main pour l’améliorer (j’ai en tête un doigt levé bien haut par notre ami Linus :) ),
2. c’est un PC peu puissant, j’ai besoin de tirer le maximum du matériel (d’autant que sa carte graphique actuelle est un « truc » très basique)
3. pour l’instant je n’arrive pas à lui faire charger le driver nouveau automatiquement au démarrage. Même si Louis saurait sans problème se débrouiller pour faire un « su root, modprobe nouveau, /etc/init.d/kdm restart » à chaque démarrage, voir lancer un script, c’est pas terrible. A ce propos je vois sur mon autre PC que le paquet « nvidia-modprobe » est installé, ce qui explique sans doute pourquoi çà se passe mieux côté nvidia.
Je vais faire un petit comparatif (en lancant synaptic sur chacun des PC, et en filtrant sur le terme « nvidia ») de ce qui est installé comme paquet nvidia sur mon autre PC pour tenter de comprendre pourquoi çà ne veut pas s’installer ici.
J’ai en effet encore tenté tout à l’heure (donc postérieurement à la 2nde grosse phase de mise à jour des paquets) un :
# m-a a-i nvidia-kernel-source
et ai obtenu les messages :
« modprobe: ERROR: Could not insert ‘nvidia_current’: No such device »
« modprobe: ERROR: Could not insert ‘nvidia’: operation not permitted »
(Je commence la liste ce soir, je la finirai demain)
Sur le PC du Bottin est installé (filtrage « nvidia » sous Synaptic) :
glx-alternative-nvidia, libcg, libegl1-nvidia, libgl1-nvidia-glx, libgles1-nvidia, libgles2-nvidia, libnvidia-eglcore, libnvidia-ml1, nvidia-alternative, nvidia-driver, nvidia-driver-bin, nvidia-installer-cleanup, nvidia-kernel-common, nvidia-kernel-dkms, nvidia-kernel-source, nvidia-kernel-support, nvidia-modprobe, nvidia-settings, nvidia-support, nvidia-vdpau-driver, xserver-xorg-video-nvidia (déjà installés)
nvidia-kernel-3.2.0-4-686-pae (ici j’ai le nvidia-kernel-4.3.0-1-686-pae, le paquet contenant le module nvidia correspondant au noyau installé cité dans sa version de paquet, créé à partir de la commande ci-dessus « # m-a a-i nvidia-kernel-source »)
libcud*, libcubl*, libcuff*, libcui*, libcurand*, libcusp*, libnvidia-compiler (je désinstalle pour l’instant sur ce PC, je verrai plus tard, ce sont des outils pour utiliser le GPU de la carte graphique pour faire du calcul. Je n’ai aucune idée/info sur la manière de s’en servir)
A suivre …
————————————————————————————
Le 2 Février
(poursuite de la liste)
libnvtoolsext1, libnvvm2, libvdpau-dev, nvidia-cg-dev, nvidia-cg-toolkit, nvidia-detect, nvidia-libopencl1, nvidia-opencl-common, nvidia-opencl-dev, nvidia-persistenced, nvidia-smi, (je désinstalle pour l’instant sur ce PC car pas installé sur l’autre, je verrai plus tard)
libnvtt2, libvdpau1, libxnvctrl0 (des bibliothèques d’utilitaires, pas sûr qu’elles me soient utiles, mais elles sont installées)
Voilà, l’alignement entre les 2 configs est terminé. Pas de différence notable entre elles, tout au plus quelques différences de versions et quelques paquets installés en plus ici.
J’en profite pour mettre à jour les derniers paquets disponibles via synaptic.
Je vais tout de même tester une nouvelle fois l’installation du module nvidia par :
# m-a a-i nvidia-kernel-source
Pour cela j’ai dû redémarrer le PC, car le module nouveau ne voulait pas se libérer de la mémoire (via un # rmmod nouveau) en dépit du fait que j’avais stoppé au préalable le serveur X (via un # /etc/inbit.d/kdm stop).
Pas de changement à la compilation : elle semble bien se passer.
Mais (après un reboot et pas de driver nouveau en mémoire, j’ai vérifié) un : # modprobe nvidia
me renvoi toujours les messages :
« modprobe: ERROR: Could not insert ‘nvidia_current’: No such device »
« modprobe: ERROR: Could not insert ‘nvidia’: operation not permitted »
Je vais faire une petite recherche sur le net.
Aparté :
J’en ai profité pour installer tous les paquets MATE manquants. Il est trop beau et trop efficace ce gestionnaire de fenêtre.
J’ai aussi mis à jour :
sysvinit (2.88dsf-12) to 2.88dsf-59.3
et installé (car ils étaient installés sur l’autre PC) :
systemd-sysv (228-4+b1)
systemd-ui (3-4)
init (1.27) (installé par le jeu des dépendances il me semble)
linux-perf (4.3+70)
linux-perf-4.3 (4.3.1-2)
linux-tools (4.3+70)
Bonnes nouvelles : j’ai à nouveau les vidéos Youtube et le son !!! (c’est mieux quand le bouton de réglage du son n’est pas à zéro :) )
Je ne sais pas si ce n’est qu’une impression, mais le son me paraît de bien meilleure qualité qu’avant (sur ce PC j’ai un petit kit d’enceinte avec caisson de basse) : en tout cas il n’y a plus le souffle assez pénible qu’il y avait avant. GE-NIAL !!!
J’installe encore (toujours dans un comparatif avec mon autre install) :
devscripts
Concernant la création du nouveau répertoire utilisateur (ma manip d’effacement du répertoire et recréation manuelle qui ne fonctionne pas) :
Je me suis résolu à utiliser les commandes UNIX standard :
# userdel nomutilisateur
# useradd -m nomutilisateur
# passwd nomutilisateur
(çà va plus vite que de m’embêter à chercher davantage, et c’est plus standard)
Oups, çà ne fonctionne pas : pas moyen de se connecter à partir de l’interface de kdm.
J’ai dû oublier quelque-chose
Je ne trouve pas d’outil de manipulation d’utilisateurs – en dehors de kuser.
Il est vrai que ce n’est pas un outil que l’on utilise très souvent.
En regardant sur le net je trouve : $ /usr/bin/users-admin (appartenant au paquet gnome-system-tools)
C’est assez simpliste, mais çà pourrait faire l’affaire.
J’ai testé l’outil, il me semble Ok.
Par contre, pas moyen de me connecter à un nouveau compte avec kdm
Pour vérifier, j’ai ajouté un utilisateur lambda avec la commande : # adduser utilisateur
Il me met qu’il créé le répertoire utilisateur à partir d’un squelette prédéfini et me pose quelques questions dont le mot de passe, tout va bien.
Mais là aussi : impossible ensuite de se connecter à cet utilisateur à partir de kdm.
J’ai essayé gdm3 et xdm (avec, par exemple, # dpkg-reconfigure xdm) : ils ne marchent plus :)
Décidément …
Plus inquiétant, en console de démarrage (Ctrl Alt F1), je viens de voir passer un message, que j’ai retrouvé via la commande : # dmesg
(…)
[ 960.069046] perf interrupt took too long (2513 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[ 2715.090908] systemd-gpt-auto-generator[7852]: /dev/sda: failed to determine partition table type: Input/output error
[ 2715.369865] systemd-gpt-auto-generator[7883]: /dev/sda: failed to determine partition table type: Input/output error
[ 2752.928680] systemd-gpt-auto-generator[7993]: /dev/sda: failed to determine partition table type: Input/output error
[ 2797.446087] systemd-gpt-auto-generator[8096]: /dev/sda: failed to determine partition table type: Input/output error
Aïe aïe aïe :)
Si çà continue, je me demande si je ne vais pas virer les derniers paquets installés :
systemd-sysv (228-4+b1)
systemd-ui (3-4)
init (1.27) (installé par le jeu des dépendances il me semble)
linux-perf (4.3+70)
linux-perf-4.3 (4.3.1-2)
linux-tools (4.3+70)
devscripts
Parce que je n’avais pas de message de ce genre avant leur installation.
A moins que ce soit l’un des autres paquets mis à jour …
Je vais au moins redémarrer et suivre cela.
En passant, en fouillant dans les messages de DMESG, j’ai la réponse à mon problème nvidia :
[ 12.979615] NVRM: The NVIDIA GeForce 210 GPU installed in this system is
NVRM: supported through the NVIDIA 340.xx Legacy drivers. Please
NVRM: visit http://www.nvidia.com/object/unix.html for more
NVRM: information. The 352.79 NVIDIA driver will ignore
NVRM: this GPU. Continuing probe…
[ 12.979629] NVRM: No NVIDIA graphics adapter found!
[ 12.979677] NVRM: NVIDIA init module failed!
Il n’y a pas que des mauvaises nouvelles :)
(bon, en même temps si le disque est foiré, je peux recommencer à zéro :) )
En plus j’ai la confirmation qu’en ce qui concerne ma carte graphique, j’en ai eut pour mon argent : elle n’est plus supportée qu’en Legacy.
J’adore la pub : NVIDIA GeForce 210 : Tous les PC ont besoin d’une bonne carte graphique :) mdr
(à lire entre les lignes : oui, mais pas celle-là).
————————————————————————————
Le 3 Février
Après un redémarrage, pas de nouveau message « /dev/sda: failed to determine partition table type: Input/output error ».
Et ce soir au redémarrage non plus. Ce qui ne veut pas dire que le problème est réglé.
En début de dmesg ce soir j’ai :
(…)
[ 4.938889] EXT4-fs (sda6): mounting ext3 file system using the ext4 subsystem
[ 4.963113] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
(…)
Visiblement sur ce noyau 4.3.0, tous les disques formatés en ext3 sont à présent montés via une routine commune aux formatages en ext4. Je me souviens avoir lu un truc sur le sujet sur les excellents rapports de linuxfr à chaque sortie d’un nouveau noyau.
Si çà bug, çà pourrait donc aussi venir de là (et donc la résolution pourrait consister à tester un autre noyau).
Pour l’instant je ne fais rien tant que je ne vois pas à nouveau l’erreur revenir.
Je vais m’attaquer au driver nvidia.
Commentaire en passant :
je ne comprend pas pourquoi il y a un paquet nvidia-modprobe permettant de charger automatiquement le driver nvidia lorsque le système le nécessite, et qu’il n’y a pas de paquet nouveau-modprobe qui en ferait de même, puisque visiblement tous les jours je suis obligé de charger moi-même manuellement ce driver nouveau.
Revenons à nvidia :
Il faut donc que j’installe un « NVIDIA 340.xx Legacy drivers ».
Je désinstalle le paquet nvidia-kernel-4.3.0-1-686-pae qui ne me sert à rien avec cette « vieille » carte graphique nvidia via synaptic
Et j’installe les paquets (à peu près tout ce qui se nomme 340xx) :
nvidia-legacy-340xx-alternative
nvidia-legacy-340xx-kernel-support
nvidia-legacy-340xx-driver-bin
libegl1-nvidia-legacy-340xx
libgl1-nvidia-legacy-340xx-glx-i386
nvidia-settings-legacy-340xx
libgles1-nvidia-legacy-340xx
libgles2-nvidia-legacy-340xx
libnvidia-legacy-340xx-encode1
nvidia-legacy-340xx-kernel-source
nvidia-legacy-340xx-driver
nvidia-legacy-340xx-kernel-dkms
xserver-xorg-video-nvidia-legacy-340xx
libnvidia-encode1
nvidia-legacy-340xx-vdpau-driver (une API permettant d’exposer le décodage vidéo hardware)
vdpau-driver-all
Cà tombe bien, ces paquets n’attendaient que d’être installé dans les dépôts, mille merci aux mainteneurs Debian.
Une bonne partie de ces paquets n’est probablement pas nécessaire pour obtenir l’accélération graphique sur ma carte, mais je me dis que peut-être quelques-uns d’entre eux me permettrons d’avoir en bonus des trucs cool comme l’accélération vidéo hardware. De plus ils sont dans les dépôts, çà ne coûte pas plus chère.
Une fois installés, je vais quitter Xorg, changer la ligne dans /etc/X11/xorg.conf :
(…)
Section « Device »
Identifier « Carte graphique »
# Driver « nvidia »
Driver « nouveau »
# Driver « vesa »
EndSection
(…)
Pour :
(…)
Section « Device »
Identifier « Carte graphique »
Driver « nvidia »
# Driver « nouveau »
# Driver « vesa »
EndSection
(…)
Je laisse toujours ces 3 lignes de driver, il me suffit de commenter (on ajoute un « # » devant) ceux que je n’utilise pas.
Ensuite j’enregistre, je quitte et redémarre complètement (car je ne sais pas retirer le driver nouveau à la main, puisqu’il me dit à chaque fois qu’il est en cours d’utilisation).
Bon , çà marche pas.
Avec la ribambelle de paquets installés, je m’attendais à ce que le driver se coit compilé tout seul et que le module nvidia se charge tout seul et que çà marche dès le démarrage. Eh bien non.
Un : # modprobe nvidia
modprobe: ERROR: could not insert ‘nvidia_current’: No such device
modprobe: ERROR: ../libkmod/libkmod-module.c:977 command_do() Error running install command for nvidia
modprobe: ERROR: could not insert ‘nvidia’: Operation not permitted
Après un : # apt-cache search -n nvidia
pour trouver les noms des paquets disponibles, j’ai lancé la compilation d’un module nvidia version « legacy » via la commande : # m-a a-i -f nvidia-legacy-340xx-kernel-source
La compilation semble bien se passer (en 24 étapes de mémoire), mais ensuite le modprobe nvidia me renvoit la même erreur.
Sans module nvidia qui accepte de se charger sans erreur, ce n’est même pas la peine de poursuivre plus loin.
Me revoici donc encore avec le driver nouveau.
Je vais chercher si je n’ai pas loupé quelque-chose.
Je pense que finalement je vais désinstaller (sous Synaptic c’est plus facile) tout ce qui s’appelle nvidia et qui ne semble pas indispensable (on verra le reste plus tard), notamment les paquets dont la version est la 352.79-1 (la version récente non compatible avec ma carte) au lieu de la version 340.96-2 (correspondant à la Legacy que je dois utiliser).
Le risque étant que le module nvidia qui se charge ne soit pas celui que j’ai moi-même compilé avec la commande ci-dessus.
A suivre … (demain)
————————————————————————————
Le 4 Février
Bingo ! Excellente nouvelle, mais pas celle que j’imaginais : au démarrage, inutile de faire un « # modprobe nouveau », kdm se lance tout seul avec l’accélération graphique.
Un # dmesg me donne :
(…)
[ 12.499320] fb: switching to nouveaufb from simple
[ 12.499371] Console: switching to colour dummy device 80×25
[ 12.499596] nouveau 0000:03:00.0: NVIDIA GT218 (0a8280b1)
[ 12.628632] nouveau 0000:03:00.0: bios: version 70.18.5f.00.06
[ 12.629485] nouveau 0000:03:00.0: fb: 1024 MiB DDR3
(…)
Donc nouveau n’a pas besoin de paquet spécifique pour démarrer automatiquement (type nvidia-modprobe).
Étonnant qu’à présent (une fois tous les paquets pour driver nvidia dernière génération, désinstallés) il se lance automatiquement (peut-être que l’un d’eux bloquait son démarrage ?).
Il y a encore quelque-chose qui manque visiblement :
$ glxgears
Xlib: extension « GLX » missing on display « :0 ».
Error: couldn’t get an RGB, Double-buffered visual
$ glxinfo
name of display: :0
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Error: couldn’t find RGB GLX visual or fbconfig
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Xlib: extension « GLX » missing on display « :0 ».
Je précise que les paquets suivants sont actuellement installés : glx-alternative-mesa glx-alternative-nvidia glx-diversions libegl1-mesa libgl1-mesa-dri libgl1-mesa-glx libgl1-nvidia-legacy-340xx-glx libgl1-nvidia-legacy-340xx-glx-i386 libgles1-nvidia-legacy-340xx libgles2-nvidia-legacy-340xx libxcb-glx0 libxcb-dri3-0 update-glx
En lisant un forum UBUNTU, je découvre une manip intéressante :
Ca je connaissais :
# lspci | grep VGA
03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
Ca je ne connaissais pas :
# lspci -v -s 03:00.0
03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210]
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at ce000000 (64-bit, prefetchable) [size=32M]
I/O ports at dc00 [size=128]
Expansion ROM at fea80000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 < ?>
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting < ?>
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 < ?>
Kernel driver in use: nouveau
Kernel modules: nouveau
Lecture toute aussi instructive, le contenu du fichier /var/log/Xorg.0.log, grâce à ce forum archlinux très instructif (un grand merci à eux) :
(…)
[ 68.773] (–) Depth 24 pixmap format is 32 bpp
[ 68.789] (II) NOUVEAU(0): Channel setup complete.
[ 68.796] (II) NOUVEAU(0): [COPY] async initialised.
[ 68.897] (II) NOUVEAU(0): Hardware support for Present enabled
[ 68.897] (II) NOUVEAU(0): [DRI2] Setup complete
[ 68.897] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau
[ 68.897] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau
[ 68.897] (II) Loading sub module « exa »
[ 68.897] (II) LoadModule: « exa »
[ 68.897] (II) Loading /usr/lib/xorg/modules/libexa.so
[ 68.975] (II) Module exa: vendor= »X.Org Foundation »
[ 68.975] compiled for 1.18.0, module version = 2.6.0
[ 68.975] ABI class: X.Org Video Driver, version 20.0
[ 68.975] (II) EXA(0): Driver allocated offscreen pixmaps
[ 68.998] (II) EXA(0): Driver registered support for the following operations:
[ 68.998] (II) Solid
[ 68.998] (II) Copy
[ 68.998] (II) Composite (RENDER acceleration)
[ 68.998] (II) UploadToScreen
[ 68.998] (II) DownloadFromScreen
[ 68.998] (==) NOUVEAU(0): Backing store enabled
[ 68.998] (==) NOUVEAU(0): Silken mouse enabled
[ 69.022] (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
[ 69.022] (II) NOUVEAU(0): [XvMC] Extension initialized.
[ 69.022] (**) NOUVEAU(0): DPMS enabled
[ 69.022] (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 69.044] (–) RandR disabled
[ 69.096] (II) SELinux: Disabled on system
[ 69.147] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
(…)
En lisant le forum ci-dessus, il semblerait que les drivers nouveau et nvidia ne fassent pas bon ménage.
Pourtant dans le Wiki Archlinux il est écrit : « (…) If you want to keep the proprietary NVIDIA driver installed, but want to use the Nouveau driver, comment out nouveau blacklisting in /etc/modprobe.d/nouveau_blacklist.conf or /usr/lib/modprobe.d/nvidia.conf (…) ». Donc à priori, c’est possible de les faire cohabiter.
Je vais tenter de me concentrer davantage sur le pilote propriétaire nvidia – dans l’attente que le pilote nouveau ait atteint son niveau de performance.
Mais je garde précieusement nouveau comme alternative fiable (pour l’instant il est le seul à fonctionner, d’autant que vesa est aux abonnés absents).
Retour à Xorg pour changer de driver sous /etc/X11/xorg.conf(je ne décris pas à nouveau la manip).
J’ai ensuite lancé à nouveau quitté Xorg (# /etc/init.d/kdm stop) puis lancé la commande :
# m-a a-i -f nvidia-legacy-340xx-kernel-source
Après de nombreuses étapes, il m’a signalé sous la forme d’une erreur que le paquet « nvidia-legacy-340xx-kernel-support–v1″ n’était pas présent, et m’a proposé d’installer néanmoins quelques paquets complémentaires, ce que j’ai accepté.
J’ai tenté ensuite un :
# apt-get install nvidia-legacy-340xx-kernel-support–v1
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances
Lecture des informations d’état… Fait
Note : sélection de « nvidia-legacy-340xx-kernel-support » au lieu de « nvidia-legacy-340xx-kernel-support–v1 »
nvidia-legacy-340xx-kernel-support is already the newest version (340.96-2).
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
g++-4.9 libcggl
Veuillez utiliser « apt autoremove » pour les supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 855 non mis à jour.
J’ai relancé la compil pour être sûr : # m-a a-i -f nvidia-legacy-340xx-kernel-source
Là pas d’erreur signalée.
Je tente un modprobe nvidia, mais il me retourne une erreur « Could not insert nvidia (…) »
Là je me dis une nouvelle fois que c’est mort.
Je tente un # dmesg
Et petit espoir, il me dit que le driver ne peut pas se charger car le module nouveau est en mémoire.
Je reboot et … me voilà sous Xorg avec le driver nvidia !!!
Un : $ glxgears
J’ai la roue dentée
Un : $ glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
(…)
Yeees !!!
Précision d’importance : l’affichage via ce driver nvidia proprio est d’une qualité incomparable. L’effet de fenêtres qui bavent sur le côté droit de l’écran a totalement disparu et çà s’est confirmé par la suite (REX de plusieurs semaines : l’écran a retrouvé son affichage d’origine, je pensais vraiment que c’était soit la carte graphique soit l’écran qui étaient à remplacer, mais à présent tout fonctionne comme s’ils étaient neufs !!).
Ca avance ! Mais je m’arrête là pour ce soir car je n’ai pas la grande forme.
Petit aparté (ajouté à posteriori), la liste des paquets installés en rapport avec ma carte nvidia (version « définitive », filtre « nvidia » sous Synaptic) avec l’accélération graphique fonctionnelle et une carte graphique nvidia utilisant les anciens drivers :
glx-alternative-nvidia, libcg, libegl1-nvidia-legacy-340xx, libgl1-nvidia-legacy-340xx-glx, libgl1-nvidia-legacy-340xx-glx-i386, libgles1-nvidia-legacy-340xx, libgles2-nvidia-legacy-340xx, libnvidia-legacy-340xx-eglcore, nvidia-kernel-common, nvidia-kernel-4.3.0-1-686 (pour mémo, non installé), nvidia-kernel-4.3.0-1-686-pae (pour mémo, non installé), nvidia-legacy-340xx-alternative, nvidia-legacy-340xx-kernel-4.3.0-1-686-pae (créé par la compilation du driver), nvidia-legacy-340xx-kernel-source, nvidia-legacy-340xx-kernel-support, nvidia-modprobe, nvidia-settings-legacy-340xx, nvidia-support.
(pas sûr qu’ils soient tous complètement indispensables, mais ils sont installés)
Optionnels :
libvdpau1 (dépendance vis à vis de gxine et mplayer2), libxnvctrl0, mate-sensors-applet, mate-sensors-applet-nvidia, nvidia-installer-cleanup, nvidia-legacy-340xx-smi, nvidia-xconfig
————————————————————————————
Le 5 Février
Donc çà y est : le module nvidia fonctionne, et l’accélération graphique fonctionne directement, sans nécessiter le chargement préalable du module, me voilà sous kdm sans rien faire.
Cerise sur le gâteau, la connexion aux comptes provisoires de test (j’avais notamment créé un compte « toto ») fonctionne également – sans avoir rien fait de plus (jusqu’ici je recevais un message de type « Oops, la connexion a échoué » ou un truc comme çà.
Me voilà par défaut sous un joli GNOME3. Le problème pour moi c’est ce panneau « Activités » auquel je ne me fais pas. Mais c’est une affaire de goûts. Le reste est irréprochable : c’est beau, c’est simple.
J’ai envie et hâte de retrouver mon p’tit bureau MATE (et de tester la dernière version de KDE vite fait).
Mais avant cela je vais tester la création des répertoires utilisateurs en manuel (la manip qui n’avait pas fonctionné précédemment : créer un répertoire utilisateur via le gestionnaire de fichier).
Bingo !
Je n’avais pas rêvé : çà marche nickel !
Il suffit (via votre gestionnaire de fichier connecté en root) d’effacer ou renommer (plus prudent) le répertoire utilisateur précédent (il faut être connecté sous un autre utilisateur évidemment sinon vous allez probablement planter la session en cours) et de créer un répertoire vierge portant son nom avec les droits en lecture/écriture pour l’utilisateur et son groupe et (éventuellement) pas de droits pour les autres utilisateur.
Ensuite vous vous connectez et le système initialise automatiquement les répertoires nécessaires. Une bonne manip selon moi pour faire du claire après une grosse mise à jour du système d’exploitation. Mais il vaut mieux sauvegarder l’ancien compte quelques temps pour venir y récupérer d’éventuels fichiers tels que les bookmarks de votre navigateur internet.
Je suis à peu près certain que précédemment çà ne fonctionnait pas parce que l’accélération graphique plantait le gestionnaire de connexion (j’aurais dû vérifier les messages de logs).
Autre test : gdm3
(interruption personnelle indépendante du système :) )
————————————————————————————
Le 6 Février
Autre test : gdm3 (suite)
La reconfiguration du gestionnaire puis le démarrage de gdm3 par :
(avec l’arrêt préalable du précédent kdm par : # /etc/init.d/kdm stop)
# dpkg-reconfigure gdm3
# /etc/init.d/gdm3 restart
Ne fonctionne pas.
L’écran et la led de verrouillage numérique du clavier se mettent à clignoter de manière ininterrompue.
Seul un # /etc/init.d/gdm3 stop parvient à arrêter cela.
J’ai d’abord cru qu’il ne fonctionnait pas.
J’ai tenté un :
# apt-get remove –purge gdm3
Pour tenter un nettoyage d’anciens éventuels fichiers. Et notamment un ancien script m’a été signalé comme ne pouvant être enlevé du répertoire /etc/gdm3.
N’étant pas à l’origine de ce fichier, j’ai donc définitivement effacé le répertoire par un (attention commande très dangereuse car pouvant tout effacer si vous vous trompez d’adresse) : # rm -R /etc/gdm3
Puis ré-installé gdm3 par : # apt-get install gdm3
Puis un : # /etc/init.d/gdm3 restart
Même j’obtiens le même résultat (clignotement simultané de l’écran et de la led)
Je me suis d’abord dis que çà ne fonctionnait pas.
Dans un 2ème temps (aujourd’hui), j’ai pensé qu’il fallait redémarrer (çà n’était pas nécessaire avant et çà ne devrait pas l’être).
Je redémarre, et là bingo, gdm3 démarre !
kdm est très bien en plus d’être fiable en toute circonstance, néanmoins j’ai une préférence pour gdm3 que je trouve plus beau et nettement plus ergonomique.
Bon voilà un autre problème (presque) réglé.
Arf, je viens de m’apercevoir que gdm3 pose problème quand on souhaite le redémarrer (après un plantage d’une application sous Xorg par exemple) : il se remet à clignoter et l’on ne peut rien faire en dehors de redémarrer. Problématique çà.
Autre souci : il est très long à démarrer et le boot est devenu une galère, car la phase est interminable (dans « interminable », il y a « minable » :) ).
Le système passe son temps à vérifier les disques (en ext3 c’est super long) et j’ai encore des messages d’erreurs :
Sous : $ dmesg
J’ai :
[ 6.496666] systemd-gpt-auto-generator[217]: /dev/sda: failed to determine partition table type: Input/output error
[ 7.034200] systemd[208]: /lib/systemd/system-generators/systemd-gpt-auto-generator failed with error code 1.
Nota (rien à voir mais j’ai la confirmation de ce que j’écrivais l’autre jour) :
[ 17.258834] EXT4-fs (sda5): mounting ext3 file system using the ext4 subsystem
et j’ai :
[ 294.070616] gnome-shell[2598]: segfault at 0 ip b599902b sp bfa88f10 error 6 in libX11.so.6.3.0[b595c000+14d000]
[ 294.694597] gnome-shell[2666]: segfault at 0 ip b59e102b sp bfcbcca0 error 6 in libX11.so.6.3.0[b59a4000+14d000]
[ 297.675048] NVRM: Your system is not currently configured to drive a VGA console
[ 297.675053] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
[ 297.675055] NVRM: requires the use of a text-mode VGA console. Use of other console
[ 297.675057] NVRM: drivers including, but not limited to, vesafb, may result in
[ 297.675059] NVRM: corruption and stability problems, and is not supported.
[ 367.450214] fuse init (API version 7.23)
[ 570.396504] perf interrupt took too long (2518 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Punaise, je n’en sort pas des emmerdes :)
Je suis entrain de faire la démonstration contraire : qu’il vaut mieux formater son système quand il est trop vieux :)
Jusqu’ici – et en ce qui me concerne, la mise à jour a toujours été largement plus intéressante car formatrice et moins consommatrice de temps libre. J’en ai ici le contre-exemple.
C’est pas grave, je n’ai pas envie de m’arrêter en si bon chemin. Je poursuis pour l’instant.
Ca va être un memorandum de toutes les emmerdes possibles sous Linux, çà va attirer (via les moteurs de recherche) plein d’internautes Linuxiens chez moi :)
Je change de page car celle-ci est si longue que WordPress rame sérieux.