Buster : j'ai fait une bêtise de plus, est-ce réparable ?

Support Debian
#1

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é :angry:
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.

#2

Bonjour,

C’est un peu ancien comme article, mais si cela peut t’aider :
https://linuxfr.org/forums/linux-debian-ubuntu/posts/comment-recuperer-des-fichiers-supprimes-avec-un-rm-f

Suppression du dossier home
#3

Merci de ce lien, Albert.
Je vais attendre demain pour tester .
Si d’autres avis je suis preneur.

#4

reinstaller le noyau

apt install --reinstall linux-image-4.19.0-5-amd64
1 J'aime
#5

Et que te dit un

uname -a

Amicalement.

Jean-Marie

#6

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. :roll_eyes:

@ 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.

#7

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

#8 
journalctl -p err

tu veux peut être dire startx ?

#9

Oui, bien “startx” mode gros doigts = touches loupées.

Je vais faire ta commande et je reviens.

#10

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.

#11 
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

#12

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 ???

#13

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 :joy:

#14

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.

#15

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.