J’essaie aussi de transférer mon identité et ma monnaie de mon compte V1 à mon compte V2, mais :
ERROR:root:{'type': 'Module', 'name': 'NotAllowedToChangeIdtyAddress', 'docs': ['Not allowed to change identity address']}
Je veux bien la liste des calls que tu vas faire pour révoquer ton adhésion forgeron, voir si je peux l’implémenter dans Tikka…
Yes, ça fait un moment que je voulais vous mettre la liste des calls, mais j’ai été aspiré par subsquid. Mais ça nous permet de voir l’historique (sans ça j’aurais pas pu retrouver) :
sur https://subsquid.gdev.coinduf.eu/graphql
tous les calls en succès des pallets SmithMembership, Identity et AuthorityMembers
query Query {
calls(limit: 10, orderBy: block_height_ASC,
where: {success_eq: true,
AND: {pallet_eq: "SmithMembership",
OR: {pallet_eq: "Identity",
OR: {pallet_eq: "AuthorityMembers"}}}}) {
block {
height
}
pallet
name
success
}
}
(j’ai pas encore ajouté la caller, on pourrait raffiner le filtre, mais là ça nous suffit)
{
"data": {
"calls": [
{
"block": {
"height": 14646
},
"pallet": "Identity",
"name": "link_account",
"success": true
},
{
"block": {
"height": 30420
},
"pallet": "SmithMembership",
"name": "revoke_membership",
"success": true
},
{
"block": {
"height": 30504
},
"pallet": "Identity",
"name": "change_owner_key",
"success": true
},
{
"block": {
"height": 30516
},
"pallet": "SmithMembership",
"name": "request_membership",
"success": true
},
{
"block": {
"height": 30525
},
"pallet": "SmithMembership",
"name": "claim_membership",
"success": true
},
{
"block": {
"height": 30630
},
"pallet": "AuthorityMembers",
"name": "set_session_keys",
"success": true
},
{
"block": {
"height": 30776
},
"pallet": "AuthorityMembers",
"name": "set_session_keys",
"success": true
},
{
"block": {
"height": 30801
},
"pallet": "Identity",
"name": "link_account",
"success": true
},
{
"block": {
"height": 30804
},
"pallet": "AuthorityMembers",
"name": "set_session_keys",
"success": true
},
{
"block": {
"height": 30813
},
"pallet": "AuthorityMembers",
"name": "go_online",
"success": true
}
]
}
}
Donc résumé :
Tu verras en étant attentif que j’ai omis quelques calls de trucs que j’ai fait entre temps 
Super! Merci.
Peux-tu expliquer, peut-être dans un sujet dédié, a quoi sert link_account ?
C’est un nouveau call, il me semble ?
Je pense que c’est pour bénéficier des quotas, c’est-à-dire que la nouvelle clé ne subisse pas les frais de transactions. Parce que le lien n’est pas automatiquement fait par change_owner_key.
Mais c’est curieux d’avoir plus d’un appel à link_account.
Oui, on peut aller en discuter ici : Lier son compte portefeuille à son identité
C’est pour cette raison que je l’ai introduit, en effet, mais je pense que c’est plus général que ça.
Quand je lance mon nœud (après avoir supprimé la db), en mode Warp ou non, il récupère et finalise quelques milliers de blocs puis se bloque :
2023-11-24 17:34:15 ⚙️ Syncing 125.0 bps, target=#75437 (9 peers), best: #26760 (0x1f12…3828), finalized #26624 (0x85c8…d2f4), ⬇ 48.5kiB/s ⬆ 0.5kiB/s
2023-11-24 17:34:15 Background worker error: IO Error: Out of memory (os error 12)
2023-11-24 17:34:15 Block import error: Database
2023-11-24 17:34:15 💔 Error importing block 0xbb01c8b88d6d66e63fd3a6bc0331ee6a2d8ee8f7bd7d7dab9b79e5b5219776f0: consensus error: Import failed: Import failed: Database
2023-11-24 17:34:15 💔 Error importing block 0x4bb576097c3425c7fbaaabee055a5b181d407dada09027e7e49a0c41f4a27769: block has an unknown parent
[...]
2023-11-24 17:34:36 Unable to author block in slot. No best block header: Chain lookup failed: Failed to get header for hash 0xbb01…76f0
2023-11-24 17:34:40 💤 Idle (0 peers), best: #26763 (0x1b57…6c3a), finalized #26624 (0x85c8…d2f4), ⬇ 10.0kiB/s ⬆ 1.2kiB/s
Avant le blocage, j’ai deux fois ce message :
Logic error: Account already dead when reducing provider
qui vient de frame::dec_sufficients ou frame::dec_providers (ils ont dû oublier de changer le message pour dec_sufficients, c’est le même).
Tu as aussi :
Pour info, je passe en offline le temps de repasser mon nœud validateur en 0.7.0 :
gcli smith go-offline
transaction submitted to the network, waiting 6 seconds...
smith went offline MemberGoOffline(34)
Je devrais être offline d’ici 15h40 si j’ai bien compris.
edit : nœud reconfiguré, je rejoins d’ici 20h45, je suis dans les incomingAuthorities :
gcli smith go-online
transaction submitted to the network, waiting 6 seconds...
smith went online MemberGoOnline(34)
Je tente de relancer mon noeud RPC, mais il ne semble pas réussir à se connecter au réseau:
$ docker run --rm -it -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s-gdev
Unable to find image 'duniter/duniter-v2s-gdev:latest' locally
latest: Pulling from duniter/duniter-v2s-gdev
0bc8ff246cb8: Pull complete
6b67551213ee: Pull complete
02b3a9910d80: Pull complete
9b170bc82d76: Pull complete
Digest: sha256:da8e10bdb7fb1e2485502b42603256612c5677f7b3f514aa7a21c61cae819f06
Status: Downloaded newer image for duniter/duniter-v2s-gdev:latest
Generating node key file '/var/lib/duniter/node.key'...
12D3KooWBCVEytGntdgQT1BPaxkrqRDE4C8adWYUffRRzDEudp3S
Node peer ID is '12D3KooWBCVEytGntdgQT1BPaxkrqRDE4C8adWYUffRRzDEudp3S'.
Starting duniter with parameters: --node-key-file /var/lib/duniter/node.key --rpc-cors all --chain gdev -d /var/lib/duniter --unsafe-rpc-external --unsafe-ws-external
2023-11-26 23:44:57 Duniter
2023-11-26 23:44:57 ✌️ version 0.7.0-unknown
2023-11-26 23:44:57 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023
2023-11-26 23:44:57 📋 Chain specification: ĞDev
2023-11-26 23:44:57 🏷 Node name: coherent-thing-0973
2023-11-26 23:44:57 👤 Role: FULL
2023-11-26 23:44:57 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full
2023-11-26 23:44:57 ⛓ Native runtime: gdev-700 (duniter-gdev-1.tx1.au1)
2023-11-26 23:45:00 🔨 Initializing Genesis block/state (state: 0x9e85…84da, header-hash: 0xc234…a857)
2023-11-26 23:45:00 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2023-11-26 23:45:01 👶 Creating empty BABE epoch changes on what appears to be first startup.
2023-11-26 23:45:01 🏷 Local node identity is: 12D3KooWBCVEytGntdgQT1BPaxkrqRDE4C8adWYUffRRzDEudp3S
2023-11-26 23:45:01 💻 Operating system: linux
2023-11-26 23:45:01 💻 CPU architecture: x86_64
2023-11-26 23:45:01 💻 Target environment: gnu
2023-11-26 23:45:01 💻 CPU: AMD Ryzen 7 3750H with Radeon Vega Mobile Gfx
2023-11-26 23:45:01 💻 CPU cores: 4
2023-11-26 23:45:01 💻 Memory: 13917MB
2023-11-26 23:45:01 💻 Kernel: 5.15.116-1-pve
2023-11-26 23:45:01 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)
2023-11-26 23:45:01 💻 Virtual machine: no
2023-11-26 23:45:01 📦 Highest known block at #0
2023-11-26 23:45:01 〽️ Prometheus exporter started at 127.0.0.1:9615
2023-11-26 23:45:01 Running JSON-RPC HTTP server: addr=0.0.0.0:9933, allowed origins=["*"]
2023-11-26 23:45:01 Running JSON-RPC WS server: addr=0.0.0.0:9944, allowed origins=["*"]
2023-11-26 23:45:01 ***** Duniter has fully started *****
2023-11-26 23:45:06 💤 Idle (0 peers), best: #0 (0xc234…a857), finalized #0 (0xc234…a857), ⬇ 0 ⬆ 49 B/s
2023-11-26 23:45:11 💤 Idle (0 peers), best: #0 (0xc234…a857), finalized #0 (0xc234…a857), ⬇ 0 ⬆ 12 B/s
2023-11-26 23:45:16 💤 Idle (0 peers), best: #0 (0xc234…a857), finalized #0 (0xc234…a857), ⬇ 0 ⬆ 12 B/s
Je suis sur le même système que mon ancien noeud RPC. Le résultat est le même avec mon docker compose adapté à ce nouveau runtime.
Les bootnodes ne seraient-ils plus les bons dans ce client ?
Oui c’était le cas hier avant que je ne relance mon noeud gdev-validator, mais ça devrait être bon depuis hier soir.
Il faut peut-être que tu purges le dossier de données avant.
J’ai essayé de purger le dossier mais avec cette commande docker run, il n’est pas persistant:
$ docker run --rm -it --entrypoint duniter duniter/duniter-v2s-gdev purge-chain --chain=gdev -d /var/lib/duniter
Are you sure to remove "/var/lib/duniter/chains/gdev/paritydb/full"? [y/N]: y
"/var/lib/duniter/chains/gdev/paritydb/full" did not exist.
Avec mon docker composer je rm -rf directement le dossier duniter-data/chains/.
Je viens de tester la même commande docker sur mon pc local, et j’ai exactement le même résultat.
docker run --rm -it -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s-gdev
Unable to find image 'duniter/duniter-v2s-gdev:latest' locally
latest: Pulling from duniter/duniter-v2s-gdev
0bc8ff246cb8: Already exists
6b67551213ee: Pull complete
02b3a9910d80: Pull complete
9b170bc82d76: Pull complete
Digest: sha256:da8e10bdb7fb1e2485502b42603256612c5677f7b3f514aa7a21c61cae819f06
Status: Downloaded newer image for duniter/duniter-v2s-gdev:latest
Generating node key file '/var/lib/duniter/node.key'...
12D3KooWFTcV3aCPE2ksCUDPWmr4Bank3DC3ktQoRQiZtEnFLcpf
Node peer ID is '12D3KooWFTcV3aCPE2ksCUDPWmr4Bank3DC3ktQoRQiZtEnFLcpf'.
Starting duniter with parameters: --node-key-file /var/lib/duniter/node.key --rpc-cors all --chain gdev -d /var/lib/duniter --unsafe-rpc-external --unsafe-ws-external
2023-11-27 11:09:28 Duniter
2023-11-27 11:09:28 ✌️ version 0.7.0-unknown
2023-11-27 11:09:28 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023
2023-11-27 11:09:28 📋 Chain specification: ĞDev
2023-11-27 11:09:28 🏷 Node name: belligerent-circle-0426
2023-11-27 11:09:28 👤 Role: FULL
2023-11-27 11:09:28 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full
2023-11-27 11:09:28 ⛓ Native runtime: gdev-700 (duniter-gdev-1.tx1.au1)
2023-11-27 11:09:29 🔨 Initializing Genesis block/state (state: 0x9e85…84da, header-hash: 0xc234…a857)
2023-11-27 11:09:30 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2023-11-27 11:09:30 👶 Creating empty BABE epoch changes on what appears to be first startup.
2023-11-27 11:09:30 🏷 Local node identity is: 12D3KooWFTcV3aCPE2ksCUDPWmr4Bank3DC3ktQoRQiZtEnFLcpf
2023-11-27 11:09:30 💻 Operating system: linux
2023-11-27 11:09:30 💻 CPU architecture: x86_64
2023-11-27 11:09:30 💻 Target environment: gnu
2023-11-27 11:09:30 💻 CPU: AMD Ryzen 7 3700X 8-Core Processor
2023-11-27 11:09:30 💻 CPU cores: 8
2023-11-27 11:09:30 💻 Memory: 31987MB
2023-11-27 11:09:30 💻 Kernel: 5.15.0-89-generic
2023-11-27 11:09:30 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)
2023-11-27 11:09:30 💻 Virtual machine: no
2023-11-27 11:09:30 📦 Highest known block at #0
2023-11-27 11:09:30 Running JSON-RPC HTTP server: addr=0.0.0.0:9933, allowed origins=["*"]
2023-11-27 11:09:30 Running JSON-RPC WS server: addr=0.0.0.0:9944, allowed origins=["*"]
2023-11-27 11:09:30 〽️ Prometheus exporter started at 127.0.0.1:9615
2023-11-27 11:09:30 ***** Duniter has fully started *****
2023-11-27 11:09:35 💤 Idle (0 peers), best: #0 (0xc234…a857), finalized #0 (0xc234…a857), ⬇ 0 ⬆ 49 B/s
2023-11-27 11:09:40 💤 Idle (0 peers), best: #0 (0xc234…a857), finalized #0 (0xc234…a857), ⬇ 0 ⬆ 12 B/s
Je pense donc qu’il y a un soucis avec les bootnodes de ce client, même si ça me parait étrange car dans mes souvenirs des bootnodes invalides sont indiqués dans les logs avec l’emoji 
, ce qui n’est pas le cas ici.
Effectivement, il semble y avoir un soucis avec l’API P2P de mon nœud validateur.
Pour te débloquer, tu peux utiliser le nœud d’Hugo :
docker run --rm -it -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s-gdev --bootnodes /dns/gdev.coinduf.eu/tcp/30333/p2p/12D3KooWFseA3B66eBzj4NY5ng3Lb2U3VPnKCi3iXYGYUSAahEw7
Je ne suis pas spécialement bloqué ni pressé, j’essaie de comprendre ce qui ne va pas avec ce client ou ton noeud bootstrap, tant mieux si tu as une piste
OK, ceci dit c’est aussi pour ceux qui nous liraient (et même un mémo pour moi).
En tout cas c’est bon, j’ai corrigé mon installation, j’avais bien un soucis de port. Et même de clé…
Merci 
Pourrais-tu le faire sans trop tarder quand même ? La branche n’est déjà plus mergeable sans conflits.
Oui, désolé, j’ai laissé passer, et il n’y a rien de nouveau à ajouter à part une liste plus étendue de bootnodes.
Je vais rajouter ton nœud déjà, nous en rajouterons davantage d’ici la prochaine release.
J’ai un peu cherché dans parity-db, j’ai toujours des problèmes liés à l’allocation mémoire ou à mmap. Apparemment ces problèmes se retrouvent couramment sur Raspbian surtout si on joue entre arm32 et arm64. J’ai pourtant un swap de 8 Go libre et je ne constate aucun pic d’utilisation si élevé.
Je passerai mon serveur sous Debian arm64 (un vrai OS fait par des gens sérieux) pendant les vacances, avec un peu de chance ça suffira. (même si on passe en aarch64, Raspbian reste en 32 bits donc peut-être que Linux n’accepte pas certaines grosses allocations de mémoire virtuelle, indépendamment de la mémoire physique)