Après avoir supprimé une image très ancienne, j’ai lu qu’il fallait enlever le module correspondant à la main, s’il n’avait pas été pris en compte dans le remove --purge. C’était le cas.
J’ai vérifié ce que /lib/modules contenait : 3 dossiers :
3.16.0-4-amd64
4.9.0-3-amd64
4.19.0-5-amd64
En plus du dernier, j’ai voulu garder l’avant-dernier, en secours.
J’ai entré la commande suivante :
sudo rm -r /lib/modules/3.16.0-4-amd64
Résultat : /lib/modules entièrement vidé 
Bien sûr, Plus d’X.
Peut-être ai-je fait une erreur dans ma commande, peut-être ai-je oublié d’entrer la dernière ligne oblique ???
J’ai deux autres Buster (sur disques différents)qui fonctionnent bien, une sous NVIDIA, comme celle que je viens de tuer, l’autre sous NOUVEAU.
Bien sûr, je ne les modifie pas, celles-là.
Est-ce que cette bêtise se répare ou je suis bon pour une réinstallation ?
Merci.
Merci de ce lien, Albert.
Je vais attendre demain pour tester .
Si d’autres avis je suis preneur.
reinstaller le noyau
apt install --reinstall linux-image-4.19.0-5-amd64
Salut, Grandtoubab.
Tu dois avoir raison, et je vais tenter ça tout de suite.
J’ai honte de ne pas y avoir pensé. Je crois que je vais changer mon pseudo en Don Diègue. 
@ Diesel :
4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux
Le même que le disque sur lequel je suis actuellement et dont Buster fonctionne parfaitement.
Ben non, pas mieux !
La réinstallation s’est bien faite, mais au reboot, toujours deux erreurs en rouge au défilement. Impossible e les lire.
Je n’ai rien vu dans /var/log/dmesg
Quels logs faudrait-il aller voir ?
startx n’est plus reconnu, certainement remplacé par une autre commande ???
Il n’y aurait pas une commande avec ‘modeprobe’ ???
Merci
journalctl -p err
tu veux peut être dire startx ?
Oui, bien “startx” mode gros doigts = touches loupées.
Je vais faire ta commande et je reviens.
Résultat de “journalctl -p err” :
Je passe sur des erreurs de port usb que je traine depuis longtemps et qui n’ont pas d’incidences pour moi.
1/
systemd-modules-load[310] erreur running install co....(Fin de ligne : lecture de la suite impossible)
failed to install module
2/
systemd-udev[372] même chose que dessus : erreur running install puis failed
3/
nvidia-persistenced [565] failed to query nvidia...
Pour le dernier, je peux revenir sur “nouveau”, mais ce n’est pas ça qui règlera les problèmes de systemd.
À te lire, et merci encore.
journalctl -p err -l --no-pager
donnera les lignes entières mais ça ne m’inspire rien
il y a aussi
systemctl --failed
pour voir les services qui ont échoués
Pas grandes découvertes, en effet :
pour les “failed” :
nvidia-persistented.service failed failed nvidiaPersistence daemon
system-modules-load.service
Pour journalctl :
nvidia = idem dessus
+
error resolving pool 1.debian.pool-ntp.org
temporary failure in name resolution (-3)
Je pense que je pourrais déjà remplacer nvidia par Nouveau (qui fonctionne très bien sur un autre disque). Ainsi, il n’y aurait plus qu’une seule grosse erreur à essayer de corriger.
Qu’en penses-tu ?
Sinon, sur le présent disque, qui est le clone de celui que j’ai massacré, est-ce que je ne pourrais pas copier les dossiers qui sont dans /lib/modules et les coller sur le malade ???
pour avoir plus d’infos sur chaque service
systemctl status nvidia-persistented.service
systemctl status system-modules-load.service
je ne connais rien aux cartes Nvidia
il y a apparemment aussi un problème de dns car il ne sait pas atteindre le pool pour synchroniser l’horloge
dig pool.1.debian.pool-ntp.org
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> pool.1.debian.pool-ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pool.1.debian.pool-ntp.org. IN A
;; ANSWER SECTION:
pool.1.debian.pool-ntp.org. 3600 IN A 108.61.159.72
;; Query time: 110 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: sam. août 03 08:40:23 CEST 2019
;; MSG SIZE rcvd: 71
Ce sont tes disques tu les massacre à ta guise 
Je n’étais pas présent ce jour.
aux deux systemctl status, il est répondu qu’il ne trouve pas.
Demain, je mets en service une seconde machine car il est difficile de recopier une commande sans faire de fautes et d’avoir à passer d’un disque à un autre.
Bonne soirée.
J’ai règlé sommairement mon problème d’X en supprimant nvidia-*
Je suis sous nouveau.
Il subsiste des erreurs mais comme elles n’ont pas l’air de poser de problèmes, je vais patienter, jusqu’à ce que qq’un qui connait la marche à suivre me l’indique.
Je liste ci-dessous le “journalctl -p err”.
Je n’ai pas encore testé après reboot, mais auparavant, je vais déjà sauvegarder.
août 04 16:10:09 stretch-ssd ntpd[735]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
août 04 16:10:10 stretch-ssd kernel: usb 8-5: device not accepting address 5, error -32
août 04 16:10:10 stretch-ssd kernel: usb usb8-port5: unable to enumerate USB device
août 04 16:10:10 stretch-ssd ntpd[735]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
août 04 16:10:12 stretch-ssd /hpfax[1043]: [1043]: error: Failed to create /var/spool/cups/tmp/.hplip
août 04 16:10:15 stretch-ssd minissdpd[1360]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
==========
Ne pas tenir compte du nom de la machine qui n’a pas été modifié (stretch). En fait, je suis sous Buster 4.19.0-5-amd64. Disque = SSD ; SDDM et KDE.
EDIT :
Reboot effectué : no problem.