### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [20 November 2023 11:11 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/21 "2023-11-20T11:11:14Z")
J’ai ajouté 8Go de swap et toujours OOM. Idem en retirant toutes les options optionnelles.
```auto
$ duniter --chain gdev700.json
2023-11-20 11:51:15 Duniter
2023-11-20 11:51:15 ✌️ version 0.7.0-c4773062fb5
2023-11-20 11:51:15 ❤️ by Axiom-Team Developers , 2021-2023
2023-11-20 11:51:15 📋 Chain specification: ĞDev
2023-11-20 11:51:15 🏷 Node name: tuxmain-polux-smith-gdev
2023-11-20 11:51:15 👤 Role: AUTHORITY
2023-11-20 11:51:15 💾 Database: ParityDb at /home/pi/.local/share/duniter/chains/gdev/paritydb/full
2023-11-20 11:51:15 ⛓ Native runtime: gdev-700 (duniter-gdev-1.tx1.au1)
Error: Service(Client(Backend("IO Error: Out of memory (os error 12)")))
```
Il y a plusieurs issues sur Polkadot/Substrate à propos d’OOM ou de fuites mémoires mais seulement dans certaines phases de consensus, et jamais avec ce message. J’essaie de trouver d’où ça vient mais il faudrait arriver à installer valgrind ou lldb en arm64 (les dépôts raspbian bullseye sont uniquement en armv7).
Edit: C’est dans `sc_service::new_full_parts`, à cause du backend db. D’ailleurs ne comprends pas pourquoi les builds armv7 marchent puisque parity-db ne supporte que x86-64 et aarch64.
Edit: Finalement ça marche après suppression de l’ancienne db. C’est tout de même un bug de parity-db.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [20 November 2023 11:43 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/22 "2023-11-20T11:43:34Z")
Il y a un problème chez moi avec la commande pour purger la chaîne :
Dans le container, `/var/lib/duniter` pointe sur mon dossier de données contenant `chains/gdev/paritydb/full` et pas `.local/share/duniter/chains/gdev/paritydb/full`
```auto
docker exec -ti home_duniter_validator.1.nalo348fqf89gavs2joq40c48 duniter purge-chain --chain=gdev
Are you sure to remove "/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full"? [y/N]: y
"/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full" did not exist.
```
Dans telemetry, je ne vois que mes deux nœuds en 0.7.0. Et seul le validator avance sur une nouvelle chaîne de blocs, le RPC reste sur l’ancienne…
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 November 2023 12:03 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/23 "2023-11-20T12:03:38Z")
> [@HugoTrentesaux](#):
>
> il me manque les specs au format json pour démarrer l’indexeur.
Le fichier a bien été produit mais j’ai oublié de l’ajouter aux assets de la release. C’est [corrigé dans le code](https://git.duniter.org/nodes/rust/duniter-v2s/-/commit/17fc34086f2d0d57e0d190ae9f3b379b7c98c86b) et [corrigé dans la release](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases).
> [@HugoTrentesaux](#):
>
> Est-ce que tu aurais le bloc précis ?
Oui, les tables LevelDB du dump indiquent : #657075.
> [@HugoTrentesaux](#):
>
> Et est-ce qu’il y avait des messages de warnings comme des certifications expirées ?
Tout le détail se trouve dans [les logs de ce job](https://git.duniter.org/nodes/rust/duniter-v2s/-/jobs/119957).
> [@HugoTrentesaux](#):
>
> Ce serait bien d’avoir le fichier `g1-data.json` aussi ^^
Il est [dans les fichiers de la release](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/runtime-700), ça fait partie des livrables 🙂
Je préfère qu’il soit dans la release plutôt que les fichiers d’input, puisque précisément ce n’est _pas_ un fichier d’entrée mais un fichier intermédiaire généré par la CI dans son processus de création de la release.
> [@vit](#):
>
> Il y a un problème chez moi avec la commande pour purger la chaîne :
Tu as raison, je vais éditer mon post plus haut, il faut lancer avec l’option `-d /var/lib/duniter` :
```
purge-chain --chain=gdev -d /var/lib/duniter
```
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 November 2023 12:15 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/24 "2023-11-20T12:15:46Z")
> [@cgeek](#):
>
> [corrigé dans le code](https://git.duniter.org/nodes/rust/duniter-v2s/-/commit/17fc34086f2d0d57e0d190ae9f3b379b7c98c86b) et [corrigé dans la release](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases).
Je ne comprends pas tout à fait comment fonctionne la CI, mais _a priori_ on ne publie les specs qu’une fois (au démarrage d’un réseau) alors qu’on peut faire des publications de runtime régulièrement (pour mettre à jour le réseau). Est-ce que comme tu l’as fait ces fichiers seront ajoutés à chaque release de runtime ou uniquement au démarrage d’un nouveau réseau ?
> [@cgeek](#):
>
> 657075
Chouette, facile, à retenir en plus \>\<
> [@cgeek](#):
>
> [les logs de ce job](https://git.duniter.org/nodes/rust/duniter-v2s/-/jobs/119957).
- 12 certifications expirées (normal en 30 minutes)
- 5319 adhésions expirées, pas la peine de les afficher toutes, uniquement les adhésions qui n’étaient pas expirées au bloc de l’export
- `actual monetary_mass (8,457,743,556) and initial_monetary_mass (8,457,771,775) do not match ` soit 28219 de différence, ~ ok pour 282 Ğ1
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 November 2023 12:24 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/25 "2023-11-20T12:24:33Z")
> [@HugoTrentesaux](#):
>
> _a priori_ on ne publie les specs qu’une fois (au démarrage d’un réseau) alors qu’on peut faire des publications de runtime régulièrement (pour mettre à jour le réseau). Est-ce que comme tu l’as fait ces fichiers seront ajoutés à chaque release de runtime ou uniquement au démarrage d’un nouveau réseau ?
Comme pour l’instant nous sommes susceptibles de redémarrer régulièrement le réseau, la CI builde tous les fichiers à chaque release. Ensuite libre à nous ensuite de mettre à jour les raw-specs dans le code (étape 3) puis de relivrer une image Docker du Client (étape 4, [voir le détail des étapes](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/42)).
Mais effectivement à terme, la plupart des fichiers ne seront plus à livrer.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [20 November 2023 13:57 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/28 "2023-11-20T13:57:35Z")
2 posts were merged into an existing topic: [Ğecko talks / user support](https://forum.duniter.org/t/gecko-talks-user-support/9372/283)
---
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [20 November 2023 14:51 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/29 "2023-11-20T14:51:27Z")
DU réévalué maintenant et à une valeur de 14.00 ĞDev c’est correct selon les paramètres qui ont été choisis je suppose ? 🙂
Oui 🙂
> [@cgeek](#):
>
> ```auto
> - money growth rate: 4.88% every 24 hours
> - UD creation period: 4 hours
>
> ```
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 November 2023 15:58 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/30 "2023-11-20T15:58:37Z")
> [@cgeek](#):
>
> Le fichier a bien été produit
On ne s’est pas bien compris quand j’ai retravaillé sur le format du genesis de l’indexeur. Je n’utilisais pas la struct custom `GenesisIndexerExport`, mais les chainspecs au format json (mais pas raw). En gros j’utilisais la sortie de `duniter build-spec` (pas la sortie de `duniter build-spec --raw` ni la sortie optionnelle quand la variable d’environnement `DUNITER_GENESIS_EXPORT` est définie). Donc ce qu’il me manque là si je ne veux pas changer le format d’entrée de l’indexeur, c’est bien les specs au format json (pas raw).
Je pourrais peut-être partir des raw specs pour revenir au format “pas raw”, mais ce serait plus pratique de les avoir directement.
Ou alors je pourrais le re-générer si je connaissais le `DUNITER_GENESIS_TIMESTAMP` puisque ça devrait être déterministe, mais je ne connais pas cette valeur. Je pourrais essayer de rétro-ingénierer cette valeur, mais ce n’est pas très propre.
[edit] je pars pour l’instant de ce timestamp : `1700388302`
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [20 November 2023 16:20 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/31 "2023-11-20T16:20:03Z")
Ce fichier est aussi sur la page de releases : fichier `gdev.json`.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 November 2023 16:25 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/32 "2023-11-20T16:25:50Z")
Ok, en fait j’avais juste pas les yeux en face des trous ! Merci 🙂
On devrait pouvoir le recréer en faisant :
```auto
duniter build-spec --chain ./node/specs/gdev-raw.json 1> ./node/specs/gdev.json
```
mais curieusement ça donne un fichier raw 🤔
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [21 November 2023 12:59 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/33 "2023-11-21T12:59:15Z")
> [@cgeek](#):
>
> Oui, les tables LevelDB du dump indiquent : ~~#657075~~.
Je me suis trompé, désolé, c’était plutôt #679340 (l’autre valeur, c’était le dump que j’avais fait le 31/08/2023).
Le n° de bloc, ainsi que son `medianTime` [seront désormais consignés](https://git.duniter.org/tools/py-g1-migrator/-/commit/1ceb0fa794feb0a2db01dd9892c5cc5e3ada040b) par py-g1-migrator.
> [@HugoTrentesaux](#):
>
> - 5319 adhésions expirées, pas la peine de les afficher toutes, uniquement les adhésions qui n’étaient pas expirées au bloc de l’export
Il me manquait l’information du bloc courant à au moment de la génération du Genesis pour pouvoir faire ce filtre. Étant donné le point ci-dessus, j’ai pu apporter [un correctif](https://git.duniter.org/nodes/rust/duniter-v2s/-/commit/3aa3546337fee2ada5e9144daf6e907613024b11).
> [@HugoTrentesaux](#):
>
> Ou alors je pourrais le re-générer si je connaissais le `DUNITER_GENESIS_TIMESTAMP` puisque ça devrait être déterministe, mais je ne connais pas cette valeur. Je pourrais essayer de rétro-ingénierer cette valeur, mais ce n’est pas très propre.
La valeur précise peut se déduire [des logs](https://git.duniter.org/nodes/rust/duniter-v2s/-/jobs/119957), notamment ceux qui indiquent “Building chain spec” :
```
2023-11-19 10:04:34 Building chain spec
```
Le timestamp précis serait donc plutôt autour de `1700384674 `. Mais après quelques essais, je n’ai pas réussi à le reproduire localement. [edit] : ah oui, je n’ai pas testé avec le Runtime produit par srtool, c’est pour ça.
* * *
En tout cas, j’ai créé la [MR!199](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/199) pour finaliser la release et merger les modifications apportées durant le processus. Je t’invite à la relire.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [21 November 2023 13:04 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/34 "2023-11-21T13:04:31Z")
Super super ! On commence a avoir lissé pas mal de rugosités, je continue de travailler sur les indexeurs parce que j’en tirerai sûrement quelques retours et je ferai une relecture à froid plus tard, il n’y a pas d’urgence à merge ça.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [21 November 2023 13:16 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/35 "2023-11-21T13:16:33Z")
J’ai implémenté ChangeOwnerKey dans Ğcli (en deux minutes, par copier-coller de link account), et ça me permet de me rappeler une autre raison pour laquelle on migrait les identités des forgerons dans le genesis :
```sh
gcli -S cesium identity change-owner-key -s "... mon mnemonic ..."
Cesium id:
Cesium password:
transaction submitted to the network, waiting 6 seconds...
Pallet error: SmithSubWot::NotAllowedToChangeIdtyAddress
```
Les forgeons n’ont pas le droit de migrer leur identité.
Donc je suis partagé entre deux solutions :
- révoquer mon adhésion forgeron, migrer mon identité, puis redemander l’adhésion forgeron
- devenir forgeron avec ma clé actuelle
L’inconvénient de la deuxième option est que je ne pourrai pas utiliser mon identité dans polkadotjs app, donc il faudra que j’implémente tout dans Ğcli. Je pense donc partir sur la première option.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [21 November 2023 13:22 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/36 "2023-11-21T13:22:15Z")
> [@HugoTrentesaux](#):
>
> Les forgeons n’ont pas le droit de migrer leur identité.
Oui c’est la principale raison qui m’avait poussé à permettre le switch des adresse v1/v2 dans py-g1-migrator, pour que les smiths puissent utiliser gecko.
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [21 November 2023 13:24 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/37 "2023-11-21T13:24:20Z")
On peut aussi essayer de permettre aux forgerons de changer de clé. Le problème devait être lié à la mise à jour du storage des authority-members ? Peut-être qu’avec le nouveau mécanisme de lien identité\<-\>compte ce serait plus simple ? La seule condition serait d’être offline.
Un gros problème aussi est que l’extension PolkadotJS ne permet pas d’importer une clé privée qui n’a pas été générée avec un mnemonic. Sinon on pourrait tout faire avec le client PolkadotJS.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [22 November 2023 12:09 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/38 "2023-11-22T12:09:28Z")
@cgeek, il me semble que ton nœud a été HS récemment, donc on a loupé quelques blocs.
> **en dehors de ça, la blockchain est assez précise à deux forgerons**
>
> 
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [22 November 2023 12:12 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/39 "2023-11-22T12:12:45Z")
> [@poka](#):
>
> pour que les smiths puissent utiliser gecko.
> [@tuxmain](#):
>
> permettre aux forgerons de changer de clé
En vrai, ça se fait très vite, et comme les certifications forgeron sont liées à l’identité et pas à la clé, on n’a même pas besoin de redemander des certifications. Ça m’a pris quelques minutes, tout est implémenté dans Ğcli sur ma branche, je ferai une démo vidéo.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [22 November 2023 15:55 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/40 "2023-11-22T15:55:07Z")
> [@HugoTrentesaux](#):
>
> @cgeek, il me semble que ton nœud a été HS récemment, donc on a loupé quelques blocs.
Je ne pense pas, il n’y a eu aucun restart de noté sur le pod et la machine n’a pas rebooté non plus. Par contre j’ai pu perdre la connexion Internet, et si tu étais déjà passé autorité à ce moment-là, ça peut expliquer le loupé.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [23 November 2023 16:14 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/41 "2023-11-23T16:14:08Z")
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…
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [23 November 2023 18:13 UTC](https://forum.duniter.org/t/gdev-runtime-700/11684/42 "2023-11-23T18:13:59Z")
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) :
### Requête
sur [https://subsquid.gdev.coinduf.eu/graphql](https://subsquid.gdev.coinduf.eu/graphql)
tous les calls en succès des pallets `SmithMembership`, `Identity` et `AuthorityMembers`
```graphql
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)
### Réponse
```json
{
"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é :
- bloc [30420](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/30420) je révoque mon identité forgeron
- bloc [30504](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/30504) je change ma clé membre
- bloc [30516](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/30516) je demande l’adhésion forgeron
- bloc [30525](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/30525) je demande à valider mon adhésion forgeron (j’ai déjà les certifications forgeron)
- bloc [30630](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/30630) je set mes session keys une première fois avec Ğcli (après l’avoir implémenté)
- bloc [30776](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/30776) je set mes session keys une deuxième fois avec polkadotjs pour vérifier que c’est le même résultat et que je n’ai pas fait d’erreur de code qui auraient corrompu mes session keys
- bloc [30813](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/30813) je go\_online et commence à participer deux sessions après
Tu verras en étant attentif que j’ai omis quelques calls de trucs que j’ai fait entre temps 🙂
[Previous page](https://forum.duniter.org/t/gdev-runtime-700/11684.md?page=1)
[Next page](https://forum.duniter.org/t/gdev-runtime-700/11684.md?page=3)