Script d'information sur les fichiers contenu dans une arborescence :)

Et czkawka pour nettoyer l'espace disque.

Reprend l'ajout d'un Dropbear à l'initramfs et évoque également le fait de requêter un serveur d'identification.

Mais… il n'y a pas (encore ?) d'article détaillant la partie serveur :) À suivre donc.

Utilisé dans Ansible pour récupérer automatiquement l'UUID de la partition actuellement montée sur /boot :

  - name: '/boot'
    # Get UUID from device currently mounted to /boot
    src: "UUID={{ ansible_mounts | json_query('[?mount == `/boot`] | [0].uuid') }}"
    fstype: 'ext3'
    opts: 'defaults,ro,nodev,nosuid,noexec'

Afin de lui coller automatiquement quelques options lors d'une installation 👍 :)

objcopy below image base no efi bootable devices

Du jour au lendemain, l'UEFI qui veut plus démarrer mon système Debian…

Ma configuration :

• Un noyau unifié EFI - kernel efi stub;
• Plus de grub installé depuis 3~4 ans 👍

Problème :

• Au démarrage, peu importe l'entrée UEFI sélectionnée, le résultat restait : No bootable devices found…

Comportement attendu :

• Démarrage de Linux;
• Prompt pour entrer ma passphrase Luks;
• Fin du démarrage de Debian et atterrissage dans tty1 👍

Version courte

J'ai dû mettre à jour ma commande ''objcopy'' afin qu'elle tienne compte de "l'adresse" du fichier de base et par la même occasion de la taille des différentes sections ajoutées. Cette nouvelle commande fonctionne :

osrel_offs=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}')
cmdline_offs=$((osrel_offs + $(stat -Lc%s "/usr/lib/os-release")))
linux_offs=$((cmdline_offs + $(stat -Lc%s "/proc/cmdline")))
initrd_offs=$((linux_offs + $(stat -Lc%s "/boot/vmlinuz-6.3.0-1-amd64")))

objcopy \
        --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \
        --add-section .cmdline="/proc/cmdline" --change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \
        --add-section .linux="/boot/vmlinuz-6.3.0-1-amd64" --change-section-vma .linux=$(printf 0x%x $linux_offs) \
        --add-section .initrd="/boot/initrd.img-6.3.0-1-amd64" --change-section-vma .initrd=$(printf 0x%x $initrd_offs) \
        /usr/lib/systemd/boot/efi/linuxx64.efi.stub /boot/efi/EFI/debian/debian.6.3.0-1.efi

La dernière version de cette commande est présente dans mon script create-efi-kernel qui s'occupe également de "plein" d'autres trucs afin d'avoir automatiquement les noyaux unifiés à partir des noyaux Linux disponibles, d'ajouter les entrées efi correspondantes, nettoyées les anciennes,…

Version longue

Ma précédente commande avec des valeurs d'adresses fixes qui fonctionnait jusqu'à systemd ≤ 253 :

objcopy \
        --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=0x20000 \
        --add-section .cmdline="/proc/cmdline" --change-section-vma .cmdline=0x30000 \
        --add-section .linux="/boot/vmlinuz-6.3.0-1-amd64" --change-section-vma .linux=0x2000000 \
        --add-section .initrd="/boot/initrd.img-6.3.0-1-amd64" --change-section-vma .initrd=0x3000000 \
        /usr/lib/systemd/boot/efi/linuxx64.efi.stub /boot/efi/EFI/debian/debian.6.3.0-1.efi

Mais qui pose problème à partir de systemd 254, en m'indiquant des "erreurs" :

objcopy: /boot/efi/EFI/debian/debian.efi:.osrel: section below image base
objcopy: /boot/efi/EFI/debian/debian.efi:.cmdline: section below image base
objcopy: /boot/efi/EFI/debian/debian.efi:.linux: section below image base
objcopy: /boot/efi/EFI/debian/debian.efi:.initrd: section below image base

Ça tient plus du warning parce que la commande se termine correctement… (code retour = 0 🤦).
Et ça me donne un noyau "debian.efi" qui fait la même taille que d'habitude…

➡️ Je vais donc tenter de récupérer le fichier /usr/lib/systemd/boot/efi/linuxx64.efi.stub pour chaque version de systemd (celle qui fonctionnait et la nouvelle) pour comparaison + le détails du cheminement pour y arriver.

1. Vérifier le paquet qui contient le fichier recherché :

apt-file search /usr/lib/systemd/boot/efi/linuxx64.efi.stub
systemd: /usr/lib/systemd/boot/efi/linuxx64.efi.stub
systemd-boot-efi: /usr/lib/systemd/boot/efi/linuxx64.efi.stub

• ➡️ Dans les récentes versions de systemd, le "boot-efi" a été envoyé dans un paquet dédié, on va donc se focaliser sur systemd-boot-efi.

2. Vérifier les version de systemd-boot-efi disponible :

apt-cache policy systemd-boot-efi
systemd-boot-efi:
  Installed: 254~rc2-3
  Candidate: 254~rc2-3
  Version table:
 *** 254~rc2-3 500
        500 http://deb.debian.org/debian sid/main amd64 Packages
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     253.5-1 100
         -1 http://deb.debian.org/debian trixie/main amd64 Packages
…

• ➡️ La version actuellement installée, 254~rc2-3 c'est celle qui ne fonctionne pas. On va donc tenter de récupérer la version disponible dans Debian Trixie.

3. Télécharger la version 253 et extraire le fichier linuxx64.efi.stub de ce premier paquet :

aptitude download systemd-boot-efi=253.5-1
ar p systemd-boot-efi_253.5-1_amd64.deb data.tar.xz | tar xJ -C . --strip-components=6 ./usr/lib/systemd/boot/efi/linuxx64.efi.stub
mv linuxx64.efi.stub linuxx64.efi.stub.253

4. Idem pour la version 254 :

aptitude download systemd-boot-efi/unstable
ar p systemd-boot-efi_254\~rc2-3_amd64.deb data.tar.xz | tar xJ -C . --strip-components=6 ./usr/lib/systemd/boot/efi/linuxx64.efi.stub
mv linuxx64.efi.stub linuxx64.efi.stub.254

5. Et maintenant si je compare la "taille + offset" des deux fichiers linuxx64.efi.stub.253 et linuxx64.efi.stub.254 :

objdump -h "/tmp/linuxx64.efi.stub.253" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}'
 82187

objdump -h "/tmp/linuxx64.efi.stub.254" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}'
 5603209336

6. Ah bah oui… 😅 82187 vs 5603209336 ! Le message d'objcopy est donc cohérent.

En vrai, ci-dessus c'est quand même une version condensée/expliquée du problème… Le cheminement pour arriver jusque là a été un poil plus long et "stressant"…

1. Plusieurs passages en mode rescue.
2. La crainte d'un défaut de l'UEFI (on est pas à l'abri sur les Dell…).
3. Recherche de bug/documentation/… pas très fructueuse (une recherche "noyau unifié + debian" c'est pas la panacée, heureusement il y a ArchLinux et Gentoo).
4. Même le manuel Debian qui évoque un assemblage de ce type de noyau utilise potentiellement des valeurs d'adresses trop petites 😀
5. Vérification des derniers paquets mis à jour (en regardant la fin du fichier /var/log/apt/history.log).
6. Via le mode rescue, un petit downgrade de tous les récents paquets systemd qui ont été mis à jour et là j'arrive bien à générer des noyaux fonctionnels ! Début de piste…
7. Maintenant que j'ai accès à mon système la recherche d'info sur le net et les tentatives de génération de noyaux sont plus simples ! J'augmente au fur et à mesure la valeur de chaque adresse jusqu'à ne plus avoir ce warning. Oh "miracle", j'ai un noyau généré sans "erreurs" ! Je tente le boot et obtiens un message d'erreur différent "kernel not found". Ok, donc lien de cause à effet confirmé :)
8. Délivrance avec le wiki ArchLinux et la génération manuelle des noyaux unifiés qui calcule la taille de l'image et de chaque sections (la solution détaillée ci-dessus) 👌

Conséquences

1. J'ai perdu un peu de temps…
2. Les adresses utilisées par chaque section sont maintenant cohérentes et moins sujettes à problème 🤞
3. Je conserve maintenant quelques versions des noyaux unifiés précédents. Comme ça si les derniers plantent, je peux toujours m'ajouter manuellement une entrée EFI qui pointe vers un précédent noyau (théoriquement) fonctionnel et "retrouver" mon système ! 🤞🤞
4. TODO: Il faut que j'investigue sur Dracut et la possibilité d'avoir des noyaux signés et ainsi pouvoir activer le SecureBoot…
5. J'ai "appris" la possibilité d'ajouter un splash screen dans un noyau unifié. Bon par contre, c'est forcément en bmp (d'après le peu de tests que j'ai réalisé) donc ça alourdit quand même le noyau pour un intérêt limité… J'ai déjà pas de gestionnaire de session, alors le fait de voir un logo Debian pendant deux secondes au démarrage… ¯_(ツ)_/¯

• Installer ddcutil :
  sudo aptitude install ddcutil
• Charger le module i2c-dev :
  sudo modprobe i2c-dev
• Détecter les écrans :
  sudo ddcutil detect
• Lister les propriétés d'un écran :
  ddcutil capabilities | less
  ddcutil capabilities --bus XX | less
• Vérifier la source d'un écran :
  ddcutil getvcp 60
  VCP code 0x60 (Input Source ): DisplayPort-1 (sl=0x0f)
• Changer la source d'un écran (vérifier les valeurs possibles via la liste des "capabilities") : ❗
  ddcutil setvcp 60 0x11
  ddcutil setvcp --bus 10 60 0x0f
• Changer la luminosité d'un écran :
  ddcutil getvcp 10
  ddcutil setvcp 10 70
• … ~30 fonctionnalités sur mon écran actuel, dont :
  • Color temperature request
  • Brightness
  • Contrast
  • Input Source
  • Power mode
  • 😍

Sources :

• https://lord.re/posts/50-controller-ecran/
• https://sebsauvage.net/links/?Z-WRLA
• https://wiki.archlinux.org/title/Backlight#External_monitors

Plus qu'à scripter un peu ça. Et espérer que ça fonctionne également avec le vidéo proj 🤞

Liste des variables utilisables dans un unit systemd.

WIP

Vosk

• Les fichiers utilisés dans ce tuto : https://www.mediafire.com/folder/fl511k0sieq2e/Fichier+reco
• Les exemples d'utilisation du projet Vosk : https://github.com/alphacep/vosk-api/tree/master/python/example
• Les modèles de langues disponibles : https://alphacephei.com/vosk/models
• Doc d'installation : https://alphacephei.com/vosk/install
• Forum gladys 4 − reconnaissance vocale : https://community.gladysassistant.com/t/gladys-4-reconnaissance-vocale/5157/44?page=2

Kalliope

• Qui semble également très bien d'après la vidéo présente dans le README.md : https://github.com/kalliope-project/kalliope
• Sans réelles activités depuis ~1 ans 😥
• Évoqué ici : https://quotech-23.webself.net/blog/2020/04/24/kalliope-lassistant-vocal-sur-mesure
• Elle a même réussit à intégrer Vosk pour en faire un speech-to-text : https://quotech-23.webself.net/blog/2020/04/24/integration-de-vosk-a-kalliope
• Un des problèmes majeurs semble être l'arrêt du développement de Snowboy utilisé jusque là pour détecter le réveil… voir les tickets en lien avec ce trigger
• La vidéo donne envie… Mais ça semble particulièrement compliqué de mettre les mains dedans et en plus de réussir à en sortir quelques choses de fonctionnel… Avec Vosk, c'est relativement basique (pour le moment ?) et je bricole/apprends du Python ^^

Hassil

• https://github.com/home-assistant/hassil
• Assistant audio pour Home Assistant.
• Semble très orienté domotique et passablement compliqué à avoir en standalone.

Voice-assistant by hwpoison

• https://github.com/hwpoison/voice-assistant
• Assistant "basique" (>25 commits) mais bien plus évolué et propre que ce que je peux faire pour l'instant 😅
• Les commandes/actions/… sont à écrire dans un fichier .json (dommage ça n'autorise pas les commentaires…).
• Développé sous/pour Windows, mais ça s'adapte assez facilement (en modifiant le utils.py).
  • autoit pour remplacer Pyautoit ?
• Pensé pour le multi-langue 👍
• Ça ne correspond pas tout à fait à mon besoin mais c'est du Python avec plein de choses qui me manquent et qui pourraient donc me servir (liste des entrées/sorties, TTS, parsing d'un fichier de configuration, la façon de dev,…).

Rhasspy

• https://github.com/rhasspy/rhasspy
• Semblait un peu au point mort depuis septembre 2022.
• Mais home-assistant va visiblement tenter de l'intégrer à partir de 2023 dans sa solution logicielle : https://www.home-assistant.io/blog/2022/12/20/year-of-voice/
• À suivre.

Autres

• La liste des projets Github avec Vosk : https://github.com/topics/vosk?o=desc&s=updated

Le paquet systemd ne fournit visiblement plus le fichier linuxx64.efi.stub que j'utilise pour créer mes noyaux EFI Stub, c'est maintenant (depuis quand… ?) disponible dans le paquet systemd-boot-efi !

Ça a été l'occasion de réécrire quelques lignes sur comment refaire ses noyaux EFI Stub depuis le mode rescue 😅

Pour rappel, "EFI Stub" permet de créer des noyaux "complets" directement utilisables par UEFI, et donc, de se passer de Grub ! :)

Pour vérifier les versions disponibles sur son système :
strings /lib/x86_64-linux-gnu/libm.so.6 | grep GLIBC
…
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_PRIVATE

Si la version souhaitée n'est pas disponible, il y a plus qu'à mettre à jour son OS ou à installer la version souhaitée depuis : http://ftp.gnu.org/pub/gnu/glibc/

Comment contrôler MPV "à distance".

Parce que :

1. Je n'utilise que trop rarement un gestionnaire de fichier graphique.
2. C'est assez léger (~18 paquets supplémentaires pour ~31M d'espace disque).
3. Nemo précedemment installé nécessitait 67 paquets supplémentaires le tout pour ~85M d'espace disque en plus de venir avec plein de cochoneries (gvfs, udisks2,…).
4. Parce Alacritty, tmux, vim, mv, ls,… c'est quand même vachement plus adapté à mon usage :)

Ou comment passer d'un système Proxmox qui consomme ~980M de RAM à ~570M.

Quelques services "inutiles" dans la cas d'un serveur Proxmox isolé et/ou avec peu de ressources :

• pve-ha-crm : Proxmox-Cluster-Ressource-Manager
• pve-ha-lrm : Proxmox-Local-Ressource-Manager
• pve-firewall : Proxmox Firewall
• pvfw-logger : Proxmox Firewall Logger
• spiceproxy : Proxmox-Spice-VM-connection
• pvesr : Proxmox-Replication

Et pour arrêter tout ça :
sudo systemctl stop pve-ha-crm.service
sudo systemctl stop pve-ha-lrm.service
sudo systemctl stop pve-firewall.service
sudo systemctl stop pvfw-logger.service
sudo systemctl stop spiceproxy.service
sudo systemctl stop pvesr.service

Désactiver les units au niveau de systemd serait préférable, mais il y a beaucoup d'inter-dépendances avec les autres services Proxmox "utiles". Seul pvesr peut être désactivé sans trop foutre la merde…

Quick and dirty fix : Arrêter ces services quelques secondes après le démarrage du serveur… 👍

EDIT : Il vaut mieux éviter de couper pve-cluster 😅

Exemple d'erreur rsync obtenue récemment :
deflate on token returned 0 (1326 bytes left)
rsync error: error in rsync protocol data stream (code 12) at token.c(476) [sender=3.2.3]
rsync: connection unexpectedly closed (117 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [receiver=3.1.3]
rsync: connection unexpectedly closed (117 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [generator=3.1.3]
zsh: exit 12 rsync -avz --progress -e "ssh -p 22"

1. Vérifier le protocole de rsync sur chaque machine :
   rsync --version
   rsync version 3.1.3 protocol version 31
2. Si les protocoles diffèrent, utiliser le protocole le plus bas (option --protocol) :
   rsync --protocol=31 …
3. Vérifier les algorythmes de compression supportés (si listés avec --version), sinon simplement désactiver la compression (option --compress ou -z).
4. Si ça démarre, essayer avec l'ancienne compression (option --old-compress) :
   rsync --old-compress

Avec la "récente" faille log4Shell il est maintenant demandé de filtrer tout le contenu des serveurs.

1. Proxy sortant au niveau du système, via /etc/profile :

   MY_PROXY_URL=http://proxy.tld:PORT
   HTTP_PROXY=$MY_PROXY_URL
   HTTPS_PROXY=$MY_PROXY_URL
   FTP_PROXY=$MY_PROXY_URL
   http_proxy=$MY_PROXY_URL
   https_proxy=$MY_PROXY_URL
   ftp_proxy=$MY_PROXY_URL
   export MY_PROXY_URL HTTP_PROXY HTTPS_PROXY FTP_PROXY http_proxy https_proxy ftp_proxy

2. Pour APT, via /etc/apt/apt.conf.d/proxy.conf :

   Acquire {
   HTTP::proxy "http://proxy.tld:PORT";
   HTTPS::proxy "http://proxy.tld:PORT";
   }

3. Pour YUM, via /etc/yum.conf :
   proxy=http://proxy.tld:PORT

4. Pour les services systemd via :

   systemctl edit my-service

   [Service]
   Environment="HTTP_PROXY=http://proxy.tld:PORT/"
   Environment="HTTPS_PROXY=http://proxy.tld:PORT/"

   systemctl restart my-service

Impossible d'envoyer des données (et donc de partager un torrent) depuis transmission à cause de cette satanée erreur !

Possiblement lié à une "amélioration" de youteub : https://blog.youtube/inside-youtube/new-era-video-infrastructure/

MPV

1. Issues sur le dépôt du projet :
   • mpv slow download speed? − https://github.com/mpv-player/mpv/issues/8655
   • youtube-dl is dead, add yt-dlp as default − https://github.com/mpv-player/mpv/issues/9208

2. Fix :

   • Installer yt-dlp : sudo aptitude install yt-dlp
   • Tester en utilisant l'option --script-opts=ytdl_hook-ytdl_path=yt-dlp mpv : `mpv --script-opts=ytdl_hook-ytdl_path=yt-dlp "YT_URL"
   • Si c'est bon, créer un fichier de configuration pour MVP (~/.config/mpv/mpv.conf) et ajouter :

   script-opts=ytdl_hook-ytdl_path=yt-dlp

Youtube-dl

1. Issues sur le dépôt du projet :
   • [YouTube] Randomly slow youtube download speed − https://github.com/ytdl-org/youtube-dl/issues/29326
   • My downloadspeed of my Youtube Downloads are being reduced/limited. What is the Problem? − https://github.com/ytdl-org/youtube-dl/issues/29361
2. Fix :
   • Idem, installer et passer à yt-dlp… : sudo aptitude install yt-dlp
   • Je ne sais pas encore si ça fait tout "aussi bien/pareil", mais au moins ça permet de lire les vidéos YouTube… 👍
   • Ajouter un alias youtube-dl="yt-dlp" ?

Kodi

1. Issues avec l'extension YouTube pour Kodi (plugin.video.youtube) :
   • Buffering when playing − https://github.com/anxdpanic/plugin.video.youtube/issues/211
2. Fix :
   • Le problème semble résolut à partir de la version 6.8.18.alpha3. Mais ça nécessite quand même encore quelques tests pour éviter des régressions ou autres pertes de fonctionnalités…

Bon… tout n'est pas résolut mais ça progresse.

Réaliser pour corriger une limitation lorsque Grub est installé directement sur un LVM, j'ai dû diviser la première partition de mon disque en deux plus petites puis ré-ordonner les partitions.

Tout ça s'est magnifiquement bien déroulé… "troublant" :)

Et ddclient est toujours vivant :) Pfiu, ~7 ans depuis la dernière utilisation. Mais bon, tant que des FAI fourniront un service "passable"… (ip non fixe, box,…).

Et en bonus ça fonctionne bien avec une petite commande dig :

# /etc/ddclient.conf

daemon=2
protocol=dyndns2

use=cmd,cmd="dig +short myip.opendns.com @resolver1.opendns.com"

server=www.ovh.com
login=identifiant DynHost OVH
password=mot de passe lié à l'identifiant DynHost
sous-domaine.domain.tld

Changement de serveur DNS @home et les conteneurs Docker n'arrivaient plus à accéder à internet.

Dans les conteneurs, le fichier /etc/resolv.conf contenait effectivement les informations liées au précédent serveur DNS (IP,…).

Pour corriger ça, éditer le fichier /etc/docker/daemon.json sur l'hôte et redémarrer pour vérifier que tout fonctionne correctement.