@chronophonix oui et c’est vrai, c’est pourquoi j’ai branché un SSD via usb3 sur mon rpi4 
Mais je ne me suis pas pris la tête, j’ai gardé la carte sd pour l’OS. Puis j’ai créé un lien symbolique pour que mon ~/.config pointe sur le ssd, comme ça mes applications écrivent sur le ssd
Je t’invite a faire de même, je ne voit pas l’intérêt a essayer de booter directement sur le SSD, c’est bien compliqué pour un apport quasi nul.
Ah, ben c’est une bonne nouvelle ça ! Tu peux me donner la marche à suivre pour créer ce lien symbolique et faire en sorte que les opérations de lecture/écriture se passent sur le SSD ? En plus, c’était une idée qui m’avait traversé la tête… 
Créer un lien symbolique : ln -s path_cible path_source
Donc par exemple si tu monte ton ssd sur /mnt/mon_ssd :
ln -s /mnt/mon_ssd/duniter .config/duniter
Je suppose qu’il me faut dupliquer le dossier duniter qui se trouve dans .config sur le ssd ? A moins que l’instruction en ligne de commande ne suffise à faire tout ça…
J’imagine aussi que je peux réitérer cette procédure pour d’autres applications ?
Je suis plutôt débutant concernant les systèmes linux, je découvre petit à petit comment ça fonctionne… 
Bien sur qu’il te faut d’abord le copier sur le ssd, dsl pour moi c’était trop évident pour le préciser 
oui
Lol ! Dans mon activité de musicien (et de prof de musique), il m’arrive souvent, à moi aussi, d’omettre certaines informations tant elles me paraissent évidentes, alors qu’elles ne le sont pas du tout pour mon interlocuteur… 
Bon, l’image jointe en dira plus long que des explications. Devant l’impossibilité de renommer mon ssd, j’ai donc entré ceci : ln -s /media/pi/USB STICK/duniter .config/duniter
L’instruction a été acceptée, j’ai donc à présent deux liens symboliques, est-ce que ça va fonctionner ? Je remet le rpi en service demain soir…
Note : le ssd est un western digital, série green, 120 go, monté dans un stick adwits.
(J’avais tout d’abord tenté d’écrire la ligne d’instruction suivante :
ln -s /media/pi/USB_STICK/duniter .config/duniter, mais ça ne marche pas !)
@chronophonix c’est parce que la création du lien symbolique (commande ln -s cible source) nécessite que la source n’existe pas a la crétion.
Il te faut donc au préalable supprimer le dossier ~/.config/duniter (ou le déplacer).
Les données de ton noeud se trouve dans le dossier duniter_default (a dépalcer sur ton ssd donc).
cd ~/.config/duniter
mv duniter-default /media/pi/USB_STICK/duniter/ // Déplacement de duniter_default (et tout son contenu) au bon endroit sur ton ssd
cd // permet de revenir dans ton home
rm -rf .config.duniter // Suppression de la source du futur lien symbolique
ln -s /media/pi/USB_STICK/duniter .config/duniter // Création du lien symbolique
Ok, j’ai suivi la procédure, ça a fonctionné parfaitement. Le dossier duniter et son sous dossier duniter_default ont été déplacés sur le ssd. Voici une copie de mon dossier .config à présent, avec les propriétés du lien symbolique. Est-ce que c’est bon ?
Ah, mais du coup, duniter ne démarre plus !!!
Bon, j’ai trouvé la solution, en entrant ces lignes de commande, après avoir démonté le ssd :
sudo mount -t ext4 /dev/sda1 /mnt/ssdgreen/
ln -s /mnt/ssdgreen/duniter /home/pi/.config/duniter
Et là, j’obtiens l’image suivante :
Et duniter démarre !
Le problème, c’est que bien qu’ayant désactivé le montage automatique du stick, après avoir rebooté, le stick était quand même monté, et j’ai donc dû le démonter, et entrer à nouveau les deux lignes de code. Et ça remarche ! Comment faire pour empêcher le rpi de monter automatiquement ce stick usb contenant le ssd ?
Bon, je pose des questions, et une heure (bien laborieuse 
) plus tard, je trouve la réponse : j’ai, sous root, rajouté une ligne au fichier fstab :
UUID=c5e622aa-db13-4731-812b-012dad7dbda7 /mnt/ssdgreen ext4 defaults,errors=remount-ro 0 1 Et là, miracle, ça fonctionne du premier coup !
Suite (pour moi) à tout à l’heure, normalement, ce soir le rpi retourne chez mon amie et reprendra son travail de fourmi ! Merci en tout cas pour toutes les infos qui m’ont été bien utile
Un dernier point, qui peut intéresser tous ceux qui utilisent un rpi 4 sans disque externe (et même les autres, pour ma part, je l’ai installé et ça fonctionne bien) :
Citation
Log2Ram - Ecrire les logs dans la RAM = augmenter la durée de vie des cartes SD & SSD sur vos OS Linux / Raspbian
Pour la marche à suivre, consulter ce lien : Log2Ram
Encore une petite question : mon nœud duniter tourne à nouveau, avec les mêmes réglages que m’avait préconisés elois précédemment : 4 peers en connexion privée active, 24 en connexion publique active. Du fait d’avoir dû tout réinstaller (Raspbian, duniter, et donc nouvelle synchro) pour mettre en place les liens symboliques et déporter duniter sur le ssd, je me retrouve avec deux nœuds homonymes, et celui qui est actif actuellement tente de communiquer avec l’ancien, probablement en pure perte, et consommant des ressources inutiles. Comment arranger ça ? Comment supprimer le nœud inactif ? (voir les deux captures d’écran ci-dessous)
PS : le nœud inactif est celui qui figure sur cette capture d’écran, il est figé sur le bloc 293 700 et n’évolue plus.
@chronophonix, perso je vois que ta fiche de peer est bien a jours donc il n’y a rien a faire de particulier par attendre (c’est cesium qui garde en cache des anciens nœuds) :
{
"version": 10,
"currency": "g1",
"status": "UP",
"first_down": null,
"last_try": null,
"pubkey": "FpAi3xR2PueMfNUQCZQVc9DkbaMt1184KNDdii4iA9Z7",
"block": "294957-0000019880F46EE40C3B4FABDB6B93D32EA6A78563816A62E2B1E81462415A37",
"signature": "Xx5l7YoS57Kn65ZLN+18oiMWPOQyhAK1GCYlbf2uLpKHoEcmr/8iNFVr4R1hkPNh7ayyZUusDsHo9sQy3rM3Dg==",
"endpoints": [
"WS2P 5d6bc954 78.228.11.24 20900"
]
}Ok, merci.