Cannot allocate memory (os error 12) sur raspberry

Avec le paquet debian du dernier build pour la gtest j’obtiens une erreur au lancement de duniter sur mon raspberry :

duniter@aynic:/home/duniter$ /usr/bin/duniter2 --chain ${DUNITER_CHAIN_NAME} --name ${DUNITER_NODE_NAME} --listen-addr ${DUNITER_LISTEN_ADDR} --rpc-cors ${DUNITER_RPC_CORS} --state-pruning ${DUNITER_PRUNING_PROFILE} --base-path ${BASE_PATH} --rpc-methods Unsafe --validator
2025-10-12 07:29:29 Duniter
2025-10-12 07:29:29 ✌️  version 0.12.0-1f6b6584e4e
2025-10-12 07:29:29 ❤️  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-12 07:29:29 📋 Chain specification: ĞTest
2025-10-12 07:29:29 🏷  Node name: aya-gtest-smith
2025-10-12 07:29:29 👤 Role: AUTHORITY
2025-10-12 07:29:29 💾 Database: ParityDb at /home/duniter/.local/share/duniter/chains/gtest/paritydb/full
2025-10-12 07:29:31 Cannot create a runtime error=Other("cannot create the wasmtime engine: failed to create memory pool mapping: mmap failed to allocate 0x6080000000 bytes: Cannot allocate memory (os error 12)")
Error: Service(Client(VersionInvalid("Other error happened while constructing the runtime: cannot create the wasmtime engine: failed to create memory pool mapping: mmap failed to allocate 0x6080000000 bytes: Cannot allocate memory (os error 12)")))

Raspberry Pi 4 Model B Rev 1.4 avec 8Gb de RAM.

1 Like

Il y avait combien de RAM libre ?

Et si tu ajoutes 8 Go de swap ? Peut-être qu’il a besoin de beaucoup de mémoire (peut-être même en virtuel uniquement) au démarrage, mais après ça consomme moins donc le swap ne sera pas utilisé.

1 Like


Il y a plus de 7Go de RAM dispo :

duniter@aynic:/home/duniter$ cat /proc/meminfo
MemTotal:        7998788 kB
MemFree:         4046372 kB
MemAvailable:    7316596 kB
Buffers:          164712 kB
Cached:          2974140 kB
SwapCached:            0 kB
Active:          2086584 kB
Inactive:        1507756 kB

J’ai ajouté 16Go de swap pour tester mais cela ne change rien j’ai toujours le mm message d’erreur.

2025-10-12 09:04:01 Cannot create a runtime error=Other("cannot create the wasmtime engine: failed to create memory pool mapping: mmap failed to allocate 0x6080000000 bytes: Cannot allocate memory (os error 12)")
Error: Service(Client(VersionInvalid("Other error happened while constructing the runtime: cannot create the wasmtime engine: failed to create memory pool mapping: mmap failed to allocate 0x6080000000 bytes: Cannot allocate memory (os error 12)")))

L’OS est en 32 ou 64 bits ? Par défaut Raspbian est en 32 bits même si le CPU supporte le 64. Je ne sais pas si ça peut être ça.

Même problème ici : Erreur duniter sur Raspberry Pi 4 - 2 Go de RAM - #16 by dieudo

C’est un 64 bits.

duniter@aynic:/home/duniter$ uname -a
Linux aynic 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

Le problème n’est pas lié au build debian, j’ai la même erreur en compilant directement sur le raspberry.

aya@aynic:~/Sources/duniter-v2s $ cargo run -Zgit=shallow-deps --no-default-features --features gtest,embed -- --no-telemetry --chain gtest --name aya-testing-raspberry
warning: `/home/aya/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
⚡ Found 3 strongly connected components which includes at least one cycle each
cycle(001) ∈ α: DisputeCoordinator ~~{"DisputeDistributionMessage"}~~> DisputeDistribution ~~{"DisputeCoordinatorMessage"}~~>  *
cycle(002) ∈ β: CandidateBacking ~~{"CollatorProtocolMessage"}~~> CollatorProtocol ~~{"CandidateBackingMessage"}~~>  *
cycle(003) ∈ γ: NetworkBridgeRx ~~{"GossipSupportMessage"}~~> GossipSupport ~~{"NetworkBridgeRxMessage"}~~>  *
warning: gdev-runtime@1.0.0: You are building WASM runtime using `wasm32-unknown-unknown` target, although Rust >= 1.84 supports `wasm32v1-none` target!
warning: gdev-runtime@1.0.0: You can install it with `rustup target add wasm32v1-none --toolchain nightly-2025-08-07-aarch64-unknown-linux-gnu` if you're using `rustup`.
warning: gdev-runtime@1.0.0: After installing `wasm32v1-none` target, you must rebuild WASM runtime from scratch, use `cargo clean` before building.
warning: gtest-runtime@1.0.0: You are building WASM runtime using `wasm32-unknown-unknown` target, although Rust >= 1.84 supports `wasm32v1-none` target!
warning: gtest-runtime@1.0.0: You can install it with `rustup target add wasm32v1-none --toolchain nightly-2025-08-07-aarch64-unknown-linux-gnu` if you're using `rustup`.
warning: gtest-runtime@1.0.0: After installing `wasm32v1-none` target, you must rebuild WASM runtime from scratch, use `cargo clean` before building.
warning: g1-runtime@1.0.0: You are building WASM runtime using `wasm32-unknown-unknown` target, although Rust >= 1.84 supports `wasm32v1-none` target!
warning: g1-runtime@1.0.0: You can install it with `rustup target add wasm32v1-none --toolchain nightly-2025-08-07-aarch64-unknown-linux-gnu` if you're using `rustup`.
warning: g1-runtime@1.0.0: After installing `wasm32v1-none` target, you must rebuild WASM runtime from scratch, use `cargo clean` before building.
warning: field `protocol_id` is never read
   --> node/src/chain_spec/gtest.rs:160:5
    |
153 | pub struct ClientSpec {
    |            ---------- field in this struct
...
160 |     protocol_id: Option<String>,
    |     ^^^^^^^^^^^
    |
    = note: `ClientSpec` has a derived impl for the trait `Clone`, but this is intentionally ignored during dead code analysis
    = note: `#[warn(dead_code)]` on by default

warning: `duniter` (lib) generated 1 warning
warning: `duniter` (bin "duniter") generated 1 warning (1 duplicate)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.36s
warning: the following packages contain code that will be rejected by a future version of Rust: trie-db v0.30.0
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
     Running `target/debug/duniter --no-telemetry --chain gtest --name aya-gtest-raspy`
2025-10-16 17:36:35 Duniter    
2025-10-16 17:36:35 ✌️  version 0.12.0-91e3b99e9f2    
2025-10-16 17:36:35 ❤️  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-16 17:36:35 📋 Chain specification: ĞTest    
2025-10-16 17:36:35 🏷  Node name: aya-testing-raspberry    
2025-10-16 17:36:35 👤 Role: FULL    
2025-10-16 17:36:35 💾 Database: ParityDb at /home/aya/.local/share/duniter/chains/gtest/paritydb/full    
2025-10-16 17:36:55 Cannot create a runtime error=Other("cannot create the wasmtime engine: failed to create memory pool mapping: mmap failed to allocate 0x6080000000 bytes: Cannot allocate memory (os error 12)")
Error: Service(Client(VersionInvalid("Other error happened while constructing the runtime: cannot create the wasmtime engine: failed to create memory pool mapping: mmap failed to allocate 0x6080000000 bytes: Cannot allocate memory (os error 12)")))
cannot create the wasmtime engine

Ça me fait penser à ça :

Peut-être qu’il faudrait l’augmenter encore.

Pas forcément, cela semble spécifique à raspberry, je pense plutôt à ce type de pb : Crash on runtime upgrade related to wasmtime (Raspbian only) · Issue #12538 · paritytech/substrate · GitHub.

Actuellement duniter réserve plus de 512Go de RAM et ca n’est pas possible sur un raspberry
par défaut

Je vais tenter de bidouiller les paramètres et recompiler un kernel de mon côté. Est-ce qu’il est envisageable de maintenir la consommation de RAM de duniter en dessous des 512Go ?

3 Likes

Une solution peut être de ne pas utiliser l’OS édité par Raspberry Pi, qui est juste un Debian en moins bien et avec des trucs propriétaires en plus. J’utilise Debian Raspi qui est un projet communautaire Debian. Expérimental mais ça marche pour moi depuis quelques années. Les images téléchargeables sont un peu vieilles mais on peut les mettre à jour sans problème (enfin je n’ai pas testé le dist-upgrade vers Trixie).

Moi aussi en général je préfère armbian, dietpi ou alpine mais celui là c’est un cadeau de @Frederic_Renault.
Je peux le réinstaller mais cela ne règlera pas le pb pour les autres :slight_smile:
On devrait donc conseiller de ne pas utiliser raspbian pour faire tourner duniter pour le moment ?

À moins qu’il y ait une autre solution simple, puisque ce problème est récurrent, ça semble mieux.

Est-ce que quelqu’un arrive à le faire tourner sur Raspbian ? Il se peut que ce soit un peu aléatoire, si c’est juste un problème d’efficacité de l’allocateur utilisé par Substrate.

@aya avant de recompiler le kernel Linux ou de tout réinstaller, réessaie juste un cargo run de Duniter sur ton raspi en ajoutant l’option
--wasmtime-instantiation-strategy recreate-instance au reste de tes arguments (arguments de Duniter, pas de cargo, donc après --).

Cette option force Wasmtime à ne pas réserver un énorme espace mémoire virtuel, ce qui devrait régler ton problème.


Sinon effectivement passer sur un Debian ARM plus stock devrait aussi régler le soucis.

4 Likes

Waw merci poka mon sauveur !

aya@aynic:~/Sources/duniter-v2s $ cargo run -Zgit=shallow-deps --no-default-features --features gtest,embed -- --no-telemetry --chain gtest --name aya-testing-raspberry --wasmtime-instantiation-strategy recreate-instance
warning: `/home/aya/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
⚡ Found 3 strongly connected components which includes at least one cycle each
cycle(001) ∈ α: DisputeCoordinator ~~{"DisputeDistributionMessage"}~~> DisputeDistribution ~~{"DisputeCoordinatorMessage"}~~>  *
cycle(002) ∈ β: CandidateBacking ~~{"CollatorProtocolMessage"}~~> CollatorProtocol ~~{"CandidateBackingMessage"}~~>  *
cycle(003) ∈ γ: NetworkBridgeRx ~~{"GossipSupportMessage"}~~> GossipSupport ~~{"NetworkBridgeRxMessage"}~~>  *
warning: gtest-runtime@1.0.0: You are building WASM runtime using `wasm32-unknown-unknown` target, although Rust >= 1.84 supports `wasm32v1-none` target!
warning: gtest-runtime@1.0.0: You can install it with `rustup target add wasm32v1-none --toolchain nightly-2025-08-07-aarch64-unknown-linux-gnu` if you're using `rustup`.
warning: gtest-runtime@1.0.0: After installing `wasm32v1-none` target, you must rebuild WASM runtime from scratch, use `cargo clean` before building.
warning: g1-runtime@1.0.0: You are building WASM runtime using `wasm32-unknown-unknown` target, although Rust >= 1.84 supports `wasm32v1-none` target!
warning: g1-runtime@1.0.0: You can install it with `rustup target add wasm32v1-none --toolchain nightly-2025-08-07-aarch64-unknown-linux-gnu` if you're using `rustup`.
warning: g1-runtime@1.0.0: After installing `wasm32v1-none` target, you must rebuild WASM runtime from scratch, use `cargo clean` before building.
warning: gdev-runtime@1.0.0: You are building WASM runtime using `wasm32-unknown-unknown` target, although Rust >= 1.84 supports `wasm32v1-none` target!
warning: gdev-runtime@1.0.0: You can install it with `rustup target add wasm32v1-none --toolchain nightly-2025-08-07-aarch64-unknown-linux-gnu` if you're using `rustup`.
warning: gdev-runtime@1.0.0: After installing `wasm32v1-none` target, you must rebuild WASM runtime from scratch, use `cargo clean` before building.
warning: field `protocol_id` is never read
   --> node/src/chain_spec/gtest.rs:160:5
    |
153 | pub struct ClientSpec {
    |            ---------- field in this struct
...
160 |     protocol_id: Option<String>,
    |     ^^^^^^^^^^^
    |
    = note: `ClientSpec` has a derived impl for the trait `Clone`, but this is intentionally ignored during dead code analysis
    = note: `#[warn(dead_code)]` on by default

warning: `duniter` (lib) generated 1 warning
warning: `duniter` (bin "duniter") generated 1 warning (1 duplicate)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 6.76s
warning: the following packages contain code that will be rejected by a future version of Rust: trie-db v0.30.0
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
     Running `target/debug/duniter --no-telemetry --chain gtest --name aya-testing-raspberry --wasmtime-instantiation-strategy recreate-instance`
2025-10-21 19:39:24 Duniter
2025-10-21 19:39:24 ✌️  version 0.12.0-91e3b99e9f2
2025-10-21 19:39:24 ❤️  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-21 19:39:24 📋 Chain specification: ĞTest
2025-10-21 19:39:24 🏷  Node name: aya-testing-raspberry
2025-10-21 19:39:24 👤 Role: FULL
2025-10-21 19:39:24 💾 Database: ParityDb at /home/aya/.local/share/duniter/chains/gtest/paritydb/full
2025-10-21 19:40:28 🔨 Initializing Genesis block/state (state: 0x2fe3…190b, header-hash: 0xd458…c57a)
2025-10-21 19:40:38 Creating transaction pool txpool_type=ForkAware ready=Limit { count: 8192, total_bytes: 20971520 } future=Limit { count: 819, total_bytes: 2097152 }
2025-10-21 19:40:38 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2025-10-21 19:40:38 👶 Creating empty BABE epoch changes on what appears to be first startup.
2025-10-21 19:40:38 Local node identity is: 12D3KooWH9WRKtiDnEBtgxUndRxkCZdeeUCHYKAQZmo69ZPa1bKk
2025-10-21 19:40:38 Running litep2p network backend
2025-10-21 19:40:38 💻 Operating system: linux
2025-10-21 19:40:38 💻 CPU architecture: aarch64
2025-10-21 19:40:38 💻 Target environment: gnu
2025-10-21 19:40:38 💻 Memory: 7811MB
2025-10-21 19:40:38 💻 Kernel: 6.1.21-v8+
2025-10-21 19:40:38 💻 Linux distribution: Debian GNU/Linux 12 (bookworm)
2025-10-21 19:40:38 💻 Virtual machine: no
2025-10-21 19:40:38 📦 Highest known block at #0
2025-10-21 19:40:38 〽️ Prometheus exporter started at 127.0.0.1:9615
2025-10-21 19:40:38 Running JSON-RPC server: addr=127.0.0.1:9944,[::1]:9944
2025-10-21 19:40:38 ***** Duniter has fully started *****
2025-10-21 19:40:39 maintain txs=(0, 0) a=1 i=0 views=[(1, 0, 0)] event=Finalized { hash: 0x0f4c3576498379c71b0e14cb7022f279cde651706b73450f0edddd24aae9f900, tree_route: [] } duration=3.45845ms
2025-10-21 19:40:43 ⚙️  Syncing, target=#151810 (1 peers), best: #97 (0x767c…1e99), finalized #1 (0x0f4c…f900), ⬇ 145.6kiB/s ⬆ 0.5kiB/s
4 Likes

Chouette !!
Tu nous dira si ça sync sans soucis sur rapsi du coup, et si ça dure :slight_smile:

Rien à voir mais le warning field protocol_id is never read c’est ma faute, c’est en ajoutant ce field manquant au specs sans quoi ça faisait crash la noeud que ce warning est apparu. C’est un field récemment ajouté par substrate, ça a été déplacé d’ailleurs je ne sais plus d’exactement où.

Ca avait été fait sur la gdev par elois mais pas sur gtest, à voir les implications.
Un autre truc que j’ai cassé ce sont les tests de validation des membres sur master suite à un merge un peu rapide de la MR de distance de @tuxmain, je verrai si j’ai le temps de regarder ça prochainement.

Maintenant qu’on voit que ça fonctionne ainsi, tu peux essayer à la place l’option --wasmtime-instantiation-strategy recreate-instance-copy-on-write, qui devrait en théorie fonctionner aussi mais être un peu plus optimisé.

Dans les deux cas on évite le pooling allocator, la seconde option utilise CoW, qui en gros permet d’éviter des lecture/écriture lors de l’instanciation du runtime WASM, qui se fait au démarrage du noeud et lors de runtime upgrade (donc rarement pendant le cycle de vie du programme en général).
Par de défaut le pooling allocator réserve un énorme espace pour la runtime WASM un peu par prévention, ce qui permet ensuite d’aller réinstancier le runtime à la volée très rapidement sans se soucier de la place qu’il prends en RAM.

La stratégie recreate-instance-copy-on-write semble être le meilleurs compromis sur raspi.


Si on confirme la solution, alors il faudrait simplement exposer une variable d’environnement que Duniter écoute et qu’on puisse alors configuré dans notre docker compose, un boolean pour activer ou non cette option.

duniter a démarré avec l’option --wasmtime-instantiation-strategy recreate-instance en réservant moins de 512Go.

Par contre après quelques jours de fonctionnement il semble avoir atteint la limite fatidique :frowning:


et a perdu la synchro (on est actuellement au block 183000)…

Je relance avec la stratégie recreate-instance-copy-on-write pour voir.

Ca plante quelque soit l’option recreate-instance-copy-on-write ou recreate-instance.

Je drop db et relance avec l’option recreate-instance-copy-on-write.
Ca à l’air plus lent mais ça sync…


et ca semble consommer moins de RAM pour le moment.

ca grimpe…


je suis a jour !



a suivre…

3 Likes

Oui a suivre, à monitorer de prêt, pour la science.

Ce qui serait intéressant d’observer c’est l’usage ram et cpu des noeuds pendant un runtime upgrade :wink:

1 Like

Pas la peine d’attendre un runtime upgrade :stuck_out_tongue:


1 Like

duniter démarre correctement avec un kernel debian vanilla, le pb est donc bien lié à la configuration de l’adressage mémoire sur le kernel raspberrypi.

Pour savoir si vous avez un kernel raspberrypi vous pouvez exécuter la commande suivante :

dpkg -l |grep raspberrypi-kernel

Si vous voyez une ligne commençant par ii raspberrypi-kernel alors vous avez un kernel raspberrypi et il est probablement compilé avec l’option CONFIG_ARM64_VA_BITS_39=y.

ii  raspberrypi-kernel                  1:1.20230405-1                                 arm64          Raspberry Pi bootloader

Pour installer un kernel debian sur Raspberry Pi OS (raspbian), il faut supprimer le kernel raspberrypi et installer le kernel debian à la place, en veillant à ce que tous les prérequis nécessaires au boot soit bien respectés car les raspberry ont un mécanisme de boot particulier qui est différent des ordinateurs classiques (un raspi n’a pas de bios, c’est le GPU qui exécute le bootloader). C’est une manipulation délicate qui peut empêcher votre raspberry de redémarrer si elle n’est pas réalisée correctement. Préparez vous à réinstaller votre raspberry si les choses tournent mal et assurez vous que vous avez sauvegardé vos données utiles avant de continuer.

Le plus simple pour un débutant est de réinstaller son raspberry avec une distribution compatible (et/ou de remplacer son raspberry par une board bananapi ou olimex).

Les opérations listées ci-dessous ont fonctionné pour moi mais ne sont données qu’à titre d’exemple et doivent être adaptées à votre configuration. La démarche présentée permet d’installer un kernel debian sur un raspberrypi 4b (64bits) depuis un raspberrypi OS basé sur debian 12 bookworm. La procédure DOIT être adaptée en fonction de votre matériel (armv7/armv8/…) et de votre version de debian (bookworm/trixie/…).

ATTENTION DANGER : effectuer cette manip à distance est (très) risqué, il va falloir redémarrer le raspberry après installation du nouveau noyau et il est possible (et même fort probable :p) que cela ne fonctionne pas du 1er coup et que vous perdiez la main sur votre raspberry.

Voila, maintenant que les avertissements d’usage sont donnés, passons à la description des étapes :

  • configuration des repos debian
  • suppression du kernel raspberry
  • installation du kernel debian
  • vérification des prérequis
  • reboot

Configuration des repos debian

  • vérifier votre version debian
lsb_release -a

  • ajouter les repos debian au fichier /etc/apt/sources.list
deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  • mettre à jour la liste des paquets
apt-get update --allow-insecure-repositories
apt-get install debian-archive-keyring --allow-unauthenticated
apt-get update

Suppression du kernel raspberry

apt-get remove --purge raspberrypi-bootloader raspberrypi-kernel raspi-firmware raspi-config plymouth

Installation du kernel debian

  • préparer la partition de boot
umount /boot
mkdir /boot/firmware
sed -i s+/boot+/boot/firmware+ /etc/fstab
mount /boot/firmware
  • installer les paquets debian
apt-get install linux-image-arm64 raspi-firmware

Si vous avez un message d’avertissement concernant le support des versions de l’initramfs et du kernel, vous n’avez pas désinstallé les paquets rapsberrypi avant d’installer les paquets debian. Veillez à bien désinstaller les paquets raspberrypi avant, surtout le paquet raspi-firmware.

Vérification des prérequis

Si vous avez effectué les commandes dans l’ordre et que vous n’avez pas eu d’erreur, votre système devrait être fonctionnel et prêt à redémarrer.

Si tout ne s’est pas passé comme prévu et/ou que vous êtes prudent, assurez vous d’avoir une configuration fonctionnelle avant de redémarrer. Il vous faut :

  • une partition vfat montée sur /boot/firmware
grep boot /etc/fstab

Capture d’écran 2025-11-06 à 20.34.27

  • une version du kernel linux adaptée à votre raspberry (image-armmp-lpae pour raspi2 et image-arm64 pour raspi3 ou raspi4)
dpkg -l |grep linux-image

  • une config qui pointe vers cette image linux avec son initramfs
ls -l /boot/firmware/|grep arm64
grep arm64 /boot/firmware/config.txt

Si les fichiers vmlinuz et initrd ne sont pas présents, vous pouvez les copier manuellement pour créer les fichiers attendus par défaut (kernel8.img et initramfs8 pour un raspi3 ou raspi4, kernel.img et initramfs pour un raspi2).
Capture d’écran 2025-11-05 à 08.59.42

  • les fichiers de firmware
ls /boot/firmware/bcm*.dtb


Si les fichiers ne sont pas présents, vous pouvez les copier manuellement.

rsync -av /usr/lib/linux-image-*-arm64/broadcom/* /boot/firmware/

  • les fichiers d’overlays
ls /boot/firmware/overlays/*.tdbo

Capture d’écran 2025-11-06 à 21.40.39

Si vous avez chargé des fichiers d’overlay spécifiques dans le fichier config.txt, assurez vous qu’ils soient bien présents dans le répertoire overlays.


Capture d’écran 2025-11-05 à 08.27.07

reboot

Si votre config est fonctionnelle il ne vous reste plus qu’à redémarrer votre raspberry et vérifier la version de votre nouveau kernel.

uname -a
grep -i va_bits /boot/config-*-arm64

Félicitations ! Vous avez désormais un kernel compatible avec duniter v2 :slight_smile:

3 Likes