L’autre jour, je voulais démarrer une VM pour faire un test, je lance mon gestionnaire de machines virtuelles KVM mais aucun VM n’apparaît.
Je vais tout de suite voir l’état du service libvirtd, et en toute logique j’ai bien un problème de démarrage :
Le service libvirt ne démarre pas
J’essaie de redémarrer le service sans succès, on voit bien que le système a essayé plusieurs fois sans succès. Je regarde les logs sans rien trouver de bien parlant. Le plus étonnant, c’est que j’arrive à lancer le daemon en mode su (libvirtd --verbose), puis à lancer ma VM et faire ce que je voulais faire.
Le problème est contourné, mais pas résolu. J’ai regardé ça de plus près cet AM, alors voilà la vraie résolution, très simple, et qui était due à une mise à jour du BIOS sur le PC. Je fais cet article pour m’en souvenir.
J’utilise Gnome comme environnement de bureau (DE) et j’en suis très content. Il est à la fois beau, ergonomique, homogène, tout en restant limité dans ses options, ce qui évite de se perdre dans des menus sans fin. C’est le choix fait par les devs, et ma foi, c’est cohérent.
Pour une part, on s’adapte à leurs choix, et pour le reste il y a les extensions Gnome qui permettent de personnaliser un peu l’expérience utilisateur. L’ensemble me convient.
Par contre, je n’avais pas trouvé comment afficher la petite ville où j’habite dans Gnome-weather. Je n’avais pas d’autre choix que de choisir Quimper, la ville la plus proche reconnue par l’application. Mais voilà, le problème est désormais réglé (il y a toujours une solution).
Pas de chance, aujourd’hui il pleut ! 😉
Il faut d’abord se rendre sur https://nominatim.openstreetmap.org pour identifier les coordonnées de latitude et de longitude de votre ville :
Dans mon cas, on obtient donc les valeurs suivantes :
Centre Point (lat,lon)
47.9081865,-3.979665
test légende
Il va falloir ensuite convertir les valeurs avec l’opération suivante :
Voilà, il ne reste plus qu’à lancer dconf, l’éditeur de configuration de Gnome, et d’ouvrir la clef org.gnome.Weather.locations, et de modifier la valeur comme suit :
La valeur personnalisée à entrer dans mon cas est :
Attention, la moindre erreur de syntaxe ne sera pas pardonnée ! Personnellement, j'ai d'abord choisi Quimper via l'interface de l'application, puis je suis allé modifier à la main la valeur des coordonnées lat/lon, en appliquant le même nombre de décimales.
Créer un double boot entre (typiquement) Windows et Linux, c’est hélas toujours et encore source de problème. Le sujet est assez technique à appréhender, et l’on a vite des sueurs froides si tout ne se passe pas comme prévu.
L’autre jour, je suis tombé sur cet article, qui présente rEFInd et ses avantages. S’il est limité aux machines équipées de l’UEFI (apparu en 2007, et donc largement répandu aujourd’hui), il offre un énorme avantage pour les configurations « multi-boot » : rEFInd scanne le système à chaque démarrage pour détecter les OS existants. En outre, il est facile à configurer, offre un mode graphique, des thèmes, supporte le Secure boot, macOS, etc… Enfin, son installation est on ne peut plus simple, puisque c’est un paquet disponible comme n’importe quel autre sous Linux.
Bref, il n’y a aucun raison de continuer à utiliser GRUB, pourtant toujours présent sur la majorité des distributions Linux, et ce pour une seule raison : la compatibilité avec les vieux PCs qui n’ont pas d'(U)EFI. Or GRUB est complexe, statique, avec des fichiers de configurations pas évidents à modifier. De nos jours, le choix est vite fait si l’on veut faire du multi-boot.
J’en ai donc profité pour réinstallé mon laptop Asus en double boot, avec Windows 10 et Debian 12. Et voilà le résultat au démarrage après l’installation d’un thème :
C’est quand même autre chose que le menu de GRUB non ?
Revoyons tout ça, cet article s’est révélé plus long que prévu : je l’ai démarré avec l’idée de simplement décrire l’installation de rEFInd et d’un thème, mais j’ai creusé le sujet au fur et à mesure pour mieux comprendre le boot EFI. 😎
C’est quelque chose que j’aurais du faire depuis longtemps, mais comme j’utilise la mise en veille le plus souvent sur mon PC, ce n’était pas un besoin pressant.
Toujours est-il qu’en cas de redémarrage, je devais systématiquement replacer les fenêtres au bon endroit, et même ouvrir une seconde fenêtre de terminal, puisque si l’on peut définir les applications qui démarreront automatiquement, on ne peut pas définir le nombre de leurs fenêtres (par défaut).
Gnome fournit gnome-tweaks pour ajuster divers paramètres : essentiellement les thèmes, l’apparence des fenêtres, et les applications au démarrage. Par contre, pour la position des fenêtres, rien n’est prévu. La philosophie de Gnome, c’est de fournir l’essentiel et de s’y limiter (et c’est très bien comme ça, cela évite de surcharger les menus). Il faut donc passer par une extension pour ce genre de besoin, et Smart Auto Move (SAM) y répond parfaitement.
Dernier souci : lancer deux fenêtres de la nouvelle Console de Gnome, que j’utilise à la place du gnome-terminal classique, qui m’a posé un petit problème.
J’ai récemment installé une nouvelle application de recettes de cuisine, j’ai nommé Anymeal, celle que j’utilisais auparavant (Gourmand, un fork de Gourmet en Python 3) ne démarrant plus sur Debian 13, et le projet semblant plus ou moins abandonné.
Anymeal est présent dans les dépôts Debian, et s’installe donc très facilement. Il est de plus maintenu, puisque j’ai été en contact avec le dev lorsque j’ai remarqué que le dash de Gnome (la barre du Dock en bas de l’écran) n’affichait pas l’icône de l’application, alors que l’icône apparaissait bien quand on lançait l’application :
L’icône n’est pas très chouette !
Mais une fois lancée, plus d’icône :
Le fichier .desktop
Comme toujours dans ce type de problème, il faut commencer par aller voir le fichier .desktop de l’application. Celui-ci était bien présent dans /usr/share/applications/de.wedesoft.anymeal.desktop, tout comme une icône dans /usr/share/icons/hicolor/64x64/apps/anymeal.png.
Tout avait l’air correct, et après avoir bidouillé un peu (en renommant le fichier en anymeal.desktop, cela fonctionnait), j’ai préféré créer un bug, et le développeur a été très réactif : il a créé une VM pour pouvoir reproduire le problème, puis a trouvé la solution dans ce billet de blog, ma foi fort intéressant. Il s’agit en fait de définir la fenêtre de l’application d’une autre manière, plus efficace manifestement que par son nom, et c’est toujours bon à savoir et surtout à retenir (d’où cet article).
Pour ce faire, on va lancer l’application, puis appuyer sur Alt-F2 afin de lancer le debugger de GNOME Shell appelé Looking Glass, en tapant « lg » :
Il suffit alors de cliquer sur « Windows » pour voir s’afficher la valeur de wmclass pour l’application anymeal :
Et voilà, il ne reste qu’à renseigner ce paramètre dans le fichier .desktop indiqué plus haut pour le paramètre StartupWMClass :
À ce stade, l’icône s’affiche bien dans le Dash, le but recherché est donc atteint. Mais un autre problème est apparu : l’icône mettait plus de 10 secondes à apparaître dans le Dash ! 😡 Par contre, si on lançait l’application via le terminal, elle apparaissait bien immédiatement.
On trouve un bug à ce sujet ici, qui est fermé en indiquant qu’il est lié à celui-ci, également fermé, mais avec des explications. La remarque intéressante à retenir est :
This only seems to happen when I start the applications from the launcher and not directly from a terminal, so it may be related to the startup notifications.
Le plus simple dès lors est de désactiver les notifications pour l’application en ajoutant un autre paramètre StartupNotify=false à la fin du fichier ci-dessus.
Et voilà tout fonctionne ! Et comme je n’aime pas l’icône d’Anymeal, j’en ai fait une autre en partant d’icônes libres de droit (ici) avec l’aide de GIMP :
Franchement, je préfère celle-ci !
Bon, je reviendrai sur ce nouveau logiciel de recettes dans un autre article, je ne suis pas encore certain de l’utiliser, même si le développeur a montré qu’il était très réactif.
C’est en parcourant le flux RSS de la page This week in GNOME que j’ai vu cette application, bien pratique pour régler la luminosité de ou des écrans en évitant d’avoir à naviguer à travers l’OSD et ses boutons démoniaques… 👿
De plus, l’application se trouvant dans la section « Third Party projects » de la page, elle est fournie au format .deb. J’y serai désormais plus attentif, car dans la section « Gnome Circle Apps and library », si on y trouve des petits programmes sympas, ceux-là sont tous au format Flatpak, un format que j’essaie d’éviter.
Arrivé sur le site de l’application, on peut y lire :
Luminance A simple GTK application to control brightness of displays including external displays supporting DDC/CI
Le DDC/CI
Luminance permet donc de régler la luminosité de vos écrans si ces derniers supportent le DDC/CI. Comme nous l’explique la page wikipedia, le Display Data Channel (canal des données de l’écran) ou DDC permet à un écran de communiquer ses spécifications à l’émetteur du flux vidéo. Le DDC/CI est une extension (CI : Command Interface) qui permet à l’émetteur d’ajuster les paramètres comme la luminosité ou le contraste.
C’est le cas pour la plupart des écrans récents, et vérification faite, des miens :
AOC 24G2SPU (acheté très récemment)
Philips 243S7 (acheté en 2022)
À noter que DDC est transporté sur 3 broches — données, horloge, masse — dans un connecteur VGA D-sub 15 broches, un connecteur DVI, ou un connecteur HDMI. Soit les 3 sorties dont je dispose sur ma carte mère, c’est parfait ! 😀
Installation
J’ai donc télécharger le paquet DEB de Luminance à partir de sa page Github, puis je l’ai installé. Déception au premier lancement, j’avais pour toute réponse « No compatible displays found ».
En utilisant la ligne de commande, c’était même pire, j’avais un crash :
$ /usr/bin/com.sidevesh.Luminance -l
No displays found.
(libddcutil:5852): GLib-CRITICAL **: 10:06:27.249: g_atomic_ref_count_dec: assertion 'old_value > 0' failed
Erreur de segmentation
Et plus moyen de relancer la commande, j’obtenais « Another instance of the application is already running. », alors que je ne voyais aucun process correspondant.
J’ai donc créé un bug sur le site du développeur, qui m’a répondu très vite : il fallait effacer un fichier /tmp/com.sidevesh.Luminance.lock pour pouvoir réutiliser l’outil (suite au crash), et ensuite concernant la détection des écrans d’utiliser la commande ddcutil interrogate pour voir le retour.
Après quelques recherches sur ce message d’erreur, j’ai vu ici que ddcutil nécessite le module i2c-dev du noyau. S’il n’est pas intégré à votre noyau, il doit être chargé explicitement. Pour ce faire, il faut ajouter un fichier dans le répertoire /etc/modules-load.d contenant la ligne suivante : i2c-dev. Aussitôt lu, aussitôt fait, et reboot dans la foulée :
J’utilise KeepassXC pour gérer mes mots de passe, couplé avec KeepassDX sur le smartphone. Les deux applications ouvrent le même fichier, sur mon serveur Nextcloud. Tout va pour le mieux dans le meilleur du monde libre des mondes.
Sauf que sur le PC, et donc sous Gnome Wayland en ce qui me concerne, la fenêtre de l’application ne s’affichait pas correctement : aucune bordure, et la barre de titre ne respectait pas le style de Gnome.
Cela faisait un bout de temps que je traînais ce problème, je croyais que c’était un bug de KeepassXC avec ma version récente de Gnome (Debian SID, environnement Qt, GTK, Adwaita, que sais-je…). J’avais accepté de vivre avec ce problème ! 😥
Ce matin, j’ai même testé le nouveau Proton Pass pour voir ce que cela donnait, afin d’éventuellement changer d’application et retrouver un fenêtrage homagène. Mais bon, je l’ai vite désinstallé quand j’ai vu que pour créer plusieurs coffre-forts, il fallait passer à la version payante. Beau produit d’appel, certes, mais en général je n’aime pas trop ces applications soi-disant gratuites, mais aux fonctionnalités volontairement limitées pour vous faire passer à la version payante quand vous voulez utiliser autre chose que les fonctionnalités de base.
Je me suis alors penché pour de bon sur ce problème : en fait, KeepassXC est une application Qt, et les fenêtres de ce type d’application n’ont par défaut pas de bordure sous Gnome Wayland (au moins sous Debian). Il y a plusieurs façons de corriger ce problème.
Ventoy est un outil pour créer une clef USB multiboot permettant d’avoir une seule clé pour différents systèmes, ce qui est extrêmement pratique quand on fait un peu de dépannage ou de tests : plus besoin d’avoir une clef GParted, une autre Clonezilla, ou encore une Debian Live…
Une fois la clef créée, il suffit d’y copier les images ISO de votre choix, et les systèmes apparaîtront automatiquement dans le menu Ventoy en démarrant sur la clé USB.
Plus que cela, Ventoy permet aussi via une série de plugins de personnaliser la clef (menu, thèmes, etc…) mais aussi de gérer la persistance pour les distributions « Live » comme Debian, Ubuntu, Mint… Et ça c’est un vrai plus, rien de plus énervant que de devoir par exemple repasser à chaque fois l’OS en français dans une session LIVE…
Voyons voir comment préparer sa clef USB Ventoy et la personnaliser. J’utilise une clef de 32 Go pour ce premier essai. À la fin, on obtient un truc assez sympa (finalement, je choisirai le thème Ventoy Adwaita) :
Le temps passe vite en informatique, et la durée de vie des produits ou du matériel encore plus.
J’avais acheté mon Odroid-HC2 et installé OMV V5 en 2020. Quatre ans plus tard, si tout fonctionne encore, je recevais quotidiennement des mails m’informant que la mise à jour système avait échouée :
CRON-APT RUN [/etc/cron-apt/config]: Tue Mar 5 07:05:30 CET 2024
CRON-APT SLEEP: 2353, Tue Mar 5 07:44:43 CET 2024
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get update -o quiet=2
E: The repository 'http://apt.armbian.com buster Release' does not have a Release file.
En regardant tout ça de plus près, je me suis rendu compte que plus rien n’était supporté : ni le matériel, ni l’OS, pas plus que la version d’OpenMediaVault ! Il était temps de faire quelque chose…
Le 10 juin dernier, Debian 12 sortait en version « release » et passait de fait en version « stable ». Comme conseillé, j’attendais environ un mois avant de repasser mon PC en version « testing », afin de bénéficier des dernières versions de logiciels, l’environnement Gnome, etc… Un bon compromis, si l’on accepte d’avoir quelques soucis de temps en temps et de mettre les mains dans le cambouis…
L’opération est toute simple et consiste à modifier le fichier /etc/apt/sources.list et de remplacer le mot bookworm par testing (ou trixie), puis de lancer la commande suivante :
$ sudo apt full-upgrade
Auparavant, on aura pris soin de faire un sudo apt update ; sudo apt upgrade comme il se doit.
La mise à jour s’effectue, et après un redémarrage me voilà en Debian 13 « trixie » : 😎
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux trixie/sid
Release: n/a
Codename: trixie
Tout s’était bien passé apparemment… jusqu’à ce que je veuille lancer une VM : virt-manager restait en état « Connexion… » et pas moyen d’en sortir :
NOTE : même en mode commande : $ virt-manager –debug, je n’ai pas plus d’infos…
systemd logo
Le problème survient après quelques minutes de fonctionnement : au démarrage tout va bien, puis après quelques minutes, virt-manager ne se connecte plus.
Ça m’a obligé à faire pas mal de tests avec le service libvirt et permis d’apprendre à contrôler cette partie, alors voilà le résultat de mes investigations. À la fin de l’histoire, c’est apparemment un bug de systemd (régression), dont il ne reste qu’à attendre la correction. Cela fait partie des risque d’utiliser la version « testing » de Debian ! 😉 Mais au moins j’y vois désormais un peu plus clair avec KVM et surtout libvirt, l’interface réseau virbr0 et les réseaux virtuels créés pour les VMs.
