19 Jun 2019, 00:00

Désactiver la mise en veille de la carte son sous Linux

Sous Linux, il arrive que, pour économiser de l’énergie, la carte son se mette en veille après quelques temps d’inactivité. Ceci génère chez moi des craquements assez désagréables lors de sa remise en fonctionemment, ou parfois un craquement très régulier tout le long de la veille.

Pour voir si la mise en veille est activée :

cat /sys/module/snd_hda_intel/parameters/power_save

S’il contient autre chose que 0, alors le mode powersave est activé.

Pour le désactiver, on peut ajouter le fichier /etc/modprobe.d/snd_disable_powersave.conf et entrer dedans la ligne suivante :

options snd_hda_intel power_save=0

Puis redémarrer, ou bien décharger/recharger le module.

07 Jan 2019, 00:00

Notes rapides sur récupération mdadm

Disques tous en spare

Après une panne d’éléctricité, un RAID6 de 12 disques (dégradé, avec 1 disque manquant) a refusé de se remettre en route. Après vérification (par live-cd) via un cat /proc/mdstat, les 11 disques étaient tous en spare (se manifeste par un [S] ).
Pour ce raid sont utilisées les 2e partitions de chaque disque de sda -> sdk. J’ai vérifié l’état de synchronisation de tous les volumes : sudo mdadm --examine /dev/sd[abcdefghijk]2 | grep Events

Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752

Ils sont bien synchronisés, mais pas assemblés. J’ai alors testé
sudo mdadm --assemble --force /dev/md126 /dev/sd[abcdefghijk]2
mais ai obtenu 11 jolis “Device or ressource busy”. Ce qui est normal, les disques étant intégrés dans le RAID, mais en spare. J’ai alors lancé
sudo mdadm --stop /dev/md126
suite à quoi la commande d’assemblage précédemment citée a bien fonctionné, le RAID s’est resynchronisé sans perdre de données, en prenant toutefois son temps.

RAID fonctionnel qui ne se synchronise pas tout seul

Dans un autre cas, où le RAID était resté fonctionnel mais dans lequel un volume manquait (sdl2, détecté mais non intégré/synchronisé), j’ai pu le réintégrer avec la commande sudo mdadm --re-add /dev/md126 /dev/sdl2 (si re-add ne fonctionne pas, add devrait fonctionner mais prendre plus de temps).

Dans encore un autre cas, un seul disque était intégré au RAID, mais non synchronisé, car il restait en “spare”. J’ai pu forcer la réintégration avec la commande
echo check > /sys/block/md126/md/sync_action
De la lecture intéressante se trouve sur cette page.

Ici aussi : https://robbat2.livejournal.com/231207.html?nojs=1

06 Jan 2019, 00:00

Ripper des cd audio avec abcde et intégrer l'image dans les fichiers

Suite à quelques soucis de recherche dans la base CDDB avec Asunder, voici un mini-tuto pour abcde. Déjà,

sudo apt install abcde lame eyed3 glyrc imagemagick cdparanoia

Les préférences d’extraction se définissent dans le fichier /etc/abcde.conf ou bien dans un fichier user qui outrepassera le précédent, et que nous éditons ici : pluma ~/.abcde.conf

# VBR bonne qualité
LAMEOPTS='-V 0'
# On extrait la couverture
ACTIONS=default,getalbumart
# On range les fichiers finaux dans ce dossier :
OUTPUTDIR="/path/to/music/dir"
# On encode en mp3
OUTPUTTYPE=mp3
# Arborescence type Artiste/Album/01 - Morceau.mp3
OUTPUTFORMAT='${ARTISTFILE}/${ALBUMFILE}/${TRACKNUM} - ${TRACKFILE}'
# On ne remplace PAS les espaces par des underscores (et autres modifs)
mungefilename ()
{
echo "$@"
}

On peut ensuite lancer abcde ou encore abcde -d /dev/sr1 si on spécifie manuellement le lecteur CD.

Enfin, dans le dossier final, si on souhaite intégrer la pochette au fichier :

for i in *.mp3
do
eyeD3 --add-image cover.jpg:FRONT_COVER "$i"
done

(cf cette page)

30 Dec 2018, 00:00

Freeze du poste avec Optimus lorsque bumblebee est installé

Habituellement, lorsque je souhaite installer une Debian sur un pc avec double carte graphique Intel-Nvidia (système Optimus), il suffit d’installer bumblebee via apt install bumblebee bumblebee-nvidia (ou simplement bumblebee si on souhaite essayer avec les pilotes libres Nouveau, ce qui m’a semblé fonctionner moins souvent).
La configuration des paquets met en place toute la configuration nécessaire (glx, alternatives, modprobe/blacklist etc). Ceci installe également un module noyau bbswitch, dont le but est d’éteindre ou d’allumer à la demande la carte graphique dédiée.

Cependant, sur un poste, après avoir installé ces paquets, le pc freezait au démarrage, que le pilote soit nouveau ou nvidia. Comme le pc démarrait correctement en mode recovery, j’ai désactivé le lancement automatique du gestionnaire de connexion graphique. Ainsi, le pc démarrait correctement, je pouvais me connecter, mais dès le moindre service lightdm start ou startx, il freezait à nouveau. Après pas mal de lecture, j’ai appris que le fichier /proc/acpi/bbswitch contenait entre autre l’état de la carte graphique (ON ou OFF), et que la commande tee /proc/acpi/bbswitch <<<ON permettait de l’allumer à la demande.
Et j’ai constaté que la carte était en OFF à chaque démarrage, que si on essayait de lancer un programme graphique (même une interface graphique qui tourne sur la carte intégrée au CPU) alors que la carte dédiée était OFF, alors ça freezait. Si par contre on allumait manuellement la carte avant, on pouvait lancer l’interface, et ensuite ça fonctionnait, même si la carte était coupée. Mais si on souhaitait simplement se déconnecter, comme ceci coupe puis relance l’interface graphique, alors ça freezait à nouveau…

Mais avec le détail des cas où ca plantait, j’ai facilement trouvé ce rapport de bug, et après moult tests, modifier la ligne dans le fichier /etc/default/grub pour qu’elle ressemble à ceci :

GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi='Windows 2009'"

suivi d’un update-grub a bien fonctionné ! Les graphiques standards sont bien lancés sur le gpu intégré, le gpu dédié est éteint la plupart du temps, allumé correctement lorsqu’on lance un programme avec optirun, et bien éteint lorsque ce programme se termine.

07 Nov 2018, 00:00

Réinitialiser le mot de passe BIOS sur certains portables HP

HPBR

Un outil nommé HP Bios Reset permet, sur certains modèles, notamment des Probook et des Elitebook, de réinitialiser le mot de passe du bios. Lien vers le thread mydigitallife.
Et un exemplaire de HPBR mirroré chez moi

Il faut déjà créer la clé bootable.
Depuis Windows, il suffit de lancer l’exécutable, de brancher la clé (qui sera effacée), la sélectionner, cliquer sur Restore, choisir le fichier image fourni dans l’archive.
Sous Linux, je n’ai pas testé, mais je présume que l’image se dumpe simplement sur la clé avec dd.

On boote l’ordinateur sur la clé. Au lancement, il faut en trer les commandes suivantes :

cd ..
HPBR

Dans “reprogram” on peut sauvegarder les informations actuelles (fichiers .sav dans le répertoire HPBR).
Dans “first run” on peut lancer la réinit du mot de passe du bios en choisissant le bon modèle.

Forcer l’upgrade du bios

Dans mon cas, le bios était trop vieux, et n’était pas supporté par HPBR. J’ai donc du faire la mise à jour, mais la procédure standard me demandait le mot de passe, que je n’avais toujours pas.

Pour ceci, des indications données sur ce post peuvent être utiles. Les images et signatures de BIOS sont stockées dans le dossier Hewlett-Packard/BIOS/Current. L’image HPBR en contient certains, mais pas tous. On peut donc rajouter celui d’un autre modèle.
J’ai donc récupéré le bios le plus récent sur le site de support de HP.
J’ai extrait le fichier exe, puis le fichier rom.cab.
Dedans, il y’a un fichier “ver.txt”, on trouve dedans le numéro de la ROM, par exemple _ROM_ 68PDD v0F.20 12/07/2011 ROLL_BACK_WARNING
Dans ce cas, c’est “68PDD”. On renomme rom.bin par 68PDD.bin et efibios.sig par 68PDD.sig, on copie ces 2 fichiers dans “Current” (à noter que sur un clé usb vierge en fat32, l’arborescence et ces 2 fichiers suffisent pour la MAJ du BIOS, pas besoin de HPBR).
On éjecte la clé proprement.

Ensuite, il faut faire booter l’ordi sur la clé, mais pas par le boot habituel. Il faut, ordi éteint, brancher la clé, maintenir Super+B, allumer le pc en maintenant les touches enfoncées, normalement la LED de VerrMaj clignote, puis le voyant de la clé usb (s’il y’en a un…) va commencer à clignoter. C’est le moment de relacher les touches.

Normalement l’écran reste noir, pendant au maximum 2 minutes (selon le readme), puis devrait redémarrer tout seul et informer du succès de la mise à jour. Il est alors possible de reset le mot de passe via HPBR
Si rien ne se passe au bout de 10 minutes (soyons précautionneux…) ,c’est que la MAJ n’a pas réussi, et il faut redémarrer le poste.

29 Oct 2018, 00:00

Utilisation de ddrutility pour identifier les secteurs contenant de la données NTFS pour une utilisation optimale de ddrescue

EDIT

Il semblerait que partclone permette aussi de créer le fichier domaine, sur plusieurs systèmes de fichiers, avec la syntaxe :

sudo partclone.FSTYPE -s /dev/sdX_1 -D --offset_domain=1048576 -o ./domain.log

L’option -s (sdX_1) précise la source, c’est-à-dire la partition à cartographier (par ex sdb1 ou loop0p1),
-D précise que nous souhaitons créer un fichier de domaine,
l’offset calculé de la même manière qu’expliqué plus loin dans l’article (et utile seulement si on dumpe le disque entier),
-o nomme le fichier de sortie.
A noter que le fichier créé est par défaut non lisible par les non-root. De plus; le fichier de domaine n’intégrera pas (contrairement à ddrutility) les zones à lire pour identifier correctement la table de partition et les débuts/fins de partitions.

———

Cet article se penche sur l’utilisation de ddrutility pour créer un fichier de carte de domaine à utiliser avec ddrescue, afin de focaliser ce dernier sur les secteurs qui contiennent effectivement des données. Dans cet exemple, je ne parle que du ntfs.

L’ensemble d’utilitaires ddrutility peut être installé depuis les dépôts Debian à partir de Buster, ou bien compilé depuis la source disponible ici.

L’utilitaire qui nous intéresse : ddru_ntfsbitmap qui va créer un fichier de domaine, c’est-à-dire une liste des secteurs à lire sur la partition ntfs (secteurs effectivement utilisés). Concrètement, ce fichier a le même format qu’un fichier mapfile de ddrescue, mais où les secteurs censés contenir des données sont déterminés grâce à l’analyse du MBR et de la MFT, et sont marqués comme “finished” (lus), bien que rien ne soit effectivement lu.

Ceci ne fonctionnera que si ddrescuelog est présent dans la release de ddrescue (à partir de la version 1.15, normalement)

Création du fichier de délimitation du domaine

Voici la syntaxe pour une partition seule :

sudo ddru_ntfsbitmap /dev/sdX1 ./domain_ntfs.log

Dans mon cas, j’ai l’habitude de dumper le disque en entier, y compris la table de partitions. Pour ceci, il faut calculer l’offset de la partition (en octets) avec des maths assez simples : multiplier le secteur de démarrage de la partition par la taille d’un secteur en octets. Pour ceci : sudo fdisk -lu /dev/sdX qui nous donne par exemple :

Disk /dev/sdX: 465,7 GiB, 500074283008 bytes, 976707584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004a183

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdX1        2048 976707583 976705536 465,7G  7 HPFS/NTFS/exFAT

On voit que la partition démarre au secteur 2048, et que chaque secteur (logique) pèse 512 bytes (octets).
Dans le cas où les valeurs logique et physique sont différentes, il faut prendre la valeur logique.
On multiplie donc : 2048*512 = 1048576, puis on passe l’argument -i à ddrutility, ce qui donne la commande

sudo ddru_ntfsbitmap /dev/sdX ./domain_ntfs.log -i 1048576

Ceci va aller lire le secteur de boot de la partition ntfs, puis la section bitmap afin de déterminer quels sont les clusters sur lesquels des données sont stockées.
Selon la doc de ddrutility, si des secteurs du bitmap sont illisibles, alors ddrutility va les remplir avec le motif 0xFF (soit uniquement des 1), ce qui signifie que les secteurs en question sont utilisés pour stocker des données. Ainsi, en l’absence de certitude (grâce à la lecture correcte du bitmap) qu’un secteur est inutilisé, alors il sera extrait par ddrescue. On a ainsi le “risque” de lire des secteurs inutilisés, mais beaucoup moins de risque de sauter des secteurs sur lesquels des données sont effectivement stockées !

On obtient plusieurs fichiers en résultat :

  • __bootsec qui est un dump du secteur de boot de la partition (et est utilisé pour trouver l’emplacement de la MFT
  • __bootsec.log : la mapfile ddrescue utilisée pour l’extraction du secteur de boot

  • __mftshort : dump de la MFT

  • __mftshort.log : mapfile utilisée par ddrescue pour dumper la MFT

  • __bitmapfile : dump du fichier $BitMap de la partition

  • _partX__bitmapfile.log : fichier mapfile utilisé par ddrescue pour dumper le fichier $BitMap. Il est possible qu’il y en ait plusieurs si le fichier $BitMap est fragmenté

  • ntfsbitmap_rescue_report.log : résumé des différentes passes de ddru

  • domain_ntfs.log : le fichier à donner à ddrescue lors de la réelle tentative de récupération de données. Le nom dépend de la ligne de commande invoquée.

Utilisation de ce fichier avec ddrescue

Il faut impérativement penser à accorder la ligne de commande ddrescue avec celle utilisée par ddrutility pour obtenir le fichier domaine. Notamment déterminer si on dumpe une partition ou bien un disque entier. Dans mon cas, c’est un disque entier.

Une fois le fichier obtenu, on peut lancer la récupération de données avec ddrescue avec l’option -m, comme ceci :

sudo ddrescue -m ./domain_ntfs.log /dev/sdX ./disk_image.img mapfile.log

Si on souhaite suivre l’avancement en graphique avec ddrescueview, il est possible dans le menu de ce dernier d’ouvrir une mapfile de domaine (et séléctionner domain_ntfs.log). Ainsi, le secteurs hors domaine seront coloriés en grisé.

À noter qu’il est possible de combiner cette méthode avec ddrescue sans carte de domaine, en utilisant le même fichier source (disque défectueux), la même destination et la même mapfile. Après avoir laissé tourner ddrescue séquentiellement sur le disque, et une récupération extremement lente (quelques ko/s), j’ai repris l’avancement en cours en rajoutant l’argument de la carte de domaine. Il est également possible de reprendre le dump du disque sans carte de domaine une fois que tous les secteurs sur la carte de domaine ont été correctement récupérés (même si cela devrait théoriquement être inutile).

Analyse des secteurs défectueux pour connaître les fichiers affectés

Le disque dur sur lequel je travaillais m’a donné un taux de récupération supérieur à 99%, mais toutefois incomplet.
Pour connaître la liste des fichiers dont certains secteurs peuvent être manquants, ddrutility propose un autre utilitaire, ddru_ntfsfindbad.

Bien qu’il puisse fonctionner directement sur le disque, il est plutôt prévu pour être utilisé sur l’image résultant de la récupération avec ddrescue. En effet, à ce stade, l’image devrait être suffisamment complète pour ne pas avoir à refaire de lecture lente et incertaine sur le disque défaillant.

De la même manière que ddru_ntfsbitmap, cet utilitaire va avoir besoin de connaître l’offset de la partition, et de pouvoir lire la MFT ntfs (si cette dernière est endommagée, le processus risque d’être compliqué et infructueux…).

Pour ceci, je lance : ddru_ntfsfindbad ./disk_image.img mapfile.log -i 1048576
Le fichier disk_image.img doit être précisément celui créé par ddrescue.
Le fichier mapfile.log doit aussi être celui utilisé par ddrescue.
L’offset (-i) doit être le même que celui determiné à l’étape ddru_ntfsbitmap (si seule la partition du disque défaillant est dumpée, alors il vaut 0 et n’a pas besoin d’être précisé).
Seront comptabilisés comme secteurs non lisibles au moins les secteurs “non-trimmed” et les secteurs “failed”, mais pas les “non-tried”.

L’outil va ensuite créer un fichier ntfsfindbad.log, qui contient la liste des fichiers/dossiers dont la récupération est incomplète, et qu’il suffit de lire pour obtenir les informations !
Notons enfin que l’outil est prévu pour lister les fichiers qui sont dans la corbeille (et qui seront clairement affiché comme présents dans le dossier “$RECYCLE.BIN”), mais PAS les fichiers supprimés (pour ceci, un outil du genre testdisk ou photorec est plus adapté).

27 Apr 2018, 00:00

Monter une image de disque complet sous Linux (y compris Gparted, et VirtualBox)

Présentation et analyse

Si on a créé une image entière de disque (par exemple avec dd , dcfldd ou bien ddrescue), il est possible de la monter au sein du système, pour qu’elle soit détectée par le noyau, par Gparted, et même transférable (en tant que disque brut) à une machine virtuelle sous VirtualBox.

Dans mon exemple, on a le fichier /home/user/sdi.img, qui est une image complète d’un disque (avec le boot code et la table de partition, dans cet exemple au format MBR).

On vérifie la structure de l’image (qui doit être une copie du disque, donc avec une ou des partitions) : sudo fdisk -l ~/sdi.img. Chez moi, ça donne :

Disk sdi.img: 1,8 TiB, 2000399892480 bytes, 3907031040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x909b28dc

Device     Boot Start        End    Sectors  Size Id Type
sdi.img1   *     2048 3907031039 3907028992  1,8T  7 HPFS/NTFS/exFAT

J’ai bien la partition sdi.img1, formattée en NTFS.

Montage du disque complet

On utilise pour ça la commande losetup (en root).
Si on l’exécute toute seul, elle nous liste les périphériques actuellement montés. Par défaut, ce devrait être vide.
Si on l’exécute avec le paramètre -f, elle nous donne le premier périphérique disponible pour monter une image. Par défaut, ce devrait être /dev/loop0.

On monte l’image sur le périphérique loop : sudo losetup -r -P /dev/loop0 ~/sdi.img.
Note : l’option -r sert à monter le périphérique en lecture seule, pour éviter les corruptions de données, au cas où.
L’image est bien montée (vérifiable avec losetup sans argument), mais la partition n’est pour l’instant pas prise en compte par le noyau. (EDIT : plus vrai avec l’option -P)

Prise en compte de la table de partition par le noyau

EDIT : l’option losetup -P permet de faire cette étape automatiquement. Ceci dit c’est toujours bien d’avoir un peu les détails des rouages :)

Pour ceci : sudo partprobe /dev/loop0.

Ceci va dire au noyau d’aller réactualiser la table des partitions connues (en l’occurence en n’analysant que le périphérique loop0). Ceci a du créer les périphériques pour chacune des partitions de l’image (pour moi une seule). On vérifie : ls -l /dev/loop0* qui donne chez moi :

 20423171 brw-rw---- 1 root disk   7, 0 avril 27 13:56 /dev/loop0
213017956 brw-rw---- 1 root disk 259, 0 avril 27 13:56 /dev/loop0p1

J’ai bien le périphérique loop0p1 qui représente la première partition de mon image. On peut alors utiliser cette partition comme une partition physique : la monter (sudo mount /dev/loop0p1 /mnt), la fsck (sudo fsck /dev/loop0p1) etc.
On peut également manipuler l’image comme un vrai disque avec Gparted : sudo gparted /dev/loop0. Il faut spécifier manuellement l’emplacement, car Gparted sans argument ne liste que les disques physiques.

À noter, si la partition a été retrécie via GParted, l’image du disque ne le sera pas pour autant (car l’espace non-partitionné existe toujours). Pour ceci, suivant les conseils de ce billet, on peut lancer la commande sudo fdisk -l /home/user/sdi.img pour analyser la table de partition, puis utiliser la commande truncate pour couper l’image dès que la partition se finit. Pour ceci, on multiplie le numéro de secteur final de la dernière partition+1 par la taile des secteurs (logique, je suppose, en cas de différence entre physique et logique. A vérifier).

Par exemple, selon mon exemple en début d’article :

truncate --size=$[(3907031039+1)*512] /home/user/sdi.img

Accès à l’image depuis Virtualbox

VirtualBox permet l’accès depuis le système invité aux disques physiques de la machine hôte. Cela se fait via les disques virtuels VMDK.

Cette partie est grandement recopiée de ce billet.

On commence par s’assurer qu’on fait bien partie du groupe disk : sudo usermod -G disk -a `whoami` (et on pense à log out pour appliquer les modifs). Ceci permet de pouvoir accéder aux disques sans avoir besoin de lancer VB en root.

On crée le fichier vmdk avec la commande suivante : VBoxManage internalcommands createrawvmdk -filename image.vmdk -rawdisk /dev/loop0. Ceci va donner l’accès au disque complet.

Si on souhaite ne donner accès qu’à une partition, on peut utiliser l’option -partitions 2 (pour donner l’accès à la 2ème partition).
A noter que, selon ce Github, cet outil n’est capable de comprendre que les tables MBR. L’outil proposé par le github lui-même semble capable de lire le GPT aussi.

Une fois le fichier créé, il n’y a plus qu’à l’ajouter dans la configuration Stockage de la machine virtuelle.

Démontage

Une fois que l’on a fini, on peut démonter la partition de son point de montage (umount), puis démonter l’image du périphérique loop0 via la commande sudo losetup -d /dev/loop0.

[EDIT : avec l’option -P au montage, losetup supprimera les blocks partitions au démontage, l’étape suivant n’est donc pas nécessaire.]

Ceci ne supprime néanmoins pas le block /dev/loop0p1. Pour ceci : sudo delpart /dev/loop0 1.
C’est l’inverse de partprobe, cette commande dit au noyau d’oublier la partition 1 du périphérique loop0. A faire pour chaque partition.

18 Dec 2017, 00:00

Divers imprimantes

“Envoyé vers l’imprimante”

Sur un Windows Server 2012, les travaux restaient bloqués dans la file d’attente avec le statut “Envoyé vers l’imprimante”, bien qu’ils soient imprimés correctement. La solution qui semble bien marcher est de passer à un port type IP (au lieu d’un port WSD par exemple).

Outlook et les paramètres d’impression par défaut

Outlook 2016 a certains paramètres définis dans les “styles d’impression” (le style de base étant Mémo) qui outrepassent les réglages par défaut de l’imprimante (par exemple le choix du bac de sortie). Il faut les modifier directement dedans pour qu’il soient respectés.

14 Sep 2017, 00:00

Carte SD non reconnue si branchement à chaud

J’ai sur ma tour un lecteur de carte SD USB qui, depuis Stretch, ne monte plus automatiquement les cartes SD à la volée. Celles-ci sont bien lisibles lorsqu’elles sont déjà insérées lors du boot, mais l’ejection du media est définitive.

La solution, trouvée ici est d’ajouter le paramètre suivant à la ligne GRUB_CMDLINE_LINUX_DEFAULT= du fichier /etc/default/grub :
GRUB_CMDLINE_LINUX_DEFAULT="block.events_dfl_poll_msecs=2000"

Il faut ensuite lancer sudo update-grub pour actualiser le fichier de conf.

Si on veut appliquer le changement sans rebooter, on peut aussi entrer le paramètre 2000 au fichier /sys/module/block/parameters/events_dfl_poll_msecs

06 Dec 2016, 00:00

Mise en veille de l'écran récalcitrante

Il arrive, sous Linux, particulièrement après une install neuve ou bien une upgrade du système, que l’écran se mette en veille au bout d’un certain temps d’inactivité, quand bien même l’économiseur d’écran et l’extinction d’écran sont désactivés. Ceci est dû à la fonction DPMS de l’écran, qui se gère de manière distincte des 2 réglages précédents.

Pour la gérer, on utilise le programme xset. Pour sonder les paramètres actuellent en usage, on utilise xset q. Il est assez probable que les lignes suivantes apparaissent :

DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

Si on souhaite simplement désactiver dpms, il suffit de lancer xset -dpms, et les soucis de mise en veille intempestive de l’écran devraient disparaître ! Il est bien sûr possible de gérer les paramètres plus finement avec la sommande xset.