Reprise du message précédent :

 
Donc tu ouvres un terminal et tu tappes/copies: /usr/sbin/xfpm-power-backlight-helper --set-brightness 10

Si si sous Ubuntu je pouvais le régler, mais j'ai un vague souvenir d'avoir galéré aussi à l'époque (il y a longtemps)

Quand je regarde les fichiers dans /sys/class/backlight/acpi_video0/ j'ai :

• bightness = 10
• actual_brightness = 10
• max_brightness = 10
• scale = unknown
• type = firmware

Bon bah tu testes avec sudo. Sauf que ton histoire de fichier dans /sys/ ça n'inspire pas confiance. Je sèche et je laisse ma place...

est ce que ça marche avec xbacklight ?

si tu fais (en root) un truc du genre :

il se passe quelque chose ?

Attends parce qu'en attendant j'ai tenté de modifier le fichier grub et après reboot j'ai plus de slider pour la luminosité et le clavier ne marche plus

 
J'ai testé l'installation de brightness controller mais en fait ce truc assombri l'écran sans jouer sur la luminosité

Mjules disait en tant que root, donc avec sudo devant.

hmm, il s'est passé quelque chose entre ces deux posts vu que le fichier existait tout à l'heure.

Je confirme que les fichiers ont disparu

Tu disais avoir modifié la config grub, tu as fait quoi? Les fichiers réaparaissent après un redémarrage?

Help, mon daron a un souci sur Mint xfce car il vient de faire une maj :

Bien sûr j'habite à 800 bornes de lui

C’est à l’arrêt, ça ? Vu que ça se produit à 24 111 secondes après le dernier démarrage…

L’erreur est donc que le processus servant à arrêter le système crashe car il ne trouve pas le fichier libpcre2-8.so.0 (apparemment, il est nécessaire pour ça, mais le fichier n’existe pas ; peut-être que la MAJ a oublié de créer un lien symbolique requis). Et après, il arriverait pas à « faire un sync » (nécessaire pour le démontage propre des disques) et tenterait de tuer le processus « init » (le processus initial, qui gère tous les services système et est le premier à être lancé au démarrage).

Il a essayé de redémarrer ? Si ça se trouve, faut juste relancer et ça se règlera de soi-même (même si ça ne devrait évidemment pas arriver).

Il me dit que c'est arrivé quand il a cliqué sur le bouton redémarrer qui est apparu à la fin de la MAJ. Je vais lui dire de forcer le reboot et je pense qu'à Noël je lui laisserai une clé USB avec Mint dessus au cas où (je comprends que ça peut servir de dépannage).

Après reboot manuel c'est rentré dans l'ordre, ouf !

Eh ben, voilà !
 
Ouais, il peut arriver que des mises à jour nécessitent vraiment de redémarrer (parce que la version actuellement chargée dans la RAM n’est plus celle présente sur le disque). Dans le cas du noyau ou d’autres logiciels critiques, c’est pas un état à faire perdurer pour éviter des incompatibilités.
 
Ça ne change rien au fait qu’une MAJ du système bien faite (et là, je parle de comment l’équipe de Mint aurait dû la préparer ; pas de ton père qui ne devrait normalement pas avoir à se soucier de ça, et encore moins se demander si faire la mise à jour ne va pas causer des problèmes comme celui-ci) ne devrait pas causer un plantage. Surtout sur une distribution qui se veut aussi clefs-en-main et pas prise de tête comme Mint. Après, il pourra toujours y avoir des couacs à l’occasion, mais faut que ça reste une exception.

Ouais j'avoue que j'ai cru perdre trop rapidement en crédibilité mais ça va
Next step : lui laisser une clé USB avec Mint dessus au cas où et surtout réussir à configurer Remmina pour prendre le contrôle à distance mais quand on a essayé l'autre fois on y arrivait pas

La clé de secours est une bonne idée, à condition de bien configurer le UEFI pour que l'ordi démarre depuis la clé si elle est présente. Ca peut être un peu délicat, donc selon le niveau de l'utilisateur vaut mieux prévoir. Et prévoir une clé Live ou une installation sur clé AVEC Rustdesk ou du genre pour un accès à distance.

Bah logiquement j'ai pas touché à la priorisation du boot quand j'ai installé Mint depuis une clé USB donc ça a du rester en l'état non ?