J’ai configuré un serveur de VPN Wireguard sur mon Odroid M1 (alternative du Raspberry Pi). Cela me permet me connecter à Internet avec mon téléphone de manière sécurisée et confidentielle quand je suis sur un Wi-Fi auquel je n’ai pas confiance. Voici la configuration (j’espère ne pas avoir oublié d’étape).
Continuer la lecture(mise à jour: j’ai acheté un Odroid M1 pour des raisons de disponibilité)
Mon vieux Odroid X2 (un mini-ordi ARM de 9×9.5cm) de 2013 vient de tomber en panne. Pour le remplacer, je vois 3 options: un Raspberry Pi 4, un Odroid M1 ou un Odroid N2+. Je vais prendre le Raspberry (à la fin de la pénurie), parce que par le passé mon Odroid a fini par ne plus être supporté et je ne pouvais plus mettre à jour le système à jour, ce qui me laissait avec des vulnérabilités de sécurité et des vieux logiciels très durs à mettre à jour si eux et leurs dépendances ne sont pas déjà préparés par quelqu’un.
Sur Kubuntu 22.04, j’ai fait la malheureuse expérience de perdre plusieurs semaines de mon profil Firefox en réinstallant la version snap (maintenant par défaut dans Kubuntu, plutôt qu’une version apt/deb). C’est la première fois que je vois une désinstallation et/ou installation d’une application Linux modifier (et en l’occurrence supprimer) des données situées dans le profil de l’utilisateur. Une première affligeante. Jusqu’à présent, les données utilisateurs vivaient leur propre vie dans /home, et on pouvait réinstaller le système ou en changer tout en gardant ses données.
Comment en suis-je arrivé là?
Il était temps de passer ma Kubuntu 20.10 à une version plus récente, étant donné qu’il y a une faille d’élévation de privilège dans polkit/pkexec (CVE-2021-4034) et qu’il n’y a plus de patch pour Kubuntu 20.10 (plus supporté). Et là j’ai découvert que ce n’était plus possible officiellement de passer de Kubuntu 20.10 (groovy) à 21.10 (impish) même indirectement (via la 21.04), sauf à tenter de mettre à jour tous les paquets (pas sûr que ça marche). Donc je suis parti pour une réinstallation.
Continuer la lecturePour le moment, un seul problème: pas de sortie don détectée. Solution: désinstaller « pipewire » (un système de son qui interfère avec pulseaudio). Autre solution temporaire: « pulseaudio –kill » redétecte les périphériques immédiatement.
En faisant joujou avec la distribution Linux GNU Guix (Wikipédia) dans une VM, j’ai voulu utiliser le système de fichiers Btrfs, afin de pouvoir faire des instantanés (snapshots) entre deux essais. Mais cela a demandé un peu de travail.
Continuer la lectureUne des mises à jour les plus problématiques depuis longtemps:
Point positif: disparition du délai de 30 secondes à chaque démarrage si /usr se trouve dans un LVM.
Nouvelle mise à jour de Kubuntu, nouveaux petits problèmes. Au moment de jouer un son et également 6 secondes après, un gros bruit de craquement se fait entendre. Ce qui rend fou si les sons sont brefs. Avant je ne l’avais qu’à l’extinction de la machine.
Dans le fichier « /etc/pulse/default.pa », commenter la ligne suivante en mettant un dièse devant:
load-module module-suspend-on-idle
Ensuite vous pouvez tuer pulseaudio avec « killall pulseaudio », il sera redémarré au prochain son voire immédiatement. Vous pourrez immédiatement constater si cela a marché ou pas.
Cela évite que le périphérique audio soit suspendu quand il n’est plus utilisé. Hypothèse: peut-être que c’est utile sur un portable pour lequel on veut économiser la batterie… En tous cas ce n’est pas techniquement une bonne solution. Il faudrait plutôt chercher au niveau du gestionnaire du périphérique audio (un intégré Realtek dans mon cas).
Certains ont proposé de configurer la ligne suivante, ce qui a été sans effet pour mon cas:
load-module module-hal-detect tsched=0
À part ce problème de LVM que j’ai relaté ici en anglais (un volume logique vide empêchait le démarrage), le reste de la mise à jour s’est bien passé. Et les notifications de calendrier de KDE marchent à nouveau.
After the update from Kubuntu 17.04 to 18.04 and a reboot, my system refused to boot and only gave me « emergency mode ». Long story short: for an unknown reason I had an empty volume « pvmove0 » that the new version did not like, and after removing it it worked.
I had a look at the system journal with this command (the LANG is to have all messages in English, which is easier to find on the net than French):
LANG="en_GB.UTF-8" journalctl -xb
I had lines like that:
May 04 20:46:05 mymachine lvm[415]: LV pvmove0: has no segment. May 04 20:46:05 mymachine lvm[415]: Couldn't read all logical volumes for volume group fablvm.
Also, most of the LVM commands could not read the Physical Volume (PV) and the Logical Volumes (LV) on this disk: they told me that the physical volumes did not belong to a Volume Group and they had no size.
As Kubuntu 17.10 (on an USB stick) could still read all my PV and LV, I had the idea to backup the Volume Group metadata in Kubuntu 17.10 and restore it from Kubuntu 18.04.
vgcfgbackup -f path/to/my/backup.vg my_vg
Then I looked at the backup file and (holy cow!) I saw that I had an empty Logical Volume called « pvmove0« .
pvmove0 {
id = "Jp8y0E-RYIU-g4s0-PdUs-LEdo-N110-MLBwmQ"
status = ["READ", "WRITE", "PVMOVE", "LOCKED"]
flags = []
allocation_policy = "contiguous"
segment_count = 0
}
I searched on the net « pvmove0 » and found that someone had the same problem and remove it by:
Apparently, having such an empty logical volume breaks things at several levels (among others, the graphical tool system-config-lvm would not start).