Arriving. Thanks!
6 Likes
Comment faire pour se connecter sur cette nouvelle Gtest avec Gecko ?
@poka Faut-il le réinstaller ?
De quand date la prise d’image ? Pour informé les utilisateurs !
1 Like
Bravo @joss.rendall pour duniter panel, tu peux faire une MR !
Pas encore, j’ai presque finit de migrer vers Graphile, il ne me manque plus qu’a faire fonctionner les subscriptions en websocket côté squid et je peux livrer gecko sur gtest #2, je ne sais pas quand je n’ai pas beaucoup de temps cette semaine.
Le block number du snapshop g1 est inscrite dans le fichier networks sur le gitlab si tu veux en déduire la date exacte: gtest.json · master · nodes / networks · GitLab
"last_g1_v1_block_number": 872134
→
https://g1.duniter.org/blockchain/block/872134
→
09/10/2025 22:52:44 heure blockchain
1 Like
OK, j’attends pour inviter les utilisateurs à voir comment ça fonctionne…
2 Likes
Je galère depuis hier quand j’ai pris connaissance de ce fil. Quoi que je fasse, mon nœud se retrouve seul et ne synchronise pas. J’ai aussi testé avec un bootnode (cf la conf de cgeek), j’ai de plus testé avec l’ajout suffixe “-arm64” au nom de l’image. J’observe le même phénomène, mon nœud est seul avec 3 configs différentes.
Voici un extrait de mon compose :
services:
G1test-smith:
image: duniter/duniter-v2s-gtest-1100:1000-0.12.0-arm64
restart: unless-stopped
container_name: Daigongen-G1test
networks:
- duniterG1
ports:
- "127.0.0.1:9944:9944"
- "30333:30333"
environment:
DUNITER_NODE_NAME: "$SMITH_DUNITER_NODE_NAME"
DUNITER_VALIDATOR: "true"
DUNITER_PUBLIC_ADDR: "/dns/$SMITH_VIRTUAL_HOST/tcp/443"
DUNITER_LISTEN_ADDR: "/ip4/0.0.0.0/tcp/30333"
VIRTUAL_HOST: "$SMITH_VIRTUAL_HOST"
VIRTUAL_PORT: "$SMITH_VIRTUAL_PORT"
LETSENCRYPT_HOST: "$SMITH_VIRTUAL_HOST"
LETSENCRYPT_TEST:
volumes:
- data-G1test:/var/lib/duniter
command:
- "--bootnodes"
- "/dns/gtest.axiom-team.fr/tcp/30333/p2p/12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y"
et un extrait de la log :
Generating node key file '/var/lib/duniter/node.key'...
error: unexpected argument '--dev' found
Usage: duniter key generate-node-key --file <FILE>
For more information, try '--help'.
Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
Node peer ID is ''.
Starting duniter with parameters: --bootnodes /dns/gtest.axiom-team.fr/tcp/30333/p2p/12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y --name daigongen-gtest-smith --node-key-file /var/lib/duniter/node.key --public-addr /dns/daigongen-g1.hd.free.fr/tcp/443 --listen-addr /ip4/0.0.0.0/tcp/30333 --rpc-cors all --rpc-methods Unsafe --validator --dev -d /var/lib/duniter --unsafe-rpc-external
It isn't safe to expose RPC publicly without a proxy server that filters available set of RPC methods.
2025-10-15 08:23:53 Duniter
2025-10-15 08:23:53 ✌️ version 0.12.0-unknown
2025-10-15 08:23:53 ❤️ by librelois <c@elo.tf>:tuxmain <tuxmain@zettascript.org>:c-geek <https://forum.duniter.org/u/cgeek>:HugoTrentesaux <https://trentesaux.fr>:bgallois <benjamin@gallois.cc>:Duniter Developers <https://duniter.org>:Axiom-Team Developers <https://axiom-team.fr>, 2021-2025
2025-10-15 08:23:53 📋 Chain specification: ĞTest Local Testnet
2025-10-15 08:23:53 🏷 Node name: daigongen-gtest-smith
2025-10-15 08:23:53 👤 Role: AUTHORITY
2025-10-15 08:23:53 💾 Database: ParityDb at /var/lib/duniter/chains/gtest_local/paritydb/full
2025-10-15 08:23:55 🔨 Initializing Genesis block/state (state: 0xca47…053e, header-hash: 0xc9f2…c6d3)
2025-10-15 08:23:55 Creating transaction pool txpool_type=ForkAware ready=Limit { count: 8192, total_bytes: 20971520 } future=Limit { count: 819, total_bytes: 2097152 }
2025-10-15 08:23:55 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2025-10-15 08:23:55 👶 Creating empty BABE epoch changes on what appears to be first startup.
2025-10-15 08:23:55 Using default protocol ID "sup" because none is configured in the chain specs
2025-10-15 08:23:55 Local node identity is: 12D3KooWDM2gwJ38nHKab8yzyygbSJH3uS65d5ZsCNi9H5bmKkFf
2025-10-15 08:23:55 Running litep2p network backend
2025-10-15 08:23:55 👶 Starting BABE Authorship worker
2025-10-15 08:23:55 💻 Operating system: linux
2025-10-15 08:23:55 💻 CPU architecture: aarch64
2025-10-15 08:23:55 💻 Target environment: gnu
2025-10-15 08:23:55 💻 Memory: 15705MB
2025-10-15 08:23:55 💻 Kernel: 6.1.115-vendor-rk35xx
2025-10-15 08:23:55 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)
2025-10-15 08:23:55 💻 Virtual machine: no
2025-10-15 08:23:55 📦 Highest known block at #0
2025-10-15 08:23:55 〽️ Prometheus exporter started at 127.0.0.1:9615
2025-10-15 08:23:55 Running JSON-RPC server: addr=0.0.0.0:9944,[::]:39625
2025-10-15 08:23:55 ***** Duniter has fully started *****
2025-10-15 08:24:00 🧙 [distance inherent] No published result at this block.
2025-10-15 08:24:00 🙌 Starting consensus session on top of parent 0xc9f22abe877c799ca6435a99adb48efc6186554674ee7099bea7704dd3b7c6d3 (#0)
2025-10-15 08:24:00 🎁 Prepared block for proposing at 1 (5 ms) hash: 0x5b673aa17789b372ef1ced7fe2db931366f1785dc9eecdd68d6ef8ba864b0b1d; parent_hash: 0xc9f2…c6d3; end: NoMoreTransactions; extrinsics_count: 1
2025-10-15 08:24:00 🔖 Pre-sealed block for proposal at 1. Hash now 0x716496fbf0e09a16b7ee5a7233d69c5a0390d50a86a8476b59e1d2ecfe1560b3, previously 0x5b673aa17789b372ef1ced7fe2db931366f1785dc9eecdd68d6ef8ba864b0b1d.
2025-10-15 08:24:00 👶 New epoch 0 launching at block 0x7164…60b3 (block slot 293419440 >= start slot 293419440).
2025-10-15 08:24:00 👶 Next epoch starts at slot 293420040
2025-10-15 08:24:00 🏆 Imported #1 (0xc9f2…c6d3 → 0x7164…60b3)
2025-10-15 08:24:00 maintain txs=(0, 0) a=1 i=1 views=[(1, 0, 0)] event=NewBestBlock { hash: 0x716496fbf0e09a16b7ee5a7233d69c5a0390d50a86a8476b59e1d2ecfe1560b3, tree_route: None } duration=399.092µs
2025-10-15 08:24:00 💤 Idle (0 peers), best: #1 (0x7164…60b3), finalized #0 (0xc9f2…c6d3), ⬇ 0.3kiB/s ⬆ 0.2kiB/s
2025-10-15 08:24:01 🔍 Discovered new external address for our node: /ip4/82.66.23.221/tcp/30333/p2p/12D3KooWDM2gwJ38nHKab8yzyygbSJH3uS65d5ZsCNi9H5bmKkFf
2025-10-15 08:24:05 💤 Idle (0 peers), best: #1 (0x7164…60b3), finalized #0 (0xc9f2…c6d3), ⬇ 3.1kiB/s ⬆ 1.6kiB/s
On voit que la version est correcte et que le bootnode est bien pris en compte.
En revanche, le noeud est isolé.
Des idées pour investiguer ce pb ?
Peut-être est-ce dû à ce port qui correspond au localhost ?
- "127.0.0.1:9944:9944"
La plupart des docker-compose.yml indiquent :
# prometheus telemetry to monitor resource use
- 9615:9615
# RPC API (ws and http)
- 9944:9944
# public p2p endpoint
- 30333:30333
non, ce n’est pas l’origine du problème 
1 Like
Rajoute :
DUNITER_CHAIN_NAME: "gtest"
2 Likes
Merci, le pb est résolu!
C’est marrant, je n’ai pas eu besoin de ce paramètre jusqu’à présent.
Pour info, cette entrée de log quand cela ne fonctionne pas :
📋 Chain specification: ĞTest Local Testnet
a été remplacée par la suivante, quand cela fonctionne :
📋 Chain specification: ĞTest
2 Likes
Tu as oublié d’indiquer le log à remplacer en question.
Une erreur de spec dans ce log ?
1 Like
J’ai modifié mon post pour que cela soit plus compréhensible 
le copier coller avait “surligné” l’entrée mais en recopiant la log entière
1 Like
@1000i100 m’a fait la même remarque. Je ne comprends pas car pour moi c’est normal de devoir spécifier le nom de la chaine embed ou chemin vers raw spec, sans quoi ça lance une chaine de dev locale par defaut.
Je n’explique pas le changement de comportement à ce sujet.
Peut être une valeur de chaine par defaut mal configuré quelque part pour ce client, je ne sais pas.
1 Like
Idem ! Il ne reste plus que @HugoTrentesaux @Moul @Nicolas80 sur l’ancienne ĞTest (@Damery y était il y a quelques heures aussi mais je ne le vois plus forger désormais).
En effet, j’ai passé mon noeud sur la nouvelle Gtest. Pas sûr qu’il soit efficient …
2 Likes
J’essaie d’y regarder ce week-end 
Est-ce que l’on a déjà des nouvelles images Arm64 pour squid également ?
2 Likes
Oui normalement les images squid sont multi arch, elles sont toutes les 3 ici: https://hub.docker.com/u/duniter?page=1&search=squid
2 Likes
Quels “certains endroits” ? Est-ce juste un problème d’étiquette ? Quand j’interroge gt.p2p.legal avec state.getStorageHash(0x3a636f6465) (c’est la clé du code, CODE in sp_storage::well_known_keys - Rust, b":code".hex() -> '3a636f6465'), j’obtiens 0x2dce7bc455dfa42ead19fe88c2e4d25e5044700d9c1f3bc3a0a2a3cded17a0e6 qui est bien le hash indiqué dans la release gtest-1100. Donc apparemment c’est le bon runtime, juste mal étiqueté.
Dans Hasura de l’ancienne gtest :
query AllSmithLastForged {
smith(orderBy: {lastForged: DESC_NULLS_LAST}) {
identity { name }
lastForged
}
}
{
"data": {
"smith": [
{
"identity": {
"name": "HugoTrentesaux"
},
"lastForged": 1423797
},
{
"identity": {
"name": "Nicolas80"
},
"lastForged": 1423795
},
{
"identity": {
"name": "moul"
},
"lastForged": 1423794
},
{
"identity": {
"name": "Damery"
},
"lastForged": 1413191
},
{
"identity": {
"name": "Bulmananabelle"
},
"lastForged": 1401023
},
{
"identity": {
"name": "gui_tooun"
},
"lastForged": 1386277
},
{
"identity": {
"name": "vjrj"
},
"lastForged": 1381845
},
{
"identity": {
"name": "JosselinFERREIRA"
},
"lastForged": 1360908
},
{
"identity": {
"name": "cgeek"
},
"lastForged": 1357832
},
{
"identity": {
"name": "tuxmain"
},
"lastForged": 1357520
},
{
"identity": {
"name": "1000i100"
},
"lastForged": 1349192
},
{
"identity": {
"name": "poka"
},
"lastForged": 1344859
},
{
"identity": {
"name": "Elois"
},
"lastForged": 87324
},
{
"identity": {
"name": "vit"
},
"lastForged": null
}
]
}
}
Le dernier bloc forgé par Joss était le 1360908, donc ça dépend de si tu as regardé avant ou après ça.
J’ai fait “go offline” de l’ancienne gtest pour la forme, mais je vais rejoindre la nouvelle sans attendre.
Étrange, mon nœud apparaissait bloqué au bloc 50267 dans la télémétrie alors que dans les logs il était à ~91000 soit correctement synchronisé. Et puis la moitié des nœuds ont disparu de la télémétrie, et je ne peux plus me ssh sur mon serveur (???). Les noeuds sont revenus dans la télémétrie, mais pas mon serveur 
Je me suis connecté dans la console VNC du cloud, et on dirait un out of memory. Je redémarre le VPS. Il faudrait surveiller la mémoire nécessaire au démarrage d’un nœud et éviter que ça devienne bloquant. J’ai que 2Go sur mon nœud validateur qui fait quasiment que ça.
C’est reparti après un reboot, ça resynchronise, j’ai dû perdre un bout.
J’ai exécuté les commandes suivantes :
# passerelle ssh vers mon noeud forgeron (uniquement utile pour rotate keys)
ssh -NL 9944:localhost:9944 trentesaux
# sauver le endpoint dans mon gcli
gcli -u ws://localhost:9944 config save
# générer un nouveau mnemonic
gcli vault generate
# dériver une clé ed25519 de cette seed et l'ajouter à mon vault
gcli vault import -c ed25519
# nom HugoGtest
# addresse 5GvgXwuaAcT6P7xzAjukqDR4iNrdf4ABfY64Sb2bBqBAxmAX
# transfert d'assez de ĞT depuis mon ancien compte
gcli account transfer 100000 5GvgXwuaAcT6P7xzAjukqDR4iNrdf4ABfY64Sb2bBqBAxmAX
# migration de mon identité
gcli identity change-owner-key -v HugoGtest
# (fait au bloc 92,328)
# enregistrement de mon nouveau compte par défaut
gcli -v HugoGtest config save
# rotation de mes clés et set_session_keys en une commande
# (c'est là qu'il est nécessaire d'être connecté à mon validateur pour la partie rotate keys)
gcli smith update-keys
# (fait au bloc 92,340)
# passage online
gcli smith go-online
# (fait au bloc 92,346)
Donc je devrais passer online dans pas longtemps.
4 Likes
J’ai lancé mes premiers nœuds :
# validateur
# (premier bloc calculé 93194)
# archive
/dns/gtest.coinduf.eu/tcp/30333/p2p/12D3KooWK6KDYpEhrGTTYRqSanXhgt4Hb2YpFZfUugSiiuzB3XUi
# rpc
wss://gtest.coinduf.eu/
# squid
https://squid.gtest.coinduf.eu/v1/graphql
D’une manière surprenante, je me suis retrouvé avec toutes mes requêtes hasura préremplies dans mon playground graphiql (https://squid.gtest.coinduf.eu/graphiql). Ça doit être stocké au même endroit dans les cookies.
2 Likes