RaphAstronome

Linux

Fil des billets - Fil des commentaires

samedi, 10 juin 2023

Problème de génération de config grub lié à LVM

Par RaphAstronome le samedi, 10 juin 2023, 12:06

Imaginez que vous mettiez à jour votre serveur comme d'habitude. Il y a une mise à jour noyau ce qui arrive parfois donc le fichier grub.cfg est automatiquement régénéré. Seulement voila des messages d'erreurs peu rassurantes apparaissent :

/usr/sbin/grub-probe : erreur : disque « lvmid/123456-7890-abcd-ef01-2345-6789-0abcde/fedcba-9876-5432-10fe-dcba-9876-543210 » non disponible.

Naturellement, vous vérifiez l'uuid et vous vous rendez compte que c'est bien la partition LVM qui sert au boot. Les disques ne semblent pas être en train de lâcher, le système fonctionne normalement, le RAID indique que tout va bien. Une rapide lecture du "/boot/grub/grub.cfg" montre clairement qu'il y a un problème, il n'y a (quasiment) pas de "insmod" et rebooter comme cela et le système de se relancera pas.

Ceci à eu lieu sur un serveur Debian 11 utilisant LVM, au vue du rapport de bug sur le site de Debian, il devrait être réglé pour la version 12 de Debian qui devrait arriver dans très peu de temps au moment où j'écris ce billet. A notez que le bug ne se produit pas seulement après un renommage de partition mais lorsqu'un certain nombre d'actions (création, suppression, agrandissement, réduction ou renommage de partitions et snapshots) ont eu lieu sur un volume LVM. Le LVM en lui même va bien mais sa gestion par grub pose soucis.

Lire la suite...

aucun commentaire

dimanche, 29 janvier 2023

"rmdir" et "rm -r"

Par RaphAstronome le dimanche, 29 janvier 2023, 16:39

Sous Linux et bien d'autres systèmes la commande pour supprimer un fichier est rm. Ceci ne fonctionne toutefois pas sur les dossiers, si vous essayez vous aurez une erreur du genre :

rm: impossible de supprimer 'toto': est un dossier

Pour le supprimer un dossier et tout son contenu ce que fait rm -r mais il peut être utile de s'assurer que le dossier est bien vide avant le le supprimer. On peut bien sûr regarder avec ls -a avant de faire le rm -r mais il faut y penser et ce n'est pas très pratique. De plus on n'est jamais à l'abri de la création d'un fichier entre le moment de la vérification et de la sauvegarde.

Pour ceci il est possible de faire rmdir qui ne supprime le dossier qu'a la condition qu'il soit vide et évite tout risque l'oubli de fichier.

aucun commentaire

vendredi, 22 septembre 2017

Corriger un problème de son haché avec Mumble et PulseAudio

Par RaphAstronome le vendredi, 22 septembre 2017, 22:54

Cette modification n'est maintenant plus nécessaire. De plus elle peut entraîner des troubles dans certains logiciels, comme Hatari, qui n'ont alors plus accès au son. Je vous conseille donc de retirer cette variable d'environnement si vous l'avez.

J'ai eu un soucis avec PulseAudio : en usage général tout semble fonctionner mais dès que l'on lance Mumble c'est le drame : le son devient totalement haché à un point où il est carrément incompréhensible. Cela hache le son de Mumble mais aussi des autres programmes (jeux, musique ...). Le fait de fermer Mumble corrige le problème après quelques secondes d'attente mais revient lorsque l'on le relance.

À cause de ce bug je suis resté longtemps sur ALSA, l'ancien système de son, mais depuis la fin de son support par Firefox il me fallait remettre PulseAudio. Je n'arrivais pas à trouver l'origine du problème et pensais au début qu'il y avait un soucis au niveau de l'interface entre Mumble et PulseAudio ou alors un problème avec la gestion de l'écho. Le bug n'était pas systématique donc les rares fois où j'utilisais Mumble j'arrêtais et relançais Mumble jusqu'à ce que cela fonctionne normalement. Pas pratique !

Mumble.png

Au final en cherchant totalement autre chose je suis tombé sur un sujet de forum où quelqu'un avait ce genre de soucis avec un programme Windows qu'il faisait tourner sous Linux avec Wine. Il était question de la variable d'environnement PULSE_LATENCY_MSEC . Je ne sais pas trop pourquoi mais avec la carte son de ma carte mère la mémoire tampon alloué par PulseAudio est trop petite dans certains cas. J'ignore totalement pourquoi cela le fait spécifiquement avec Mumble, peut être qu'il passe en mode de faible latence. J'avoue ne pas avoir démonté Mumble pour voir ce qu'il fait d'autant plus que je ne connais que très peu les API lié au son.

Toujours est t'il qu'une valeur de PULSE_LATENCY_MSEC à 30 règle le soucis pour moi. Si vous avez le même problème mettez un son en arrière plan (voir le dernier paragraphe si le son ce coupe) et lancez Mumble avec la commande suivante :

PULSE_LATENCY_MSEC=30 mumble

Répétez la commande plusieurs fois pour vérifier. Si cela ne suffit pas essayez une valeur plus grande. Ne mettez pas une valeur énorme non plus car vous auriez alors une latence gênante sur le son.

Si vous êtes satisfait de cette valeur vous pouvez la fixer dans la configuration du système dans le /etc/environment (à modifier en root), ajoutez :

# Correctif PulseAudio-Mumble
PULSE_LATENCY_MSEC=30

Vous pouvez aussi faire l'ajout dans le fichier ~/.bashrc pour ne configurer que votre compte personnel. Dans les deux cas le paramètre ne sera pris en compte qu'après avoir fermé et rouvert votre session.

Dernière chose : si lancer Mumble éteint la musique c'est normal puisque Mumble est considéré comme étant une application téléphonique ce qui coupe la musique de fond automatiquement. Si cela pose soucis cela ce configure dans /etc/pulse/default.pa où j'ai retiré la ligne "load-module module-role-cork" (mettez plutôt un "#" devant pour désactiver la ligne). PulseAudio doit être relancé pour que cela soit pris en charge.

aucun commentaire

mercredi, 21 septembre 2016

Ubuntu Touch OTA-13 : écran noir au premier reboot

Par RaphAstronome le mercredi, 21 septembre 2016, 20:41

Aujourd'hui mise à jour des téléphones portable Ubuntu Touch. Bien entendu je fais la mise à jour, jusque là tout ce passe bien.

En téléphone redémarre, c'est un bq Aquarius E4.5 donc lorsqu'il redémarre il affiche son logo ... longtemps ... puis écran noir ... longtemps ... très longtemps ... cela commence à être inquiétant ...

Bon, je vais voir un peu ce que cela dit sur le web car normalement c'est plutôt rapide. Visiblement au premier boot il y a un bug qui fait qu'il est extrêmement long, cela parle de 15 min environ, il faut le laisser tourner et il devrait démarrer.

Connexion via SSH

Ayant préalablement activé SSH sur le téléphone je regarde si il répond à SSH : c'est le cas !

Je regarde un peu ce qu'il ce passe et effectivement rien de très spécial, le téléphone semble attendre un événement quelconque pour lancer l'interface graphique et il faut attendre le timeout.

La commande "w" ne donne personne d'autre connecté que moi via ssh, normalement l'interface graphique devrait apparaître si elle avait démarrée. Le réseau WiFi n'est que peu utilisé et il n'y a pas de connexion réseau mobile (logique, je n'ai pas entré le code SIM).

Finalement lorsque je branche le chargeur l'interface graphique apparaît. C'est peut être un hasard mais visiblement le fait de le recharger relance l'interface. "upstart --user" apparaît dans "w" :

phablet@ubuntu-phablet:~$ w
 20:15:40 up 37 min,  2 users,  load average: 0,00, 0,01, 0,05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
phablet  pts/7    raph2015.home.ga 19:50    4.00s  0.13s  0.04s w
phablet                            19:54   21:13   6:58  16.81s upstart --user

Retour à la normale

Bon, je commence à tester le téléphone, il a l'air OK, les mises à jour sont assez intéressantes, l'interface est maintenant plus rapide à lancer les applis et pas mal de petites améliorations. À noter qu'il affiche une indication "carte SIM absente" en plus de l'indication de qualité de réseau mobile, cela doit être dû à ce que je n'ai qu'une carte SIM sur un téléphone qui propose d'en mettre deux, les appels fonctionnent en tout cas.

Je le redémarres avec et sans chargeur ... aucun problème constaté du moins lors de mes premiers essais, on verra à l'usage.

À lire aussi :

aucun commentaire

dimanche, 15 mai 2016

Ubuntu Touch : exporter les contacts dans un .vcf

Par RaphAstronome le dimanche, 15 mai 2016, 12:53

Pour exporter les contacts du téléphone l'application classique ne semble pas proposer de fonction d'exportation. Il existe la synchronisation des contacts mais ce n'est pas une vraie solution.

Pour exporter vers un fichier .vcf dans le dossier Documents vous pouvez utiliser la commande suivante :

syncevolution --export /home/phablet/Documents/contacts.vcf backend=evolution-contacts

Les arguments :

  • --export : fichier vers lequel exporter, par précaution j'ai mis le chemin complet mais ce n'est pas obligatoire. Vous pouvez utiliser "-" pour l'envoyer sur la sortie standard.
  • backend=evolution-contacts : le backend indiquant comment accéder au données

Le man n'est pas présent sur le téléphone, vous pouvez le consulter sur le site de SyncEvolution

Contrairement à ce que l'on peut lire parfois je n'ai pas eu besoin de passer root.

Si, comme moi, vous le faite via une connexion SSH, sachez que la commande ne répondra pas (ou peut être très lentement) lorsque l'écran est éteint. Cela doit probablement être dû à un système d'économie d'énergie. Le fait d'appuyer sur le bouton pour allumer l'écran règle le problème. Quelque chose de semblable arrive avec la commande "top" lancée en SSH : le top s'ouvre mais ne se rafraîchit pas comme elle devrait le faire, écran allumé par contre tout est normal.

Une fois exporté récupérez le fichier par tout moyen à votre convenance (SSH ou autre). Une fois que c'est fait je vous conseille de supprimer le fichier .vcf car une application pourrait tout à fait le lire depuis ce dossier.

À lire sur le sujet :

aucun commentaire

- page 1 de 6