Debian on Pascal's weblog

Le service libvirtd ne démarre plus

Thu, 14 May 2026 15:26:48 +0000

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 :

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.

SVM dans le BIOS

Pendant ma recherche sur le net d’informations sur ce problème, je tombe sur une remarque assez basique mais disant de vérifier que la virtualisation est bien activée dans le BIOS. Et là, ça fait tilt, j’ai effectivement mis mon BIOS à jour il y a peu de temps. Je redémarre le PC, et rentre dans le BIOS.

Pour les carte-mères Asus équipée d’un processeur AMD, il faut aller en mode Advanced dans “CPU Configuration”, et rechercher le mode SVM (Secure Virtual Machine). Et effectivement, le paramètre a bien été réinitialisé à sa valeur par défaut, soit “Disabled” ! :mad: Je le réactive et redémarre, espérant avoir solutionné le problème.

Les logs

Hélas, le problème est toujours présent, impossible de démarrer le service. Une recherche dans les logs après ce démarrage va cette fois être plus parlante :

$ sudo journalctl -u libvirtd.service -b
...
libvirtd.service: TPM key integrity check failed. Key most likely does not belong to this TPM.
libvirtd.service: Failed to set up credentials: Object is remote
libvirtd.service: Failed at step CREDENTIALS spawning /usr/bin/libvirtd: Object is remote
...

TPM est l’abréviation de « Trusted Platform Module », c’est une histoire de clef fournie par un circuit spécialisé sur la carte-mère, afin d’améliorer la sécurité. Je n’en sais pas plus, mais je comprends que la mise à jour du BIOS a invalidé la clef existante sur mon système, d’où le refus de démarrer du service.

Après quelques recherches, la solution est de supprimer l’ancienne clé libvirt afin qu’elle soit régénérée avec la nouvelle clé principale, puis :

$ sudo rm /var/lib/libvirt/secrets/secrets-encryption-key
$ sudo systemctl disable libvirtd.service
$ sudo systemctl enable libvirtd.service
$ sudo systemctl start libvirtd.service

Et voilà, mes VMs sont revenues dans le gestionnaire KVM :

Gnome-weather et les petites villes

Fri, 07 Nov 2025 09:56:21 +0000

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).

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.979665test légende

Il va falloir ensuite convertir les valeurs avec l’opération suivante :

Coordonnées GPSFormuleRésultatLatitude47.9081865÷(180÷3.141592654)0.83615559319367762Longitude-3.979665÷(180÷3.141592654)−0,0694582573854495

Source pour la conversion : test add_city.sh.

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 :

[<(uint32 2, <('La Forêt-Fouesnant', 'LFRQ', false, [(0.8361555931936776, -0.069458257385449501)], @a(dd) [])>)>]

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.

rEFInd, le multi boot facile

Tue, 31 Dec 2024 17:28:26 +0000

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. :cool:

Les bases à connaître

UEFI vs BIOS

UEFI signifie U nified E xtensible F irmware I nterface. Il s’agit d’une solution moderne qui a remplacé progressivement le BIOS ( B asic I nput- O utput S ystem) traditionnel sur les PC. Tout ce qui suit concerne donc un PC équipé d’un firmware de type UEFI.

GPT

Le corollaire d’un boot UEFI est un disque disposant d’une table de partition GUID ou GPT ( G UID P artition T able), plus moderne, qui vient en lieu et place de l’ancien MBR (limité à 4 partitions, etc…). L’une des partition sera obligatoirement une partition de type EFI, sur laquelle on viendra charger le “boot loader” choisi.

NOTE : On peut migrer les partitions de type MBR en GPT, voir cet article, c’est ce que j’avais fait sous Ubuntu en 2018.

Boot loaders et Boot managers

J’ai volontairement laissé les termes anglais pour simplifier la lecture de documents sur le sujet.

Un boot loader (chargeur d’amorçage) charge un noyau de système d’exploitation dans la mémoire et l’exécute.
Un boot manager (gestionnaire d’amorçage) transfère le contrôle à un autre boot loader.
GRUB est à la fois un boot loader et un boot manager.
rEFInd n’est qu’un boot manager.

Comme tout noyau Linux incorpore de nos jours un EFI-boot loader, un boot manager est suffisant pour passer le contrôle au noyau Linux que l’on veut démarrer. Le noyau va se charger tout seul en mémoire, au lieu de dépendre d’un boot loader externe comme GRUB. Windows dispose de ses propres boot manager & boot loader.

GRUB sera ainsi capable d’utiliser sa fonction de boot loader pour démarrer un système Linux, et d’utiliser sa fonction de boot manager pour lancer le boot manager spécifique de MS Windows ( bootmgfw.efi).

Lire cette page qui explique comment forcer rEFInd comme boot loader par défaut, et empêcher Windows 10 de se (re)déclarer à chaque démarrage du PC, c’est très instructif.

Une fois ces principes en tête, il est temps d’installer Windows et Debian sur mon laptop.

Installation des deux OS

Mon portable est un Asus Zenbook UX301LA, qui a déjà dix ans maintenant. Je m’en sers peu, et j’avais depuis longtemps effacé Windows pour y installer d’abord Ubuntu puis désormais Debian. Il est équipé de 2 SSD Sandisk de 128 Go, configurés en RAID 1 (miroir) lors de l’achat.

J’ai donc désactivé ce RAID pour installer Windows sur le premier SSD, puis Debian 12 sur le second. Il faut toujours installer Linux en second, car lui prendra en compte la présence de Windows, la réciproque n’étant pas vraie (merci MS). J’ai laissé toutes les valeurs par défaut concernant le partitionnement des disques pour chaque OS.

Les deux installations se passent sans problème particulier, et au redémarrage, Grub me propose alors cet écran de démarrage :

On voit que Debian est défini comme système par défaut. Si je voulais mettre Windows à la place, il me faudrait éditer en tant que root le fichier /etc/default/grub, modifier la ligne GRUB_DEFAULT=0 en GRUB_DEFAULT=2, sauvegarder le fichier, puis lancer la commande update-grub pour que le fichier /boot/grub/grub/cfg soit mis à jour. Si on modifie manuellement ce dernier, il sera écrasé à la prochaine mise à jour.

Mais bon, tout fonctionne, je peux choisir de démarrer Windows ou Debian, et c’est bien là l’essentiel. Voir en fin d’article quelques actions à prendre si le boot Windows n’apparaît pas dans le menu Grub.

Disques et partitions

En démarrant l’un ou l’autre des systèmes, je peux aller voir les deux disques :

Gestionnaire de disques Windows

Gestionnaire de disque Gnome

On voit que chaque système a créé sa propre partition EFI pour démarrer : /dev/sda2 pour Windows et /dev/sdb1 pour Debian. Les UUID de chacune sont aussi également affichées.

J’aurais pu faire différemment, et demander lors de l’installation de Debian d’utiliser la même partition EFI que Windows, mais j’ai fait au plus simple, mon but premier étant de tester et d’utiliser rEFInd. D’autre part, cela rend les disques indépendants l’un de l’autre : si l’un tombe en rade, je peux toujours démarrer sur l’autre (partition EFI nécessaire).

Partitions EFI

Au démarrage, un PC UEFI va charger le boot loader spécifié par le boot manager intégré de l’UEFI. Ce gestionnaire de démarrage maintient une liste d’options de démarrage dans la NVRAM du PC, ainsi qu’un ordre dans lequel les essayer. Voilà ce que j’ai désormais dans l’UEFI (aka BIOS) du PC :

En fait, chaque OS, tout comme rEFInd, a déclaré son propre chemin de boot à l’UEFI du PC, qui l’a strocké dans sa NVRAM (mémoire non-volatile). Ce point est très important à comprendre.

On peut aussi obtenir les infos avec la commande efibootmgr sous Debian :

# efibootmgr
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0002,0000,0001,0004,0005
Boot0000* Windows Boot Manager
Boot0001* UEFI:CD/DVD Drive
Boot0002* debian
Boot0003* rEFInd Boot Manager
Boot0004* UEFI:Removable Device
Boot0005* UEFI:Network Device

Voir cette page pour utiliser efibootmgr.

Puis le système démarre sur la partition EFI correspondante, où se trouve le boot manager ou le boot loader sélectionné. Ce sont des fichiers avec l’extension .efi :

root@pascal-UX301LAA:/# ls /boot/efi/EFI/debian/*.efi
/boot/efi/EFI/debian/fbx64.efi	  /boot/efi/EFI/debian/mmx64.efi
/boot/efi/EFI/debian/grubx64.efi  /boot/efi/EFI/debian/shimx64.efi
root@pascal-UX301LAA:/# ls /boot/efi/EFI/refind/*.efi
/boot/efi/EFI/refind/refind_x64.efi
root@pascal-UX301LAA:/# ls /media/pascal/D0A1-
8658/EFI/Microsoft/Boot/*.efi
/media/pascal/D0A1-8658/EFI/Microsoft/Boot/bootmgfw.efi
/media/pascal/D0A1-8658/EFI/Microsoft/Boot/bootmgr.efi
/media/pascal/D0A1-8658/EFI/Microsoft/Boot/memtest.efi

rEFInd

Pour une information claire et complète sur rEFInd, cette page fournit toutes les informations de base. La page de l’auteur est très détaillée et très technique, et peut servir de référence si l’on veut creuser un aspect particulier.

Installation de rEFInd

L’installation de rEFInd sous debian est on ne peut plus simple :

sudo apt install refind

Voilà, c’est tout, il ne reste plus qu’à redémarrer pour arriver sur le menu rEFInd. Mais auparavant, je vais installer un thème pour améliorer l’affichage. Les thèmes se trouvent sur cette page, et j’ai choisi rEFInd-glassy.

Pour installer le thème c’est assez simple : il faut d’abord localiser le dossier EFI, créer un dossier themes, cloner le thème, puis ajouter une ligne dans le fichier refind.conf pour inclure le thème. Dans mon cas, cela donne :

$su
# cd /boot/efi/EFI/refind
# mkdir themes ; cd themes
# git clone https://github.com/Pr0cella/rEFInd-glassy

Puis on édite le fichier /boot/efi/EFI/refind/refind.conf pour y ajouter à la fin la ligne suivante :

include themes/rEFInd-glassy/theme.conf

Et on redémarre ! Voilà mon premier écran rEFInd :

C’est pas mal, mais il y a une chose qui ne me convient pas : il y a deux entrées pour Debian d’affichées. J’aimerais aussi changer l’icône Windows.

Pour les deux entrées Debian, il s’agit en fait pour la première de celle correspondant à GRUB, comme on le voit sur l’image avec le chemin affiché. Comme expliqué plus haut (boot loader vs boot manager), je n’ai pas besoin de passer par le boot manager de Grub, autant lancer directement le boot loader de Debian, c’est-à-dire l’icône de droite. Il faudrait donc cacher celle de “Debian Grub”.

Or rEFInd propose bien cette possibilité, sauf qu’elle n’apparaissait pas dans les outils fournis (petites icônes grises). Il s’agit de l’outil hidden_tags défini dans la variable show_tools du fichier /boot/efi/EFI/refind/refind.conf. En fait, le thème redéfinit cette variable. Il faut donc aller modifier le fichier /boot/efi/EFI/refind/themes/rEFInd-glassy/theme.conf et y ajouter la valeur hidden_tags :

# grep hidden_tags /boot/efi/EFI/refind/themes/rEFInd-glassy/theme.conf
showtools reboot, hidden_tags, shutdown, firmware

Concernant les icônes, le thème contient un dossier icons. Il suffit de modifier les icônes de ce dossier pour afficher ce que l’on souhaite, c’est tout simple.

Et voilà, on obtient l’image affichée en début d’article. Jepeux booter Windows ou Debian, le choix par défaut est le dernier utilisé. Je peux aussi accéder au BIOS, arrêter, redémarrer.

Info

Pour prendre une capture d’écran de rEFind, il suffit d’appuyer sur la touche F10. Le fichier sauvegardé est nommé screenshot_XXX.bmp. Mais le fichier peut être sauvegardé dans la partition EFI du disque Windows même si vous démarrez Debian. C’est ce qui m’est arrivé, peut-être rEFInd choisit-il le premier disque avec une partition EFI ?

Toujours est-il qu’un fichier .BMP pouvant être volumineux, et une partition EFI pas très grande, il est facile de remplir cette dernière ! :wink:

Le PC de bureau

Mon PC de bureau n’a pas encore de dual-boot, mais la réflexion est en cours. J’ai finalement installé rEFInd pour préparer le terrain. À noter que je n’ai pas eu à ajouter de ligne showtoools dans le fichier theme.conf, les petites icônes apparaissaient correctement dès le premier redémarrage (peut-être avais-je fait une mauvaise manip sur le laptop ?).

N’ayant pas de dual-boot, j’ai décidé par contre de laisser l’entrée pour le menu GRUB : cela peut servir en cas de problème, pour démarrer sur un ancien noyau, ou en mode “recovery”. Mais je ne voulais pas avoir deux fois la même icône, à savoir celle de Debian (comme sur l’image plus haut).

Pour ce faire j’ai récupéré l’icône de l’utilitaire “boot-repair”, je l’ai modifié un peu sous Gimp, et je l’ai copiée dans le dossier où se trouve le boot loader de grub, et en lui donnant le même nom que le boot loader (comme indiqué dans la documentation ici), soit le fichier grubx64.png :

# cd /boot/efi/EFI/debian/
root@Ryzen7-5700G:/boot/efi/EFI/debian# ls
BOOTX64.CSV  fbx64.efi	grub.cfg  grubx64.efi  grubx64.png  mmx64.efi  shimx64.efi

Et voilà ce que ça donne :

Dépannage Grub

Il existe plein de pages expliquant comment réparer un dual-boot Windows-Linux (où l’on se perd d’ailleurs). À toutes fins utiles, je note donc ici les trucs de base à faire quand Windows n’est plus affiché après l’installation de Debian (rappel : toujours installer Windows en premier, puis Debian).

Si Windows n’est pas affiché dans le menu Grub, la première chose à faire est d’aller dans l’UEFI (aka BIOS) du PC si l’on voit le Windows boot manager. S’il n’est pas là, c’est que l’entrée en NVRAM a disparu. Une simple installation de rEFInd peut résoudre avantageusement le problème (en se passant de GRUB).

Pour rajouter Windows au menu GRUB, il faut dans un premier temps s’assurer que GRUB_DISABLE_OS_PROBER=FALSE est bien défini dans le fichier /etc/default/grub, puis relancer la commande update-grub. Cela permet de déclencher op-prober qui va détecter les autres OS disponibles sur la machine (tout comme fait rEFInd à chaque démarrage).

Si cela ne fonctionne toujours pas, reste la méthode manuelle : il faut d’abord identifier l’ UUID de la partition EFI utilisée par Windows, soit de la partition où se trouve Windows si un seul disque a été utilisé. L’UUID est affiché par le gestionnaire de disque (voir les captures d’écran plus haut), ou alors avec la commande blkid ou lsblk -f. Une fois ceci fait, on édite le fichier /etc/grub.d/40.custom et on y ajoute ceci selon la configuration (UEFI ou pas) en renseignant l’UUID :

menuentry "Windows" --class windows --class os {
   insmod part_gpt  # pour partition EFI
   search --no-floppy --set=root --fs-uuid COPIEZ-ICI-LE-UUID
   chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
}

Et on relance update-grub avant de redémarrer.

NOTE : je n’ai pas testé cette solution.

Conclusion

Avec cet article, je comprend désormais mieux le boot EFI, et rEFInd simplifie énormément les problèmes que l’on peut rencontrer avec GRUB dans les configurations multi-boot.

Voilà, c’était le dernier article de l’année 2024 ! :grin:

Retrouver ses fenêtres Gnome au login

Wed, 18 Sep 2024 15:48:17 +0000

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.

On reprend tout ça depuis le début.

Gnome-tweaks

On commence donc par installer gnome-tweaks si ce n’est pas déjà fait :

$ sudo apt install gnome-tweaks

Puis on le lance, et on ajoute les programmes que l’on souhaite voir démarrer automatiquement. Par exemple :

Par défaut, on ne peut indiquer ici qu’une seule instance d’une application donnée. Pour arriver à avoir deux instances de Terminal, il faut aller dans le dossier ~/.config/autostart, et faire une copie du fichier concernant le Terminal :

$ cd ~/.config/autostart
$ cp org.gnome.Terminal.desktop org.gnome.Terminal1.desktop

Et voilà :

À ce stade, les applications démarrent automatiquement dès l’ouverture de session, tout va bien. Mais le positionnement des fenêtres n’est pas forcément celui que l’on souhaite, sauf si les fenêtres sont en plein écran bien sûr.

L’espace de travail

Comme j’aime bien avoir certaines applications en plein écran, j’utilise les espaces de travail que fournit Gnome. Pour ce faire, une extension est fournie de base par Gnome : Auto Move Windows.

Je place donc Evolution sur l’espace de travail numéro 2 :

Je ne suis d’ailleurs plus certain que cette étape soit requise, puisque l’extension Smart Auto Move ci-dessous gère également les espaces de travail.

Smart Auto Move

Reste à gérer le positionnement des fenêtres. On va installer une autre extension Gnome pour ce faire.

Smart Auto Move est une extension Gnome qui permet de sauvegarder l’emplacement des fenêtres de toutes vos applications, et de les restaurer au démarrage. De plus, il supporte Wayland, ce qui tombe bien puisque c’est le serveur d’affichage que j’utilise. Il gère aussi le multi-écran (avec toutefois des problèmes pas encore résolus si l’on ajoute/supprime les écrans comme dans le cas d’un laptop avec station d’accueil).

On commence donc par installer l’extension :

Puis on lance l’application Extensions de Gnome, et on ouvre les paramètres de SAM. Les fenêtres ouvertes sont automatiquement détectées et affichées dans l’onglet “Saved Windows” :

Il ne reste plus qu’à positionner chaque fenêtre comme on le souhaite, sur les espaces de travail ou sur l’écran de notre choix. Une fois ceci fait, il suffit d’activer l’option “Freeze Saves” sur l’onglet General. Tout est alors sauvegardé et gardé en l’état.

À la prochaine ouverture de session, on retrouve alors les fenêtres de nos applications aux positions que l’on avait défini. :cool:

Gnome Console

Il se trouve que j’utilise désormais Console, le nouvel émulateur de terminal de Gnome, arrivé avec la version 42. S’il n’est pas installé, la commande est la suivante :

$ sudo apt install kgx

Et j’ai rencontré des problèmes pour lancer deux instances de ce terminal. La manip décrite ci-dessus pour gnome-terminal ne fonctionnait pas, une seule fenêtre s’ouvrait, même je voyais bien deux instances dans “Applications au démarrage”.

En fait, il faut aller dans ~/.config/autostart, éditer les deux fichiers concernant Console, soit org.gnome.Console.desktop et org.gnome.Console1.desktop (ce dernier étant une copie du premier), et de supprimer la ligne DBusActivatable=true responsable de ce comportement. J’ai obtenu cette solution en posant la question sur le forum Discourse de Gnome (ici).

Conclusion

C’est une bonne chose de faite, et bien pratique. Désormais, après un redémarrage, je retrouve mon environnement de bureau comme je le souhaite. La seule chose que je n’ai pas réussi à paramétrer, c’est d’avoir certaines applications démarrées automatiquement, mais avec une fenêtre en status “minimized”. Pas sûr que ce soit possible, on voit parfois des applications qui proposent cette option, et cela ne fonctionne pas toujours (selon le gestionnaire de fenêtres).

Pas d'icône dans le Dash de Gnome

Sun, 11 Aug 2024 17:02:36 +0000

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 :

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.

pascal$ cat /usr/share/applications/de.wedesoft.anymeal.desktop
[Desktop Entry]
Name=anymeal
GenericName=Recipe Manager
Comment=Free recipe management software
Keywords=recipes;cooking;database;
Exec=anymeal
Terminal=false
Type=Application
Icon=anymeal
Categories=Qt;Utility;Viewer;

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 :

pascal$ cat /usr/share/applications/de.wedesoft.anymeal.desktop
[Desktop Entry]
Name=anymeal
GenericName=Recipe Manager
Comment=Free recipe management software
Keywords=recipes;cooking;database;
Exec=anymeal
Terminal=false
Type=Application
Icon=anymeal
Categories=Qt;Utility;Viewer;
StartupWMClass=anymeal

À 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 ! :mad: 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.

pascal$ cat /usr/share/applications/de.wedesoft.anymeal.desktop
[Desktop Entry]
Name=anymeal
GenericName=Recipe Manager
Comment=Free recipe management software
Keywords=recipes;cooking;database;
Exec=anymeal
Terminal=false
Type=Application
Icon=anymeal
Categories=Qt;Utility;Viewer;
StartupWMClass=anymeal
StartupNotify=false

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 :

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.

Luminance pour régler la luminosité des écrans

Sat, 06 Jul 2024 16:12:47 +0000

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… :evil:

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 D isplay D ata C hannel (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 : C ommand I nterface) 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 ! :grin:

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.

Ce que j’ai fait :

$ sudo apt install ddcutil
$ ddcutil interrogate
No /dev/i2c devices exist.
ddcutil requires module i2c-dev

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 :

$ sudo echo i2c-dev > /etc/modules-load.d/ddcutil.conf
$ sudo reboot

Et au redémarrage, je peux enfin utiliser Luminance, régler la luminosité, et même synchroniser les valeurs entre les deux moniteurs :

Voilà, un petit outil bien sympathique. Je vais suggérer au développeur d’y intégrer le contraste, puisque le DDC permet aussi ce réglage…

La fenêtre de KeepassXC sous Gnome Wayland

Wed, 12 Jun 2024 16:45:40 +0000

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 ! :cry:

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.

Voilà à quoi ressemblait la fenêtre une fois keepassxc-full d’installé :

Les contours de la fenêtre sont mal définis (pas de bordure), la barre de titre n’est pas de la bonne couleur et ses boutons de contrôle sont différents : on est loin de la fenêtre de Gnome par défaut pour mon thème (Adwaita). Ça n’a l’air de rien, mais quand cette fenêtre était sur un fond blanc, je perdais mes repères pour déplacer la fenêtre avec la souris. Comme quoi un environnement de bureau homogène est important pour nos réflexes visuels.

Info

Au passage, j’installe keepassxc-full, car j’utilise l’extension dans Firefox. En effet, le package par défaut de keepassxc est désormais réduit au minimum (aucune fonctionnalité réseau) pour assurer une sécurité optimale et est donc fournit sans les options pour gérer une extension dans le navigateur.
On peut soit installer keepassxc puis le paquet webext-keepassxc-browser (dédié pour l’extension navigateur) , soit installer keepassxc-full pour retrouver le paquet habituel.

J’ai d’abord cherché du côté de KeepassXC dans les issues sur le dépôt Github de KeepassXC. Je tombais vite sur ces infos :

Title bar color and min max styling are not controlled by KeePassXC. Those are set by the window styling of the compositor.

This isn’t a problem with KeePassXC, you’ll have to direct your concern with either Qt or Gnome.

J’ai alors lancé une VM Fedora pour vérifier que la fenêtre s’affichait correctement avec cet OS qui fournit un Gnome réputé d’origine (non modifié), et c’était bien le cas. J’ai ensuite lancé une VM Debian 12 (version stable) et constaté que le même problème était présent.

Première solution

Voici la première solution (contournement) trouvée, mais ce n’est pas celle que j’ai choisi finalement.

En regardant d’autres problèmes de fenêtrage sur le même dépôt Github de KeepassXC, de fil en aiguille et de click en click, j’arrivais sur ce problème de copier/coller. Et de fait, une solution de contournement était proposée : il s’agissait d’éditer le fichier /usr/share/applications/org.keepassxc.KeePassXC.desktop, et de modifier la ligne Exec :

Exec= keepassxc %f
TryExec=keepassxc

En ajoutant la définition d’une variable QT avant de lancer KeepassXC :

Exec=env QT_QPA_PLATFORM=xcb keepassxc %f
TryExec=keepassxc

NOTE : Penser aussi à modifier le fichier ~/.config/autostart/org.keepassxc.KeePassXC.desktop si KeepassXC est défini en démarrage automatique et que vous choisissez cette solution.

Cela fonctionnait, mais ne règle finalement le problème que pour KeepassXC, oblige à modifier deux fichiers manuellement, et il n’est pas sûr que cela résiste à une mise à jour de l’application… J’ai donc continué à chercher, cette fois avec le nom de cette variable Qt.

Solution pérenne

Et je suis tombé sur cette page : Fix no window border issuefor Qt Apps in GNOME Wayland. Il propose trois solutions, dont celle ci-dessus, mais je préfère celle-ci :

La solution consiste à installer un paquet QGnomePlatform, qui permet aux applications Qt d’utiliser le thème de Gnome :

QGnomePlatform is a Qt Platform Theme designed to use as many of the GNOME settings as possible in unmodified Qt applications. It allows Qt applications to fit into the environment as well as possible.

Le projet n’est toutefois plus maintenu ni développé, mais toujours disponible dans Debian 13 et donc opérationnel. C’est à mon avis la meilleure solution, car elle est plus globale et fonctionnera pour toute application Qt installée sur le PC qui aurait le même souci.

Il suffit donc d’installer le paquet :

$ sudo apt install qgnomeplatform-qt5

Puis d’aller définir une variable dans le fichier qui s’exécute à l’ouverture de session. Il s’agit soit de .profile, de .bash_login ou de .bash_profile selon votre environnement (un seul existe) . Dans mon cas, c’est .profile, j’y ajoute donc la ligne suivante :

export QT_QPA_PLATFORMTHEME='gnome'

Et voilà, après un logout/login, je peux enfin lancer KeepassXC avec une fenêtre correspondant à mon thème Gnome : :cool:

Une bonne chose de faite, pour un problème dont j’aurais du m’occuper il y a bien longtemps !

Ventoy, la clef USB universelle

Sat, 06 Apr 2024 14:46:27 +0000

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) :

Installation

Il suffit de télécharger la dernière image sur le site officiel, et de dézipper l’archive dans un dossier. Pour ma part, j’ai créé un dossier /home/pascal/.local/bin/Ventoy afin de garder l’outil. Il ne plus qu’à lancer le script qui va bien, dans mon cas VentoyGUI.x86_64. La page officielle " Get Started" est ici.

La fenêtre de Ventoy s’ouvre (sélectionner le langage French) :

NOTE : Il existe aussi une WebUI si vous préférez : dans ce cas, lancer la commande sudo VentoyWeb.sh puis ouvrir la page http://127.0.0.1:24680.

À noter que Ventoy peut être aussi être installé sur un disque local, mais par défaut seuls les clefs USB sont affichées (pour éviter les erreurs). Il faut aller dans le menu Option et cocher “Afficher tous les périphériques” si vous le désirez.

Avant de lancer l’installation, il reste une question à se poser : souhaite-t-on créer sur la clef USB une partition MBR ou GPT ?

J’ai choisi GPT car c’est la partition d’amorçage des BIOS UEFI que l’on trouve partout aujourd’hui. Si l’on souhaite travailler plutôt avec des vieux PCs, il est sans doute préférable de choisir MBR. Cette page résume quelques informations sur le sujet.

Il ne reste plus qu’à cliquer sur le bouton Installation, un message vous prévient que le périphérique va être formaté, et quelques secondes plus tard, votre clef USB est prête :

Après l’installation, la clef USB est divisée en deux partitions :

Une première Ventoy formatée en exFAT (on peut la reformater dans un autre système si on le souhaite). C’est sur cette partition que seront copiées les images ISO que l’on souhaite utiliser.
Une seconde VTOYEFI de 32 Mo contenant les informations nécessaires à Ventoy et au boot. On peut y voir les dossiers EFI, GRUB, tool et ventoy…

Au démarrage, Ventoy va scanner toute la partition 1 pour y trouver les images ISO. On peut donc les copier à la racine de la partition 1, ou bien créer un dossier ISO pour organiser l’arborescence.

Si l’on dispose d’une clef de grande capacité, on peut aussi réserver de l’espace à la fin de la clef pour y créer une ou deux partitions réservées à d’autres usages. Il est par contre impératif que Ventoy occupe les partitions 1 et 2. Voir cette page pour plus d’informations.

Voilà, il ne reste plus qu’à copier quelques images ISO sur la clef, et de démarrer dessus : c’est cool de pouvoir utiliser plusieurs images avec une seule et même clef USB :

Plugins

Il y a pas mal de Plugins pour étendre les capacités de Ventoy ou le personnaliser (thème, menus, etc…). Pour les configurer, il est recommandé d’utiliser le plugin VentoyPlugson, la syntaxe du fichier ventoy.json pouvant se révéler peu tolérante aux erreurs de syntaxe…

Tous les fichiers liés aux plugins doivent être placés dans le dossier ventoy de la première partition.

VentoyPlugson plugin

La page de documentation du plugin se trouve ici.

Pour le lancer, il suffit d’exécuter le script VentoyPlugson.sh présent dans le dossier Ventoy que l’on a créé précédemment, en indiquant le périphérique USB concerné (taper $ lsblk pour l’identifier en cas de doute), en mode sudo :

$ sudo ./VentoyPlugson.sh /dev/sde
Ventoy version in Disk: 1.0.97
Disk Partition Style  : GPT
Secure Boot Support   : YES
/dev/sde1 is mounted at /media/pascal/Ventoy exfat
ventoy directory exist OK

===============================================================
  Ventoy Plugson Server is running ...
  Please open your browser and visit http://127.0.0.1:24681
===============================================================

################## Press Ctrl + C to exit #####################

Il suffit ensuite d’ouvrir la page web indiquée pour afficher la page d’accueil du plugin :

Global Control Plugin

La page de documentation du Plugin est ici.

Ce plugin permet de définir pas mal de paramètres globaux, je commence par celui-là pour passer Ventoy en français : VTOY_MENU_LANGUAGE à fr_FR, et VTOY_DEFAULT_KBD_LAYOUT à FRENCH.

On peu aussi citer le paramètre VTOY_LINUX_REMOUNT pour pouvoir accéder à la clef USB en ayant booté sur un Live CD Linux car par défaut ce n’est pas possible (linux kernel restriction). Ce paramètre est toutefois expérimental et n’a pas été totalement testé.

Mais celui qui m’intéresse pour l’instant, c’est le Persistence Plugin : en effet, il permet lorsque l’on démarre sur un CD Live (Debian, Mint…) de conserver les modifications effectuées, telles que la langue, la disposition clavier, ou même des programmes installés. C’est vraiment quelque chose d’indispensable dans le cas d’une utilisation d’une distribution en mode “Live”.

Persistence Plugin

La page de documentation du Plugin se trouve ici.

Pas besoin de créer une partition dédiée comme c’est souvent le cas pour ce besoin : grâce à Ventoy, un simple fichier sera suffisant. Attention, sa taille peut tout de même être conséquente, selon vos besoins (de 256 Mo à 4 Go typiquement). J’ai choisi 4 Go pour avoir suffisamment de place ; après on doit pouvoir faire encore plus gros si l’on a une clef USB de grande capacité.

Il est même possible d’installer plusieurs fichiers pour une même distribution : dans ce cas, Ventoy proposera un menu pour sélectionner le fichier de persistance voulu au démarrage. Ce peut être pratique pour avoir plusieurs configurations disponibles pour une même distribution.

Ventoy pousse le détail jusqu’à fournir une liste de fichiers “prêts à l’emploi” que l’on peut télécharger ici. C’est pratique car il y a plusieurs types de fichiers selon les OS utilisés.
En cas de besoins spécifiques, un script CreatePersistentImg. sh est fourni pour créer ses propres fichiers. Voir la page du plugin car les paramètres à passer diffèrent en fonction des spécificités de chaque OS.

Info

L’archive comprenant les fichiers “prêts à l’emploi” n’est pas très grosse, puisqu’il s’agit de fichiers vides ! (l’algo de compression s’en donne à cœur joie…). Mais lors de l’extraction du fichier vers la clef USB (dans mon cas, j’ai choisi un fichier de 4 Go), il faudra un certain temps pour y copier le fichier (copier des zéros prend autant de temps que de copier des 1 et des 0…). :wink: . En cas de doute, utiliser la commande sync pour s’assurer que le transfert est bien terminé.

Je vais créer un fichier de persistence pour Debian et un autre pour LinuxMint. Ce dernier OS (version Cinnamon) est pratique pour faire découvrir Linux à quelqu’un venant de Windows : l’interface est proche, et tout est fait pour simplifier son utilisation. Et je veux l’avoir en français dès le démarrage…

Pour Debian, j’extrais le fichier persistence_ext4_4GB_persistence.dat, et pour LinuxMint ce sera le fichier persistence_ext4_4GB_casper-rw.dat. Une fois extraits dans le dossier ventoy de la première partition, je les renomme afin de mieux les identifier.

Puis je lance le plugin VentoyPlugson et sa page web, sélectionne à gauche “persistence Plugin”, clique sur Add, et fournit les infos demandées :

La page affiche alors les infos suivantes : on voit que l’on peut ajouter un autre fichier “persistence” pour la même image, ou ajouter un autre fichier pour une autre image ISO :

Je vérifie le contenu du fichier ventoy.json :

$ ls /media/pascal/Ventoy/ventoy/
persistence_ext4_4GB_casper-rw_linuxmint21_3.dat  ventoy_backup.json
persistence_ext4_4GB_debian12_5_0.dat             ventoy.json
[~]
$ cat /media/pascal/Ventoy/ventoy/ventoy.json
{
    "persistence":[
        {
            "image": "/debian-live-12.5.0-amd64-gnome.iso",
            "backend":[
                "/ventoy/persistence_ext4_4GB_debian12_5_0.dat"
            ]
        },
        {
            "image": "/linuxmint-21.3-cinnamon-64bit.iso",
            "backend":[
                "/ventoy/persistence_ext4_4GB_casper-rw_linuxmint21_3.dat"
            ]
        }
    ]
}

Voilà, il ne reste plus qu’à tester tout ça en redémarrant le PC et en appuyant sur F8 pour sélectionner la clef Ventoy, lancer Debian ou Mint, modifier ou ajouter quelque chose, puis redémarrer et voir si le changement a bien été sauvegardé ! :cool:

Personnalisation

Je ne vais pas me limiter à ces deux OS Live, je vais aussi y copier une image ISO d’installation Windows 10, et quelques images d’utilitaires Linux et/ou Windows, histoire d’avoir une clef complète ( "One ring to rule them all"). Et je n’ai déjà plus assez de place sur la clef pour une image d’installation de Windows 11 ! :sad:

Une fois ceci fait, reste à soigner l’apparence : thème, menu, et une spécificité pour le fichier WIM pour une image d’un mini Windows 10 trouvé

La page de documentation du Plugin se trouve ici.

Un autre plugin pratique et rapide à configurer est le “Menu Alias”, qui permet de donner un alias plus convivial aux noms de fichiers ISO. On procède de la même façon en utilisant VentoyPlugson comme interface de configuration, et pour chaque fichier ISO on fournit un alias. On obtient alors un menu déjà un peu plus sympa :

Image List plugin

La page de documentation du Plugin se trouve ici.

Par défaut, on a vu que Ventoy scanne toute la partition pour y trouver les images ISO, puis il les affiche par ordre alphabétique.

Pour s’affranchir de l’affichage par ordre alphabétique, la meilleure solution est d’utiliser le plugin “Image List”. Ce dernier a deux modes de fonctionnement :

White List : Ventoy affiche une liste statique des images ISO que vous renseignez. On perd donc le scan et l’affichage automatique des ISO.
Black List : on conserve le scan automatique, mais les ISO listées ne seront pas affichées.

Ici, je choisis de mettre en avant les images “Live” de Debian et Mint, puis les outils selon leur fréquence d’usage :

Wimboot plugin

La page de documentation du plugin se trouve ici.

Windows ayant l’habitude de réinventer la roue, a son propre format pour les images disques, ce sont des fichiers .WIM. Il faut dès lors activer ce plugin (en fait copier un fichier ventoy_wimboot.img sur la clef) afin de pouvoir booter sur ces fichiers. La mini-image de Windows 10 que j’ai trouvé (sur medicatUSB, voir en fin d’article) utilise ce format, j’en ai donc besoin.

La page de documentation du plugin se trouve ici.

Ventoy présente par défaut un second menu une fois l’image sélectionnée, permettant d’autres modes d’amorçage en cas de problème (Wimboot, Grub2, memdisk). Je l’ai laissé activé, à voir à l’usage si j’en ai réellement besoin.

Theme Plugin

La page de documentation du plugin se trouve ici.

On peut donc aussi modifier l’apparence de Ventoy : ce dernier étant basé sur Grub2, tous les thèmes pour Grub peuvent être utilisés. Vous pouvez faire votre choix sur la page GRUB Themes - Gnome-Look.org., certains thèmes sont directement faits pour Ventoy.

Il suffit alors d’extraire le fichier du theme dans la partition 1 (il peut être utile de créer un dossier theme pour s’y retrouver !). Puis on procède toujours de la même façon avec le plugin VentoyPlugson, en lui indiquant le chemin du fichier theme.txt, et qui se chargera de modifier le fichier ventoy.json.

On voit que sur l’image ci-dessus, en bas à gauche, les infos de version et de “boot mode” sont peu lisibles (bleu sur fond noir). Pour corriger cela, il faudra aller dans le fichier ventoy.json et modifier la valeur du paramètre ventoy_color (ici, je l’ai passé en blanc):

$ more ventoy.json
{
    "control":[
        { "VTOY_LINUX_REMOUNT": "1" },
        { "VTOY_DEFAULT_KBD_LAYOUT": "FRENCH" },
        { "VTOY_MENU_LANGUAGE": "fr_FR" }
    ],
    "theme":{
        "file": "/ventoy/adwaita/theme.txt",
        "ventoy_color": "#ffffff"
    },

Quant à la couleur du menu des touches fonctions, elle se définit dans le fichier theme.txt du thème (blanc par défaut avec mon thème) :

+ hbox{
    left = 30%
    top = 95%
    width = 10%
    height = 25
    + label {text = "@VTOY_HOTKEY_TIP@" color = "white" align = "left"}

S’il est nécessaire de redéfinir l’emplacement du cadre du menu s’il y a beaucoup d’entrées (ce que j’ai du faire pour éviter une barre de navigation verticale puis un empiétement sur le menu des touches fonctions), cela se passe aussi dans theme.txt (en modifiant les valeurs de top et height):

+ boot_menu {
  left = 10%
  width = 80%
  top = 25%
  height = 66%

Les valeurs left, top, width et height ci-dessus permettent de définir le cadre du menu (j’ai du ajuster

L’image de fond d’écran dans le dossier du thème est background.png. Il est donc facile de mettre le fond d’écran de votre choix si vous le souhaitez.

La page de documentation du plugin se trouve ici.

Il ne reste plus qu’à ajouter icônes pour que ce soit parfait ! C’est très simple, on copie les icônes dans un sous-dossier icons du thème, puis on les lie au fichiers images. La “Key/Absolute Path” doit être une chaîne de caractère faisant partie du nom du fichier image, et “Menu Class” le nom du fichier de l’icône (debian.png, linuxmint.png, etc…).

Voilà, avec tout ça, j’ai déjà une clef USB pas mal du tout ! Mais je n’ai pas trouvé comment insérer un séparateur dans le menu de présentation des différentes images, et je voulais séparer les images d’OS des outils Linux et Windows.

J’ai fini par créer des fausses images ISO avec genisoimage (en pointant sur un dossier vide de manière à obtenir un fichier ISO de petite taille) :

$ sudo apt install genisoimage
$ genisoimage -o separator.iso /home/pascal/emptydir/

que j’ai ensuite inséré dans le fichier ventoy.json :

"menu_alias":[
...
        {
            "image": "/ISO/menu-separator.iso",
            "alias": "-----"
        },
        {
            "image": "/ISO/menu-separator2.iso",
            "alias": "-----"
        }
    ],
"image_list":[
        "/ISO/debian-live-12.5.0-amd64-gnome.iso",
        "/ISO/linuxmint-21.3-cinnamon-64bit.iso",
        "/ISO/Windows-10-Pro-Home-v1803-FR-x64.iso",
        "/ISO/menu-separator.iso",
        "/ISO/gparted-live-1.6.0-1-amd64.iso",
        "/ISO/clonezilla-live-3.1.2-9-amd64.iso",
        "/ISO/systemrescue-11.00-amd64.iso",
        "/ISO/rescatux-0.74.iso",
        "/ISO/supergrub2-classic-2.06s2-beta1-x86_64_efi-CD.iso",
        "/ISO/menu-separator2.iso",
        "/ISO/HBCD_PE_x64.iso",
        "/WIM/Mini_Windows_10.wim"
    ]

J’ai du créer deux fichiers ISO car apparemment on ne peut pas afficher deux fois la même image dans le menu.

Voilà, j’ai désormais une belle clef USB multi-fonctions, prête à l’emploi et bien pratique ! Voir la première image de l’article pour avoir le rendu de toutes ces modifications.

La documentation de Ventoy est très complète, ne pas hésitier à s’y référer en cas de problème. Il existe aussi un forum assez actif semble-t-il, si vous avez des questions ou des besoins spécifiques.

Autres remarques

Clef USB

Selon ce que l’on veut installer comme images ISO sur sa clef, il faudra prévoir une taille suffisante pour celle-ci. Les images ISO peuvent prendre de la place, et la persistance, avec des fichiers de 4Go par exemple, peut vite remplir une clef.

D’autre part, travailler avec la session Live + persistance d’un OS peut se révéler intéressant en mode nomade, ce qui donne une autre possibilité d’utilisation de cette clef. Dès lors, il est bon de choisir une clef USB 3.0 afin d’améliorer la performance.

J’ai vu de belles clefs USB3 avec un double port USB Type A et USB Type C pour des capacités et un prix très raisonnable : 128 Go pour 16 €.

Car n’oublions pas que l’on peut utiliser comme on le souhaite la partition 1 de Ventoy (ou même en créer d’autres), rien n’empêche donc d’utiliser une clef comme ci-dessus pour la connecter aussi au smartphone, y copier des fichiers, etc… Cela fait un solution assez complète avec une seule clef à trimballer. :cool:

MedicatUSB

Une autre solution clef en main existe, avec une multitude d’utilitaires plus ou moins utiles et redondants, MedicatUSB, et désormais basée sur Ventoy. Si vous cherchez une solution complète toute prête, plus orienté Windows à mon sens, cela peut être intéressant.

Il vous faudra une clef d’au moins 32 Go pour l’installer. On y trouve des antivirus, des outils de partitionnement, de sauvegarde et restauration, de réinitialisation de mots de passe, etc… C’est un peu la foire au logiciel !

L’archive à télécharger fait 21 Gb , et le site web n’explique pas grand chose. On trouve la procédure d’installation sur le site GBATemp (qui consiste à installer Ventoy puis extraire l’archive de medicatUSB sur la clef).

J’y ai juste pioché une image “mini Windows 10” qui peut se révéler pratique.

Mise à jour openmediavault v5 vers v7

Tue, 19 Mar 2024 17:50:46 +0000

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…

Obsolescence

Je vois que le dépot armbian pour Buster (soit Debian 10) n’existe effectivement plus. Une petite vérification côté Debian me montre que la version Buster ne sera plus supporté le 20 juin 2024. Les équipes d’ armbian ont donc juste un peu d’avance, sans doute parce que leurs ressources sont limitées.

Rien d’alarmant, je pourrais rester en l’état (tant que ça marche…), mais ce n’est jamais une très bonne solution, je fais donc un peu de recherches complémentaires. Et je m’aperçois qu’OMV5 est également passé en E nd O f L ife depuis juin 2022.

Côté matériel, ce n’est pas mieux : ma carte Odroid-HC2 est elle aussi passée en “Obsoleted Product”, et il n’y a plus d’images de fournies pour Debian v11 ou même v12… La page armbian n’affiche même plus de modèles Odroid pour une architecture armhf ! Je vous le dis, le temps passe vite et en 4 ans, plus rien n’est supporté ! :eek:

Ma seule option est alors de faire une mise à jour d’OMV5 vers OMV6 pour passer à Debian 11.

Suppression des mails

Mais dans un premier temps, comme cela me fatiguait de recevoir un mail d’erreur tous les matins, j’ai commencé par mettre en commentaire le lien pointant sur le dépôt en question dans le fichier /etc/apt/sources.list.d/armbian.list :

$ cat /etc/apt/sources.list.d/armbian.list
# deb http://apt.armbian.com buster main buster-utils buster-desktop

Cela a fonctionné, mais j’ai alors reçu un autre mail quotidien concernant le dépôt de plugins :

CRON-APT RUN [/etc/cron-apt/config]: Sun Mar 17 07:37:59 CET 2024
CRON-APT SLEEP: 1502, Sun Mar 17 08:03:01 CET 2024
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get  update -o quiet=2
E: The repository 'https://dl.bintray.com/openmediavault-plugin-developers/usul buster Release' does not have a Release file.

Et donc même façon de résoudre le problème, je commente la ligne dans /etc/apt/sources.list.d/omvextras.list :

$ cat /etc/apt/sources.list.d/omvextras.list
# deb https://dl.bintray.com/openmediavault-plugin-developers/usul buster main

Mise à jour OMV6

Bon, je savais que tout cela devait être temporaire, et je me décide pour faire une mise à jour d’OMV5 vers OMV6.

Prudent, je commence par faire une image de ma carte microSD avec Clonezilla histoire de pouvoir revenir en arrière si la mise à jour plante, car je ne souhaite pas me retrouver bloqué sans serveur Plex, Nextcloud ou Qbittorrent…

Puis je lance la commande suivante pour m’assurer que tout est à jour :

$ sudo omv-upgrade

Huit paquets sont d’ailleurs mis à jour, parfait. J’enchaîne avec la véritable commande de mise à jour vers OMV6 et Debian 11. En fait les deux sont liés, chaque version d’OMV est associée à une version de Debian, et le script de mise à jour en tient compte bien sûr.

$ sudo omv-release-upgrade

La fenêtre suivante s’affiche :

Je valide, et la mise à jour démarre. Cela prend du temps, mais à la fin le système redémarre et je découvre la nouvelle interface d’OMV6, dont un écran de connexion inspiré de Matrix du plus bel effet :

Sauf que je m’aperçois que tout ce qui concerne les plugins a été totalement revu et profondément modifié. Et de ce fait, je n’ai aucun plugin d’installé, et bien sûr aucun de mes conteneurs Docker ne fonctionne.

Je commence à regarder tout ça, à chercher un tuto sur internet, et puis je me dis que dans ces conditions, autant en profiter pour passer à OMV7. Il sera toujours temps de refaire la configuration des plugins ensuite, et j’aurai une version très récente d’Openmediavault, puisque cette version date du 03 mars 2024.

Aussitôt dit aussitôt fait, un coup de omv-upgrade suivi d’un omv-release-upgrade et me voilà en OMV7 sous Debian 12 Bookworm. :cool:

Configuration

Je me retrouve donc au même point qu’avec OMV6 : aucun plugin d’installé. Il faut commencer par installer les OMV Extras en téléchargeant un script comme indiqué sur cette page :

$ sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Pour ma part, j’ai du d’abord télécharger le fichier, puis l’exécuter, le “pipe” sur bash ne fonctionnait pas. Donc cette commande :

$ sudo wget https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install

Puis je renomme le fichier en installomvextra.sh et lance le script, qui extrait un fichier openmediavault-omvextrasorg_latest_all7.deb puis procède à l’installation.

Voilà, nos plugins sont désormais disponibles, et pour Docker, il faut installer openmediavault-compose dans Système-Extensions :

À ce stade, j’ai un beau menu dans Services-Compose qui me remplit d’espoir : Docker a l’air beaucoup mieux intégré à l’interface d’OMV, on y retrouve directement les containers par exemple, mais pas que :

Mais quand je vais dans Conteneur, si je vois bien mes conteneurs (c’est déjà ça), il sont tous à l’arrêt et refusent de démarrer. Il faut d’abord aller dans Shared Folders, vérifier que tout est correct et corriger ce qui ne l’est pas.

Puis aller dans Compose - Paramètres vérifier les deux entrées suivantes qui correspondent aux données des containers créés (Compose Files), et à l’emplacement de Docker (j’avais déplacé Docker sur le disque externe du NAS, voir cet article).

Une fois tout ceci vérifié, j’essaie à nouveau de démarrer un container, et nouvel échec ! Le message d’erreur n’est pas évident, si ce n’est que le container ne peut être démarré, et un beau " function not implemented" :

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker restart  25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc 2>&1': Error response from daemon: Cannot restart container 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown

OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker restart  25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc 2>&1': Error response from daemon: Cannot restart container 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown in /usr/share/openmediavault/engined/rpc/compose.inc:1080
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(622): OMVRpcServiceCompose->{closure}()
#1 /usr/share/openmediavault/engined/rpc/compose.inc(1068): OMV\Rpc\ServiceAbstract->execBgProc()
#2 [internal function]: OMVRpcServiceCompose->doContainerCommand()
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(122): call_user_func_array()
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()
#5 /usr/sbin/omv-engined(535): OMV\Rpc\Rpc::call()
#6 {main}

Le Kernel

Je fais alors une recherche sur internet, et je dois dire que je suis assez chanceux, car je tombe immédiatement sur cette page, qui indique que le problème vient d’une version de kernel trop ancienne.

Je vérifie sur ma machine et effectivement, mon kernel ne semble pas à niveau :

$ uname -a
Linux odroidhc2 4.14.222-odroidxu4 #1 SMP PREEMPT Mon Nov 22 12:13:27 UTC 2021 armv7l GNU/Linux
$
$ sudo docker info
...
Kernel Version: 4.14.222-odroidxu4
...
$

Mon premier réflexe est d’aller voir le fichier que j’avais modifié manuellement pour éviter le premier mail : il est toujours en l’état avec le ligne pour Buster commentée, j’y ajoute la ligne qui correspond à ma nouvelle version de Debian :

$ cat /etc/apt/sources.list.d/armbian.list
# deb http://apt.armbian.com buster main buster-utils buster-desktop
deb http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop
$

Puis je lance une mise à jour, et je vois que 3 paquets vont être mis à jour : armbian-config armbian-firmware base-files. Mais cela ne change pas la version du kernel, et ne résout pas mon problème.

Pour identifier le kernel à installer, la commande suivante permet de les afficher :

$ sudo apt-cache search linux-image | grep odroid
linux-image-current-odroidxu4 - Armbian Linux current kernel image 6.1.79-current-odroidxu4
linux-image-edge-odroidxu4 - Armbian Linux edge kernel image 6.1.77-edge-odroidxu4
linux-image-legacy-odroidxu4 - Linux kernel, version 4.14.222-odroidxu4

Et j’ai déjà vu lors de l’installation de la première image que ma carte odroid-hc2 utilise la même image que celle d’un odroid-xu4 : voir cet article sur le changement du motd ! :wink: . À priori, il faudrait prendre le “current”. Mais bon j’ai quand même quelques interrogations, je n’ai jamais fait cette opération, et évidemment il n’y a pas le droit à l’erreur…

Mais internet va me fournir une solution alternative, avec un outil armbian dédié pour configurer les cartes ARM, et qu’il suffit d’installer :

$ sudo apt-get install armbian-config

Il ne reste plus qu’à le lancer en mode sudo, puis de choisir System, et enfin de sélectionner Switch to other kernels :

Il ne reste plus qu’à laisser l’outil récupérer les versions disponibles, et choisir parmi celles qu’il vous propose : et l’outil me propose bien la même version de kernel que la commande apt, cela me rassure. Je valide, et le nouveau kernel est installé avant que le système ne redémarre :

Après le redémarrage, je vérifie et cette fois mon kernel est passé en version 6 :

$ uname -a
Linux odroidhc2 6.1.79-current-odroidxu4 #3 SMP PREEMPT Thu Feb  8 13:10:24 UTC 2024 armv7l GNU/Linux

Voici venu le moment décisif : je retourne dans Services - Compose - Conteneurs pour démarrer un container Docker, et YES ! il démarre sans aucun problème… :razz:

Conclusion

La mise à jour d’OMV s’est tout de même très bien passée, puisque j’ai quand même fait un saut de 2 versions majeures où la gestion des plugins a été complètement revues et modifiée, tout en incluant une mise à jour de l’OS (Debian 10 à Debian 12).

Ce n’était donc pas une mince affaire, et finalement, je n’ai eu que quelques paramètres à vérifier côté purement OMV. Pour la version de Kernel, c’était un peu plus compliqué à priori, mais l’utilitaire fourni par armbian a parfaitement rempli sa fonction et résolu mon problème en quelques minutes.

Voilà, il me reste à découvrir un peu mieux cette nouvelle version d’OMV. À priori, je n’aurai sans doute plus besoin de la page Portainer pour gérer mes conteneurs, tout semble gérable à partir de l’interface d’OMV7. Et je suis normalement tranquille pour quelques années de support ! :cool:

Passage en Debian 13 (Trixie) et problème KVM (libvirt)

Sun, 16 Jul 2023 16:45:08 +0000

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” : :cool:

$ 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 :

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 ! :wink: 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.

Voyons voir tout cela…

Problème

Le problème survient semble-t-il après quelques minutes de fonctionnement du PC, après un redémarrage où tout est OK . Puis quelques minutes après, je lance virt-manager et il reste en état “Connexion…”, alors qu’il fonctionnait juste après le démarrage.

Réinstallation

Comme je ne m’en sortais pas, j’ai d’abord décidé de désinstaller puis réinstaller les paquets les paquets nécessaires afin de repartir d’une situation saine. Étape inutile, mais bon… au moins je ne vais installer que les paquets nécessaires.

Je commence par désinstaller les paquets que j’avais installé en Debian 12 :

$ sudo apt  remove qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager
$ sudo apt  purge qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager

Puis je suis la doc Debian pour n’installer que les paquets nécessaires, auxquels j’ajoute virt-manager, l’interface graphique de libvirt :

$ sudo apt install qemu-system libvirt-daemon-system virt-manager

En fait le paquet bridge-utils n’est nécessaire que si l’on souhaite utiliser un bridge pour l’interface réseau des VMs. Ce n’est pas mon cas, en mode NAT c’est plus simple (pour accéder aux autres machines du réseau typiquement).

Ensuite, il faut s’ajouter au groupe libvirt, ainsi qu’au groupe kvm (ce dernier pour éviter d’avoir le mot de passe root à entrer au lancement de virt-manager) :

$ sudo adduser pascal libvirt
$ sudo adduser pascal kvm

Voilà, normalement tout est bon. Il est sans doute préférable de redémarrer le PC à ce moment, et on devrait être en état d’utiliser virt-manager pour créer/utiliser des VMs.

Fichier default.xml

On va beaucoup utiliser par la suite la commande virsh qui permet de gérer les réseaux virtuels créés pour les VMs. C’est l’interface de commande de libvirt. Ces réseaux virtuels sont créés à partir d’un fichier default.xml. Il est bon d’en parler un peu.

Ce fichier default.xml par défaut est situé dans le dossier /etc/libvirt/qemu/networks/. En voici un contenu typique :

On y voit que l’on utilisera le NAT, et le range d’adresse IP qui seront attribuées, ainsi que le nom de l’interface réseau sur laquelle on va s’appuyer : virbr0, soit le bridge virtuel utilisé pour le NAT fourni par libvirt.

À toutes fins utiles, une liste des commandes virsh est disponible ici. En cas de réseau manquant, on peut donc en recréer un ( $ sudo virsh net-create) avec le fichier fournit par défaut. Ce n’est pas nécessaire sauf mauvaise manip, par contre il est préférable de le faire en mode ‘sudo’ : en effet, selon que l’on lance la commande virsh en mode ‘user’ ou en mode ‘sudo’, ce ne sera pas le même réseau virtuel que l’on manipulera, ce qui peut mener à des confusions.

Première analyse

Je commence donc par aller voir du côté de libvirt, avec la commande virsh en mode “sudo”, mais la commande virsh ne répond pas (hang), et je suis obligé de faire un Ctrl-C pour en sortir :

$ sudo virsh net-list --all

Ctrl-C
$

À ce stade, on peut dire que l’on a un souci avec le service libvirtd. Il n’est pas normal que la commande sudo virsh net-list -all ne réponde pas.

Dépannage

Je redémarre donc le service libvirtd pour voir et regarde le status :

$ sudo systemctl restart libvirtd.service
$ sudo systemctl status libvirtd.service
● libvirtd.service - Virtualization daemon
     Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2023-07-16 18:38:08 CEST; 6s ago
TriggeredBy: ● libvirtd-ro.socket
             ● libvirtd-admin.socket
             ● libvirtd.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
   Main PID: 68342 (libvirtd)
      Tasks: 21 (limit: 32768)
     Memory: 39.6M
        CPU: 248ms
     CGroup: /system.slice/libvirtd.service
             ├─ 1654 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib>
             ├─ 1655 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib>
             └─68342 /usr/sbin/libvirtd --timeout 120

juil. 16 18:38:08 Ryzen7-5700G systemd[1]: Starting libvirtd.service - Virtualization daemon...
juil. 16 18:38:08 Ryzen7-5700G systemd[1]: Started libvirtd.service - Virtualization daemon.
juil. 16 18:38:09 Ryzen7-5700G dnsmasq[1654]: read /etc/hosts - 7 names
juil. 16 18:38:09 Ryzen7-5700G dnsmasq[1654]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 names
juil. 16 18:38:09 Ryzen7-5700G dnsmasq-dhcp[1654]: read /var/lib/libvirt/dnsmasq/default.hostsfile

Tout a l’air OK, je ne vois aucune erreur significative. Je relance alorsune commande virsh et Bingo ! cette fois elle répond, le réseau virtuel est actif et démarré :

$ sudo virsh net-list
* Nom       État    Démarrage automatique   Persistant
-------------------------------------------------------
 default   actif   oui                     oui

Et virt-manager démarre , se connecte, affiche mes VMs, et je peux lancer celles-ci, tout fonctionne comme attendu :

Tout va bien, sauf que… si je ferme virt-manager, quelques minutes plus tard, le problème est réapparu à l’identique ! :sad: Par contre, la bonne nouvelle, c’est que je sais désormais qu’un simple redémarrage du service libvirtd résout le problème.

Solution

Ça ressemble tout de même furieusement à un bug de libvirt… après tout je suis sous Debian “testing”, c’est le prix à payer…

J’envoie donc un mail au support libvirt chez redhat, comme je l’avais déjà fait une fois pour un problème avec iptables. Et le soir même, j’ai une réponse :

Likely the systemd issue already mentioned on this list

https://listman.redhat.com/archives/virt-tools-list/2023-July/017724.html

Regards, Jim

Génial, réponse courte mais précise : c’est un problème connu, et ce n’est pas libvirt qui est en cause, mais systemd.

À la lecture des différents threads, on arrive à ce bug, et il en ressort que :

Dans sa configuration par défaut, libvirtd.service lance un processus libvirtd qui s’arrête après 120 secondes d’inactivité (aucun domaine en cours d’exécution et aucun client connecté). Le service reste actif et libvirtd est réactivé à la demande via l’activation de la socket systemd.

Après la mise à jour de systemd 253.4 à 253.5, l’activation des sockets a cessé de fonctionner. Tenter de se connecter à libvirtd via une socket après qu’elle se soit arrêtée ne donne rien.

Voyons dans quelle version de systemd je suis :

$ sudo apt policy systemd
systemd:
  Installé : 253.5-1

Ok, tout concorde, ce bien ce bug. Il est indiqué en “closed” depuis aujourd’hui (15/07) et la version de systemd prévue pour intégrer cette correction est la v254.

Cela ne devrait donc pas tarder, il ne reste plus qu’à attendre ! Je surveillerai les packages mis à jour ces prochaines semaines, en attendant d’y voir systemd ! :cool:

Conclusion

Bonne expérience, j’ai appris plein de commandes concernant la partie réseau virtuel des VMs… et j’en maîtrise mieux désormais le fonctionnement.

La réactivité du support libvirt de redhat est vraiment top et de vraiment bonne qualité. Du coup j’en ai profité pour partager l’info sur le forum debian où un type faisait face au même problème (ici).

Voilà un petit résumé de commandes utiles pour investiguer le problème :

$ sudo systemctl stop libvirtd     !! Arrêt du service libvirt
$ sudo systemctl disable libvirtd     !! Déactivation du service libvirt pour démarrer "propre"

$ sudo ip link delete virbr0     !! Suppression de l'interface réseau

$ sudo virsh net-list --all     !! vérifier l'état du réseau virtuel

$ sudo virsh net-autostart default --disable     !! mettre le réseau en démarrage manuel
$ sudo virsh net-autostart default     !! mettre le réseau en démarrage automatique

$ sudo systemctl start libvirtd     !! démarrer le service
$ sudo systemctl enable libvirtd     !! réactiver le service
$ sudo virsh net-start default     !! démarrer le réseau

Dash to dock : problèmes et solutions

Mon, 03 Jul 2023 16:52:18 +0000

J’utilise depuis longtemps l’excellente extension Dash to Dock pour Gnome, elle remplace avantageusement le dock par défaut de Gnome qui manque singulièrement d’options.

Hélas, comme je suis sous Testing, bénéficiant par conséquence de versions récentes de Gnome, il y a régulièrement des bugs qui apparaissent avec cette extension (plus précisément, la version de Gnome n’est pas encore supportée), et qui m’obligent soit à en changer en attendant la correction, soit à trouver une autre solution…

Voyons voir cela en détail : les problèmes rencontrés avec Dash to Dock, l’alternative Dock from Dash, et enfin comment forcer l’utilisation d’une ancienne version de Dash to Dock, si cette dernière répond à mes attentes.

Problèmes rencontrés

Badge counter

Le premier problème rencontré fut celui du compteur des notifications d’applications (notification badge counter). Au passage de la v79, ce petit compteur bien pratique pour vous indiquer notamment qu’un nouveau mail est arrivé s’est mis à afficher des valeurs inattendues, notamment sur le gestionnaire de fichiers, qui normalement n’en affiche jamais :

Renseignements pris, il s’agit d’un nouveau comportement qui inclut les notifications qui apparaissent dans la liste des notifications de Gnome :

Explications :

Notification badges now also includes the tray notifications you have. This could be probably be re-considered in case an application provides its own counting though.

Et bien sûr, au vu des retours des utilisateurs peu satisfaits de ce nouveau fonctionnement, ils ont reconsidéré leur position, et ont ajouté une option sur la version suivante (v80) pour n’afficher que le compteur fourni par les applications, c’est-à-dire revenir au fonctionnement précédent dont tout le monde était satisfait :

Mauvais moniteur

Quand j’ai installé la v80, un nouveau problème est apparu. Bien que l’affichage du Dock était défini pour le premier écran uniquement, l’extension passait systématiquement sur le second écran après une mise en veille de l’écran ou un redémarrage :

C’était vraiment gênant, et en cherchant dans les bugs, ce problème avait l’air d’avoir plusieurs causes possibles, et pas encore fixé. N’ayant aucune envie de l’afficher sur les deux écrans, le problème s’est alors posé sérieusement de trouver une alternative durable.

Extension Dock from Dash

Quand le premier problème s’est produit, il a fallut attendre un bon mois avant d’avoir cette nouvelle option. Entre-temps, j’avais installé une autre extension similaire, dock-from-dash, basée sur le dock par défaut de Gnome, et très légère, mais avec moins d’options de personnalisation que Dash to Dock. Elle a bien fait son job de remplacement, je la garde désormais sous le coude au cas où.

Forcer une ancienne version de Dash to Dock

Finalement, la meilleure solution est de rester avec la version précédent le premier problème, à savoir la v78, qui me convenait tout à fait : affichage sur le bon écran, et uniquement les notifications de l’application. Oui mais voilà, comment faire ?

La solution est finalement assez simple : il faut récupérer la version que souhaite installer, la dézipper dans un dossier, éditer le fichier metadata.json et modifier le numéro de version afin d’éviter une mise à jour automatique :

{
"shell-version": [
    "40",
    "41",
    "42",
    "43",
    "44"
],
"uuid": "dash-to-dock@micxgx.gmail.com",
"name": "Dash to Dock",
"description": "A dock for the Gnome Shell. This extension moves the dash out of the overview transforming it in a dock for an easier launching of applications and a faster switching between windows and desktops. Side and bottom placement options are available.",
"original-author": "micxgx@gmail.com",
"url": "https://micheleg.github.io/dash-to-dock/",
"gettext-domain": "dashtodock",
"version": 84
}

On peut y voir les versions de Gnome-shell supportées, et en dernière ligne le numéro de version actuelle de l’extension (que j’ai donc modifié).

Dans mon cas j’ai donc téléchargé et dézippé le code source de la version v78 ici, puis modifié le fichier metadata.json comme ci-dessus. Il ne reste plus qu’à lancer l’installation en se plaçant dans le répertoire du zip, et en lançant la commande d’installation, après avoir installé deux packages pour celle-ci fonctionne :

$ sudo apt install massc gettext
$ make install

Si tout se passe bien, on a un beau " done" en fin d’exécution, et on retrouve l’extension dans le dossier des extensions :

Il reste à fermer la session et la rouvrir pour voir l’extension Dash to Dock installée, et identifiée avec le dernier numéro de version (alors que c’est la v78 qui tourne). Il ne reste qu’à l’activer :

Important

Bien sûr, il faudra recommencer l’opération lorsqu’une nouvelle version viendra se mettre à jour automatiquement. Mais ce sera l’occasion de voir si le problème du second moniteur est désormais réglé, puisque celui des notifications est désormais paramétrable.

Prise en main d'Evolution

Mon, 31 Oct 2022 17:35:05 +0000

Me voilà donc avec Gnome Evolution, le client mail par défaut sur Debian, qui a finalement remplacé Thunderbird (voir cet article) sur mon PC. Il s’agit désormais de le paramétrer.

L’interface est claire et ne soulève pas beaucoup de questions, c’est celle d’un client mail classique, au look assez professionnel. Avec le thème d’icône Adwaita sous Debian 12 bookworm/sid, les icônes sont monochromes et très sobres, ce qui n’est pas pour me déplaire :

L’intégration au système est meilleure, que ce soit les agendas, les contacts, et c’est bien agréable. Voilà quelques screenshots :

J’ai rapidement créé mes comptes mails, puis synchronisé mes calendriers et mes contacts. Tout cela est rapide avec les protocoles IMAP (boites mails), et CardDAV et CalDAV pour les contacts et agendas (grâce à mon serveur Baïkal).

Que reste-t-il à faire ? d’abord une boite de réception unifiée pour tous mes comptes mails, c’est quand même bien pratique, mais n’existe pas de base dans Evolution. Ensuite il faudra que je m’organise pour mes archives : d’abord récupérer celles de Thunderbird, et préparer les prochaines.

Pour cela, j’utiliserai les dossiers de recherche, les filtres, les étiquettes… En fait, Evolution propose beaucoup de choses, ne pas hésiter à consulter l’aide, elle entièrement traduite et très complète. Enfin, on verra comment supprimer l’agenda local et celui de Google qui sont apparus et dont je ne veux pas.

Allons-y… C’est un article assez long, mais avec plein d’images ! :wink:

Les comptes

Je ne vais pas détailler la création des comptes, c’est assez basique et ne pose en général aucun problème, il suffit de suivre les recommandations du fournisseur d’une part, et les clients sont de plus en plus intelligents de ce côté, donc “ça roule”.

On retrouve chaque compte listé indépendamment des autres, dans le menu Édition ▸ Préférences ▸ Comptes de messagerie :

En plus des comptes que j’ai créé, il y en a 2 autres qui apparaissent et que je coche car je vais en avoir besoin :

Dossiers de recherche : Celui-là va me permettre de simuler une boîte de réception unifiée.
Sur cet ordinateur : Celui-ci va me servir pour stocker mes archives de mails.

Dossiers par défaut

J’ai tout de même rencontré un petit souci avec l’un de mes comptes : je ne retrouvais pas les mails envoyés à partir de ce compte dans les dossiers “Envoyés” (ou “Sent”). Si j’envoyais un mail à partir de l’interface web de mon compte, ou même de Thunderbird, tout allait bien, mais à partir d’Evolution, pas moyen !

La solution était toute simple, et se trouvait dans les options du compte en question :

Le plus étonnant était que cela n’est arrivé que sur un seul de mes comptes, je ne sais pour quelle raison. En tout cas, il est bon de le savoir et d’aller vérifier ces valeurs en cas de problème.

Dossiers unifiés

Ayant plusieurs comptes mail, j’aimais bien les “Dossiers unifiés” de TH, qui offrent une vue combinée sur toutes vos adresses e-mail, avec une boîte de réception globale, un autre dossier pour les mails envoyés, etc.

Rien de tel de disponible avec Evolution. Il va falloir passer par un dossier de recherche, et le paramétrer de façon à ce qu’il affiche le contenu des boites de réception de chacun des comptes.

Je choisis donc de créer un nouveau dossier de recherche, et le définit comme suit :

Voilà, c’est tout simple, et j’ai ma nouvelle boite de réception unifiée dans laquelle apparaissent les mails reçus de tous mes comptes.

Pour les dossiers Envoyés, c’est un peu différent, mais avec le même principe :

Ces dossiers qui apparaissent dans Evolution sont en fait des dossiers virtuels, et reflètent le contenu du serveur. On peut constater que pour certains comptes, le dossier est bien traduit et s’appelle “Envoyés”. Pour d’autres, ce sera “Sent” ou “OUTBOX”, et un autre aura même à la fois “Envoyés” et “Sent”. Le mieux est alors de les ajouter tous ici !

Pour un dossier unifié “Brouillons”, on procédera de la même manière.

Faire suivre un mail

Par défaut, quand vous faites suivre (forward) un mail reçu, le format du mail en question est attaché en tant que pièce jointe, soit sous la forme d’un fichier sans extension que vos correspondants auront bien du mal à interpréter :

Il est possible de modifier ce format par défaut de manière ponctuelle, en cliquant sur la peite flèche à droite de “Faire suivre” :

Et pour changer le mode par défaut, il faut aller dans le menu Édition ▸ Préférences ▸ Préférences de l'éditeur ▸ Réponses et transfert :

Sauvegarde

Evolution propose une solution de sauvegarde complète. Menu Fichier ▸ Archiver les données d'Evolution tout simplement ; choisir un dossier, accepter la demande de fermeture d’Evolution, et voilà !

Evolution sauvegarde les paramètres, mails, contacts, mémos et agendas. Le fichier chez moi fait 1,5 Go ! J’ai testé la restauration dans une VM, et tout semble bien y être (il faut toutefois ressaisir les mots de passe de chaque compte), y compris les archives dans les dossiers locaux. On pense bien sûr à automatiser l’opération, mais le mode ligne de commande d’Evolution n’offre que quelques options de base, essentiellement sur le mode de démarrage (voir evolution --help-all ).

Si l’on souhaite automatiser cette sauvegarde de manière récurrente, il faudra passer par un script, c’est assez simple à mettre en œuvre apparemment. Tout est expliqué sur cette page. Pour l’instant, les dossiers en question sont déjà sauvegardés par BackInTime en ce qui me concerne, mais si un jour je veux séparer les backups de mails, ça peut être utile.

Mise en places des archives

Maintenant, il faut penser à archiver les mails : il peut toujours être utile de retrouver un mail fût-il vieux de 10 ans ! :smile: L’idée, c’est aussi de déplacer les mails présents sur le serveur (IMAP) vers un dossier local, afin de soulager l’espace occupé sur le serveur qui est généralement soumis à quota.

Organisation

Avant d’aller plus loin, il est nécessaire d’expliquer comment j’étais organisé et ce que j’ai modifié pour m’adapter à ce que propose Evolution.

Avec TH, j’avais pris l’habitude de créer quelques dossiers et sous-dossiers (du genre Admin, Perso, etc…) sur mon compte mail principal (celui définit par défaut), où je classais les mails arrivant dans mon Inbox unifiée et que je voulais conserver :

Ensuite, j’utilisais l’extension AutoArchiveReloaded de TH, qui permettait facilement d’archiver ces mails et de reproduire l’arborescence de ces dossiers en local (voir cet article).

Après avoir regardé ce qu’offrait Evolution de ce côté, je me suis dit qu’il me fallait changer de méthode. En effet, si on peut bien définir un dossier d’archivage, et y envoyer manuellement des mails sélectionnés en choisissant “Archiver”, tout se fait “à plat” et manuellement (voir plus bas).

La mise en place d’un système équivalent à TH me permettant de retrouver mon arborescence de dossiers, et de manière automatisée, est peut-être possible, mais complexe : en utilisant les “filtres”, on doit pouvoir y arriver, mais ce ne sera pas simple, et au mieux un peu fastidieux (il faudra de toutes façons créer un filtre par dossier et sous-dossier concerné).

De plus, les filtres me semblent plus destinés à s’appliquer au courrier entrant (ou sortant), qu’à gérer l’archivage de mails existants. C’est en tout cas ce que j’en ai compris. Et pour ceux qui veulent s’y essayer, attention à bien se rappeler que les filtres s’appliquent dans l’ordre…

Après réflexion, j’ai donc décidé de simplifier mon système d’archivage : plutôt que de déplacer mes mails dans des dossiers qui sont encore sur le serveur, je vais directement les déplacer dans des dossiers locaux, et en profiter pour réduire le nombre de dossiers. Cela ne changera pas grand chose à ma pratique, et l’archivage sera en plus fait directement. :idea: Ici, je les déplace dans un sous-dossier situé dans Sur cet ordinateur/Archives/2022/ :

Importation de Thunderbird

Mais commençons par importer de TH les archives des années précédentes.

Pour les archives locales, il va donc falloir les exporter puis les importer dans Evolution. La partie Export sera très simple grâce à une extension TH appelée ImportExportToolsNG, et l’importation se fera tout aussi facilement avec l’assistant présent dans Evolution.

Dans TH, on définit d’abord un dossier où l’on placera les exports :

Une fois ceci fait, il suffit de faire un click droit sur un dossier de vos archives locales (disons le dossier 2017), puis de choisir Importer / Exporter au format " mbox " / " eml " ▸ Exporter un dossier et ses sous-dossiers (simple) . On retrouve ainsi à plat tous ses dossiers de mails dans le dossier précédemment choisi. Attention : s’il y avait des sous-dossiers, on retrouvera aussi un fichier de 0 octets pour chacun d’entre-eux, qu’il faudra juste supprimer, car ils provoqueraient un message d’erreur lors de l’importation dans Evolution.

Ensuite, on va créer dans Evolution, dans le compte local que l’on a activé précédemment, et sous le dossier Archives, autant de dossiers que nécessaire, un pour chaque année :

Ensuite, il suffit de sélectionner tous les fichiers exportés de TH, faire un click droit, et choisir Ouvrir avec Evolution (le type des fichiers est détecté automatiquement) :

L’assistant d’importation d’Evolution s’ouvre. Le type de fichier “Boîte à lettres Berkeley (mbox)” est affiché, ainsi qu’une prévisualisation du premier mail, il suffit de cliquer sur “Suivant”, choisir un dossier de destination, pour cet exemple “Sur cet ordinateur - 2017” :

Evolution va alors importer tous les fichiers sélectionnés sans ne plus rien vous demander. Il peut être utile ensuite de créer une étiquette 2017 et de l’appliquer à tous les mails du dossier (voir plus bas).

Voilà pour les archives avec Evolution, il y a probablement des choses plus évoluées à faire avec les filtres, mais je n’en ai pas vraiment l’utilité, en tout cas pour l’instant. En fait j’ai même simplifié mon système d’archivage, et c’est très bien comme ça.

Étiquettes, filtres et recherche

Filtre pour les mails entrants

Je me suis tout de même attaché à créer un filtre pour ajouter automatiquement une étiquette “2022” aux mails rentrant… cette année ! :cool:

On crée d’abord l’étiquette dans Édition ▸ Préférences ▸ Préférences du courriel ▸ Onglet Etiquettes en pensant à modifier la couleur qui lui sera affecter :

Une fois ceci fait, je peux créer un filtre dans Édition ▸ Filtres de messages ▸ Ajouter :

Et on crée le filtre qui va s’appliquer à n’importe quel compte :

TIP : Et chaque début d’année, il suffit de modifier cette règle (nom, dates) pour la nouvelle année (inutile d’en créer une nouvelle, puisque l’ancienne ne servira plus).

Pour les comptes IMAP, Il faut aussi vérifier que l’option suivante est bien activée dans Édition ▸ Préférences ▸ Comptes de messagerie ▸ Options de réception :

Filtre pour les messages sortants

C’est bien archiver les mails reçus, c’est encore mieux de ne pas oublier les mails envoyés. Parfois on a besoin de retrouver ce que l’on a précédemment répondu, en cas de non réponse, ou de mauvaise compréhension, etc…

Pour ce faire, j’ai créé un filtre sur les messages sortants, qui me permet de les copier automatiquement dans le dossier des archives locales. Voilà le filtre en question, sur le même principe que celui des étiquettes :

Chaque message envoyé est immédiatement copié dans le dossier d’archives. :cool:

En début d’année prochaine, je viderai les dossiers virtuels “Envoyés” ou “Sent” de chaque compte pour libérer de la place sur les serveurs, et je modifierai le filtre pour pointer sur un nouveau dossier Sur cet ordinateur/Archives/2023/Envoyés que j’aurai créé.

TIP : Et chaque début d’année, il suffit de modifier cette règle (nom, date, dossier) pour la nouvelle année (inutile d’en créer une nouvelle, puisque l’ancienne ne servira plus).

Recherche

Grâce à l’étiquette, on peut par exemple, dans les dossiers de recherche que l’on a utilisés pour créer la boite de réception unifiée, créer un nouveau dossier intitulé “Recherche dans Archives”, et le configurer par exemple comme cela : recherche dans les dossiers locaux, on fournit l’année via l’étiquette, et on rentre un mot clef.

C’est juste un exemple bien sûr, on peut aussi lancer une recherche sur tout le dossier Archives (et les sous-dossiers) directement depuis la fenêtre principale, en cherchant un mot clef, ou un expéditeur, etc…

Archivage

Je reviens sur les possibilités d’archivage que propose Evolution, au cas où…

C’est un peu trompeur, car il y a une option globale où l’on peut définir un dossier pour les archives, dans Édition ▸ Préférences ▸ Préférences du courriel ▸ Onglet Général :

Mais cela ne concerne que les mails dans les dossiers locaux, et pas ceux qui sont dans des dossiers virtuels de chaque compte IMAP. Pour archiver ceux-ci, il faut aller indiquer le dossier pour chaque compte, dans le menu Édition ▸ Préférences ▸ Comptes de messagerie :

Voilà, une fois ceci fait, il suffit de sélectionner les mails que l’on souhaite archiver, et ils seront déplacés dans ce dossier.

Voilà pour les archives avec Evolution, il y a certainement des choses plus évoluées à faire avec les filtres, mais je n’en ai pas vraiment le besoin, en tout cas pour l’instant. Attention d’ailleurs à l’ordre des filtres si vous en créez plusieurs, car ils sont appliqués dans l’ordre, et cela peut avoir des effets inattendus !

Agendas

Un petit mot à propos des agendas : je me suis retrouvé avec deux calendriers non désirés : un correspondant au compte local (celui utilisé pour les archives), et un calendrier Google ajouté automatiquement et dont je n’ai aucune utilité :

Pour le calendrier local, le seul moyen que j’ai trouvé pour le faire disparaître est d’aller éditer le fichier ~/.config/evolution/sources/system-calendar.source et de passer le paramètre Enabled à false :

J’ai d’abord essayé de le supprimer, mais il est recréé automatiquement au redémarrage.

Pour le calendrier Google, c’est un manque d’attention lors de la création du compte mail, il faut décocher l’option lors de la création de celui-ci (idem pour les contacts d’ailleurs) :

Je supprime donc le compte, et le recrée en décochant ces options. ET voilà, il ne me reste que les agendas que je souhaite :

Conclusion

Il est temps de finir ce long article ! Bon, cela m’a permis de voir à peu près ce que me propose Evolution, et comment m’y adapter.

La partie Archive m’a fait hésiter au début, et puis finalement la solution que j’ai adopté me satisfait pleinement, c’est encore plus simple et tout aussi efficace, sinon plus. Et les possibilités de Recherche ont l’air assez puissante et fonctionnent parfaitement, pour les quelques tests rapides que j’ai pu faire.

Je suis finalement assez satisfait de passer au client mail proposé de base par Debian Gnome. C’est ce vers quoi je veux aller : profiter pleinement de Gnome, et donc utiliser ce qu’il propose, sauf besoin particulier. Evolution me semble cocher toutes les cases, alors pourquoi s’en priver ?

Passage de Thunderbird à Evolution

Tue, 25 Oct 2022 09:42:39 +0000

C’est la lecture d’une dépêche sur les dernières avancées de Thunderbird sur linux-fr.org qui m’a donné envie de migrer vers Evolution, le client de messagerie (et d’informations personnelles comme l’agenda ou le carnet d’adresses) par défaut de Gnome.

L’article est pourtant positif, pointant les progrès de Thunderbird, que j’avais d’ailleurs pu constater avec la dernière version v102 : amélioration de l’interface, correction de bugs, support de protocoles amélioré permettant de se passer de certaines extensions…

Tout allait pour le mieux, mais une phrase m’a fait tiquer :

Pour des questions de sécurité, IMAP et SMTP ont été réécrits de C vers JavaScript.

Bon, je ne suis pas développeur, mais dire ça, c’est tout de même assez gonflé ! Il est sans doute plus juste de dire que les compétences de développement en C sont plus rares que celles en JS, comme il est suggéré dans l’un des commentaires de la dépêche, que d’invoquer des raisons de sécurité. Mais c’est un commentaire très ironique qui a retenu mon attention, qui “dégomme” pas mal TH, et notamment son utilisation mémoire :

Passer de C à Javascript c’est surtout encore consommer utiliser intelligemment plus de ressource processeur et de mémoire vive. Effectivement, Rust aurait été un meilleur choix risqué. Mais il y a aussi l’option d’auditer le code C et d’écrire une suite de test complète.

Thunderbird fait partie de ces logiciels qui se dégradent lentement mais sûrement avec le temps qui migrent vers les technologies du web 3.0 . Pour gérer mes 4 boîtes emails, il s’accapare n’utilise admirablement qu’ un unique gigaoctet de mémoire vive, a des lenteurs et crashs aléatoires incite son utilisateur a le fermer régulièrement dans un soucis d’optimisation des ressources.

L’équipe de développement a clairement pris le chemin de la réécriture totale en JavaScript, une route sans retour au pays du typage dynamique et autres joyeuseté qu’il est bon de fuir quand on cherche à faire un logiciel performant et fiable des meilleurs logiciels actuels.

Heureusement que l’on a de jolies icônes maintenant, merci la MZLA Technologies Corporation.

En plus de me faire bien rigoler, cela m’a fait prendre conscience d’un certains nombre de choses. Et comme j’avais aussi observé d’autres problèmes avec Thunderbird, cela m’a décidé à me pencher sur Gnome Evolution, le client par défaut sous Debian. Et ça m’a plu, c’est mieux intégré au système que Thunderbird, plus sobre aussi.

Dans cet article, nous allons voir les nouveautés apportées par Thunderbird qui auraient du me satisfaire, puis les raisons qui m’ont finalement décidé à migrer vers Evolution.

Concernant le passage proprement dit et la personnalisation nécessaire, comme la boite de réception unifiée, ou l’archivage des mails, ce sera l’objet d’un prochain article.

Les nouveautés de Thunderbird 102

Et voilà : au moment ou Thunderbird s’améliore, je le quitte ! :roll:

Avec la version 102, les nouveautés sont pourtant sympas : une nouvelle barre d’espaces pour basculer rapidement entre les mails, les contacts, le calendrier, les tâches… et de nouvelles icônes avec de jolies couleurs :

Plus important la gestion complète du protocole CalDAV avec la découverte des calendriers : il suffit désormais de rentrer l’adresse principale du serveur CalDAV et tous les calendriers apparaissent (auparavant, il fallait rentrer l’adresse de chaque calendrier un par un) :

Ou encore un meilleur support du protocole vCard pour les contacts. Celui-là, je l’attendais depuis un bout de temps : les photos des contacts n’étaient pas synchronisées via CarDAV et j’étais obligé d’utiliser deux extensions (“Tbsync” & “Provider for CalDAV & CardDAV”) pour contourner le problème. J’avais même ajouté une entrée à ce bug Sync the contact photo via CarDAV créé il y a deux ans et qui dormait un peu… Le problème a donc enfin été fixé avec la v102 de TH : passage au format vCard pour stocker les contacts (et remplacement d’une lib en C par une autre en JS au passage).

Voilà pour les choses qui me concernaient directement, voir la dépêche citée au début de l’article pour plus d’infos sur les nouveautés.

Les problèmes

La consommation mémoire

Il y a donc ce problème d’utilisation mémoire mentionné dans l’article. Je suis immédiatement allé voir combien de mémoire utilisait Thunderbird sur ma machine. J’étais non pas à 1 Go mais à 600 Mo, ce qui me paraît déjà considérable. J’ai fermé puis ré-ouvert Thunderbird : j’étais revenu à 329 Mo.

J’ai laissé TH tourner, et trois jours plus tard, j’étais déjà passé à 466 Mo :

Il semble bien qu’en laissant Thunderbird ouvert plusieurs jours, la taille mémoire augmente de façon assez considérable.

Certains développeurs disent que c’est normal, que JS a son propre GC (“Garbage Collector”, disons sa corbeille), et que tant qu’il y a de la mémoire libre sur le système, ce n’est pas un problème de l’utiliser. La théorie est la suivante :

Regarder l’utilisation mémoire brute est une mauvaise mesure, puisque JavaScript a aussi son garbage collector et qu’il peut être plus efficace de garder les objets en mémoire plutôt que de constamment la vider.

Bien sûr, si l’environnement mémoire est restreint le Garbage Collector nettoiera plus souvent la mémoire, mais ça implique que le processeur commence a passer plus de temps à faire des choses inutiles pour l’utilisateur.

Bon, je ne suis pas fan de ce genre d’argument. Personnellement, j’appelle ça une fuite mémoire (memory leak) qui normalement doit être corrigée (bug) et c’est souvent très compliqué à traiter pour les développeurs.

Les autres problèmes

Mais il y a d’autres points qui me posaient problème avec Thunderbird :

Le plus gênant était des problèmes d’indexation des dossiers. Cela se traduisait par un affichage du corps du mail (panneau message) qui ne changeait plus alors que je sélectionnais un autre message dans la liste des mails, ce qui était tout de même très gênant, car pouvant amener à la suppression non souhaitée d’un mail. La seule manière de régler ce problème (hormis un redémarrage) était de ré-indexer le dossier :

Il y avait aussi l’obligation d’installer l’extension Thunderbird Conversation pour obtenir un affichage en mode conversation des mails, ce que je trouve assez pratique, mais aussi et surtout pour que la photo des contacts s’affiche dans l’en-tête, ce qui est bien pratique pour visualiser l’expéditeur.
Voilà d’ailleurs le genre de fonctionnalité qui me paraît tout de même assez basique et simple à implémenter dans un client mail. Or ce n’est pas le cas, j’utilisais une autre extension précédemment pour ce faire, puis elle a disparu (elle n’était plus compatible), et maintenant seule l’extension Conversation permet de le faire. Mais cette extension a parfois des soucis à afficher les attachements… :cry:

D’ailleurs, à propos du système d’extensions de TH, elles ont montré leurs limites, devenant régulièrement incompatibles au gré des nouvelles versions, ce qui est finalement assez lassant. Et on peut comprendre les développeurs bénévoles qui doivent soudainement tout réécrire parce que Mozilla a brusquement décidé de changer les règles.

En conclusion, Thunderbird me fait tout de même l’effet d’être une belle usine à gaz, évoluant difficilement, longue à adopter les standards, et au développement incertain (abandonné par la Mozilla Corporation, repris par la Mozilla Foundation…). Quand je lis cet article, ça ne me rassure pas plus que ça :

The long term plan is to migrate our code to web technologies, but this will take time, staff, and planning. We are looking for highly skilled volunteer developers who can help us with this endeavor, to make sure the world continues to have a high-performance open-source secure email client it can rely upon.

Il y a aussi le fait que K-9 Mail rejoigne la famille Thunderbird pour un futur “Thunderbird Android” : pas sûr que les utilisateurs de K-9 soient très gagnants dans l’histoire…

Gnome Evolution

Donc voilà, je me suis tourné vers Evolution pour voir ce que cela vaut aujourd’hui. On peut le comparer à MS Outlook en terme de fonctionnalités. Il est très complet, gère les mails, l’agenda, les contacts, les tâches et les mémos.

Petit retour en arrière, je faisais le chemin inverse en 2010, comme je le décris dans cet article (c’est pratique un blog, pour se rappeler de certaines choses). Mais c’est dommage, je n’en explique pas vraiment les raisons : " pris d’une inspiration subite, je migre d’Evolution à Thunderbird" parce que " Evolution ne me satisfait pas complètement". J’aurais du un peu plus argumenter les raisons de cette migration. Peut-être le manque de “customisation” d’Evolution, comparé aux nombreuses extensions disponibles avec Thunderbird ? Aujourd’hui, ce serait presque l’inverse qui me fait revenir vers Evolution. Et comme l’intégration à l’environnement de bureau me paraît être un élément de poids dans le choix du client de messagerie, il y a une certaine logique à ce changement : Thunderbird est le client mail par défaut d’Ubuntu mais je suis désormais sous Debian Gnome ! :wink:

La première impression, c’est une interface propre, complète et sobre, ce qui n’est pas pour me déplaire. Comme pour tout l’environnement Gnome, il n’y a pas une multitude d’options pour tout modifier/personnaliser, mais ce qu’il y a fonctionne.

Je crée rapidement les comptes mails, les calendriers, les contacts. Tout se fait très rapidement, grâce aux protocoles IMAP pour les comptes mail, CardDAV pour les contacts, et CalDAV pour les calendriers (ces deux derniers étant synchronisés via mon serveur Baïkal).

Il reste maintenant un peu de travail à faire, comme de créer une boite de réception unifiée pour tous les comptes qui n’existe pas par défaut sur Evolution. Ou encore de s’organiser pour archiver les mails localement, y compris la récupération des archives des années précédentes à partir de Thunderbird.

Ce sera l’objet du prochain article. :cool:

Installation Debian sur le nouveau PC

Tue, 13 Sep 2022 16:43:15 +0000

Suite à l’achat du nouveau PC, j’ai bien sûr du réinstaller tout le système. Voilà près de 8 mois que je suis passé d’Ubuntu à Debian, et je ne regrette pas une seconde ce choix. J’ai pourtant choisi la version “unstable” pour bénéficier des dernières versions de logiciel (Gnome particulièrement), et franchement, ce n’est que du bonheur ! :cool:

Bref, me voilà avec ce nouveau PC, et tout le système à réinstaller. Je décide de repartir d’un système propre, et comme je peux avoir les deux machines démarrées en même temps, d’utiliser Filezilla pour une copie via le réseau de différents dossiers de fichiers perso. J’en profite d’ailleurs pour réorganiser mes dossiers un peu mieux. disons de manière plus rationnelle.

Concernant mon ancien répertoire home, je vais tout simplement le recopier dans un répertoire /home/pascal-SH87R6 afin d’avoir à ma disposition tout fichier dont je pourrais avoir besoin pour “reconstruire” mon nouvel environnement (comme les fichiers playlists de Rhythmbox par exemple).

Voyons voir tout cela, après un début difficile du au BIOS de ma nouvelle carte-mère, tout s’est déroulé sans problème, j’ai juste noté quelques spécificités rencontrées sur certains logiciels…

Installation

Pour installer Debian 12, je suis parti de l’image qui inclut les pilotes non-free, ayant déjà expérimenté quelques soucis si l’on utilise le CD officiel. C’est un vieux débat chez Debian : faut-il proposer par défaut un système ne comprenant que du logiciel libre ? C’est toujours le cas aujourd’hui, même si cela risque de changer, un débat (avec vote) ayant été ouvert récemment sur le sujet.

J’ai donc téléchargé l’image CD nommée firmware-testing-amd64-netinst.iso que l’on trouve sur cette page. Cela permettra au firmware non libre de la carte mère d’être installé automatiquement, ce qui est tout de même beaucoup plus simple pour l’utilisateur lambda.

Pas grand chose à signaler lors de l’installation, tout se passe sans anicroche. Je remarque juste qu’en laissant l’installeur me proposer le partitionnement, la partition de swap est de 1GB ! Comme j’ai 32 GB de mémoire vive, ceci explique sans doute cela. Je laisse tel quel, ils doivent savoir ce qu’ils font ! Je crée par contre une partition séparée pour /home, c’est tout de même plus simple à gérer.

Voilà ce que donnera mon disque SSD une fois tout installé (applications comprises) :

C’est au redémarrage que les problèmes vont apparaître.

Boot Debian

Au premier reboot, après le menu GRUB, j’obtiens un écran noir, le dernier message étant :

fb0: switching to amdgpu from EFI VGA

Si je comprends bien le problème est quand le système passe sur le cœur graphique intégré au processeur AMD, et sans doute lié au mode EFI.

J’essaie de supprimer le secure boot dans le BIOS ASUS, mais même ça, je ne m’en sors pas, les options dans le BIOS ne sont pas claires : je vais dans Advanced - Boot\Secure Boot, et dans « OS Type » on peut choisir « Windows UEFI mode » ou « Other OS », mais dans les deux cas le « Secure Boot State » semble rester actif (« User ») et le Platform Key (PK) State est à « Loaded ». Ces deux dernières entrées étant grisées et non modifiables…

Je réussis tout de même à démarrer en ajoutant nomodeset à GRUB au démarrage (ce qui permet de ne pas charger les pilotes graphiques avant que X ou Wayland soit chargé), mais évidemment la résolution de l’écran est plutôt basique.

J’ai fini par trouver cette FAQ Asus qui indique comment faire pour désactiver le Secure Boot (il suffit de choisir « Autre OS » dans le type de système d’exploitation). Par contre, le problème est toujours présent… Je vérifie que le paquet firmware-amd-graphics est bien installé, c’est bien le cas :

$ sudo apt policy firmware-amd-graphics
firmware-amd-graphics:
  Installé : 20210818-1
  Candidat : 20210818-1
 Table de version :
 *** 20210818-1 500
        500 http://deb.debian.org/debian bookworm/non-free amd64 Packages
        100 /var/lib/dpkg/status

Je regarde les logs du dernier démarrage sans avoir activé nomodeset , donc quand j’ai l’écran noir : sudo journalctl -b -1 (soit l’avant-dernier boot) : je ne vois rien de spécial après le message “switching to amdgpu”… J’en reste là pour cette première journée.

La nuit portant conseil, je fais un essai le matin suivant : j’avais branché mon moniteur sur la sortie HDMI de la carte mère (elle a 3 sorties video : D-Sub, DVI-D et HDMI, une de raisons pour laquelle j’ai choisi cette carte). J’ajoute mon deuxième écran sur la sortie DVI-D (ou D-Sub d’ailleurs), et là, dès que le message « Switching to amdgpu… » apparaît, l’affichage bascule sur ce nouvel écran. :idea: ! Mais l’écran sur la sortie HDMI reste désespérément noir.

Donc je résume : avec un seul écran sur la sortie HDMI, j’ai pu faire l’installation, rentrer dans le BIOS, etc… Mais démarrage de Debian, il me faut un écran sur l’une des sorties D-sub ou DVI-D. Et je n’ai pas de câble pour tester l’utilisation de ces 2 dernières sorties en même temps.

Et donc retour dans le BIOS pour activer le mode multi-monitor. Je trouve cette FAQ, et vais activer cette option « IGFX Multi-Monitor » qui ne l’était pas par défaut :

Et cette fois cela fonctionne ! Il me faut toutefois faire un arrêt/redémarrage après avoir activé l’option dans le BIOS, et je retrouve enfin mes deux écrans, sur les deux sorties DVI-D et HDMI comme souhaité. :cool: Et je suis enfin en session Wayland, ce que je ne pouvais pas faire avec mon ancien PC et sa carte nVidia.

Mise à jour Firmware

Avant d’acheter le PC, je m’étais renseigné sur LVFS ( L inux V endor F irmware S ervice) mais je n’avais pas trouvé grand chose concerannt les fabriquants de carte mère (seulement les grandes marques genre HP, Lenovo, DELL, etc…), j’avais donc abandonné ce pré-requis qui m’aurait bien plu. Mais j’avais du mal chercher, car Asus fait bien partie des fabriquants de hardware qui publient sur ce portail les mises à jour de leurs produits, typiquement leurs carte-mères.

Et voilà, je peux désormais faire la mise à jour du firmware (BIOS et UEFI) depuis Gnome, qui intègre le dameon fwupd (qui pointe sur le portail de LVFS).

Voilà les commandes essentielles à connaître :

# si le programme n'est pas installé :
$ sudp apt install fwupd
# pour afficher les périph. détectés :
$ sudo fwupdmgr get-devices
# pour télécharger les dernières métadonnées :
$ sudo fwupdmgr refresh
# pour savoir si des màj sont nécessaires :
$ sudo fwupfmgr get-updates
# pour mettre à jour
$ sudo fwupdmgr update

Mon système est bien détecté, et est à jour :

$ sudo fwupdmgr get-updates
Devices with no available firmware updates:
 • System Firmware
Devices with the latest available firmware version:
 • UEFI dbx

Il y a un dameon qui tourne ( sudo systemctl status fwupd pour le voir), et si j’ai bien compris il va télécharger automatiquement les mises à jour s’il y en a. Ensuite, une fenêtre popup s’affichera pour vous informer de cette possibilité de mise à jour. Franchement, c’est top ! :cool:

Installation des programmes

Je ne reviens pas sur la configuration/personnalisation du système (sudo, extensions gnome, imprimante…), je l’ai déjà décrite ici. J’ai toutefois remplacé l’extension Dash to Dock (qui ne fonctionne toujours pas sous Gnome 42 sauf à compiler localement une version non officielle) par Dock from Dash, une version plus simple basée sur le Dash d’origine de Gnome. Et ça fonctionne très bien.

La suite se déroule sans problème particulier pour la plupart des logiciels. Je fais bien attention à installer des .deb car moins j’aurai de flatpak ou d’ Appimage, mieux je me porterai !

Voilà les quelques applications non disponibles que j’ai noté :

gufw (l’interface graphique pour ufw) n’est plus disponible . Ce qui m’amènera à passer à netfilter pour le pare-feu, voir cet article.
handbrake (transcoder vidéo) est proposé en flatpak, mais je le trouve en .deb sur debian.pkgs.org et il s’installe sans problème (et à la dernière version). Même chose pour handbrake-cli (version ligne de commande).
xsane, une interface pour le scanner, idem : xsane_0.999-12_amd64.deb trouvé sur debian.pkgs.org, mais penser à récupérer aussi xsane-common_0.999-12_all.deb et à l’installer en premier !

Voilà la liste des applications au format Appimage :

Cozy-Drive (un cloud bien pratique pour les services de l’État mais pas que).
Deemix (tél. Deezer en 128 kbps)
Gourmand (logiciel de recettes de cuisine, le format Appimage s’intègrant mieux au desktop que le format flatpak je trouve).

Et enfin la liste des applications au format flatpak :

Signal (messagerie, pour la famille). Il est possible d’installer un .deb mais en ajoutant un dépôt (voir ici) ; J’ai fini par le faire pour virer le format flatpak.

Tout le reste est donc au format .deb ! :cool:

Console

Je profite d’être sous Gnome 42 pour utiliser le nouveau terminal, appelé Console. Même s’il est toujours en cours de développement, et présenté comme “a minimal terminal for Gnome”, destiné aux utilisateurs de base, sans pour autant remplacer le gnome-terminal utilisé par les administrateurs avancés et autres développeurs…

S’il n’est pas installé, un simple sudo apt install kgx fera l’affaire.

Franchement, il est pas mal, et j’aime particulièrement son changement de couleurs selon que l’on soit en train d’effectuer une tâche en tant que root (on passe en rouge) ou connecté en ssh (on passe en violet). C’est simple et efficace :

TextEditor

Dans le même genre, il y a un nouvel éditeur de texte, au look adapté à Gnome 42, y compris le changement de style (sombre ou par défaut). Sympa !

Mais ce n’est la seule nouveauté, fort heureusement. Il est développé pour garder les traces de changements apportés à vos fichiers en cas de fermeture malencontreuse de l’application. Et ça, cela peut être bien pratique !

Conclusion

Après une belle frayeur au premier redémarrage (un écran noir, ce n’est jamais cool !), je n’ai pas rencontré de problème particulier. Le nouveau PC est une belle bête de course, fini les problèmes avec nVidia et Xorg, le boitier est hyper silencieux, bref je suis très content de mon achat.

Comme je suis très content de Debian ! Avec la version “testing” (ou “sid”, nom de code “bookworm” pour cette v12), je bénéficie des dernières versions sans rencontrer de problèmes de stabilité. Ainsi je suis en Gnome 42 et commence déjà à voir certaines applications passer en Gnome 43. C’est plutôt sympa !

Le seul souci que j’ai pu observer est un problème de dépendances m’empêchant de faire les mise à jour ( sudo apt upgrade échoue). La solution est alors de faire un sudo apt update suivi d’un sudo apt dist-upgrade au lieu d’un simple sudo apt upgrade.

L’occasion de faire un petit rappel :

apt update met à jour le cache local des paquets et indique ainsi à votre système les paquets qui peuvent être mis à niveau. C’est pourquoi on commence toujours par celle-ci.
apt upgrade permet de mettre à niveau les paquets installés sur le système. Mais il ne peut pas installer un nouveau paquet ou supprimer un paquet déjà installé sur le système.
dist-upgrade permet de mettre à niveau les paquets installés sur le système. Mais en revanche, il peut installer de nouveaux paquets ou supprimer des paquets existants si nécessaire.

Avec le toutefois le risque non négligeable de voir une application désinstallée… Ça m’est arrivé par exemple avec “DB Browser for SQL” ou encore Digikam par exemple. Comme ce sont des applis que je n’utilise pas fréquemment, je m’en suis rendu compte lorsque j’ai voulu les lancer ! :roll:

Conclusion : en cas de dist-upgrade, bien lire les messages affichés par la commande afin de vérifier ce qui est fait sur le système.

KDE Connect : La connexion a échoué

Fri, 02 Sep 2022 14:28:04 +0000

Pour connecter le smartphone au PC, j’utilise le très pratique KDE Connect, avec l’extension Gnome GSConnect.

J’apprécie particulièrement que la musique du PC se mette en pause lors d’un appel (entrant ou sortant). J’utilise aussi la possibilité de copier des fichiers sur le smartphone sans avoir besoin d’utiliser un câble USB, et enfin quelques fois pour les SMS, bien que la synchronisation si on a un long historique ne fonctionne pas toujours très bien. Voilà pour l’essentiel de mon usage.

C’est le deuxième point qui me posait problème, le menu “Monter” ne faisant pas apparaître le smartphone dans Nautilus :

Voyons voir comment analyser ce qui se passe… et résoudre le problème ! :cool:

Heureusement, l’extension GSConnect permet de voir facilement les logs :

En choisissant l’option “Générer les logs pour le support”, une boite s’ouvre vous demandant de faire le nécessaire pour reproduire l’erreur, puis un bouton “Vérifier les logs” vous permet de les visualiser immédiatement. Dans mon cas, cela donnait ceci :

Bon, le message est clair : “La connexion a échoué”… mais cela n’aide pas vraiment !! On voit tout de même l’adresse IP du smartphone (192.168.1.138), le numéro de port, le nom d’utilisateur utilisé, le nom du dossier partagé, et le protocole sftp.

Il faut ici comprendre que la connexion se fait à partir du PC vers le smartphone, qui pointe sur un répertoire qui doit être définit auparavant dans KDE Connect :

On peut dès lors simuler la connexion dans un terminal :

$ sftp -P 1740 kdeconnect@192.168.1.138
Unable to negotiate with 192.168.1.138 port 1740: no matching host key type found.
Their offer: ssh-rsa
Connection closed.
Connection closed

On y voit déjà plus clair : il s’agit d’un problème de clefs ssh, et la négociation échoue (en sftp, la connexion est chiffrée).

Après quelques recherches sur le net, le problème a été remonté ici. Ce n’est pas un bug de GSConnect, mais plutôt un problème côté Android qui utilise une version de chiffrement ssh-rsa qui n’est plus utilisée (deprecated) car jugée non sécurisée. Voir ici pour plus d’infos.

Heureusement, il est très facile de corriger le problème en autorisant cette méthode pour cet appareil : le “trou” de sécurité sur mon LAN est à mon avis minime et négligeable ! :wink:

Le plus simple est de créer un fichier config dans ~/.ssh et d’y mettre le contenu suivant :

$ cat ~/.ssh/config
Host 192.168.1.138
  HostKeyAlgorithms +ssh-rsa

Et voilà, le problème est réglé, le smartphone apparaît désormais dans Nautilus comme il se doit en faisant “Monter” :

Conclusion

Le problème était donc côté smartphone. J’utilise LineageOS for microG 18.1, dûment mis à jour tous les mois.

On peut donc dire que sur LineageOs, le système d’échange de clefs ssh utilise toujours ssh-rsa (qui utilise la fonction de hachage SHA-1) pour le chiffrement de la connexion. Mais côté PC (Debian 12 “bookworm”), avec une version openssh 9.0, cet algorithme n’est plus utilisé. Voilà d’ailleurs la notice d’information publiée à l’époque (pour openssh 8.2, en avril 2020) :

Future deprecation notice

It is now possible to perform chosen-prefix attacks against the SHA-1 hash algorithm for less than USD$50K. For this reason, we will be disabling the ssh-rsa public key signature algorithm that depends on SHA-1 by default in a near-future release.

This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.

Bon, faut quand même avoir 50 000 $ pour s’offrir le moyen d’attaquer le système ! :cool:

Pare-feu : iptables ou netfilter ?

Sun, 28 Aug 2022 16:05:40 +0000

Après avoir lu sur un forum qu’il devenait assez compliqué d’avoir à la fois iptables et nftables d’installés sur le système pour la gestion du pare-feu, je me suis penché sur le sujet (auquel je ne connaissais rien) et décidé d’utiliser netfilter en lieu et place de ce bon vieux iptables, puisque c’est le futur (et même le présent !).

Ça n’a pas été aussi simple que prévu, puisque après avoir enlevé iptables, je me suis retrouvé avec un problème avec mes machines virtuelles, leur interface réseau virtuelle ne démarrant plus (dépendance de libvirt sur iptables).

Mais par contre j’ai appris plein de choses sur le pare-feu, et c’était aussi le but recherché, à savoir de comprendre un peu mieux comment tout ça fonctionne sur Debian. Mes règles sont désormais directement créées dans nftables, excepté celles de libvirt. Et je me suis débarrassé de ufw.

Voyons voir un peu tout ça dans le détail, en commençant par expliquer de quoi il retourne, comment je suis passé de iptables à nftables, puis le problème avec libvirt que ça a déclenché, et enfin la solution, qui je le dis tout de suite consiste à conserver iptables, puisque libvirt en a besoin (et ça risque de durer !). Ceci n’empêchant pas d’utiliser nftables pour le reste, c’est déjà ça.

Les bases

Je ne suis pas pour autant devenu un spécialiste des pare-feu, que les choses soient claires. Mais je vais vous expliquer ce que j’ai compris sur le sujet. Si cela paraît un peu confus au départ, tout s’éclaire en mettant en pratique et en créant nos règles. Mais il faut assimiler deux ou trois choses avant de commencer.

Pour une explication plus complète, vous pouvez suivre ce cours en ligne qui explique bien (et en français) tout le fonctionnement et la mise en place. Ce ne sont pas les tutos en anglais qui manquent, comme celui-ci, ou encore celui-là, toutefois aucun n’indique comment sauvegarder les règles créées et les retrouver après un redémarrage, ce qui est assez surprenant… :shock: Peut-être ai-je loupé quelque chose ? Toujours est-il que j’indique ici comment j’ai fait, au moins ça marche !

NetFilter

Le pare-feu dans Linux, c’est NetFilter. Il est intégré au noyau, et comporte des hooks (crochets) qui permettent d’intercepter tout ce qui entre et qui sort du système (je laisse passer, je bloque, etc…). Il existe 5 types de hooks : input, output, forward, prerouting, postrouting (les deux derniers n’existant que sur les routeurs).

Que ce soit iptables ou nftables, les deux permettent de communiquer avec NetFilter. Mais aujourd’hui, iptables est délaissé pour des raisons de performance, de sécurité, etc… Une réécriture du code s’imposait. Ainsi, Debian est fourni avec nftables depuis Debian 10 (aka “Buster”), sorti en 2019. Mais le paquet iptables est toujours installé par défaut ! :roll:

ufw & iptables

Auparavant, j’utilisais ufw (Uncomplicated FireWall), qui servait d’interface pour iptables. Quand on installe ufw, iptables est automatiquement installé (si ce n’est pas déjà le cas sur le système). En d’autres termes, ufw dépend de iptables :

$ sudo apt show ufw
Package: ufw
Version: 0.36.1-4
Priority: optional
Section: admin
Maintainer: Jamie Strandboge
Installed-Size: 861 kB
Depends: iptables, lsb-base (>= 3.0-6), ucf, python3:any, debconf (>= 0.5) | debconf-2.0
Suggests: rsyslog

Et voilà ce que je faisais précédemment sur mon PC pour déclarer les quelques règles dont j’avais besoin :

$ sudo apt install ufw
$ sudo ufw enable
$ sudo ufw status verbose
$ sudo ufw allow 873 comment 'rsync'
$ sudo ufw allow 22 comment 'ssh'
$ sudo ufw allow 137,138/udp comment 'samba'
$ sudo ufw allow 139,445/tcp comment 'samba'
$ sudo ufw allow 1714:1764/udp comment 'KDE Connect'
$ sudo ufw allow 1714:1764/tcp comment 'KDE Connect'

On pourrait donc croire que l’on crée des règles iptables à l’aide d’ ufw. Mais /usr/sbin/iptables est désormais un lien symbolique qui pointe sur iptables-nft qui utilise l’API de nftables pour insérer toutes les règles dans des tables nft spéciales appelée “filter” et “nat”.

Cela permet de voir les règles iptables comme des règles nftables sur une commande comme sudo nft list ruleset.

Et donc les commandes ci-dessus que je rentrais étaient en fait “traduites” pour être vues comme des règles nft ! On peut le vérifier facilement et tapant la commande sudo nft list table ip filter |grep ufw- : on voit alors tout un tas de chaînes intitulées “ufw-before…”, “ufw-after…” , etc…

D’où l’idée de tout simplifier en utilisant directement nftables !

nftables

nftables est donc le nouvel intermédiaire qui permet de communiquer avec NetFilter. Il a été conçu avec l’idée de corriger les problèmes d’ iptables.

On crée d’abord une table, qui n’est au final qu’un conteneur pour s’organiser. Il n’y a pas de table prédéfinie, mais il existe des familles de tables : IP, ARP, IP6, INET (qui regroupe ipv4 et ipv6), et enfin BRIDGE.

Chaque table va contenir des chaînes qui elles vont stocker les règles proprement dites. Il n’existe pas de chaînes prédéfinies, mais elles doivent se rattacher aux hooks (crochets).

Les règles définissent les actions à appliquer. Elles se composent d’un filtre suivi d’une action. C’est assez simple à comprendre.

Mise en place

Je vais maintenant créer les règles dont j’ai besoin. Elles sont très basiques et consistent à ouvrir quelques ports pour mes services, à savoir ssh, rsync, samba et KDE Connect (ce dernier est pour mon smartphone).

Je commence donc par créer ma propre table appelée “pc-filtre” (désolé, je n’ai pas trouvé mieux ! :wink: ). Je choisis d’utiliser la famille inet, qui a l’avantage de regrouper ipv4 et ipv6 :

$ sudo nft add table inet pc-filtre

Puis je crée deux chaînes, pour séparer l’entrée et la sortie. On précise bien à quel hook on veut se rattacher, notre chaîne “ipnut” va donc se rattacher au hook “INPUT”.

La notion de priorité permet de gérer les cas où l’on a plusieurs chaînes, la priorité la plus basse prend alors le pas sur les autres ; mais dans mon cas, je ne vais utiliser cette possibilité de réglage plus fin, je crée juste deux chaînes basiques :

$ sudo nft add chain inet pc-filtre input { type filter hook input priority 0 \;}
$ sudo nft add chain inet pc-filtre output { type filter hook output priority 0 \;}

Et enfin je crée mes règles dans la chaîne “input” :

$ sudo nft add rule inet pc-filtre input tcp dport 22 accept
$ sudo nft add rule inet pc-filtre input tcp dport 139 accept
$ sudo nft add rule inet pc-filtre input tcp dport 445 accept
$ sudo nft add rule inet pc-filtre input udp dport 137 accept
$ sudo nft add rule inet pc-filtre input udp dport 138 accept
$ sudo nft add rule inet pc-filtre input tcp dport 873 accept
$ sudo nft add rule inet pc-filtre input udp dport 873 accept
$ sudo nft add rule inet pc-filtre input tcp dport 1714-1764 accept
$ sudo nft add rule inet pc-filtre input udp dport 1714-1764 accept

Et je vérifie :

$ sudo nft list table inet pc-filtre
table inet pc-filtre {
	chain input {
		type filter hook input priority filter; policy accept;
		tcp dport 22 accept
		tcp dport 139 accept
		tcp dport 445 accept
		udp dport 137 accept
		udp dport 138 accept
		tcp dport 873 accept
		udp dport 873 accept
		tcp dport 1714-1764 accept
		udp dport 1714-1764 accept
	}

	chain output {
		type filter hook input priority filter; policy accept;
	}
}

Terminé ? pas vraiment, il va falloir faire en sorte que cette table soit chargée au démarrage, parce que à ce stade, si vous redémarrez le PC, tout est perdu ! Le plus bizarre c’est que je n’ai rien trouvé à ce sujet dans les différents tutoriaux, comme si les commandes tapées étaient automatiquement conservées… Sauf qu’après un redémarrage, j’avais tout perdu. Donc, bon, voilà au cas où vous observez le même comportement :

Le plus simple est de créer un fichier contenant vos règles :

$ sudo nft list ruleset > ~/nftables-pc-filter.conf

Ensuite éditer ce fichier pour y ajouter une première ligne indiquant qu’il s’agit d’un fichier pour nft, ce qui me donne au final :

$ cat ~/nftables-pc-filter.conf
#!/usr/sbin/nft -f

table inet pc-filtre {
	chain input {
		type filter hook input priority filter; policy accept;
		tcp dport 22 accept
		tcp dport 139 accept
		tcp dport 445 accept
		udp dport 137 accept
		udp dport 138 accept
		tcp dport 873 accept
		tcp dport 1714-1764 accept
		udp dport 1714-1764 accept
		udp dport 873 accept
	}

	chain output {
		type filter hook input priority filter; policy accept;
	}
}

Puis je copie ce fichier dans /etc, et j’édite le fichier de configuration par défaut de nftables, soit /etc/nftables.conf, et d’y ajouter un “include” de mon fichier :

$ cat /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
	chain input {
		type filter hook input priority filter;
	}
	chain forward {
		type filter hook forward priority filter;
	}
	chain output {
		type filter hook output priority filter;
	}
}

include "/etc/nftables-pc-filter.conf"

Et voilà, cette fois,je peux redémarrer, toutes mes règles seront chargées à chaque démarrage.

Importer les règles de iptables

Si vous avez beaucoup de règles existantes, il est possible de faire une migration :

$ iptables-save > save.txt
$ iptables-restore-translate -f save.txt > ruleset.nft

Il ne reste plus qu’à inclure votre ruleset.nft au démarrage de nftables. Voir cette page pour plus d’infos.

Problème rencontré

Une fois ceci fait, j’ai supprimé les deux paquets ufw et iptables, puis j’ai passé le service nftables à “enable” :

$ sudo apt remove ufw iptables
$ sudo systemctl status nftables
● nftables.service - nftables
     Loaded: loaded (/lib/systemd/system/nftables.service; enabled; preset: enabled)
     Active: active (exited) since Fri 2022-08-12 18:10:54 CEST; 16h ago
       Docs: man:nft(8)
             http://wiki.nftables.org
   Main PID: 716 (code=exited, status=0/SUCCESS)
        CPU: 6ms

J’avais une VM de démarrée à ce moment-là, la fenêtre a brutalement disparue ! Et dans la fenêtre du gestionnaire de machines virtuelles ( virt-manager), ma liste de VMs avait disparue aussi ! :shock:

J’ai désinstallé/réinstallé l’ensemble des paquets nécessaires pour KVM/QEMU, et j’ai tout de suite retrouvé la liste de mes VMs. Mais au lancement, message d’erreur :

J’avais déjà vu ce message, il concerne le réseau virtuel créé par libvirt pour gérer l’interface réseau (en NAT) des VMS. Libvirt est l’API de virtualisation utilisée par KVM.

Hélas, impossible de démarrer ce fameux réseau, et le message est assez clair : il ne trouve pas iptables, et pour cause, puisque je viens de le désinstaller !

$ sudo virsh net-list --all
 Nom       État      Démarrage automatique   Persistent
---------------------------------------------------------
 default   inactif   Oui                     Oui

$ sudo virsh net-autostart default
Réseau default marqué en démarrage automatique

$ sudo virsh net-start default
erreur :Impossible de démarrer le réseau default
erreur :internal error: Failed to apply firewall rules /usr/sbin/iptables -w --table filter --list-rules: libvirt:  erreur : cannot execute binary /usr/sbin/iptables: Aucun fichier ou dossier de ce type

À ce stade, il apparaît que libvirt a une dépendance sur iptables. Sur Debian, elle se trouve dans le paquet libvirt-daemon-system :

$ sudo apt show libvirt-daemon-system
Package: libvirt-daemon-system
Version: 8.5.0-1
Priority: optional
Section: admin
Source: libvirt
Maintainer: Debian Libvirt Maintainers
Installed-Size: 460 kB
Depends: adduser, gettext-base, iptables | firewalld, libvirt-clients (= 8.5.0-1), libvirt-daemon (= 8.5.0-1), libvirt-daemon-config-network (= 8.5.0-1), libvirt-daemon-config-nwfilter (= 8.5.0-1), libvirt-daemon-system-systemd (= 8.5.0-1) | libvirt-daemon-system-sysv (= 8.5.0-1), logrotate, policykit-1, debconf (>= 0.5) | debconf-2.0

Pour être plus précis, la lib dépend soit de iptables, soit de firewalld :

iptables | firewalld

OK, firewalld est un “wrapper” censé faciliter la gestion du pare-feu et l’écriture des règles nftables. De ce que j’ai pu lire, il est assez compliqué et peu adapté à la gestion de quelques règles simples comme c’est le cas sur un poste de travail.

Mais, bon, je fais le test par acquis de conscience : firewalld était bien installé sur mon système, mais le service non démarré. Je l’autorise ( sudo systemctl enable firewalld.service), puis redémarre le système. Mais le même message d’erreur est toujours là au démarrage du réseau virtuel : libvirt réclame iptables.

Conclusion

Il y a bien une dépendance de libvirt à iptables, et ce n’est pas normal que je puisse désinstaller le paquet iptables sans être averti de celle-ci. J’ai donc fini par le réinstaller, tout en gardant mon nouveau fichier de règles nftables.

On peut d’ailleurs très bien continuer à gérer son pare-feu avec iptables, puisque les règles sont traduites automatiquement. Peut-être que sur des serveurs aux règles complexes, c’est effectivement plus sain de migrer vers une solution purement nftables.

J’ai d’abord posté un sujet sur le forum debian-fr.org, où j’ai reçu de l’aide même c’était parfois un peu tendu (!). Mais cela m’a pas mal éclairé et amené dans la bonne direction. En l’absence de solutions, j’ai fini par envoyer un mail au support utilisateur de libvirt (chez red-hat), et le lendemain j’avais une longue réponse très détaillée sur le sujet (génial !). D’après cette personne, si Debian te laisse désinstaller iptables, il y a un problème car libvirt a bien une dépendance, et ne peut fonctionner directement avec nftables.

J’ai alors posté sur le forum Debian Users pour signaler le problème : il y a eu des commentaires, mais pas sûr que le problème soit réglé pour l’instant. Apparemment, certains attendent que libvirt soit corrigé (cela devrait fonctionner avec iptables-nft, voir plus haut), quand d’autres émettent l’hypothèse que le patch devrait être fait côté Debian… La situation est plus proche d’un status-quo qu’autre chose semble-t-il.

Voilà, tout cela a été très formateur, j’ai appris plein de choses, comme toujours, et même si iptables est toujours installé sur mon système, les règles sont désormais directement créées à la mode nftables ! :cool:

Mon nouveau PC : système AMD

Sat, 06 Aug 2022 16:36:03 +0000

Voilà, j’ai fini par m’offrir un nouveau PC, idée qui me trottait dans la tête depuis quelque temps, et pour des raisons absolument pas primordiales… mais à force de regarder les belles configs disponibles, on finit vite par craquer !

Mon brave Shuttle SH87R6 (qui datait de 2014) se défendait pourtant encore bien, mais la carte graphique Nvidia que j’avais rajoutée ne faisait pas bon ménage avec Linux (j’y reviendrai) et cela me contrariait. :mad:

Alors me voilà l’heureux possesseur d’un PC à base de processeur AMD Ryzen 7 qui intègre un cœur graphique Radeon, bye bye Nvidia ! Voilà les “specs” principales :

PC Ryzen7-5700GProcesseurAMD Ryzen 7 5700G, 8x 3.80GHzCarte mèreAsus Prime B550M-AGraphiqueAMD Radeon GraphicsMémoireDDR4-3200 32 GB PC4-25600USSDSSD M.2 SATA 512 GBDisque dur2xHD 2000 GB Seagate BarraCuda, SATA 6Gb/sBoitierBe Quiet! Pure Base 600 Black

Voyons un peu plus en détail les raisons de ce changement, et les performances de cette nouvelles machine.

Pourquoi changer le PC

Le Shuttle était une belle machine à l’époque, avec un processeur Core i7 et fonctionnait encore très bien. Un peu plus tard j’y avais ajouté une carte graphique 3D (pour jouer à SuperTuxKart !) et choisi une Nvidia GeForce GTX 1050 Ti.

Sauf qu’en passant à Debian, je me suis rendu compte de plusieurs choses :

Je devais me passer de Wayland, le nouveau serveur d’affichage qui remplace X11, car Nvidia ne jouant pas le jeu de l’open source avec ses pilotes, le portage s’avère délicat. Ce n’est plus vraiment le cas avec les toutes dernières cartes Nvidia, mais pour la mienne, c’était quasiment mort : il aurait fallu tenter l’installation du binaire linux fourni par Nvidia (au lieu de celui disponible dans les dépôts Debian), et je ne voulais pas de ça (à mon avis la porte d’entrée à beaucoup de problèmes potentiels, genre écran noir !).
Pas grave me direz-vous, il suffit de revenir à X11. Sauf qu’avec ma configuration double-écran (le deuxième étant sur le chip Intel intégré à la carte-mère, mon process Xorg me prenait en permanence de l’ordre de 28% de CPU… qui n’avait pas besoin de ça !

Car d’autre part, lors de conversions de vidéos (ce qui m’arrive de temps en temps), je voyais que le processeur commençait à montrer ses limites. Et j’entendais le ventilateur tourner à fond dès que j’utilisais un peu ses ressources… Idem pour mes 8Go de RAM lorsque j’utilisais des machines virtuelles, l’ensemble devenait un peu juste et commençait à “ramer” sérieusement.

Bref, il était temps de faire un saut de 8 ans et de s’offrir ce que l’on fait de bien aujourd’hui.

Le choix AMD

Le premier critère était donc la carte graphique. Une fois Nvidia d’écarté, il reste AMD (Radeon) et Intel. Quand j’ai vu que certains modèles de la gamme AMD Ryzen intégraient un cœur graphique Radeon, ça m’a tout de suite plu : je n’ai pas besoin d’une carte GPU dédiée pour l’usage que je fais de mon PC.

J’en suis vite venu au processeurs AMD de la gamme Ryzen, qui intègrent un cœur Radeon. Et le modèle AMD Ryzen 7 5700G (le “G” indique le cœur graphique intégré) avait l’air d’être bien noté par la rue-montgallet (ça m’a rappelé des souvenirs, quand j’allais dans le 12e acheter mes composants PC il y a bien longtemps : j’avais même construit mon premier PC avec un processeur Cyrix !).

Mais revenons au processeur, et comparons sa puissance avec mon Core i7 de 2014 sur le site cpubenchmark (je passe de 4 à 8 cœurs et de 8 à 16 threads) :

Le choix de matériel et le site

Une fois à peu près décidé sur le processeur, reste à choisir la configuration. J’ai commencé par aller sur des sites comme LDLC pour me construire une configuration, mais j’ai vite été coincé par leur configurateur que j’ai trouvé plutôt mal foutu, car très permissif et laissant la porte ouverte à des choix incompatibles. En plus, le hardware, je ne suis plus cela depuis longtemps, donc j’étais un peu largué ! :neutral:

C’est sur reddit (le mercredi, il y a un sujet mercredi tech que je lis parfois) que quelqu’un mentionnait le site MEMORY:PC, un site allemand, que je suis allé voir. Et malgré une traduction en français plutôt incomplète, j’ai vite été séduit : d’abord, il proposait une série de configurations “Systèmes AMD”, dont l’une avec mon processeur Ryzen 7 5700G. Ensuite, leur configurateur est très bien conçu, et ne propose que le matériel compatible. Enfin, et ce n’est pas le moins important, le prix est tout à fait attractif.

Leur configuration de base pour le Ryzen 7 5700G est à 619 € :

Je suis parti de ce modèle, et lancé leur configurateur. J’ai modifié pas mal de trucs : boitier et ventilo Be quiet! super silencieux, carte-mère Asus, 32 Go de RAM, 2 HD de 2 To ajoutés, ainsi qu’un lecteur/graveur DVD, sans OS bien sûr. Je suis arrivé finalement à un prix de 969 € (monté). À ce prix il faut ajouter environ 20€ pour la livraison.

Chez LDLC, pour la même configuration, j’arrive à 1155 €, soit presque 200 € de plus (ou 20%) ! Franchement, il n’y a pas photo entre les deux sites.

Conclusion

J’ai passé la commande le 13 juillet, envoi prévu le 21 ; le 21, je reçois un mail m’informant d’un petit retard, et envoi finalement le 25 juillet, livré à domicile le 28 juillet.

L’étape suivante sera bien sûr d’installer Debian sur ce nouveau PC, et de transférer toutes mes données… Ce sera l’objet d’un prochain article. Je peux déjà dire que tout s’est très bien passé, à part une petite frayeur due au BIOS ASUS, dont les options manquent je trouve un peu de clarté…

KVM : Partager un dossier et le presse-papier entre la machine hôte et l'invité

Fri, 27 May 2022 15:39:08 +0000

Quand on utilise des machines virtuelles (VM), il vient toujours un moment où l’on a besoin de partager des fichiers avec la machine hôte. C’est à peu près aussi indispensable que le copier/coller…

Je pensais que ce serait fait nativement avec KVM, mais ce n’est pas le cas, il y a un peu de configuration à faire.

Dans cet article, je me limite à une machine hôte/host Linux (mon PC sous Debian en fait) ; pour la machine invitée/guest (la VM donc) je traiterai les deux cas : Linux et Windows. En clair, je me limite à mon environnement ! ;-)

Voir cet article pour l’installation de KVM sur le PC Linux. On y installe le gestionnaire de machines virtuelles virt-manager parmi les autres paquets nécessaires : c’est l’interface graphique pour gérer les VMs, et l’on va s’en servir ici.

Je me suis basé sur cette page pour écrire cet article (Host & Guest Linux), qui utilise les solutions natives intégrées à KVM ( virtio-9p). Pour les Guest Windows), ça a été plus compliqué car il existe plusieurs solutions comme celle-ci qui essaie d’utiliser virtio sur Windows via webdav… Mais ça m’a eu l’air peu fiable et problématique, et j’ai préféré utiliser Samba sur l’hôte, beaucoup plus simple à mettre en œuvre.

Et tant que j’y suis, je termine avec le copier-coller, autre fonctionnalité bien pratique quand on utilise une VM.

On commence donc par le partage de dossier entre la machine hôte et la machine invitée.

Sur la machine hôte

Il faut simplement créer un dossier sur la machine hôte qui servira de dossier partagé avec les VMs. Par exemple :

$ mkdir ~/KVM_Share
$ chmod 777 ~/KVM_Share

Et c’est tout ! On a ainsi créé un dossier dans notre répertoire Home et autorisé les VMs à l’utiliser.

À noter que dans le premier tuto en référence, il est fait mention de commandes SELinux, mais cela ne s’applique qu’aux machines basées sur RPM, c’est-à-dire Red-Hat. Ce n’est donc pas nécessaire pour Debian (ni Ubuntu).

Sur la machine invitée

À partir du gestionnaire de machines virtuelles, on sélectionne une VM (ici Debian 11), puis on choisit Ouvrir :

Puis on clique sur la petite icône “Ampoule” pour afficher le s détails de la VM, et l’on choisit en bas “Ajouter un matériel” :

On choisit alors “Système de fichiers” dans la partie gauche, puis on à droite, on choisit virtio-9p comme Pilote, on indique le chemin du dossier créé précédemment sur la machine hôte pour le “Chemin de la source” ( /home/pascal/KVM_Share), et enfin on choisit un nom de dossier de notre choix, qui servir de point de montage à la VM une fois démarrée (ici /hostshare) :

Voilà, il ne reste plus qu’à démarrer la VM.

Sur la machine virtuelle Linux

De la même manière que pour la machine hôte, on va d’abord créer un répertoire qui servira de partage (le nom d’utilisateur dans la VM est pled) :

$ mkdir /home/pled/KVM_Share

Puis on va le monter sur le point de montage défini précédemment, avec les paramètres qu’il faut :

$ sudo mount -t 9p -o trans=virtio /hostshare ~/KVM_Share

Pour rendre le mount permanent, le mieux est de l’ajouter dans /etc/fstab avec les options suivantes :

/hostshare /home/pled/KVM_Share 9p trans=virtio,version=9p2000.L,rw,_netdev 0 0

Le paramètre _netdev permet de faire le mount une fois le réseau démarré.

Et voilà, on peut désormais partager des fichiers entre la machine hôte et la VM. À noter que Gnome affiche le dossier de partage avec une belle icône dédiée :cool: :

Les droits sur les fichiers

Il faudra tout de même gérer les droits des fichiers venant de la VM si l’on souhaite modifier ces fichiers.

J’ai créé deux fichiers dans le même répertoire partagé KVM_Share, un à partir de l’hôte ( host-file.txt), l’autre à partir de la VM ( guest-file.txt). Voilà ce que donnent les droits :

Vu de la VM : aucun problème, les deux fichiers appartiennent à l’utilisateur.

$ ls -l
total 4
-rw-r--r-- 1 pled pled 0 23 mai   11:50 guest-file.txt
-rw-r--r-- 1 pled pled 0 23 mai   11:51 host-file.txt

Vu de la machine hôte :

$ ls -l
total 4
-rw------- 1 libvirt-qemu libvirt-qemu 0 23 mai   11:50 guest-file.txt
-rw-r--r-- 1 pascal       pascal       0 23 mai   11:51 host-file.txt

On voit que le fichier venant de la VM appartient à l’utilisateur libvirt-qemu et au groupe du même nom. Il faudra donc se réapproprier les fichiers si l’on souhaite les modifier :

$ sudo chown pascal * ; sudo chgrp pascal *
$ ls -l
total 4
-rw------- 1 pascal pascal 5 23 mai   16:04 guest-file.txt
-rw-r--r-- 1 pascal pascal 0 23 mai   11:51 host-file.txt

Sur la machine virtuelle Windows

C’est bien dommage, mais il n’y a pas de solution directe avec une VM Windows. Plusieurs solutions restent possibles, mais aucune n’est vraiment idéale, car il va falloir installer des logiciels supplémentaires que ce soit côté hôte ou invité, et en général c’est ce que j’essaie d’éviter.

Voyons les possibilités, selon les usages, cela peut varier :

Sans rien installer :

Passer par de vos comptes mail proposant un accès webmail et envoyer les fichiers ainsi ! :lol: Ça peut paraître bête, mais si l’usage est ponctuel, c’est le plus simple et le plus rapide ! Et pour les gros fichiers, il reste des solutions comme WeTransfer ou mieux SwissTranfer.

Avec virt-manager

On trouve plusieurs possibilités incluant virt-manager dans la configuration d’un partage. Aucune n’est vraiment simple, vu que MS ne fournit rien en standard pour utiliser virtio.

Utiliser virt-manager avec spice-webdav (solution décrite ici): testé avec une VM Win7, le service spice-webdav proxy s’installait bien, mais le service n’a jamais démarré.
Utiliser virt-manager avec Cockpit (la solution est décrite ici). Cockpit est une interface web qui simplifie la gestion d’une machine Linux, et par laquelle on peut lancer les VM faites avec KVM. Mais ici aussi on utilise spice-webdav, donc solution non testée avec en plus Cockpit côté host.
Utiliser virt-manager avec virtiofs : non testé, ça m’a l’air compliqué. À priori, on ajoute un “Système de fichier” dans virt-manager, mais on choisit virtiofs comme pilote, puis on installe WinFsp en suivant ce tuto. Attention, cela ajoute un matériel, et il est bien possible que cela nécessite la réactivation de votre licence MS ! :evil:

J’ai fait le premier test avec une VM Windows 7, j’aurais peut-être pu essayer avec une version plus récente pour vérifier… Mais bon, je ne m’étend pas sur ces solutions puisque qu’il y a plus simple :

La solution Samba

Finalement la solution la plus simple reste d’installer Samba sur la machine hôte, et accéder au dossier partagé depuis la VM Windows. Après tout Samba implémente le protocole SMB de MS, c’est souvent dans ce sens que cela fonctionne le mieux !

On installe d’abord le service :

$ sudo apt update
$ sudo apt install samba

Puis on définit le dossier partagé que l’on souhaite dans /etc/samba/smb.conf :

[KVM_Share]
	comment = KVM_Share
	path = /home/pascal/KVM_Share
	read only = No
        browsable = yes
        guest ok = true

Et on redémarre le service sans oublier d’ouvrir les ports du pare-feu :

$ sudo systemctl restart smbd
$ sudo ufw add samba

On démarre le VM Windows (Windows 8 ici), puis dans l’explorateur de fichiers, on choisit “Connecter un lecteur réseau” :

Puis on indique l’adresse IP de la machine hôte ainsi que le nom de partage définit avec Samba :

Et voilà, même pas besoin de s’identifier grâce au paramètre “guest ok” définit avec Samba. Désormais, à chaque démarrage, on aura notre dossier partagé de connecté :

Par contre, comme avec le guest Linux, il faudra faire attention aux permissions sur les fichiers :

En cas de souci, accorder tous les droits à tout le monde à partir de la machine linux (c’est plus simple à faire de ce côté qu’avec Windows) :

$ sudo chmod 777 *

Paramétrage Samba

J’avais fait un article sur Samba il y a 2 ans, son contenu est toujours valable, et donne les bases d’une première installation, ainsi que les infos pour investiguer en cas de problème. Ici , j’ai simplifié au maximum, c’est à mon avis suffisant (et très pratique) pour un environnement privé, à moins d’être parano.

Le paramètre guest ok permet de ne pas avoir à entrer de mot de passe, c’est bien pratique, et ce sont les privilèges du compte guest qui seront appliqués ( nobody sur debian) . Si l’on veut sécuriser l’accès avec un mot de passe, il faut bien sûr retirer ce paramètre guest ok, puis définir un mot de passe Samba pour le compte utilisateur souhaité (Samba n’utilise pas les mots de passe du système Linux) :

sudo smbpasswd -a pascal

Ce compte doit par contre exister sur le système, sinon il ne sera pas sauvegardé (erreur “Failed to add entry for user xxx”). Et bien sûr, il faudra s’identifier au moment de connecter le lecteur (au moins la première fois).

Pour creuser, la documentation de Samba peut être trouvée à partir de cette page. Et les paramètres du fichier smb.conf sur celle-ci.

Copier/Coller

Si le copier/coller ne fonctionne pas nativement (notamment pour les machines virtuelles Windows), il faut se tourner vers spice.

Sur la machine Hôte

Vérifier d’abord que la VM (dans virt-manager, afficher les détails) est bien configurée pour utiliser spice, ce qui doit être le cas par défaut avec virt-manager :

Dans la VM Linux

Il faut installer l’agent spice :

sudo apt install spice-vdagent

Et pour s’assurer que le service démarrera automatiquement :

sudo systemctl enable spice-vdagentd

Dans la VM Windows

Il faut installer les spice-guest-tools, que l’on peut trouver ici.

Une fois installés, le copier/coller fonctionne immédiatement, dans les deux sens.

Conclusion

Il faut reconnaître qu’avec une VM Windows, KVM s’avère plus compliqué que VirtualBox pour partager un dossier. Mais KVM est intégré au noyau linux (donc plus performant) et la meilleure option quand on utilise un poste Linux.

Et franchement, mon expérience du temps d’Ubuntu avec Virtualbox et ses “Guest additions” qu’il fallait réinstaller à chaque nouvelle version était une vraie plaie. Je n’ai pas non plus de bons souvenirs avec le copier/coller.

Pour la partage de dossier avec un invité Windows, la solution avec spice-webdav n’a pas fonctionné quand j’ai voulu la tester. J’étais avec Windows 7, j’aurais peut-être pu essayer avec une version plus récente ? De toutes façons, il me paraît plus simple d’installer Samba sur l’hôte en deux ou trois commandes que d’utiliser un logiciel non supporté par MS et susceptible de provoquer plus de problèmes que d’en résoudre.

Voilà, tout est désormais prêt pour utiliser les VMs et pouvoir partager avec la machine hôte aussi bien le presse-papier que des fichiers ! :cool:

Debian : Installation pilote NVIDIA et configuration X11

Thu, 03 Mar 2022 17:59:05 +0000

Depuis ma première installation de Debian, j’étais resté avec la congifuration graphique de base (à savoir Wayland comme serveur d’affichage et Nouveau comme pilote graphique), après une première tentative malheureuse d’installer les pilotes NVIDIA : j’avais du tout réinstaller car l’écran connecté sur la carte NVIDIA était devenu tout blanc, et je n’avais réussi à m’en sortir (voir cet article). L’autre écran étant connecté sur le chip Intel intégré à la carte-mère.

Et puis en installant SuperTuxKart histoire de me divertir un peu, j’ai vu que je ne pouvais pas rester comme ça, le jeu étant injouable en l’état (tout fonctionnait, mais au ralenti). Il était temps de se pencher sérieusement sur les pilotes graphiques de ma Debian 12 “Bookworm”…

Première remarque, le wiki Debian est vraiment complet, fournissant plein d’informations très utiles, souvent en français (mais pas toujours). Bravo à la communauté ! Après plusieurs tentatives, j’ai fini par réussir à avoir mes deux écrans fonctionnels avec le pilote nvidia chargé.

En résumé : le pilote nouveau n’a pas fonctionné avec le firmware de ma carte graphique (Nvidia GeForce 1050 Ti), et il a fallu passer à X11 en lieu et place de Wayland car les pilotes proprio Nvidia se sont pas stables avec Wayland. Tout s’est ensuite résumé à avoir un fichier xorg.conf fonctionnel, ce qui sera le cas après quelques essais !

Je vous raconte tout ça, avec les commandes utiles à connaître. Cet article ne prétend pas tout couvrir sur ce sujet très complexe, mais il peut tout de même se révéler utile j’espère.

Terminologie

Avant de commencer, il est peut-être utile de préciser un certain nombre de choses sur la pile graphique utilisée par Debian/Gnome.

Depuis Debian version 10 “Buster” (2019), Gnome utilise Wayland par défaut. Ce serveur d’affichage moderne remplace X11, soit la version 11 de X Server, qui était lui très ancien (1987) et devenait difficile à maintenir, posant aussi des problèmes de sécurité de par sa conception. Retenons que Wayland est plus performant, plus sécurisé, mais sans doute moins stable que X11 qui bénéficie d’une longue expérience.

Par défaut, Debian Gnome va utiliser le pilote Nouveau (un pilote libre) pour une carte NVIDIA (ce fabriquant ne fournissant que des pilotes propriétaires et étant très peu coopératif avec le logiciel libre). Ce pilote n’exploite pas tout le potentiel de la carte, mais bon ! De toutes façons, comme on le verra ci-dessous, il ne fonctionnera pas pour moi.

Je serai donc amené à installer le pilote propriétaire de NVIDIA. Ce qui fera que Wayland sera désactivé par Gnome et X11 utilisé à la place (voir plus bas) ! :cry: Moralité, mieux vaut investir dans une carte Intel ou AMD si l’on a un système Linux.

Préparation

Cette fois, pas question de devoir tout réinstaller si je me retrouve coincé : j’utilise le système depuis plusieurs mois maintenant, ce serait vraiment galère de devoir tout recommencer. J’ai donc commencé par sauvegarder ma partition système en démarrant sur ma clef USB Clonezilla : l’opération prend un peu de temps, mais il suffit de la lancer au moment opportun, c’est-à-dire avant d’aller faire autre chose ! En procédant ainsi, l’opération est transparente, et je pouvais ensuite me lancer sereinement dans cet exercice périlleux.

Commandes utiles

Commandes graphiques

La première chose à faire, c’est bien sûr de vérifier que vos deux cartes graphiques sont bien identifiées par le système :

pascal$ sudo lshw -C display -short
Chemin matériel       Périphérique  Classe         Description
=================================================================
/0/100/1/0                             display        GP107 [GeForce GTX 1050 Ti
/0/100/2               /dev/fb0        display        Xeon E3-1200 v3/4th Gen Co

La carte GeForce est bien identifiée, ainsi que le chip Intel intégré à la carte mère. La commande suivante est similaire, mais va nous donner en plus les identifiants PCI qui nous seront utiles plus loin (pour le fichier xorg.conf) :

pascal$ lspci -nn | egrep -i "3d|display|vga"
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)

C’est le moment d’installer le paquet nvidia-detect puis de le lancer pour avoir l’info et quel paquet est-il recommandé d’installer :

pascal$ sudo apt install nvidia-detect
pascal$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)

Checking card:  NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
Your card is supported by all driver versions.
Your card is also supported by the Tesla 470 drivers series.
Your card is also supported by the Tesla 460 drivers series.
Your card is also supported by the Tesla 450 drivers series.
Your card is also supported by the Tesla 418 drivers series.
It is recommended to install the
    nvidia-driver
package.

La commande suivante va nous confirmer que le chip Intel supporte bien l’accélération graphique 3D :

pascal$ glxinfo|egrep "OpenGL vendor|OpenGL renderer"
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2)

Pour avoir les commandes GLX (comme glxinfo, glxheads, glxgears), il faut auparavant installer le paquet suivant :

pascal$ sudo apt install mesa-utils

Pour connaître le type de serveur d’affichage utilisé, taper l’une ou l’autre de ces commandes :

pascal$ echo $XDG_SESSION_TYPE
x11
[/etc/X11]
pascal$ ps -e | grep X
   1690 tty2     01:40:46 Xorg

Commandes démarrage

Enfin, il va falloir analyser le démarrage du système pour comprendre ce qui se passe. Pour cela, deux commandes vont être très utiles. La première va nous identifier la liste des derniers démarrages, le plus récent étant le numéro 0 :

pascal$ sudo journalctl --list-boots
...
 -5 bd3f83fc0ee94bae8b22b9bce43f6a8d Tue 2022-03-01 18:55:52 CET—Wed 2022-03-02 10:30:25 CET
 -4 ec62a9a7094d49e89905ac435e624c06 Wed 2022-03-02 10:30:40 CET—Wed 2022-03-02 11:00:06 CET
 -3 aa988af5cf41463b9b8f9e7ec9df2cd5 Wed 2022-03-02 11:03:23 CET—Wed 2022-03-02 15:02:33 CET
 -2 7bcd1f2a1d2d437e93a01eb0ea31105f Wed 2022-03-02 15:02:48 CET—Wed 2022-03-02 15:08:17 CET
 -1 0a11f7f1057f4d12b7198c4d2a892046 Wed 2022-03-02 15:08:32 CET—Wed 2022-03-02 15:29:33 CET
  0 1b08b417191a457d9b4a37b82d0ab11d Wed 2022-03-02 15:29:59 CET—Wed 2022-03-02 17:42:30 CET

Je n’affiche ici que les cinq derniers, mais le système garde les 40 derniers logs de démarrage. C’est donc très pratique !

Et la commande sudo journalctl -b 0 va par exemple nous afficher ligne par ligne le dernier démarrage, avec une coloration pour les messages d’erreur (rouge) ou d’info (jaune). Pour remonter dans le temps, indiquer le numéro “-1”, “-2”, etc… Voilà donc ce que j’avais sur mon système avant de faire quoique ce soit :

Le pilote nouveau

Une petite recherche sur le wiki debian m’amène sur cette page concernant les pilotes propriétaires NVIDIA. Je regarde ce qui concerne ma version Debian, et je me dis que dans un premier temps, je peux n’installer que les firmware, et garder le pilote nouveau. Si tout fonctionne correctement, cela me conviendra. Et en regardant le contenu du paquet (ici) je vois que scubber.bin en fait bien partie.

J’active donc “contrib” et “non-free” dans les dépots, puis installe les firmware :

pascal$ sudo apt install firmware-misc-nonfree

Puis je redémarre. Et là, je retrouve mon écran connecté sur la carte NVIDIA tout blanc… Comme la première fois ! Je regarde les logs, et je vois ceci :

sudo journalctl -b 0 | grep "dri/card1"
gnome-shell[1186]: Device '/dev/dri/card1' prefers shadow buffer
gnome-shell[1186]: Added device '/dev/dri/card1' (nouveau) using non-atomic mode setting.
gnome-shell[1186]: Created gbm renderer for '/dev/dri/card1'
gnome-shell[1738]: Device '/dev/dri/card1' prefers shadow buffer
gnome-shell[1738]: Added device '/dev/dri/card1' (nouveau) using non-atomic mode setting.
gnome-shell[1738]: Created gbm renderer for '/dev/dri/card1'
gnome-shell[1738]: Could not release device '/dev/dri/card1' (226,1): GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name :1.3 was not provided by any .service files

Bon, le message précédent a bien disparu, mais le pilote “nouveau” semble ne pas fonctionner, et cela dépasse mes compétences. Pas de panique, j’installe les pilotes NVIDIA comme indiqué sur la page du wiki :

pascal$ sudo apt install nvidia-driver

Et je redémarre ! Cette fois, j’ai bien mon écran “nvidia”, mais j’ai perdu l’autre… :oops: C’est tout de même un progrès, je me suis sorti de l’écran blanc qui m’avait bloqué lors de la première installation de Debian. Que disent les logs ?

Je vois des messages Xorg, ce qui me met sur la piste de X11 à la place de Wayland.

X11 / Xorg

Le fait d’installer les pilotes propriétaires NVIDIA a désactivé Wayland pour utiliser X11 à la place pour cause d’instabilité. C’est confirmé ici :

GDM (GNOME Display Manager) will automatically use Wayland when supported, except when using the proprietary NVIDIA driver, in which case it will fall back to X11 due to instability.

L’information ci-dessus ne semble plus valable, le texte n’existe plus, les choses ont probablement évoluées depuis. Toujours est-il que sur cette page, concernant les pilotes Nvidia et Wayland, on peut lire ceci :

The NVIDIA driver supports Wayland, with caveats. The 495-series driver (or newer) is recommended for the best experience, as older versions only support Wayland through an NVIDIA-specific API which is not supported by all desktops, and is generally less reliable.

Vu que ma carte est assez ancienne, et utilise la version 470 du pilote Nvidia, j’en reste donc à Xorg.

Il s’agit donc pour moi de configurer proprement un fichier xorg.conf (qui n’existe pas encore dans /etc/X11). Sur cette page du wiki Debian je vois une référence à un outil nvidia-xconfig pour générer ce fichier xorg.conf. Aussitôt dit aussitôt fait :

pascal$ sudo apt install nvidia-xconfig
pascal$ sudo nvidia-xconfig
New X configuration file written to '/etc/X11/xorg.conf'

En regardant le fichier généré, je vois qu’un seul couple carte/écran est mentionné :

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Je redémarre à tout hasard, mais sans surprise, je n’ai toujours qu’un seul écran, celui sur la carte NVIDIA. Mais je suis sur la bonne piste, je sens que je progresse ! :cool: Et dans le log de boot, j’ai une nouvelle ligne me confirmant que le fichier xorg.conf est bien utilisé.

Je lance alors la commande sudo X -configure qui me génère un fichier xorg.conf.new dans /root :

En l’examinant, je vois que cette fois il y a bien deux cartes et deux écrans d’indiqués. Je n’affiche ici que des extraits du fichier en relation avec mon problème :

Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	Screen      1  "Screen1" RightOf "Screen0"
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection
....
Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
EndSection

Section "Monitor"
	Identifier   "Monitor1"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
EndSection
....
Section "Device"
	Identifier  "Card0"
	Driver      "intel"
	BusID       "PCI:0:2:0"
EndSection

Section "Device"
	Identifier  "Card1"
	Driver      "nouveau"
	BusID       "PCI:1:0:0"
EndSection

Je vais alors partir de ce fichier pour me construire un nouveau xorg.conf, en m’inspirant de celui créé précédemment par l’outil nvidia-xconfig. C’est la section"Device" de la “Card1” qui m’intéresse (on retrouve d’ailleurs les identifiants PCI mentionnés plus haut pour chaque carte), et je remplace le driver “nouveau” par “nvidia”. Je laisse la “Card0” avec son driver “intel”, cela paraît correct.

Et je redémarre ! Cette fois, je suis revenu sur l’écran connecté à la carte Intel ! :shock: Mais la bonne nouvelle, c’est que si mon écran “nvidia” est noir, je peux tout de même y promener la souris, qui a l’apparence d’une croix. Dans les paramètres Gnome, un seul écran est affiché. Pourtant, en lançant l’outil nvidia-config (installé avec le paquet nvidia-driver, tout a l’air correct : la carte NVIDIA, l’écran détecté, etc…

Je suis tout près de la solution… Je regarde alors ces deux pages du wiki debian, concernant la configuration et le dépannage des pilotes NVIDIA. Je relance alors l’outil nvidia-xconfig pour qu’il me régénère un nouveau fichier xorg.conf cette fois avec les deux cartes/écrans (puisqu’il va se baser sur celui existant), et une fois ceci fait, après avoir chercher les bonnes valeurs de fréquence de mes deux moniteurs (comme conseillé sur la page dépannage), je les renseigne dans le nouveau fichier :

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "PHILIPS"
    ModelName      "PHILIPS 243S7EHMB"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "DELL"
    ModelName      "DELL 2208WFP"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
EndSection

Et je redémarre une dernière fois ! Car ce sera la bonne, mes deux écrans sont là, parfaitement identifiés, et le pilote NVIDIA bien chargé :

Pour afficher les infos Nvidia, on peut installer le package nvidia-settings :

$ sudo apt install nvidia-settings

Usage CPU

Tout serait parfait si je n’observais pas une utilisation CPU un peu trop élevée :

Si j’en crois la doc, Xorg devrait utiliser autour de 10% de CPU dans un usage normal. J’ai trouvé des posts sur le sujet dans la même configuration, à savoir une carte Nvidia et chip Intel, mais sans solution.

À l’usage, ce n’est pas gênant, en tout cas pour l’instant.

Conclusion

Je retiens que NVIDIA ne jouant pas le jeu du logiciel libre, mieux vaut investir dans une carte Intel ou AMD si l’on a un système Linux.

Ceci dit, cette installation s’est plutôt bien passée, même si je préférerais utiliser Wayland (ça me résoudrait le problème de CPU). Il faut retenir deux choses :

qu’avec Gnome, on passe en X11 au lieu de Wayland dès que l’on installe les drivers proprio NVIDIA, et qu’à partir de là, il va falloir créer un fichier /etc/X11/xorg.conf.
qu’avec les deux commandes sudo X -configure et sudo nividia-xconfig, on peut assez facilement construire le bon fichier.

Enfin, l’essentiel, c’est que je peux désormais jouer à SuperTuxKart ! :cool:

Sortie de veille du PC et microcode Intel

Wed, 16 Feb 2022 14:59:33 +0000

J’ai enfin résolu mon souci de sortie de veille du PC en appuyant sur une touche du clavier. Plutôt par hasard d’ailleurs, mais peu importe ! :cool:

J’ai déjà écrit un article à ce sujet, où je décris le problème, et le fait que cela fonctionnait de manière aléatoire (plutôt rarement en fait) au gré des mises à jour système d’Ubuntu. Puis je décrivais comment créer des règles udev pour tenter de résoudre le problème, sans certitudes pour autant.

Et puis je suis passé à Debian. Et là, miracle, la sortie de veille au clavier fonctionnait parfaitement, et ce depuis plus d’un mois, après plusieurs mises à jour d’effectuées entre temps…

Par ailleurs, je remarque un message d’erreur furtif au démarrage du PC, juste après le menu GRUB, et que je n’avais pas avec Ubuntu. Je retrouve le message dans le journal d’événements :

Je fais alors quelques recherches pour faire disparaître ce message. De fil en aiguille, je finis par installer le paquet non-free intel-microcode, ce qui fera bien disparaître ce message. Mais surprise : le problème de sortie de veille au clavier réapparaît aussitôt… :sad:

Pour les plus pressés, si vous avez ce problème de sortie de veille qui ne se déclenche pas sur un appui de touche au clavier, le premier réflexe doit être une mise à jour du Bios de votre PC. Si cela ne résout pas le problème, alors vous pouvez vous pencher du côté du microcode du processeur. Peut-être la version de celui-ci est la source du problème, et il peut valoir de le coup de le désinstaller.

Voyons un peu tout cela en détail. J’ai pour ma part préféré désinstaller ce paquet Intel, afin de retrouver ma sortie de veille en appuyant sur une touche du clavier. Et tant pis pour le message d’erreur furtif ! :wink:

TSC_DEADLINE error

J’ai tout d’abord trouvé cette page qui explique que ce message d’erreur est lié au jeu d’instruction du processeur (microcode). Le “TSC deadline” est une implémentation de la gestion des événements qu’il est intéressant d’utiliser, mais pas nécessaire au bon fonctionnement du PC.

Il y est expliqué que la première chose à faire est de mettre son BIOS à jour. Sur mon bon vieux Shuttle SH87R6 (acheté en 2014), mon BIOS est à jour, mais date de 2015.

Si cette première solution ne résout pas le problème, la page explique qu’il faut soit démarrer avec un kernel plus ancien (solution peu envisageable à mon avis), soit installer ou mettre à jour le microcode Intel (ou AMD) de votre système.

Intel-microcode

En cherchant cette fois du côté de Debian, je suis tombé sur cette page très détaillée du wiki Debian à propos du microcode. En gros, il s’agit donc du firmware du processeur. On peut certes le mettre à jour via le BIOS, mais le kernel peut aussi le faire au démarrage du PC, puisque ce microcode (ou jeu d’instructions) est chargé en mémoire.

Et nous y voilà : il s’agit d’un paquet non-free, puisque fournit par Intel (ou AMD) et donc opaque pour Debian. Or je n’ai pas activé les sources “non-free” sur ma Debian, contrairement à ce que j’avais fait sur Ubuntu. D’où la différence de comportement entre les deux systèmes. Le message d’erreur TSC_DEADLINE apparaît parce que la version de mon noyau est beaucoup plus récente que le microcode de mon BIOS.

Je suis donc les instructions de la page du wiki Debian : j’active les dépots contrib et non-free :

J’actualise :

Puis j’installe le fameux paquet intel-microcode :

sudo apt install intel-microcode

Le paquet s’installe, ainsi qu’un autre : iucode-tool (dépendance). Je retourne immédiatement décocher les sources contrib et non-free, et j’actualise, afin de ne pas avoir d’autre mises à jour non-free.

En effet, je préfère les éviter tant que cela n’est pas nécessaire, et que mon PC fonctionne parfaitement sans pilote propriétaire. Je suis sous Debian “testing” que je découvre, donc je tiens à rester prudent !

Conclusion

Une fois le paquet intel-microcode installé, au redémarrage, le message d’erreur TSC_DEADLINE avait bien disparu. Mais comme je l’expliquais en début d’article, le réveil du PC par un appui sur une touche clavier ne fonctionnait plus.

Entre un message d’erreur furtif sans conséquence, et une fonctionnalité que j’utilise tous les matins, je n’ai pas hésité longtemps : j’ai désinstallé le paquet :

sudo apt remove intel-microcode

Et vérifié qu’après un redémarrage, la sortie de mise en veille était de nouveau fonctionnelle. Ce qui était le cas.

Pour conclure, et bien que je ne maîtrise pas tout loin de là, on peut supposer qu’il y a un problème entre les versions récentes du microcode Intel et ma carte-mère, qui provoque le dysfonctionnement sur la sortie de veille au clavier. Avec la version microcode fournit avec le BIOS, même si celle-ci est ancienne et génère le message TSC_DEADLINE, le réveil du PC au clavier fonctionne.

Et pour les plus curieux, voilà ce que me dit la commande lshw concernant le BIOS et le CPU :

pascal$ sudo lshw
  *-core
       description: Carte mère
       produit: FH87
       fabriquant: Shuttle Inc.
       identifiant matériel: 0
       version: 1.0
       numéro de série: 4016
       emplacement: To be filled by O.E.M.
     *-firmware
          description: BIOS
          fabriquant: American Megatrends Inc.
          identifiant matériel: 0
          version: 2.05
          date: 01/04/2016
          taille: 64KiB
          capacité: 3MiB
          fonctionnalités: pci upgrade shadowing cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb biosbootspecification uefi
     *-cpu
          description: CPU
          produit: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
          fabriquant: Intel Corp.
          identifiant matériel: 3d
          information bus: cpu@0
          version: 6.60.3
          emplacement: SOCKET 0
          taille: 3828MHz
          capacité: 3900MHz
          bits: 64 bits
          horloge: 100MHz
          fonctionnalités: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts cpufreq
          configuration: cores=4 enabledcores=4 microcode=29 threads=8

Un script pour les données de géolocalisation dans les photos

Mon, 24 Jan 2022 18:04:56 +0000

J’en parlais dans l’article Zenphoto : Nouveau thème et géolocalisation : j’ai écrit un petit script pour évaluer la quantité de photos incorporant les données GPS (données EXIF).

Le résultat n’est pas fameux d’ailleurs, seulement 10% environ des photos de mon voyage en Asie contiennent ces fameuses données permettant leur géolocalisation. Alors que je les ai toutes prises avec le smartphone… :sad: Il faudra que je sois plus vigilant lors de mon prochain voyage.

Mais revenons au script Bash : avant tout, je suis loin d’être un pro du Bash, mais j’aime bien me faire de petits scripts qui répondent à mes besoins, comme par exemple analyser le contenu de ma médiathèque (afficher les derniers ajouts, rechercher un mot clef, etc…). Avec l’aide d’internet et à force d’essais, on finit toujours par arriver à ses fins. Et en fait, j’aime bien m’y plonger, je ne vois littéralement pas les heures passer, et quand j’arrive au résultat voulu, c’est toujours gratifiant.

Pour info, voilà le résultat du script quand il analyse le dossier des photos du voyage en Asie : cela vous donne une idée de ce qu’il fait, et du soin que j’ai apporté aux couleurs ! ;-)

Voyons voir de quoi est fait ce script : quel outil j’ai utilisé, et les principales étapes du traitement.

L’outil exif

Après une rapide recherche sur le net, j’ai d’abord utilisé l’outil exif mais celui-ci s’est vite révélé peu pratique à manipuler : en effet, il renvoie les données sur stdout si tout va bien, en précisant le nom de fichier :

Jusque là tout va bien. Mais s’il considère les données corrompues, il les renvoie sur stderr sans préciser le nom du fichier ! :cry:

À ce stade, je peux encore m’en sortir avec la liste de tous les fichiers comparée à celles des fichiers ayant les données. Mais cela se complique quand je me rends compte que dans certains cas, il affiche le nom du fichier sur stdout ET un message d’erreur sur stderr :

Là, je me dis que ça va devenir très compliqué d’utiliser cet outil, qui ne semble pas vraiment abouti.

Donc EXIT EXIF ! :arrow: []

L’outil exiftool

Je me tourne alors vers un autre outil : exiftool.

$ sudo apt install exiftool

Il apparaît vite comme extrêmement complet et puissant. Et surtout, les fichiers aux données de géolocalisation indiquées comme “corrompues” par exif ne le sont plus ! Elles sont absentes ou présentes, mais ne génèrent aucun message d’erreur :

À toutes fins utiles, voilà un exemple pour insérer des données EXIF si elles sont manquantes dans les fichiers. Cela m’arrive si je récupère une photo que l’on m’a envoyée par SMS par exemple, ou d’un autre appareil où ces données ne sont pas intégrées pour une raison ou pour une autre. Ici j’insère la position GPS, la date de prise de la photo, ainsi que la marque et le modèle de l’appareil :

$ exiftool -overwrite_original -GPSLatitude="47 deg 54' 45.2" -GPSLongitude="3 deg 58' 25.6" -GPSLatitudeRef="North" -GPSLongitudeRef="West" -DateTimeOriginal="2022:01:10 11:41:06" -Make="bq" -Model="Aquaris X Pro" Image-01.jpg

Ce sont les données dont j’ai besoin pour mon album photo ! L’ensemble des tags sont disponibles sur la page d’Exiftool.

Revenons à notre script : exiftool permet d’exporter les données extraites dans un fichier .csv, qui sera bien plus pratique à traiter dans le script. Comme il est dit sur sa home page : Powerful, fast, flexible and customizable !

Le script

Vous pouvez le récupérer ici, si vous voulez l’utiliser ou vous en inspirer. Je re-précise que c’est du travail d’amateur, qu’il y a sûrement moyen de faire mieux, plus simple, plus court, etc… Le but est avant tout de partager ! :cool:

J’ai utilisé des fonctions, cela permet de structurer le code d’une part, et d’éviter de répéter les mêmes lignes d’autre part. Conséquence : puisque l’on définit d’abord les fonctions, il faut aller chercher le début d’exécution du script à la fin (vers ligne 160).

Il y a deux dépendances à installer : l’outil exiftool bien sûr, mais aussi l’outil bc (Bash Calculator) pour pouvoir afficher les pourcentages.

$ sudo apt install exiftool bc

Ces deux dépendances sont testées dans le script de façon assez simple (le “blabla…” est bien entendu un message expliquant comment installer l’outil) :

if ! command -v exiftool &> /dev/null
then
	echo "blabla..."
    exit
fi
if ! command -v bc &> /dev/null
then
	echo "blabla..."
    exit
fi

Puis je teste l’existence du paramètre ($1) que l’on doit passer au script. S’il est bien présent, je le transforme en “chemin absolu” et l’affecte à la variable $dossier.

if [ -z "$1" ] ; then
	echo "blabla..."
	exit
else
	dossier=$(readlink -f "$1")
fi

Et s’il est absent, le “blabla…” ci-dessus est un message d’aide :

Il me faut donc maintenant vérifier les informations de longitude et de latitude les fichiers images du répertoire (et de ses sous-répertoires) passé en paramètre. Une fois les tags GPS de l’outil exiftool identifiés, la commande suivante va me créer le fichier liste.csv à partir duquel je vais pouvoir faire mes calculs, en ne traitant que les fichiers JPG et PNG, et en parcourant les sous-répertoires :

exiftool -ext jpg -ext png -r -csv -filename -GPS:GPSLatitude -GPS:GPSLongitude "$dossier" >> liste.csv

exiftool génère alors un fichier liste.csv avec la virgule comme séparateur, et les données SourceFile, FileName, GPSLatitude, GPSLongitude :

Vient ensuite le traitement de ce fichier, qu’il s’agit de traiter ligne par ligne. J’ai trouvé cette page qui explique bien les différentes possibilités qu’offre le Bash. Ce n’est pas aussi trivial qu’on pourrait le croire, avec notamment le séparateur de fichier interne (IFS) à gérer. Là, avec mon fichier CSV et sa virgule comme séparateur, cela simplifie bien le problème.

J’ai opté pour le “process substitution” car je voulais supprimer la première ligne du fichier CSV avant de le traiter. Il faut aller en bas de la boucle (DONE) pour voir le fichier en entrée à traiter, puis je précise que le séparateur est la virgule, et enfin je recherche les mots clefs ’latitude’ ou ’longitude’ (les deux doivent être présents). Ensuite j’incrémente un compteur “nogps” et ajoute les noms de fichiers dans deux fichiers distincts.

while IFS="," read -r source filename latitude longitude
do
  nbreimages=$((nbreimages+1))
  if [ -z "$latitude" ] || [ -z "$longitude" ] ; then
	nogps=$((nogps+1))
	echo "$filename" >> liste_fichiers_noGPS.txt
  else
	echo "$filename" >> liste_fichiers_GPS.txt
  fi
done < <(tail -n +2 ./liste.csv)

Le reste est assez simple : on compte, on ajuste, on calcule… Puis on affiche les résultats, en proposant de sauvegarder les listes dans le répertoire home de l’utilisateur. Puis on efface tous les fichiers qui ont été créés par le script avant de sortir.

Voilà, un petit script bien pratique, même si le résultat n’est pas celui espéré pour mon voyage en Asie ! En tout cas, j’ai bien aimé le réaliser, c’est déjà ça…

Installation de Debian

Sun, 16 Jan 2022 17:16:52 +0000

Comme je l’expliquais dans l’article précédent, je suis passé de Ubuntu à Debian un peu lassé des formats snap et flatpak.

J’ai choisi d’installer Debian Testing plutôt que la version Stable, afin de bénéficier de versions de logiciels plus récentes. D’après ce que j’ai lu, c’est suffisamment stable pour une utilisation quotidienne. Je verrai à l’usage ce que cela donne.

Cet article pour résumer comment j’ai procédé pour cette installation : je voulais repartir d’un système propre y compris mon répertoire home. Il y avait bien sûr des sauvegardes de fichiers et dossiers à faire, j’en ai oublié certains qui m’auraient simplifié un peu la vie : rien de bloquant, mais je vais les lister ici pour mémoire. Il a fallu aussi recréer une bonne vieille partition de swap, puisque Ubuntu utilise un fichier (comme Windows) pour ce faire.

Sinon tout s’est globalement bien passé, le système est désormais fonctionnel, j’ai pu réinstaller toutes les applications que j’utilise, le plus souvent en .DEB. Avec un peu de personnalisation, je suis très content du résultat.

Voyons tout cela en détail…

Préparation

Les fichiers du système

Les fichiers que j’ai pensé à sauvegarder pour faciliter la configuration du nouveau système (en fait, je me les suis envoyés par mail, puisque ce sont de petits fichiers. Ça permet de les récupérer facilement une fois l’installation terminée.) :

/etc/fstab (pour les point de montage)
/var/spool/cron/crontabs/pascal (pour mes tâches planifiées)
pascal.kdbx (fichier de mot de passes de KeepassDX)

Les fichiers que j’aurais pu sauvegarder aussi mais que j’ai oublié :

Les mots de passe de Firefox : je comptais sur mon compte sync de Firefox pour me les récupérer, mais cela n’a pas fonctionné, sans doute parce que j’utilise Firefox Lockwise ? Je n’ai pas creusé, ça n’a pas l’air très clair puisque je vois dans Lockwise une option pour exporter mes identifiants, mais aucune pour importer ?? Pas grave, comme j’utilise KeepassDX pour stocker tout mes mots de passe, il me faut juste les ressaisir pour que Firefox les mémorise à nouveau.

La configuration de BackinTime : j’utilise ce soft pour sauvegarder mon home, une option permet de sauvegarder vos paramètres, j’ai recréé la tâche, pas vraiment un problème, ça m’a pris deux minutes.

La configuration du firewall : j’utilise Gufw, il y a une option pour exporter/importer le profil. Ça m’oblige à repartir de zéro, un mal pour un bien.

Les flus RSS de Liferea : je n’y ai pas pensé lors de la préparation, mais j’avais un fichier .opml récent, pas de souci donc.

Rien de vraiment gênant donc, mais autant les noter pour la prochaine fois.

Le répertoire home

Comme je voulais repartir avec un répertoire /home/pascal propre (j’utilise une partition dédiée), j’ai fait d’abord une sauvegarde avec rsync de mon répertoire vers un disque externe, et juste avant de démarrer l’installation proprement dite, j’ai démarré une dernière fois Ubuntu via GRUB en mode “mono utilisateur”, et j’ai renommé le répertoire en /home/pascal-ubuntu. Je vais ainsi pouvoir recréer le compte “pascal” et être vraiment propre sur le nouveau système.

Partitionnement et installation

Important : mon système utilise une partition UEFI (voir cet article), il est donc important de laisser dans le BIOS ce mode activé lorsque l’on va amorcer sur la clef USB pour installer Debian. Sinon le boot UEFI sera cassé.

J’ai d’abord démarré sur un disque Live Ubuntu pour pouvoir lancer l’outil Gparted et procéder aux changements de partitions avec un outil graphique.

Voilà le disque comme il était sous Ubuntu :

Et le voilà après l’installation de Debian (j’ai diminué la partition “/” pour pouvoir créer la partition swap) :

Info

Pour information, mon fichier de swap avec Ubuntu faisait 10Go. On passe donc pour le système de 26 Go à 10 Go, ce qui est loin d’être négligeable. D’une part, il y a plus de paquets .DEB de disponibles avec Debian (puisque Ubuntu les remplace par ses snaps), d’autre part parce que Debian est plus léger (plus “fit”), les modifications d’Ubuntu devant être aussi coûteuses en place.

Revenons à l’installation : une fois le partitionnement fait, j’ai redémarré sur une clef USB où j’avais installé (avec Balena Etcher) l’image debian-testing-amd64-netinst.iso.

L’installation s’est passée sans aucun problème, l’installeur est certes moins sexy que celui d’Ubuntu, mais bon on est en mode graphique, tout reste simple. Il faut bien choisir ses partitions (mode manuel dans mon cas), le reste est vraiment très facile.

Le problème

Tout se passe donc bien, j’installe mes applications, je personnalise mon environnement (voir plus bas), j’ai pratiquement tout terminé, lorsque qu’il me vient l’idée d’activer les dépôts “non free” dans mon fichier /etc/apt/sources.list , et d’enchaîner avec sudo apt update puis sudo apt upgrade sans trop vérifier ce qui se passe, ni les messages. Toujours est-il qu’au redémarrage, mon second écran, connecté sur ma carte Nivia, est tout blanc ! :roll:

Et je ne m’en sortirai pas, j’ai trouvé des choses similaires sur le net, comme cette page, c’était exactement le même symptôme, mais cela datait de plus d’un an, et je n’y voyais pas vraiment de solution proposée.

Là, j’étais bon pour tout recommencer. La leçon que j’en tire, c’est que étant sur une Debian “Testing”, je dois être plus prudent que ça. Comme je n’avais pas réellement besoin de pilotes Nvidia (le pilote Nouveau (libre) faisant très bien l’affaire), je suis resté comme ça. Mon fichier sources.list contient les lignes suivantes et va rester tel quel à priori :

deb http://deb.debian.org/debian/ bookworm main
deb-src http://deb.debian.org/debian/ bookworm main

deb http://security.debian.org/debian-security bookworm-security main
deb-src http://security.debian.org/debian-security bookworm-security main

Configuration de Debian

La première chose à faire, c’est à se rajouter comme utilisateur au groupe sudo. Avec Ubuntu, c’est fait par défaut, mais pas ici. Il faut donc passer en mode su, puis taper la commande suivante (pour l’utilisateur pascal), puis vérifier que l’on fait bien partie du groupe (27) :

pascal$ su
Mot de passe :
root@pascal-SH87R:/home/pascal# /usr/sbin/usermod -aG sudo pascal
root@pascal-SH87R:/home/pascal# id pascal
uid=1000(pascal) gid=1000(pascal) groupes=1000(pascal),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),33(www-data),44(video),46(plugdev),109(netdev),115(bluetooth),119(scanner)
root@pascal-SH87R:/home/pascal#

Ensuite, il faut redémarrer pour que les changements soient pris en compte.

Impression

Pour l’imprimante, il faut aussi installer cups qui ne l’est pas défaut :

pascal$ sudo apt install cups

Une fois ceci fait, l’imprimante TR4550 Canon a été immédiatement détectée. À ce sujet, penser également dans LibreOffice à aller indiquer les paramètres de Langue en FR pour avoir du papier au format A4 par défaut…

Sinon petit problème avec le scanner, puisque le paquet xsane a été retiré de debian bookworm (voir ce bug). Et comme expliqué dans cet article, le scanner simple-scan de Gnome ne me permet pas de corriger le contraste puisque le scanner “n’expose” pas ces paramètres. :sad: Pour l’instant, j’en suis réduit à corriger le contraste dans Gimp une fois le document scanné.

Le thème

Je voulais quelque chose de clean, léger, reposant. Sur Ubuntu, j’utilisais le thème Adwaita. Il existe ici aussi bien sûr (thème Gnome) mais j’ai trouvé le thème materia-gtk-theme, très similaire, et qui a l’avantage d’être présent dans la distribution sous forme de package, il suffit juste de l’installer :

sudo apt install materia-gtk-theme

Il y a bien bien sûr un large choix sur gnome-look.org, à commencer par le thème Orchis qui a l’air très abouti. Mais j’ai finalement voulu rester très proche de ce que propose Gnome par défaut, particulièrement les icônes. Pour l’instant cela me convient, il sera toujours temps de changer plus tard si je le souhaite.

Extensions Gnome

Je n’ai besoin que de 5 extensions :

“Automove Windows” me permet de démarrer Thunderbird sur un deuxième espace de travail, “Dash to Dock” améliore nettement le dock par défaut de Gnome, “GSConnect” est là pour le smartphone, “Logo Menu” permet de remplacer “Activités” en haut à droite de l’écran par l’icône de Debian (indispensable !), et enfin “Tray Icons: Reloaded” permet d’afficher les icônes d’applications comme Nextcloud dans la barre supérieure, à droite.

Les applications

J’ai pu retrouver certaines applications en format DEB en lieu et place des snaps proposés par Ubuntu, ce qui était la raison principale de ce changement de système. Finalement, je n’ai désormais que 3 applications Flatpak : Gourmand (recettes de cuisine), Signal (messaging), et Anydesk (prise de contrôle à distance). Pour cette dernière, il y a bien un paquet .deb, mais il génère une erreur au lancement (je n’ai pas creusé) :

anydesk: error while loading shared libraries: libpangox-1.0.so.0: cannot open shared object file: No such file or directory

Info

Depuis la réinstallation sur le nouveau PC, il y a eu des changements :

- Pour Gourmand, je suis passé au format AppImage, que je trouve mieux intégré au desktop que la version Flatpak.

- Pour Signal, il y a désormais un dépot, voir cette page.

- Enfin, pour Anydesk, le paquet est désormais installé, sans doute en récupérant le .deb du site de Anydesk.

Concernant les AppImages, j’en utilise deux. Je copie les binaires dans ~/.local/bin, et je crée un fichier .desktop dans ~/.local/share/applications pour l’intégration au DE. Exemple pour Cozy :

[Desktop Entry]
Name=Cozy Drive
Comment=Save them safely in your open source personal cloud, access them anywhere, anytime with the mobile application and share them with the world or just your friends and colleagues. You can host your own Cozy Cloud, and or use the hosting services. Your freedom to chose is why you can trust us.
Exec="/home/pascal/.local/bin/Cozy-Drive-3.31.0-x86_64.AppImage" %U
Terminal=false
Type=Application
Icon=/home/pascal/.local/share/icons/cozy.png
StartupNotify=true
Categories=Network;FileTransfer;

Voilà, j’ai juste créé le fichier icône à la main, pour que l’application soit parfaitement intégrée à Gnome. Il n’y a rien d’autre à faire, ni besoin d’installer une application pour les détecter, comme j’ai vu qu’il existait.

Autre chose à noter, les PPA ne sont à priori pas disponibles sous Debian, c’est une techno Ubuntu. Il y a des pages qui expliquent comment les utiliser, mais c’est à vos risques et périls. Pour l’instant, je vais essayer de m’en passer. Finalement, l’idée d’être un peu plus rigoureux et de garder un système propre ne me déplaît pas. En réinstallant mes applications, j’en ai vu quelques unes dans ma liste que je n’avais utilisé qu’une seule fois : je ne les ai pas réinstallées.

Une seule application pose problème : flameshot, le logiciel de capture d’écran que j’utilise désormais (adios shutter). Le problème est lié à Gnome 41 et Wayland (eh oui, fini X.org). Avec la version 11 de Flameshot, la capture d’une zone de l’écran ne fonctionne pas (fractional scaling). Cela fait partie des “known issues”, mais une solution a été trouvée, et une prochaine version devrait régler cela.

Info

22 mai 2022 : cela fonctionne désormais avec la version de développement 11.0.rc1.-1. En attendant la v12 officielle, il faut aller sur la page Development Build, et télécharger le zip pour Linux. On y trouvera un paquet .deb (entre autres formats) qu’il suffit d’installer.

Conclusion

Voilà, je suis désormais sous Debian Testing “bookworm”, avec Gnome 41 :

Les premières impressions sont bonnes, et vu que l’on reste avec Gnome et les paquets DEB, on ne sent pas trop de différence immédiate. Le démarrage et l’arrêt sont légèrement plus rapides qu’avec Ubuntu me semble-t-il…

Il y a certainement des particularités qui vont apparaître avec le temps et que je vais découvrir, j’essaierai de mettre cet article à jour pour les choses les plus évidentes.

C’est aussi le bon côté de passer à un nouveau système : la découverte et l’apprentissage ! :idea:

Passage d'Ubuntu à Debian

Fri, 14 Jan 2022 17:48:20 +0000

Cela faisait un moment que je me demandais si le moment n’était pas venu de quitter Ubuntu.

J’étais toujours avec la 20.04 (version LTS) débarrassée des Snaps, mais avec Flatpak. J’attendais la prochaine LTS pour me mettre à jour, soit la 22.04, prévue pour avril prochain. Mais cette version va intégrer encore plus les snaps au système, cette fois même Firefox est livré sous forme de snap ! :oops:

Alors si une fois Ubuntu installé, je dois commencer par virer plein de trucs (snaps) et les remplacer par d’autres qui ne me plaisent guère plus (flatpak), c’est peut-être le moment de changer de distribution, non ?

Le principal problème que je vois à ces nouvelles façons de packager les logiciels que sont les snaps ou flatpak, c’est tout bêtement la place disque occupée ! Franchement, ça devient n’importe quoi, sous prétexte que le Giga-octet ne coûte pas cher.

Du coup je me suis tourné vers Debian, puisque Ubuntu est basé sur Debian. Et autant vous le dire tout de suite, le résultat en terme de place disque a été plutôt impressionnant, puisque je suis passé d’un Ubuntu occupant 27 Go d’espace disque à un Debian qui n’utilise que 10 Go ! :roll: Soit presque trois fois moins d’espace disque utilisé, avec à peu près les mêmes applications d’installées…

Je reviendrai sur l’installation de Debian dans le prochain article, mais revenons à ces formats de packaging, et aux différentes options auxquelles j’ai pensé avant de choisir Debian. C’est le sujet de cet article.

Snaps & Flatpaks… et autres

Pour rappel, ces packages (on peut ajouter le format AppImage dans le lot) intègrent tout ce dont l’application a besoin, dupliquant à l’envie les librairies système, reproduisant finalement tout un OS générique. On fait ensuite tourner cette application dans un “bac à sable”, qui est isolé du système, en clamant haut et fort que la sécurité est ainsi assurée. Ce dernier point reste d’ailleurs à prouver, puisque l’appli devra bien avoir les droits d’écriture ‘a minima’ sur votre home pour ouvrir/enregistrer vos fichiers. À partir de là…

Il y a beaucoup d’articles vantant les pour et les contres de snap vs flatpak. Ils tournent souvent en pro/con Ubuntu, du temps de démarrage des snaps, du choix d’applications disponible chez l’un ou l’autre, et du côté propriétaire de la solution proposée (imposée ?) par Ubuntu. On peut tout de même trouver des articles plus complets, ici par exemple, en français.

Pour moi, le problème majeur est donc celui de la place disque occupée par toutes ces applications. Il y a quelque temps, j’ai du agrandir ma partition système parce que flatpak me prenait 8 Go à lui tout seul (pour quelques applis d’installées) ! :roll:

Il y a aussi des problèmes d’intégration au desktop, pour s’accorder au thème par exemple. Ou les problèmes de pilotes graphiques, etc… Bref, ces packages sont loin d’être la solution miracle que l’on veut bien nous présenter comme “le futur”.

À mon avis, de telles technologies sont vraiment utiles sur des serveurs, pas sur le PC de madame Michu (et donc le mien) qui est un simple client avec son navigateur internet. Les accès internet de type serveur sont sur mon NAS (que madame Michu n’a pas), et là j’utilise Docker et ses containers, effectivement (une solution assez similaire dans l’idée).

C’est d’ailleurs du monde des serveurs que viennent les snaps d’Ubuntu/Canonical. C’est pour se simplifier la vie, et avoir à maintenir moins de packages, qu’ils intègrent leurs snaps à leur version desktop, et en virent les .DEB petit à petit.

Générer de tels packages, c’est certainement plus simple pour les développeurs, je veux bien le comprendre, mais c’est aussi la voie de la facilité. Préparer un paquet DEB ou RPM n’est pas si complexe pour un développeur, et couvre la grande majorité des systèmes Linux. Je dirais même que cela fait partie du cycle normal de développement d’un logiciel.

De plus, avec cette nouvelle façon de faire, on jette aux orties tout le travail de fait sur le système Linux en terme de sécurité et de stabilité. C’est un peu du grand n’importe quoi quand on y réfléchit. Après la mémoire, c’est au tour de l’espace disque d’être utilisé sans restriction : ça ne coûte pas cher, alors pourquoi compter ? Un bel exemple de notre société de consommation.

Vous pouvez lire cet article très complet Flatpak is not the future (en anglais), qui détaille bien la problématique, et d’une façon plus pointue.

Les alternatives

Il y a des distributions basées sur Ubuntu qui ont viré les snaps, comme Mint ou Pop OS!, mais je souhaite absolument garder Gnome comme environnement de bureau (DE) car je le trouve très abouti et efficace à l’utilisation.

Or Mint (très populaire) utilise Mate (un bureau léger qui imite celui de Windows) et Pop OS! a annoncé récemment l’abandon de Gnome pour créer son propre DE ( c’est vrai ça manquait un DE de plus :mad: ). Il faut donc aller voir ailleurs.

Il y a bien Fedora qui apporte une expérience native de Gnome, mais il repose sur Red Hat, et donc les packages RPM. Comme j’ai maintenant une bonne expérience du monde Debian, ça m’embêtait de changer complètement de système.

Et donc voilà comment je suis arrivé finalement à Debian comme la meilleure solution : l’une des plus vieilles distributions de la communauté Linux (1993), extrêmement fiable, et offrant une expérience Gnome ’native’.

Debian

Son fondateur s’appelle Ian Murdock, qui se maria avec Debra Lynn : c’est ainsi que naquit le nom de Debian ! Il a travaillé chez Sun, puis chez Docker. Il meurt en 2015 à 42 ans, et les circonstances de sa mort ne sont pas très claires.

Le modèle de publication des nouvelles versions est assez différent d’Ubuntu. Il a donc fallu faire un choix.

Sur Ubuntu, je m’en tenais depuis quelques années aux versions LTS, paraissant tous les deux ans. Les versions intermédiaires offrent de nos jours peu de nouveautés, ce n’est plus vraiment très utile de faire ces mises à jour, et rester en LTS apporte la stabilité.

Debian a lui trois versions différentes : Stable, Testing et Unstable.

Unstable (appelée “sid”) : utilisée par les développeurs pour tester les nouvelles versions de logiciels. Réservée aux développeurs.
Testing : contient les paquets testés avec succès dans la version Unstable, mais pas encore validés dans la version stable (en attente de l’être). Nom de code “bookworm” (rat de bibliothèque) pour la future Debian 12.
Stable : C’est la version à utiliser en premier si l’on veut bénéficier de toute la stabilité et la sécurité du système Debian. Actuellement en version 11, nom de code “Bullseye” (traduction : “hublot” ou “dans le mille” ?).

J’ai finalement choisi la branche Testing, que l’on dit suffisamment stable pour un usage quotidien si l’on a quelques connaissances. Elle permet d’avoir des versions de logiciels plus récentes que la version Stable, comme par exemple la version 41 de Gnome.

Je devrais donc bénéficier de versions de logiciels plus récents que sur une LTS d’Ubuntu, avec potentiellement moins de stabilité (je prends le risque, à mon avis faible si je fais attention). Le cycle de mise à jour change aussi : quand “testing” est suffisamment mature, elle est progressivement “gelée”, jusqu’à devenir la nouvelle version “stable”. Il sera alors temps de passer sur la nouvelle version “testing” héritée de “unstable”.

Une autre différence majeure est que Debian n’intègre aucun pilote non-libre (propriétaire), contrairement à Ubuntu. On peut toujours en installer, mais c’est à faire soi-même à ses risques et périls (comme par exemple les pilotes Nvidia).

Pour l’instant, je suis très satisfait de cette version “bookworm”. L’installation proprement dite sera l’objet d’un futur article. On y verra que j’ai du m’y reprendre à deux fois, et qu’il ne faut pas faire n’importe quoi avec les pilotes non libres ! :cry:

Debian on Pascal's weblog

Le service libvirtd ne démarre plus

SVM dans le BIOS

Les logs

Gnome-weather et les petites villes

rEFInd, le multi boot facile

Les bases à connaître

UEFI vs BIOS

GPT

Boot loaders et Boot managers

Installation des deux OS

Disques et partitions

Gestionnaire de disques Windows

Gestionnaire de disque Gnome

Partitions EFI

rEFInd

Installation de rEFInd

Le PC de bureau

Dépannage Grub

Conclusion

Retrouver ses fenêtres Gnome au login

Gnome-tweaks

L’espace de travail

Smart Auto Move

Gnome Console

Conclusion

Pas d'icône dans le Dash de Gnome

Le fichier .desktop

Luminance pour régler la luminosité des écrans

Le DDC/CI

Installation

La fenêtre de KeepassXC sous Gnome Wayland

Première solution

Solution pérenne

Ventoy, la clef USB universelle

Installation

Plugins

VentoyPlugson plugin

Global Control Plugin

Persistence Plugin

Personnalisation

Menu Alias plugin

Image List plugin

Wimboot plugin

Secondary boot menu

Theme Plugin

Menu class Plugin

Séparateur de menu

Autres remarques

Clef USB

MedicatUSB

Mise à jour openmediavault v5 vers v7

Obsolescence

Suppression des mails

Mise à jour OMV6

Configuration

Le Kernel

Conclusion

Passage en Debian 13 (Trixie) et problème KVM (libvirt)

Problème

Réinstallation

Fichier default.xml

Première analyse

Dépannage

Solution

Conclusion

Dash to dock : problèmes et solutions

Problèmes rencontrés

Badge counter

Mauvais moniteur

Extension Dock from Dash

Forcer une ancienne version de Dash to Dock

Important

Prise en main d'Evolution

Les comptes

Dossiers par défaut

Dossiers unifiés

Faire suivre un mail

Sauvegarde

Mise en places des archives