Si cela peut aider, ci après la liste des nœuds valides d’après le mien :
Oui @1000i100 il suffit d’arrêter ton nœud, copier la base (dossier duniter_default) en prenant soin de supprimer le fichier keyring.yml qui contient ta clé privée de membre et aussi le fichier conf.json qui va gêner.
A partir de là, on peut stopper notre nœud, recopier directement les fichiers tels quels dans notre propre installation. Puis de redémarrer notre nœud.
Oui j’ai exactement la même erreur. Ceci dit, c’est au bloc 886951 or nous venons de passer au 887951, donc il est possible que la synchro suivante passe. En tout cas je vais tenter.
Sauf si 1000i100 fait un dump entre-temps.
A noter : le dump est agnostic de l’architecture normalement (ARM ou x86 produisent les mêmes data).
Je pense que je vais prendre l’option dump, car de mon côté ça ne veut vraiment pas, peut être par manque de ram sur la machine je ne sais pas (8Go dispo).
Et je n’ai pas accès au proxmox de mmicro pour augmenter la ram de ce container LXC.
Sinon il faut que je lancer un noeud sur une autre machine.
edit: `Ca y est en fait j’ai lancé la sync sur une autre machine avec 20Go de ram.
Changement de DNS effectué, la sync court.
J’ai retrouvé le volume docker “data” lié à mon serveur, dedans j’ai ce contenu (je ne liste que les répertoires)
root@oracle-g1-20221130:/var/lib/docker/volumes/duniter-pini_duniter_data/_data# tree -d
.
└── duniter_default
├── data
│ └── leveldb
│ ├── level_bindex
│ ├── level_blockchain
│ │ ├── actives
│ │ ├── certs
│ │ ├── dividends
│ │ ├── excluded
│ │ ├── forks
│ │ ├── idty
│ │ ├── joiners
│ │ ├── leavers
│ │ ├── revoked
│ │ └── transactions
│ ├── level_cindex
│ │ ├── expiresOn
│ │ └── writtenOn
│ ├── level_dividend
│ │ └── level_dividend_trim_index
│ ├── level_iindex
│ │ ├── hash
│ │ ├── kick
│ │ ├── uid
│ │ └── writtenOn
│ ├── level_mindex
│ │ ├── expiresOn
│ │ ├── revokesOn
│ │ └── writtenOn
│ ├── level_sindex
│ │ ├── complex_condition_pubkeys
│ │ ├── conditions
│ │ ├── consumed_on
│ │ └── written_on
│ └── level_wallet
└── g1
36 directories
Il y a besoin de tout sauf les 2 fichiers “duniter_default/keyring.yml” et “duniter_default/conf.json” ?
Aussi, si je stoppe le serveur pour faire la copie - je risque de faire rater la synchro des autres serveurs… je ne sais pas si je peux tenter une copie des fichiers sans couper le serveur.
Oui.
De mon côté la sync semble se passer beaucoup mieux sur l’autre machine. Probablement le disque qui est beaucoup plus rapide (et plus de ram).
43% de apply.
Une idée de comment fournir l’archive des données depuis mon serveur Ubuntu facilement ?
tar -zcvf duniter-archive.tar.gz \
--exclude='*/keyring.yml' \
--exclude='*/conf.json' \
/var/lib/docker/volumes/duniter-pini_duniter_data/_data/duniter_default
→
Tu peux créer un compte à partir du login de ce forum.
J’ai un tar.gz de 1.7GB
1.7G duniter_v1_data_brussels.ovh.tar.gz
créer un compte et je te met le quota si tu veux.
Tu as bien coupé duniter au moment de faire l’archive ?
Sinon on va se tapper un locker.
Non, j’avais peur de faire foirer la synchro de certain serveurs
Voilà je t’ai mis 10Go de quota.
Tu as raison.
Du coup tente comme ça mais bon, on verra.
J’ai copié dans un autre répertoire avant de faire l’archive
Oui mais ce sont les DB qui seront locké, enfin on peux tester hein.
Sinon tu installes kubo, tu lances le daemon ipfs, et tu fais un ipfs add du dossier sans les 2 fichiers, et tu nous partage le hash ipfs produis. Mais ça va mettre un peu de temps à hasher tout ce dossier.
C’est uploadé - mais je ne vois pas d’option de partage ![]()

le petit bonhome avec le + devant sur la row.
Puis le + du lien de partage
Lien de téléchargement direct: https://cloud.axiom-team.fr/s/TjPLEnx9WGmxK7x/download/duniter_v1_data_brussels.ovh.tar.gz
Je peux refaire en stoppant le serveur si vous préférez; dites moi ![]()
non non je crois qu’on est nombreux à sync à partir de toi en ce moment même, toute la g1 repose sur ton serveur là ^^
no pressure.
