[ArchLinux] Choix de la sortie son par défaut

Après avoir effectué une mise à jour et redémarré mon système il y a de cela un mois environ, j’ai constaté que je n’avais plus aucun son en sortie de mes haut-parleurs. Après bien des recherches, j’ai remarqué que le son sur la sortie HDMI semblait fonctionner.

En cherchant les sorties disponibles sur ma machine, je découvre donc que la sortie 0 utilisée jusqu’à présent, du moins dans mes souvenirs, est désormais la sortie HDMI. J’indique donc au système d’utiliser la sortie 1 :

pactl set-default-sink 1

Retour du son dans mes haut-parleurs et vérification de la sortie utilisée.

# pactl list sinks short
0 alsa_output.pci-0000_01_00.1.hdmi-stereo-extra2 module-alsa-card.c s16le 2ch 44100Hz SUSPENDED
1 alsa_output.pci-0000_00_1b.0.analog-stereo module-alsa-card.c s16le 2ch 48000Hz RUNNING

En outre, lorsqu’il s’agit de débuger un problème de son, je commence généralement par faire un tour du côté de alsamixer et pavucontrol.

Toutefois, il s’avère que si cette opération suffit pour la session courante, la configuration ne persiste pas au redémarrage du système. Pour configurer la carte par défaut, je commence donc par lister une nouvelle fois les sorties disponibles.

# pacmd list-sinks | grep -e 'name:' -e 'index:'
  index: 0 name: <alsa_output.pci-0000_01_00.1.hdmi-stereo-extra2>
* index: 1 name: <alsa_output.pci-0000_00_1b.0.analog-stereo>

Ensuite, j’édite le fichier /etc/pulse/default.pa pour y ajouter la ligne suivante :

set-default-sink alsa_output.pci-0000_00_1b.0.analog-stereo

Après un redémarrage du système, le son sort à nouveau de mes hauts-parleurs.

[ArchLinux] autorandr

Petit point rapide sur autorandr, petit programme bien pratique, pour simplifier la gestion de différentes configurations de disposition d’écrans. Une fois installé, autorandr tente de détecter la configuration à appliquer en fonction du matériel connecté. Cette solution s’avère très pratique lorsqu’on utilise un environnement de bureau simplifié de type i3 et que l’on est amené à changer sa disposition d’écran. On pensera notamment au cas d’un ordinateur portable auquel on connectera un écran supplémentaire et que l’on déconnectera en cas de changement de pièce.

Installation classique via pacman.

sudo pacman -S autorandr

La sauvegarde d’un profil s’effectue avec l’argument save.

Save your current display configuration and setup with:
$ autorandr --save home

Pour finir, j’ai ajouté la ligne suivante dans mon fichier .xprofile.

autorandr --change --default home

Soit, passage par défaut sur la configuration home au démarrage. Le chargement manuel d’un profil s’effectue à l’aide du paramètre load: autorandr <profil>. A noter qu’il est également possible de configurer pour chaque profil, des actions à effectuer après le chargement du profil.

[ArchLinux] Passage à yay

Focus rapide sur l’accès aux paquets AUR sous ArchLinux. J’utilisais jusqu’à présent yaourt, mais celui-ci n’étant plus maintenu, je vais tester yay pour la gestion de mes paquets AUR.

Le processus d’installation est simple, récupération d’une copie des sources, construction du paquet puis installation. Le programme étant écrit en go, on installera au préalable de quoi le compiler: sudo pacman -S go.

Installation :

git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

Onduleur – Surveillance sur le réseau

Dans un article précédent, nous nous étions quitté avec une connexion directe par USB entre l’une des machines connectée à l’onduleur et l’onduleur lui-même. Aujourd’hui, retour sur la configuration du service de surveillance de l’état de l’onduleur, cette fois pour que la machine connectée partage l’information sur le réseau. Le but étant que les autres machines connectées à l’onduleur soit elles aussi capable de connaître son état, de déclencher un arrêt en cas de batterie faible et ainsi, de pouvoir s’éteindre avant de subir une perte de courant totale.

Je repars ici de ma configuration déjà en place. Comme la première fois, plusieurs fichiers sont à modifier, mais en nombre plus réduit. Je commence par éditer le fichier /etc/nut/upsd.users, sur la machine déjà configurée en mode client et connectée à l’onduleur, pour y ajouter un utilisateur « esclave » qui servira à mon autre ordinateur pour l’authentification des demandes d’état.

[slave]
  password = PASSWORD
  upsmon slave

Je modifie ensuite /etc/nut/upsd.conf pour que le serveur nut soit accessible sur le réseau et non plus seulement en localhost; en considérant que l’IP de ma machine est statique.

LISTEN 192.168.24.42 3493

J’enchaîne ensuite avec /etc/nut/nut.conf, où je précise que nut devra désormais fonctionner en mode serveur.

MODE=netserver

Enfin, pour terminer la configuration de la machine principale, je redémarre ups-monitor et nut-server.

Passons maintenant à la machine cliente, où, après avoir installé nut, je définie la manière dont nut va récupérer les informations d’état de l’onduleur, en modifiant /etc/nut/upsmon.conf. J’utilise ici l’utilisateur « slave » configuré précédemment.

MONITOR eaton@192.168.24.42 1 slave PASSWORD slave

Ensuite, édition du fichier /etc/nut/nut.conf afin de préciser le mode de fonctionnement de nut, à savoir ici, client du réseau.

MODE=netclient

Pour finir sur cette machine cliente, redémarrage de ups-monitor et nut-client.

Dernier point de configuration important, mais non lié à nut, au démarrage, j’ai constaté que nut n’était pas capable d’écouter sur l’IP définie dans la configuration, cela étant due, au fait que la récupération de l’IP était encore en cours d’acquisition (statique côté DHCP), au moment du démarrage de nut. Pour palier au problème, j’ai configuré mon RPI pour attendre la connexion au réseau avant de continuer plus avant dans la procédure de boot. Sur un RPI, la configuration s’effectue comme suit :

  • sudo raspi-config
  • 3 Boot Options
  • B2 Wait for Network at Boot
  • « Yes ».
  • Sauvegarder et quitter.

Une fois ces configurations réalisées sur mes deux machines, je suis en mesure de consulter l’état de l’onduleur sur chacune des machines. Un test d’arrêt forcé, m’a permis de vérifier que l’extinction de la machine cliente a bien lieu avant l’extinction de la machine ayant le rôle de serveur, et de m’assurer que l’ensemble redémarre sans assistance au retour du courant.

Asus UX31E – Changement de clavier

Il y a de cela sept années environ, j’avais fait l’acquisition d’un ordinateur portable de marque Asus, à savoir le modèle UX31E. Celui-ci m’a accompagné pendant mes études et dans les pérégrinations qui ont suivi les années suivantes, lorsque le besoin d’emmener un ordinateur portable se faisait sentir.

Dernièrement, plusieurs touches du clavier ont commencé à dysfonctionner sérieusement, jusqu’à rendre quasiment impossible le processus de connexion et compromettant donc une utilisation apaisée de l’ordinateur. Résistant à l’envie de balancer le tout par la fenêtre après une vingtaine de tentative de connexion ratée, je me suis donc mis en tête de remplacer le clavier défectueux.

A l’aide d’une série de tournevis de précision, je me suis donc attelé au démontage pièce par pièce de l’ordinateur, afin de dégager le clavier des composants qui le recouvrent. L’opération en soi n’est pas spécialement compliquée, pour peu que l’on prenne son temps, que l’on note l’ordre de démontage et que l’on classe les vis retirées.

Pour avoir une idée des différentes étapes, j’ai pris connaissance du guide « Replacing an Ultrabook (Asus UX21E) keyboard« , qui ne correspond pas à 100%, mais dont les similitudes sont suffisantes pour être d’une aide précieuse. L’essentiel étant de ne surtout pas forcer pour le démontage des composants et autres câbles de connexion. Sur mon modèle en particulier, l’une des vis de la carte mère est cachée par la carte SSD elle-même vissée à la carte mère.

Une fois le clavier remplacé, on remonte tout en sens inverse, en prenant soin de ne pas oublier une quelconque connexion et on croise les doigts pour que ça démarre correctement. Après quelques secondes d’attente, le terminal apparaît, me demandant d’entrer mon login. Quelques appuis sur le nouveau clavier et les touches autrefois défectueuses, me confirme rapidement que la réparation est un succès.

Bref, une vingtaine d’euros, quelques tournevis, et un peu d’huile de coude m’auront permis de prolonger la vie de mon ordinateur. Si ce n’est pas forcément le modèle que je choisirais, si le choix était à refaire, il aurait été dommage de mettre l’ensemble de la machine au rebu, pour un simple problème de clavier. Cette petite réparation me permet donc de donner une deuxième vie à cet ordinateur; qui ne soit pas statique, un clavier externe pour prothèse, ni celle d’une reconversion en serveur. C’est sur ces quelques lignes que je vous laisse : j’ai 2GB de mises à jour à appliquer.