Linux Mint : Installation avec BTRFS + Chiffrement Disque

Cet article décrit la procédure pour installer Linux Mint avec un système de fichier BTRFS (permettant notamment de bénéficier de « snapshots » offrants une possibilité de restaurer le système à un état antérieur en cas de problème), tout en activant le chiffrement complet du disque dur.

L’installation débute comme une installation standard, puis :

1. A l’écran « Type d’installation« , choisir « Autre chose » :

2. Si nécessaire, créer une table de partition en cliquant sur le bouton « Nouvelle table de partition ». Attention, cette opération détruira la table de partition courante, et provoquera la perte des partitions actuellement sur le disque !

3. Créer une partition de type « Partition Système EFI », de taille 1024 Mo (c’est un peu excessif, mais cela évite de devoir la redimensionner plus tard). Pour cela, sélectionner l' »espace libre » en fin de disque, et cliquer sur le bouton « + ».

4. Créer une partition de type « Système de fichier ext2 », avec point de montage « /boot« , également de taille 1024 Mo.

5. Créer une partition de type « volume physique pour le chiffrement », occupant tout l’espace restant. Saisir la clé de sécurité qui sera demandée au démarrage de l’ordinateur pour déchiffrer le disque dur.

6. Un disque virtuel, contenant une seule partition de type ext4 , apparait alors, sous le nom /dev/mapper/xxx_crypt.

7. Choisir Btrfs comme système de fichier à la place de ext4, avec le point de montage « / ». Pour cela, sélectionner la partition, puis cliquer sur le bouton « modifier ».

8. Les différentes partition de votre système doivent correspondre à la capture d’écran ci-dessous. Cliquer alors sur « installer maintenant », et procéder à la suite de l’installation. Dans le cas d’une erreur, il est plus sage de redémarrer et de recommencer l’installation, l’installateur pouvant avoir un comportement erratique si l’on recommence l’installation après avoir déjà créé une partition chiffrée.

9. C’est terminé ! A chaque démarrage, l’écran suivant demandera le mot de passe permettant le déchiffrement du disque dur :

Cette procédure laisse par contre l’utilisateur sans espace d’échange (swap) configuré. Je n’ai pas encore expérimenté sur le sujet, mais la mise en place d’un fichier de swap (swapfile) sur une partition btrfs est assez bien documentée ( par exemple, ou encore ) , je me pencherai sans doute dessus à l’avenir.

Compiler Marlin en ligne de commande

Cet article résume le process nécessaire pour compiler Marlin en ligne de commande sous Linux avec PlatformIO Core.

1. Installer PlatformIO Core.

2. Ajouter PlatformIO au PATH local :

export PATH=$PATH:~/.platformio/penv/bin

3. Récupérer le code source de Marlin.

4. Si on récupère le code source officiel (et pas une version déjà customisée pour une machine spécifique ), récupérer les fichiers de configuration dans le dépot git MarlinFirmware/Configurations, et copier les fichiers de configuration adéquat dans le dossier Marlin / Marlin /

5. Se placer dans le dossier Marlin ( contenant platformio.ini ).

6. Identifier la valeur de MOTHERBOARD, en gras dans l’exemple ci dessous, à partir du fichier Configuration.h. ( pour une carte BTT SKR E3 MINI V2.0 )

$ cat Marlin/Configuration.h | grep MOTHERBOARD
#ifndef MOTHERBOARD
#define MOTHERBOARD BOARD_BTT_SKR_MINI_E3_V2_0
If not defined the default pin for the selected MOTHERBOAR

7. Identifier les environnements PlatformIO compatibles à partir du fichier pins.h ( attention à supprimer le BOARD dans la valeur de MOTHERBOARD ):

$ cat Marlin/src/pins/pins.h | grep BTT_SKR_MINI_E3_V2_0
elif MB(BTT_SKR_MINI_E3_V2_0)
#include "stm32f1/pins_BTT_SKR_MINI_E3_V2_0.h" // STM32F1
env:STM32F103RC_btt env:STM32F103RC_btt_512K
env:STM32F103RC_btt_USB env:STM32F103RC_btt_512K_USB

8. Compiler avec l’environnement adapté ( dans mon cas gestion de l’USB mais pas 512K de ROM ) :

$ platformio run -e STM32F103RC_btt_USB

9. Récupérer le fichier firmware.bin à l’emplacement suivant :

.pio/build/STM32F103RC_btt_USB/firmware.bin

10. Le copier sur une carte SD ( sans altérer son nom ), et la mise à jour s’effectue à la mise sous tension de l’imprimante. Le fichier sera alors renommé en FIRMWARE (sans extension).

11. Si présence d’un fichier EEPROM.DAT sur la carte SD lors de la mise à jour firmware, le contenu de l’EEPROM (calibration, réglages) sera écrasé.

ABetterXinputCalibrator : un outil pour faciliter la calibration d’écran tactiles sous X11

Il s’agit d’un petit logiciel que j’ai développé sous Qt, facilitant la calibration d’un écran tactile / tablette graphique, notamment quand l’écran en question est un écran secondaire

Screenshot :

https://gitlab.com/Pilatomic/abetterxinputcalibrator/-/raw/master/doc/Screenshot.png

Dépot gitlab :

https://gitlab.com/Pilatomic/abetterxinputcalibrator

MacPro 1,1 : Optimiser le refroidissement d’un GPU AMD sous Linux

Sur ces machines, la ventilation est réalisée en 3 canaux séparés

  • Canal 1 : CPU & RAM : 2 ventilateurs, 1 en façade et 1 à l’arrière en extraction, dont la vitesse est régulée en fonction de la température CPU
  • Canal 2 : GPU et cartes d’extensions : 1 ventilateur en façade
  • Canal 3 : Alimentation & lecteurs optiques.

Sur mon système, si les canaux 1 et 3 sont gérés correctement par le SMC ( le chip chargé de la gestion du système ), le ventilateur du canal 2 a sa vitesse fixe à 500 tr/min. J’imagine que la cause est à trouver dans mon utilisation peut habituelle de cette machine : un GPU non officiel (AMD R9 380) sous un OS non officiel (Linux).

Pour pallier à ce problème, et effectivement piloter ce ventilateur en fonction de la demande en refroidissement du GPU, j’ai écrit un script bash, qui contrôle ce ventilateur en fonction de la commande PWM du ventilateur du GPU ( attention, à ma connaissance cette information n’est disponible que sur le pilote graphique libre AMD ) :

$ cat /opt/IO_fan_control.sh
#!/bin/bash

BASE_FAN="/sys/devices/platform/applesmc.768/fan2"
GPU_PWM_FILE="/sys/class/drm/card0/device/hwmon/hwmon0/pwm1"
GPU_PWM_MIN=75
GPU_PWM_MAX=250

function setfancontrolmanual()
{
        echo $1 > $BASE_FAN"_manual"
        if (( $? == 0 ))
        then
                if (( $1 == 0 ))
        then
                        echo "Returning fan control to SMC"
                else
                        echo "Taking control of fan from SMC"
                fi
        else
                if (( $1 == 0 ))
        then
                        echo "Failed to return fan control to SMC"
                        exit 1
                else
                        echo "Failed to take control of fan from SMC"
                        exit 1
                fi
        fi
}

function abort()
{
        setfancontrolmanual 0
        exit
}

function checkforroot()
{
        if(( $(id -u)  != 0 ));
        then
                echo "Need to be run as root";
                exit
        fi
}

checkforroot
if [ "$1" == "release" ]; then
        setfancontrolmanual 0
        exit
fi

trap abort SIGINT
setfancontrolmanual 1

while true
do
        INPUT_RPM=$(<$BASE_FAN'_input')
        MAX_RPM=$(<$BASE_FAN'_max')
        MIN_RPM=$(<$BASE_FAN'_min')
        GPU_PWM=$(<$GPU_PWM_FILE)

        #compute MAC fan RPM from GPU fan PWM
        if (( $GPU_PWM >= $GPU_PWM_MAX )); then
                TARGET_RPM=$MAX_RPM
        elif (( $GPU_PWM <= $GPU_PWM_MIN )); then
                TARGET_RPM=$MIN_RPM
        else
                TARGET_RPM=$(( ($MAX_RPM - $MIN_RPM) * ( $GPU_PWM - $GPU_PWM_MIN ) / ($GPU_PWM_MAX - $GPU_PWM_MIN) + $MIN_RPM))
        fi

        #clamp value between MIN_RPM and MAX_RPM
        if (( $TARGET_RPM < $MIN_RPM )); then
                OUTPUT_RPM=$MIN_RPM
        elif (( $TARGET_RPM > $MAX_RPM )); then
                OUTPUT_RPM=$MAX_RPM
        else
                OUTPUT_RPM=$TARGET_RPM
        fi

        echo $OUTPUT_RPM > $BASE_FAN'_output'

        echo 'INPUT_RPM: '$INPUT_RPM' MAX_RPM: '$MAX_RPM' MIN_RPM: '$MIN_RPM' GPU_PWM: '$GPU_PWM' TARGET_RPM: '$TARGET_RPM' OUTPUT_RPM: '$OUTPUT_RPM

        sleep 2
done

Les variables GPU_PWM_MIN et GPU_PWM_MAX correspondent respectivement aux 2 valeur PWM à laquelle le ventilateur du canal 2 sera commandé à sa vitesse minimum, et celle où il sera commandé à sa vitesse maximum.

Ce script est exécuté automatiquement au démarrage grâce à systemd

$ cat /etc/systemd/system/system_mac-io-fan-control.service
[Unit]
Description=MacPro IO fan control from GPU temperature
After=systemd-udevd.service

[Service]
ExecStart=/opt/IO_fan_control.sh
Restart=always
StartLimitIntervalSec=10
ExecStopPost=/opt/IO_fan_control.sh release

[Install]
WantedBy=multi-user.target

Il ne reste plus qu’à activer l’unité systemd créé :

$ sudo systemctl enable system_mac-io-fan-control.service
$ sudo systemctl start system_mac-io-fan-control.service

La vitesse du ventilateur du canal 2 est maintenant asservie à celle du GPU, facilitant le refroidissement de ce dernier, et réduisant le niveau sonore de la machine.

MacPro 1,1 : Linux trucs & astuces

Installation réalisée sous Linux Mint 20 avec un kernel 5.4

Boot avec PlopKexec.

Une distro 64bit fonctionne parfaitement. Se référer à mon précédent article https://pila.fr/wordpress/?p=1078

Obtenir un affichage avec un GPU AMD

Les cartes graphiques AMD exploitant le nouveau code d’affichage « DC » provoquent un kernel panic. Il faut ajouter la commande suivante dans le fichier /etc/default/grub pour utiliser l’ancian code :

amdgpu.dc = 0

Ne pas oublier d’appliquer les changements :

$ sudo update-grub 

Bâillonner l’interruption gpe11

Sur cette machine, le taux d’occupation CPU restait important même au repos. Il s’avère que l’IRQ 9 est déclenchée à une fréquence très élevée (indiqué par le compteur du fichier /proc/interrupts), et monopolise à elle seule un des coeurs CPU. Les compteurs lisibles dans les différents fichiers à l’emplacement /sys/firmware/acpi/interrupts nous permettent de déterminer la source de cette IRQ : gpe11. Un service systemd nous permet de la désactiver, en créant le fichier /etc/systemd/system/disableGPE11.service avec le contenu suivant :

[Unit]
Description=Disables GPE 11 going crazy on this MacPro
[Service]
ExecStart=/bin/bash -c 'echo "disable" > /sys/firmware/acpi/interrupts/gpe11'
[Install]
WantedBy=multi-user.target

Ce service est rendu actif par la commande suivante :

$ sudo systemctl enable disableGPE11.service


Développer sur STM32 avec stm32plus, OpenOCD et QtCreator

Cet article décrit très rapidement la procédure que j’ai suivie ( durant de nombreuses heures de tatonnements ) afin de mettre en place sous Linux Mint un environnement de développement pour stm32f042 basé sur QtCreator, stm32plus et OpenOCD, permettant de s’affranchir des logiciels ST.

Installation de la bibliothèque stm32plus

Cloner le dépot git situé à l’URL suivante :

https://github.com/andysworkshop/stm32plus

Installer les dépendances nécessaires :

$ apt install libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib scons gdb-multiarch cmake

Compiler la bibliothèque stm32plus : Exécuter la commande suivante dans le dossier stm32plus en modifiant si nécessaire le type de MCU, le mode ( fast, small ou debug ) ainsi qu’en précisant la fréquence en Hz de l’oscillateur interne ou externe utilisé (paramètre hsi ou hse)

$ scons mode=debug mcu=f042 hsi=8000000 -j4

Installer la bibliothèque compilée :

$ sudo scons mode=debug mcu=f042 hsi=8000000 -j4 install

Corriger les problèmes de stm32plus avec CMake :
Dans le dossier /usr/local/arm-none-eabi/lib/stm32plus-040100
Pour éviter un problème de fichier non trouvé, éditer le contenu du fichier stm32plus-config.cmake pour ne conserver que les 2 premières lignes ( copiées ci dessous )

include(${CMAKE_CURRENT_LIST_DIR}/stm32plus-config-${STM32PLUS_CONFIGURATION}i.cmake
OPTIONAL RESULT_VARIABLE STM32PLUS_CONFIG_FILE)

Modifier le fichier stm32plus-config-debug-f042-8000000i.cmake ( modification à répéter pour chaque version de stm32plus compilée ) : ajouter --specs=nosys.specs aux variables CMAKE_C_FLAGS et CMAKE_CXX_FLAGS.

Répéter éventuellement avec les autres modes pour disposer de la bibliothèque compilée pour chaque mode

Configuration générale de QtCreator

Récupérer l’exemple de compilation avec CMake fourni avec stm32plus dans le dossier stm32plus/cmake/example

Activer le plugin Bare Metal

Dans QtCreator : Aide -> Plugins, activer « BareMetal », et redémarrer QtCreator

Ajouter OpenOCD

Dans les options de QtCreator, catégorie « Appareils Mobiles », onglet « Bare Metal », cliquer « Add » et sélectionner « OpenOCD », remplir ainsi :
Name : OpenOCD for STM32F042
Startup mode : Pipe mode
Executable file : openocd
Root script directory : /usr/share/openocd/scripts
Configuration file : /usr/share/openocd/scripts/board/st_nucleo_f0.cfg

Puis cliquer sur Appliquer

Ajouter le périphérique STM32F042

Dans les options de QtCreator, catégorie « Appareils Mobiles », onglet « Périphériques », cliquer « Ajouter » et sélectionner « Bare Metal Device », remplir ainsi :

Nom : STM32F042
GDB Service Provider : OpenOCD for STM32F042

Cliquer sur appliquer

Ajouter le debugger GDB-Multiarch

Dans les options de QtCreator, catégorie « Kits », Onglet « Debugger », cliquer sur « Add » et remplir les champs suivants :

Name : GDB Multiarch
Path : /usr/bin/gdb-multiarch

Cliquer sur Appliquer

Ajouter un Kit

Dans les options de QtCreator, catégorie « Kits », Onglet « Kits », cliquer sur « Ajouter » et remplir les champs suivants :
Nom : STM32F042
Device type : Bare Metal Device
Device : STM32F042
Compiler C : GCC (C, arm 32 bits in /usr/bin)
Compiler C++ : GCC (C++, arm 32 bits in /usr/bin)
Debugger : GDB Multiarch
Qt Version : None
Cmake tool : System CMake at /usb/bin/cmake
CMake Configuration : cliquer sur « change », puis supprimer la ligne commençant par CMAKE_PREFIX_PATH

Cliquer sur appliquer

Configuration d’un projet QtCreator

Se rendre dans le dossier où l’on a précédemment copié l’exemple CMake fourni avec stm32plus

Ouvrir le fichier CMakeList.txt avec QtCreator, et sélectionner le kit STM32 précédemment créé.

Editer le fichier CMakeList.txt pour refléter le MCU utilisé ainsi que le mode ( fast, small ou debug ) de compilation de stm32plus à utiliser. Spécifier aussi la fréquence de l’oscillateur, suivi de la lettre i ou e pour un oscillateur interne ou externe.

Dans mon cas, ce dossier était inexistant, j’ai copié le dossier system depuis l’example Blink ( sans CMake ), dans lequel j’ai renommé le dossier f042_48_8 en f042.

Renommer le fichier system/f042/startup.asm en system/f042/startup.s. Modifier le fichier CMakeList.txt pour refléter ce changement.

Dans la catégorie « Projet », sélectionner la variable CMAKE_PREFIX_PATH, et cliquer sur « unset », puis « Apply configuration change ». La variable doit se remplir avec le contenu suivant :

/usr/local/arm-none-eabi;/usr/arm-none-eabi

Dans QtCreator, Menu « Compiler », cliquer sur « Executer CMake ».

Il est maintenant (enfin) possible de compiler et de débugger le projet 🙂

Développer sur PSP en 2020

En 2004, Sony commercialisait la PSP, une console de jeu portable qui, pour un tarif d’environ 200€, possédait des capacités de traitements ( graphiques notamment ) bien supérieures à celles de la concurrence.

Aujourd’hui, il est possible de s’en offrir une d’occasion en déboursant moins de 50€. J’ai donc décidé de m’y intéresser, non pas en temps que console de jeu, mais comme plateforme de développement.

Les sécurités de la console ayant été contournée assez rapidement, la scène du développement amateur a produit de nombreux Homebrew, ainsi que les outils permettant de développer sur la console sans acheter le ( très onéreux ) SDK officiel.

Cet article a pour vocation de résumer mon parcours quant à l’installation logicielle nécessaire.

Lire la suite

ESP32 : Un script bash pour paramétrer les variables d’environnement

Attention : valable uniquement pour les versions de ESP-IDF non basées sur CMAKE ( versions < 4.0 )

Travaillant actuellement sur un projet nécessitant une interface audio en bluetooth, je me suis tourné vers la solution la plus en vogue, l’ESP32.

Embarquant Wifi, Bluetooth (dont BLE), un CPU dual core avec 4 Mo de Flash, mais également très abordable, il dispose également d’un SDK entièrement open-source, très bien documenté !

La procédure d’installation de ce SDK nécessitant de modifier certaines variables d’environnement ( en particulier la variable PATH ), et n’aimant pas modifier des éléments aussi critiques du système ( il est possible en modifier de PATH de remplacer certaines commandes du système à l’insu de l’utilisateur ! ), j’ai donc, avant toute expérimentation avec l’ESP32, pris le temps d’écrire un petit script bash.

Ce script permet de démarrer un nouvel interpréteur BASH contenant les variables d’environnements permettant le bon fonctionnement du SDK ESP32, sans affecter les variables d’environnement utilisées par tous les autres terminaux du système. De plus, il possède un prompt de commande personnalisé, afin de distinguer rapidement le terminal utilisé pour le SDK.

Son contenu, succin, est le suivant :

!/bin/bash
bash --rcfile <(cat ~/.bashrc; echo 'PS1="\e[33;1mesp32 \$\e[0m "' ; echo 'export PATH="$HOME/esp32/xtensa-esp32-elf/bin:$PATH"' ; echo 'export IDF_PATH="$HOME/esp32/esp-idf"')

Attention : il est supposé que l’ensemble des fichiers nécessaires au SDK se trouvent dans le dossier ~/esp32. Si ce n’est pas le cas, modifier les chemins en conséquence

Il suffit d’exécuter le script pour obtenir un interpréteur BASH adéquat, et de quitter l’interpréteur (commande »exit », ou CTRL+D) pour revenir à un terminal normal.

J’ai testé son fonctionnement quelques heures, et en suis tout à fait satisfait. N’hésitez pas à me communiquer tout bug, ou amélioration possible !

Acer SW5-011 : Installer Ubuntu

Préparation d’une clé USB bootable

Bien qu’étant un système 64 bits, la tablette est dotée d’un firmware UEFI en 32 bits, non supporté par la plupart des ISOs Linux standard. Pour créer une clé USB bootable sur cette tablette, procéder comme suit :

Depuis une autre machine sous Linux, récupérer une image ISO 64 bits de la distribution souhaitée. Dans mon cas, il s’agit d’une Ubuntu 19.04, pour sa facilité d’utilisation avec un écran tactile, et la présence par défaut d’un noyau récent prenant en charge le matériel de la tablette ( en particulier la carte Wifi interfacée en SDIO, qui pose des problèmes avec des noyaux plus anciens ).

Insérer la clé USB qui recevra l’image ISO. Utiliser dmesg pour identifier son nom de périphérique. Ici je la nommerai /dev/sdX où X est à remplacer par la lettre adaptée à votre cas. La formater et y créer une partition de type EFI, qu’on montera dans le répertoire /mnt, grâce aux commandes suivantes :

$ sudo sgdisk --zap-all /dev/sdX
$ sudo sgdisk --new=1:0:0 --typecode=1:ef00 /dev/sdX
$ sudo mount -t vfat /dev/sdc1 /mnt

Y extraire le contenu de l »image ISO Linux téléchargée :

$ sudo 7z x /home/pila/Téléchargements/ubuntu-19.04-desktop-amd64.iso -o/mnt/

Récupérer le fichier bootia32.efi à l’URL suivante : https://github.com/jfwells/linux-asus-t100ta/blob/master/boot/bootia32.efi
Il s’agit d’un grub compilé pour EFI 32 bits, que l’on va maintenant copier dans le dossier EFI de la clé USB :

$ sudo cp Téléchargements/bootia32.efi /mnt/EFI/boot

La clé USB est maintenant prête, il ne reste plus qu’à la démonter proprement :

$ sudo umount /mnt

sources :
http://www.cedric-augustin.eu/index.php?post/2015/08/24/Installer-Ubuntu-1504-sur-un-Acer-Aspire-switch-10

Machine a pince EXPENDEDORA « A-BIFUCA » : Configuration et mod

Ayant été confronté à la configuration de cette machine à pince, et devant le peu de documentation disponible sur le web, j’ai décidé de rédiger ce bref article regroupant mon expérience avec cette machine

source : http://www.mapefe.com/gruas.html
Lire la suite