diglos/ethereumonarm

Tools and scripts to build images that turn ARM devices into ful Ethereum nodes

Ethereum on ARM

Introduction

Ethereum on ARM provides a plug-and-play (PnP) Ubuntu Armbian image for various ARM64 boards, specifically designed to set up and run both Execution and Consensus clients as Systemd services. This turns the device into a Full Ethereum node or a home Staking box, with a focus on lowering the barriers for running Ethereum L1 or L2 nodes.

Supported Devices

• NanoPC-T6
• Rock 5B
• Orange Pi 5 Plus
• Orange Pi 5

Features

• EOA-gui: A console menu interface for easy setup of L1 or L2 Full/Archive nodes. (Alpha Stage)
• Multiple Client Support: Includes Geth, Erigon, Besu, Nethermind, Reth, Prysm, Nimbus, Teku, Lodestar and Lighthouse.
• L2 Support: Compatibility with Optimism, Arbitrum, Polygon, Starknet, and Gnosis.
• Distributed Validator Technology: Research and implementation for enhanced decentralization.
• Client Diversity: Promotion of minority client adoption.
• Advanced Monitoring Solutions: Ready-to-use Prometheus and Grafana dashboards provide comprehensive monitoring capabilities, allowing for detailed insights and analytics of node performance and network health.
• Optimized Operating System Configurations: The project includes several enhancements over the default Armbian settings, specifically optimized for Ethereum node performance and stability, ensuring a smooth and efficient node operation experience.

Installation

Step-by-step guide

Support and Discussion

Join our Discord Channel for support and discussion.

Stay Updated

Follow us on Twitter for the latest updates.

Acknowledgements

Thanks to our community for their ongoing donations and support.

ethereumonarm's Issues

Is this meant to boot from SD card at all times?

I was going to ask this in the discord channel, but it seems like I don't have access.

I've set up my Orange Pi 5 Plus with an NVME, flashed the SD card and ran through the setup. I can ssh to the ethereum account, I've changed my password, and I can see all the ethereum packages available.

One thing I am not clear about—is this meant to be booted from the SD card? I thought the NVME was going to be set up to be the boot volume, but when I boot with the SD card removed, it does not allow me to ssh with the ethereum user. Don't we take a performance hit by running off the SD card?

Two /var/log directories, one gets full very fast

Installed the latest image (ethonarm_21.03.00) on my raspberry pi. I noticed that it has created two var/log directories
(/var/log and /var/log.hdd)
This was not the case in the previous image. There was only one /var/log which was never overflowing.
Also, the /var/log directory gets full very fast.
Is this an config error and how to ensure that all the logs land on this (big) hdd

Unable to sync geth v1.10.25-stable on raspberry pi 4b 8gb post merge

I am running both geth and ligthouse beacon on the same raspberry pi 4 model b node with 8gb RAM, and a 2TB nvme gen4 disk, that supports 5150mb/s reads, and 4850 mb/s writes, with a 1.2 gbe internet connection

Geth is stuck around 60 blocks below a complete sync, which took about 2 days to reach this state, and has been healing trienodes for about a week since. Pre-merge, geth on its own was able to reach 60 blocks below a complete sync in 2 days, and took about 1 day to heal trienodes to reach a complete sync

I am not running a lighthouse validator node, as I only need beacon so that geth will sync so that I can use the node to make API queries against

I tried various different --cache settings for geth, such as 1024, 2048, 3072, 4096 etc, and nothing seems to help. I am wondering if the RPi 4b with 4 cores and 8gb RAM is not powerful enough to run both geth and lighthouse beacon on the same node, preventing geth from having enough resources to reach a full sync. Maybe it is a resource constraint issue?

I'd like to ask if anyone else is having this issue and if there is a way to potentially resolve the issue, or if you are able to successfully run both geth and lighthouse together on the Rpi4b

Any guidance is most appreciated. I may try to upgrade to the latest unstable version of geth to see if that might help resolve the issue, as some people have reported the issue could be with geth v1.10.25

Clarification on documentation?

Amazing project. I've read through the documentation here but it wasn't explicitly clear if i could run the consensus layer on mainnet? Is that possible?

Broken Settings after update (Grafana / Geth)

Hi!

I recently did a new install with the 1.0 preconfigured image on a new Pi 4
I directly updated geth to latest version (by adding the repo and update it like explained in the documentation)

Not sure if it's due to geth update or if I did update grafana as well without noticing, but the process broke the grafana dashboard. I had to start again grafana-server.service manually because I wasn't seeing anything at the http://node_ip:3000 url.

Now that I can connect to Grafana, data sources and dashboards are all gone. Managed to find the dashboard used on Grafana's website but I don't know what is the correct configuration for Prometheus data source.

Which services need to be running for it to work? Which configuration should I enter to setup the datasource?

Thanks in advance and have a great day!

Edit : I assume the prometheus.yml file got overwritten, if someone can upload their

Disable Ubuntu cloud init

The Ubuntu server image ships with the cloud init feature turned on by default. This is completely redundant for this image, because the customization is baked into the ethereumonarm image, and does not at all rely on the Ubuntu cloud-init machinery to customize networking, storage, ssh, etc...

Probably best to just turn it off in rc.local and save a little bit of memory

sudo echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

https://askubuntu.com/a/1031626
https://askubuntu.com/questions/1060062/im-using-ubuntu-server-for-a-simple-home-server-do-i-need-cloud-init

Validator graphs not showing data in grafana

I have a running validator, and most of my other data is showing in graphs through grafana, but for some reason, my validator graphs are missing data. Am I missing something? I can't seem to find any specifics around this in the guide.

Not compatible with new raspberry pi 4B - 8GB

I just purchased a new raspberry pi 4B and trying to boot with ethonarm_21.03.00.img.zip fails.

start.4elf: is not compatible
This board requires newer software
Get the latest software from https://www.raspberrypi.org/downloads/

Looking at other forum it seems that newest raspberry need updated OS. See https://raspberrypi.stackexchange.com/questions/127325/raspberry-pi-not-booting-recover4-elf-is-not-compatible

Seems a pi with geth no longer manages to sync

It's been a month. Recommended hardware (4gb pi + active cooling + 1TB ssd + 200mbps connection). Block headers look good, state trie looks neverending.

May 28 09:42:36 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:36.100] Imported new block receipts              count=64   elapsed=661.907ms   number=12522015 hash="b2018b…8c6303" age=15m8s    size=7.83MiB
May 28 09:42:38 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:38.423] Imported new state entries               count=768  elapsed=29.046ms    processed=1001037433 pending=40452  trieretry=2    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:39 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:39.245] Imported new state entries               count=273  elapsed="7.204µs"   processed=1001037706 pending=4319   trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:41 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:41.265] Imported new state entries               count=384  elapsed="7.389µs"   processed=1001038090 pending=5682   trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:43 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:43.084] Imported new state entries               count=384  elapsed="7.351µs"   processed=1001038474 pending=7010   trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:44 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:44.797] Imported new state entries               count=384  elapsed="7.889µs"   processed=1001038858 pending=8299   trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:46 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:46.395] Imported new state entries               count=384  elapsed="14.722µs"  processed=1001039242 pending=9598   trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:47 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:47.854] Imported new state entries               count=384  elapsed="7.351µs"   processed=1001039626 pending=10935  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:48 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:48.331] Imported new state entries               count=206  elapsed="7.445µs"   processed=1001039832 pending=14220  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:49 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:49.662] Imported new state entries               count=384  elapsed="8.315µs"   processed=1001040216 pending=15526  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:50 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:50.965] Imported new state entries               count=384  elapsed="7.63µs"    processed=1001040600 pending=17461  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:51 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:51.884] Imported new state entries               count=384  elapsed="7.129µs"   processed=1001040984 pending=23605  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:52 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:52.728] Imported new state entries               count=384  elapsed="17.926µs"  processed=1001041368 pending=29749  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:53 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:53.633] Imported new state entries               count=384  elapsed="7.999µs"   processed=1001041752 pending=35893  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:42:57 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:42:57.977] Imported new state entries               count=384  elapsed="6.314µs"   processed=1001042136 pending=36323  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:01 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:01.682] Imported new state entries               count=384  elapsed="15.463µs"  processed=1001042520 pending=36767  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:05 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:05.267] Imported new state entries               count=384  elapsed="10.315µs"  processed=1001042904 pending=37183  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:08 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:08.709] Imported new state entries               count=384  elapsed="7.444µs"   processed=1001043288 pending=37612  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:12 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:12.627] Imported new state entries               count=384  elapsed="19.796µs"  processed=1001043672 pending=38037  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:16 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:16.004] Imported new state entries               count=384  elapsed=5.400ms     processed=1001044056 pending=38467  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:19 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:19.289] Imported new state entries               count=384  elapsed="7.741µs"   processed=1001044440 pending=38902  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:22 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:22.656] Imported new state entries               count=384  elapsed="22.315µs"  processed=1001044824 pending=39330  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:25 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:25.989] Imported new state entries               count=384  elapsed="7.666µs"   processed=1001045208 pending=39763  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:27 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:27.867] Imported new block headers               count=1    elapsed=551.826ms   number=12522079 hash="793681…ca082d" age=1m28s
May 28 09:43:28 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:28.567] Downloader queue stats                   receiptTasks=0    blockTasks=0    itemSize=252.00KiB throttle=261
May 28 09:43:29 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:29.516] Imported new state entries               count=384  elapsed="162.461µs" processed=1001045592 pending=40192  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:30 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:30.528] Imported new block headers               count=1    elapsed=16.692ms    number=12522080 hash="322704…e31f18" age=1m21s
May 28 09:43:32 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:32.874] Imported new state entries               count=384  elapsed="131.165µs" processed=1001045976 pending=40608  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:33 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:33.728] Imported new block headers               count=1    elapsed=13.803ms    number=12522081 hash="ed0a88…a9d18d" age=1m1s
May 28 09:43:36 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:36.335] Imported new state entries               count=384  elapsed="7.408µs"   processed=1001046360 pending=41032  trieretry=4    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:45 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:45.146] Imported new state entries               count=384  elapsed="222.052µs" processed=1001046744 pending=41413  trieretry=2    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:46 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:46.762] Imported new block headers               count=1    elapsed=540.141ms   number=12522082 hash="945f0b…d57a3b"
May 28 09:43:54 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:54.626] Imported new state entries               count=384  elapsed="364.088µs" processed=1001047128 pending=41792  trieretry=2    coderetry=0 duplicate=763 unexpected=3267
May 28 09:43:55 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:43:55.720] Imported new block headers               count=1    elapsed=85.125ms    number=12522083 hash="f942ce…066d95"
May 28 09:44:04 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:44:04.028] Imported new state entries               count=384  elapsed="15.389µs"  processed=1001047512 pending=42181  trieretry=0    coderetry=0 duplicate=763 unexpected=3267
May 28 09:44:08 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:44:08.521] Imported new block headers               count=1    elapsed=366.077ms   number=12522084 hash="ee90aa…bcf542"
May 28 09:44:13 ethereumonarm-2d3f714f1 geth[451683]: INFO [05-28|09:44:13.767] Imported new state entries               count=384  elapsed=3.580ms     processed=1001047896 pending=42565  trieretry=0    coderetry=0 duplicate=763 unexpected=3267

Going to try OpenEthereum now. From what I understand it wouldn't get stuck on the state trie. Shame that there's no Grafana dashboard, maybe I can enable metrics and pluck one from somewhere.

This issue can be closed, just thought it be good to report in case others try setting up a Pi + Geth and find they're still not synched weeks later.

Perhaps someone also has suggestions for how to get the pi synched. Running with default arguments:

ExecStart=/usr/bin/geth --http --http.port 8545 --http.addr 0.0.0.0 --http.corsdomain '*' --cache 2048 --metrics --metrics.expensive --pprof --http --snapshot=false

Slow SSH logins

I noticed that SSH logins are excruciatingly slow with this Ubuntu server image.

I did some troubleshooting by passing the -vv flag to ssh to see what it was getting hung up on, and it was getting stuck on "pledge: network".

This is caused by an optional pluggable authentication module (PAM).
https://serverfault.com/a/998761

Commenting out

session optional pam_systemd.so

in /etc/pam.d/common-session solves this slow SSH login issue. This might be worth adding to the rc.local via a sed command

sed -i 's|session\soptional\s\bpam_systemd.so|#session optional pam_systemd.so|g' /etc/pam.d/common-session

Sources:

• https://serverfault.com/a/998761
• https://jrs-s.net/2017/07/01/slow-ssh-logins/

Instructions on how to install MEV

Can you please give instructions on how to install MEV-boost on already installed raspberry. I can't find the package in the apt.ethraspbian.com repository.

start4.elf is not compatible

"start4.elf: is not compatible
This board requires newer software"

Stuck in a loop with this error on a brand new pi 4 model b. Is this not compatible with the latest board?

Cannot resize mmcblk0p2 and partition is full

I'm using a 64G SD card, but the second partition has a file system that is only 3.3G in size as shown by df -H. The logs fill this up fairly quickly.

sudo fdisk -l shows that the partition is actually 59.2G.

resize2fs doesn't work, with the following error:

ethereum@ethnode-ef390432:~$ sudo resize2fs /dev/mmcblk0p2
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 8
Performing an on-line resize of /dev/mmcblk0p2 to 15526139 (4k) blocks.
resize2fs: Invalid argument While trying to add group #25

dmesg reveals:

[   28.229176] EXT4-fs (mmcblk0p2): resizing filesystem from 819200 to 15526139 blocks
[   28.310292] EXT4-fs warning (device mmcblk0p2): verify_reserved_gdb:778: reserved GDT 4 missing grp 1 (32772)
[   28.310304] EXT4-fs warning (device mmcblk0p2): ext4_resize_fs:2119: error (-22) occurred during file system resize
[   28.310309] EXT4-fs (mmcblk0p2): resized filesystem to 819200

I've tried using fdisk to delete and recreate the second partition, and rebooting. resize2fs still doesn't resize after that.

The error also occurs if I try to resize using my Ubuntu desktop PC with the SD card mounted.

typo on the doc

docs/goerli/goerli.rst

typo:
sudo systemctl start ligthouse-beacon-prater

Should be :
sudo systemctl start lighthouse-beacon-prater

Failed to start geth

Hi! I haven't been able to get my raspberry pi 4 up and running, The follow is what I get when I check the logs upon start up. I am following the instructions on the readthedocs so not sure what's wrong. Any help would be appreciated...thanks!

-- Logs begin at Wed 2020-04-01 17:23:43 UTC. --
Apr 22 03:55:33 ethereumonarm-37ed4dd2b geth[2725]: INFO [04-22|03:55:33.087] Maximum peer count ETH=50 LES=0 total=50
Apr 22 03:55:33 ethereumonarm-37ed4dd2b geth[2725]: INFO [04-22|03:55:33.087] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory"
Apr 22 03:55:33 ethereumonarm-37ed4dd2b geth[2725]: Fatal: Failed to create the protocol stack: mkdir /home/ethereum: permission denied
Apr 22 03:55:33 ethereumonarm-37ed4dd2b systemd[1]: geth.service: Main process exited, code=exited, status=1/FAILURE
Apr 22 03:55:33 ethereumonarm-37ed4dd2b systemd[1]: geth.service: Failed with result 'exit-code'.
Apr 22 03:55:33 ethereumonarm-37ed4dd2b systemd[1]: geth.service: Scheduled restart job, restart counter is at 5.
Apr 22 03:55:33 ethereumonarm-37ed4dd2b systemd[1]: Stopped Ethereum geth client daemon by The Ethereum Foundation.
Apr 22 03:55:33 ethereumonarm-37ed4dd2b systemd[1]: geth.service: Start request repeated too quickly.
Apr 22 03:55:33 ethereumonarm-37ed4dd2b systemd[1]: geth.service: Failed with result 'exit-code'.
Apr 22 03:55:33 ethereumonarm-37ed4dd2b systemd[1]: Failed to start Ethereum geth client daemon by The Ethereum Foundation.

[Bug] Dashboards not working

A fix that also worked for me, from r3dDoX in the Discord:

After checking the prometheus.yml I saw that the configs should all be under: /etc/prometheus/files_sd. This folder is not there on my machine though. So I copied it from the github repo under: fpm-package-builder/utils/ethereumonarm-monitoring-extras/sources/usr/lib/ethereumonarm. And now my Grafana Dashboard seems to slowly get data in 👍

I can look into fixing this at some point, but wanted to put it here in case someone else wants to.

ethonarm_21.03.00 won't finish setup

I flashed my sd card with this image a few times today and the setup never finished.

Final result is an empty home folder and no geth.service running.

It seems cloud-final.service fails to start Execute cloud user/final scripts. (see image).

Output of sudo systemctl

Image: ethonarm_21.03.00.img.zip
The hash matches 725359703b7c321f56a0e193be61c1f0102a23463549285e8f286e9fb6cc522f

Hardware

    Raspberry 4 (model B 8GB);
    MicroSD Card (128 GB);
    4 TB SSD USB 3.0 disk or an SSD with an USB to SATA case;
    Connected to internet via cable .

Websocket Error

When I try to connect to the geth websocket I am getting the following error:

2021/07/21 13:55:07 websocket: bad handshake (HTTP status 200 OK)

Put lighthouse v4.4.1 on apt repo

When you find time it would be nice to have the newest lighthouse version on the repo.

kubo (ipfs) not getting installed by default with ethonarm_rock5b_22.12.00.img.zip

After writing the image to disk and launching the system (rock5b), ipfs/kubo is not found on the system.

However, running:
sudo apt update && sudo apt install kubo
does install kubo/ipfs version 0.14.0 from the repo

When running the Makefile in the ethereumonarm/fpm-package-builder/kubo/, it creates kubo_0.18.1-0_arm64.deb in ../packages/ which is a much newer version than what is installed when manually updating and installing from the repo

Not sure where in the image installation that kubo fails to install and setup the ipfs.conf and ipfs.service

Add support for more SBC

I was wondering to buy a SBC to run my own eth node, currently this project support Rasp Pi4, Odroid M1 and Rock5B.. But can't find the Rock5B anywhere, Pi4 is old and unjustifiably expensive, Odroid M1 not really good both on RAM and CPU.. Imo the Khadas VIM4 looks a good alternative for the Rock5B is it possible to support it too? Or even better, is there a dev guide to add support for other SBC?

Thanks!

FAT Volume Not Supported

This is on the latest image ethonarm_22.04.00.img. I've tried re-flashing multiple cards and I get the same error. I see 0x0b for the format type on the error screen, is that expected?

ipfs not included with ethonarm_22.04.00.img.zip

The documentation here Updating Clients says ipfs is an available package. I am running this image and noticed that ipfs was never installed, there is no ipfs service listed or running, and there is no ipfs.conf file included. Has this been removed or is it a bug and just missing from this particular img version?

geth version 1.12.2

I noticed that a new geth version is out for a little bit now but has not yet made its way into the apt repository. Will this be updated soon?
Is there a way we could help with this?

credentials : username: ethereum and password ethereum not working to login on image (O droid M1)

Hello,

I have been following the instructions to use this disk image in these docs: https://ethereum-on-arm-documentation.readthedocs.io/

Specially, I just used the disk image: ethonarm_odroid_22.07.00.img downloaded from https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/EejUgF6sH55EoUY3Pc34jwEBMIwIxYmJYDUqfGp0TJ1Eyw?download=1 to flash my SD card. When I then boot the device the credentials do not seem to work to login, not directly or via SSH.

For comparison I just replaced the image with an Ubuntu server image from here: https://wiki.odroid.com/odroid-m1/os_images/ubuntu/20220318

and the login works fine both directly and via SSH.

Sorry if this isn't the place to report this, I really wasn't sure where else to mention it.

I'm flashing the drive on macOS Version 13.2.1 and installing on an O Droid M1 that I just purchased.

Unsupported board type

I bought a new Raspberry PI 4 with 8Gb, and, apparently, it's not supported by the ethereumonarm image. The device won't boot: the green led keeps signaling 4 long and 4 short blinks, which means "Unsupported board type" (source).

My /proc/cpuinfo:

Hardware	: BCM2711
Revision	: d03115
Serial		: 100000008bd5d2bb
Model		: Raspberry Pi 4 Model B Rev 1.5

Is this repo maintained? tests on rpi don't work

hello!
is this repo maintaned?
i followed instructions for installation but seems it doesn't work
even clients are not being installed and of course services (like lighthouse) cannot be started...

in logs i see the eth repo was installed properly but then installlation of packages fails, for example:
Jun 22 05:33:18 ubuntu rc.local[2243]: Package eth2.0-deposit-cli is not available, but is referred to by another package.

so not really usable :(

Swap usage consistently climbs over time, requiring periodic reboots to mitigate.

I've observed a consistent increase in the "Swap used" metric, reaching levels at least 50% usage after extended periods of uptime on an OrangePi 5 Plus with 16GB of RAM. Despite small fluctuations, the trend is consistently upward, necessitating a system reboot to restore swap levels to reasonable values.

After 2.3 hours of uptime:

After 5 days of uptime:

In the following graph, the only points where swap is close to 0% is after a reboot. After reboot, it gradually increases again:

On an OrangePi 5 Plus with 16GB of RAM.
Running:
geth v1.13.4
lighthouse v4.5.0

Even after a reboot, the upward trend resumes.

Is there a memory leak causing this increase in swap usage?

Swap file not getting mounted automatically

Testing out the thereumonarm-armbian-extra package and I noticed that the swap file that gets set up by the postinstall script doesn't get mounted after a reboot. Running the systemctl enable dphys-swapfile command manually seems to bring it back up.

~$ sudo cat /proc/swaps
Filename				Type		Size	Used	Priority
/dev/zram0                              partition	1599744	0	5

~$ sudo systemctl enable dphys-swapfile
Synchronizing state of dphys-swapfile.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable dphys-swapfile

~$ sudo cat /proc/swaps
Filename				Type		Size	Used	Priority
/dev/zram0                              partition	1599744	0	5
/home/ethereum/swapfile                 file		8388604	0	-2

Has anyone done any analysis on how often you burn through ZRAM and end up using swap? I would hope never, but I'm just curious

Also curious about the rationale for splicing the armbian ZRAM config into a custom package. What advantages/disadvantages do you see vs a pre-packaged zram swap script like this one?

NO_PUBKEY 8A584409D327B0A5

Hello. The script fails to add the APT EthRaspbian repository - NO_PUBKEY 8A584409D327B0A5

Lighthouse Quic Port

https://lighthouse-blog.sigmaprime.io/Quic.html
and
https://github.com/sigp/lighthouse/releases/tag/v4.5.0

Lighthouse clients as of v4.5.0, are able to to utilize a faster protocol than tcp, a protocol running on udp, called quic that benchmarks better in latency / bandwidth.

To enable this intra-lighthouse feature and gain the advantages you would need to allow port 9001/udp via the ufw rules you have in fpm-package-builder/utils/ethereumonarm-monitoring-extras/sources/usr/lib/ethereumonarm/user.rules

Cheers =)

Snap Sync Duration 3 months to years?

First of all thank you for your awesome work!

I am following your instructions to install an Eth1 node with this Raspberry Pi 4 B 1,5 GHz 64-Bit-Quad-Core 8GB LPDDR4-3200 SDRAM. I also bough the Samsung T7 Portable SSD - 2 TB which is connected on USB 3.

After 3.5 days of sync this is my status:

    State heal in progress 
    accounts=2,222,[email protected] 
    slots=3,376,[email protected] 
    [email protected] 
    nodes=28,840,[email protected] 
    pending=30434

I am trying to get a sense of the progress and compare it to these numers Peter put out a year ago:

Am I interpreting correctly that my progress (towards reaching a 1 year old block) is something between 0,4% and 4,7% after 4 days? So 3 months - couple years to reach the tip?

Console log:

Erigon timeout on normal shutdown

When Erigon is using swap space instead of physical memory on a RPI 4B 8g during initial sync [7/16 Execution]. It can take a very long time to shutdown. It might be a good idea to update the service to allow a longer shutdown.

I don't have full logs, but basically it took around 5 minutes to shut down with 14GB of memory used. This is important since if it doesn't save the DB successfully it won't save progress of sync, and really the only way to sync with reasonable speed right now on Erigon is to keep restarting it.

I updated my service to 15 minutes just to be safe, but 10 minutes would probably be sufficent.

[Service]
EnvironmentFile=/etc/ethereum/erigon.conf
ExecStart=/usr/bin/erigon $ARGS
Restart=always
RestartSec=5
User=ethereum
TimeoutStopSec=900

Missing unix command for monitoring client logs

should be something like: sudo journalctl -u lh-geth-beacon -f

Nethermind version 1.14.0 crashes on PI4-8gb

Dit a fresh install on my Raspberry PI 4 (8gb). Only thing running is Nethermind (sudo systemctl start nethermind-goerli)
It crashes right after start due to what seems OOM

Same issue at a different place in the log:

Flashed SD card from: ethonarm_22.04.00.img.zip

Never had problems with Nethermind in the past running on RPI4.
On the console:

Is NanoPC-T4 still supported?

I'm trying to boot the latest image (March 2021 v21.03.00) on the NanoPC-T4. Unsure why it's not booting automatically from the SD card after using Etcher to write the image. It used to prioritize SD boot before the eMMC. Now it just boots right into the eMMC.

is it a problem with the disk?

i ran in to following issue:

04 00 00
May 7 14:35:26 ethereumonarm-4c4e87048 kernel: [ 2530.608415] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 21 inflight: CMD OUT
May 7 14:35:26 ethereumonarm-4c4e87048 kernel: [ 2530.608423] sd 0:0:0:0: [sda] tag#3 CDB: Write(10) 2a 00 00 cc 94 00 00 04 00 00
May 7 14:35:26 ethereumonarm-4c4e87048 kernel: [ 2530.614806] sd 0:0:0:0: [sda] tag#8 uas_eh_abort_handler 0 uas-tag 27 inflight: CMD OUT
May 7 14:35:26 ethereumonarm-4c4e87048 kernel: [ 2530.614818] sd 0:0:0:0: [sda] tag#8 CDB: Write(10) 2a 00 00 d2 94 00 00 04 00 00
May 7 14:35:30 ethereumonarm-4c4e87048 kernel: [ 2535.174869] sd 0:0:0:0: [sda] tag#9 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD IN
May 7 14:35:30 ethereumonarm-4c4e87048 kernel: [ 2535.174887] sd 0:0:0:0: [sda] tag#9 CDB: Read(10) 28 00 00 6e 13 a0 00 00 08 00
May 7 14:35:32 ethereumonarm-4c4e87048 kernel: [ 2537.126896] sd 0:0:0:0: [sda] tag#10 uas_eh_abort_handler 0 uas-tag 29 inflight: CMD IN
May 7 14:35:32 ethereumonarm-4c4e87048 kernel: [ 2537.126914] sd 0:0:0:0: [sda] tag#10 CDB: Read(10) 28 00 00 10 38 d0 00 00 08 00
May 7 14:35:32 ethereumonarm-4c4e87048 kernel: [ 2537.142905] scsi host0: uas_eh_device_reset_handler start
May 7 14:35:37 ethereumonarm-4c4e87048 kernel: [ 2542.331180] xhci_hcd 0000:01:00.0: Timeout while waiting for setup device command
May 7 14:35:43 ethereumonarm-4c4e87048 kernel: [ 2547.707224] xhci_hcd 0000:01:00.0: Timeout while waiting for setup device command
May 7 14:35:43 ethereumonarm-4c4e87048 kernel: [ 2547.915023] usb 2-1: device not accepting address 2, error -62

Missing journalctl logs

Sync has been running on my Raspberry Pi 4 8GB with Samsung 2TB T7 for almost 4 days now. Geth fell over after about 6 hours of syncing, which I noticed in the morning and restarted it. It completed the head and state download and has now been on the state healing phase for about 32 hours.

The journalctl logs seem to be truncate regularly, they only hold about 9 hours of geth logs. Looking in the log.hdd directory I found more logs, but these have large gaps in them, which meant I was unable to find any logs around the time when geth crashed:

Aug 26 21:22:46 ethereumonarm-2c6005e5d geth[974]: INFO [08-26|19:22:46.298] Imported new block headers               count=0    elapsed=66.770ms  number=14,681,951 hash=088fd1..5830d8 age=3mo4w20h   ignored=192
Aug 26 21:22:46 ethereumonarm-2c6005e5d geth[974]: INFO [08-26|19:22:46.588] Imported new block headers               count=0    elapsed=35.808ms  number=14,682,143 hash=9cb765..80dbed age=3mo4w19h   ignored=192
Aug 26 21:22:46 ethereumonarm-2c6005e5d geth[974]: INFO [08-26|19:22:46.592] Imported new block receipts              count=24   elapsed=358.446ms number=14,678,445 hash=770680..3ea87a age=3mo4w1d    size=1.31MiB
Aug 26 21:22:47 ethereumonarm-2c6005e5d geth[974]: INFO [08-26|19:22:47.533] Imported new block receipts              count=23   elapsed=939.160ms number=14,678,468 hash=f40945..6939d6 age=3mo4w1d    size=1.21MiB
Aug 26 21:22:47 ethereumonarm-2c6005e5d geth[974]: INFO [08-26|19:22:47.656] Imported new block headers               count=0    elapsed=729.754ms number=14,682,335 hash=d3e2cf..1d1605 age=3mo4w19h   ignored=192
Aug 27 17:00:20 ethereumonarm-2c6005e5d geth[24835]: INFO [08-27|15:00:20.514] Imported new block receipts              count=19   elapsed=131.671ms   number=15,420,229 hash=bc9e30..0f194e age=7h39m52s  size=2.22MiB
Aug 27 17:00:21 ethereumonarm-2c6005e5d geth[24835]: INFO [08-27|15:00:21.468] Imported new block headers               count=192  elapsed=70.297ms    number=15,421,720 hash=e79203..d934dc age=1h55m36s
Aug 27 17:00:21 ethereumonarm-2c6005e5d geth[24835]: INFO [08-27|15:00:21.667] Imported new block receipts              count=17   elapsed=274.702ms   number=15,420,246 hash=01683f..74c5dd age=7h36m51s  size=3.30MiB

Looking in other logs it looks like the log system may be running out of space sometimes. Any idea why that might be? Could a space issue have caused geth to crash, and failing to complete syncing?

Aug 27 02:00:04 ethereumonarm-2c6005e5d systemd[1]: Starting Rotate log files...
Aug 27 02:00:04 ethereumonarm-2c6005e5d systemd[1]: Starting Daily man-db regeneration...
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20874]: Sat Aug 27 00:00:04 UTC 2022: Syncing logs to storage
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: sending incremental file list
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: ./
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: alternatives.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: armbian-hardware-monitor.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: auth.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: boot.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: btmp
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: cloud-init-output.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: cloud-init.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: dpkg.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: kern.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: lastlog
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: syslog
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: ubuntu-advantage-timer.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: wtmp
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: apt/
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: apt/eipp.log.xz
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: apt/history.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: apt/term.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: grafana/
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: grafana/grafana.log
Aug 27 02:00:04 ethereumonarm-2c6005e5d armbian-ramlog[20878]: grafana/grafana.log.2022-08-27.001
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20916]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20917]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20922]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20923]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20924]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20925]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20927]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20928]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d armbian-ramlog[20936]: cat: write error: No space left on device
Aug 27 02:00:07 ethereumonarm-2c6005e5d rsyslogd[900]:  message repeated 3 times: [[origin software="rsyslogd" swVersion="8.2001.0" x-pid="900" x-info="https://www.rsyslog.com"] rsyslogd was HUPed]
Aug 27 02:00:07 ethereumonarm-2c6005e5d rsyslogd[900]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try>
Aug 27 02:00:07 ethereumonarm-2c6005e5d rsyslogd[900]: action 'action-3-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2>
Aug 27 02:00:07 ethereumonarm-2c6005e5d rsyslogd[900]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2001.0 try>

here's the output from df:

Filesystem      Size  Used Avail Use% Mounted on
udev            3.8G     0  3.8G   0% /dev
tmpfs           782M  3.1M  779M   1% /run
/dev/mmcblk0p2   29G  6.7G   21G  25% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/loop2       61M   61M     0 100% /snap/lxd/21843
/dev/sda1       1.8T  582G  1.2T  34% /home
/dev/loop1       58M   58M     0 100% /snap/core20/1614
/dev/loop0       58M   58M     0 100% /snap/core20/1332
/dev/loop5       41M   41M     0 100% /snap/snapd/16299
/dev/loop3       38M   38M     0 100% /snap/snapd/14982
/dev/loop4       62M   62M     0 100% /snap/lxd/22761
/dev/mmcblk0p1  253M   61M  192M  24% /boot/firmware
/dev/zram2       73M  104K   68M   1% /tmp
/dev/zram1       49M   33M   12M  74% /var/log
tmpfs           782M     0  782M   0% /run/user/1001

Separately, I also noticed quite a few grafana warnings:

Aug 25 21:31:00 ethereumonarm-2c6005e5d grafana-server[975]: logger=ngalert t=2022-08-25T19:31:00.012582311Z level=warn msg="rule declares one or many reserved labels. Those rules labels will be ignored" labels=
"alertname=VALIDATOR: Hourly earning <= 0"
Aug 25 21:31:01 ethereumonarm-2c6005e5d grafana-server[975]: logger=ngalert t=2022-08-25T19:31:01.45294029Z level=warn msg="rule declares one or many reserved labels. Those rules labels will be ignored" labels="
alertname=VALIDATOR: Validator has been slashed"
Aug 25 21:31:02 ethereumonarm-2c6005e5d grafana-server[975]: logger=ngalert t=2022-08-25T19:31:02.890755983Z level=warn msg="rule declares one or many reserved labels. Those rules labels will be ignored" labels=
"alertname=WARN NODE/VALIDATOR: The process just restarted"
Aug 25 21:31:04 ethereumonarm-2c6005e5d grafana-server[975]: logger=ngalert t=2022-08-25T19:31:04.31123422Z level=warn msg="rule declares one or many reserved labels. Those rules labels will be ignored" labels="
alertname=NETWORK: Participation rate below 66%"
Aug 25 21:31:05 ethereumonarm-2c6005e5d grafana-server[975]: logger=ngalert t=2022-08-25T19:31:05.739122193Z level=warn msg="rule declares one or many reserved labels. Those rules labels will be ignored" labels=
"alertname=NODE/VALIDATOR: Process down"

State heal in progress

Trying to get a Geth node to run on a RP4 with 8GB RAM and 2 TB USB 3.0 SSD. However, after the state sync is completed, it goes straight into a state heal. Is this expected, and if so, how long will this phase take? If it's not expected, what went wrong and how to fix?

Jul 19 19:56:17 ethereumonarm-f93a22f29 geth[79761]: INFO [07-19|19:56:17.276] State sync in progress                   synced=99.98% state=131.91GiB  accounts=159,411,[email protected] slots=486,178,[email protected] codes=418,[email protected]    eta=-1m55.188s
Jul 19 19:56:17 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:17.964] Checkpoint challenge timed out, dropping id=71f102b6bfe7d8c8 conn=inbound addr=54.73.15.74:51648                 type=OpenEthereum/v3.2.6-...
Jul 19 19:56:20 ethereumonarm-f93a22f29 geth[79761]: INFO [07-19|19:56:20.647] Imported new block receipts              count=678  elapsed=5.601s     number=12,858,945 hash=f629cd..396da8 age=15m9s      size=78.64MiB
Jul 19 19:56:21 ethereumonarm-f93a22f29 geth[79761]: INFO [07-19|19:56:21.351] State sync in progress                   synced=99.99% state=131.92GiB  accounts=159,433,[email protected] slots=486,194,[email protected] codes=418,[email protected]    eta=-2m9.177s
Jul 19 19:56:21 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:21.616] Unexpected account range packet          peer=27ddc68d         reqid=4,939,331,682,164,732,091
Jul 19 19:56:24 ethereumonarm-f93a22f29 geth[79761]: INFO [07-19|19:56:24.224] State sync in progress                   synced=100.00% state=131.93GiB  accounts=159,441,[email protected] slots=486,198,[email protected] codes=418,[email protected]    eta=-2m16.058s
Jul 19 19:56:24 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:24.863] Checkpoint challenge timed out, dropping id=9c6767a3e0f65bc7 conn=dyndial addr=208.59.38.47:30303                type=Geth/v1.10.5-stable-...
Jul 19 19:56:37 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:37.088] Checkpoint challenge timed out, dropping id=f1f3099a705be65f conn=inbound addr=186.22.18.201:56358               type=erigon/v2021.07.3-al...
Jul 19 19:56:40 ethereumonarm-f93a22f29 geth[79761]: INFO [07-19|19:56:40.564] State heal in progress                   [email protected]              [email protected]              [email protected]            [email protected] pending=5609
Jul 19 19:56:40 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:40.571] Unexpected trienode heal packet          peer=9fccc38c         reqid=2,779,127,575,212,821,235
Jul 19 19:56:40 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:40.617] Unexpected trienode heal packet          peer=9ff17625         reqid=5,925,214,810,693,714,548
Jul 19 19:56:41 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:41.949] Unexpected trienode heal packet          peer=e70811b4         reqid=7,690,861,252,952,579,679
Jul 19 19:56:44 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:44.035] Unexpected trienode heal packet          peer=2cd761db         reqid=2,756,345,096,628,177,020
Jul 19 19:56:44 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:44.068] Unexpected trienode heal packet          peer=73fd19d8         reqid=6,385,141,813,524,173,251
Jul 19 19:56:44 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:44.276] Unexpected trienode heal packet          peer=b65d7b0b         reqid=8,375,173,560,166,334,289
Jul 19 19:56:44 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:44.303] Unexpected trienode heal packet          peer=402b4b92         reqid=6,243,137,689,026,562,439
Jul 19 19:56:44 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:44.487] Unexpected trienode heal packet          peer=fe5f77bf         reqid=7,339,829,303,620,979,336
Jul 19 19:56:44 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:44.517] Unexpected trienode heal packet          peer=fd937589         reqid=3,817,543,624,467,065,485
Jul 19 19:56:53 ethereumonarm-f93a22f29 geth[79761]: INFO [07-19|19:56:53.997] State heal in progress                   [email protected]              [email protected]              [email protected]            [email protected] pending=10937
Jul 19 19:56:54 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:54.000] Unexpected trienode heal packet          peer=2736fd6a         reqid=4,685,317,259,206,057,756
Jul 19 19:56:54 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:54.558] Unexpected trienode heal packet          peer=6533a7cc         reqid=4,708,310,855,523,396,133
Jul 19 19:56:55 ethereumonarm-f93a22f29 geth[79761]: WARN [07-19|19:56:55.635] Unexpected trienode heal packet          peer=b639490d         reqid=1,761,834,901,958,553,646```

About fifteen hours later, the log looks like this:

```Jul 20 08:55:57 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:55:57.290] Unexpected trienode heal packet          peer=e03d20ed         reqid=1,377,280,508,779,049,759
Jul 20 08:55:57 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:55:57.294] Unexpected trienode heal packet          peer=61551118         reqid=3,934,290,387,191,793,956
Jul 20 08:55:57 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:55:57.305] Unexpected trienode heal packet          peer=e24ea44e         reqid=1,111,763,378,262,048,808
Jul 20 08:55:57 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:55:57.307] Unexpected trienode heal packet          peer=11d75e71         reqid=2,907,927,302,575,975,489
Jul 20 08:55:57 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:55:57.310] Unexpected trienode heal packet          peer=22e17f9c         reqid=3,516,073,890,914,378,070
Jul 20 08:55:57 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:55:57.311] Unexpected trienode heal packet          peer=cb922008         reqid=1,894,546,731,677,936,354
Jul 20 08:56:01 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:01.592] State heal in progress                   accounts=265,[email protected]     slots=209,[email protected]     [email protected]        nodes=2,263,[email protected] pending=91006
Jul 20 08:56:06 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:06.285] Imported new block headers               count=1    elapsed=10.008ms   number=12,862,459 hash=45255a..affe22 age=1m45s
Jul 20 08:56:06 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:06.862] Downloader queue stats                   receiptTasks=0     blockTasks=0     itemSize=248.19KiB throttle=1057
Jul 20 08:56:10 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:10.576] Imported new block headers               count=2    elapsed=13.631ms   number=12,862,461 hash=fd0ef2..f463f1 age=1m27s
Jul 20 08:56:11 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:11.143] State heal in progress                   accounts=265,[email protected]     slots=209,[email protected]     [email protected]        nodes=2,263,[email protected] pending=91255
Jul 20 08:56:14 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:14.615] Imported new block headers               count=1    elapsed=11.778ms   number=12,862,462 hash=208f43..e6ef2b
Jul 20 08:56:14 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:14.867] Pivot became stale, moving               old=12,862,336 new=12,862,400
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:15.258] Imported new block receipts              count=64   elapsed=388.930ms  number=12,862,399 hash=e03ec7..423ade age=14m49s     size=7.32MiB
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: INFO [07-20|08:56:15.639] State heal in progress                   accounts=265,[email protected]     slots=209,[email protected]     [email protected]        nodes=2,264,[email protected] pending=91439
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.649] Unexpected trienode heal packet          peer=c8cb5d96         reqid=384,864,180,950,622,558
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.662] Unexpected trienode heal packet          peer=11d75e71         reqid=3,864,654,568,017,345,329
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.663] Unexpected trienode heal packet          peer=e24ea44e         reqid=596,666,107,961,133,006
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.663] Unexpected trienode heal packet          peer=cfe18f98         reqid=2,843,389,484,003,173,002
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.664] Unexpected trienode heal packet          peer=2efa6a6d         reqid=1,222,391,833,366,759,943
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.674] Unexpected trienode heal packet          peer=22e17f9c         reqid=2,876,200,310,530,783,885
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.680] Unexpected trienode heal packet          peer=cb922008         reqid=4,338,756,389,789,023,204
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.680] Unexpected trienode heal packet          peer=81e8669c         reqid=8,506,724,142,604,709,679
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.714] Unexpected trienode heal packet          peer=2736fd6a         reqid=7,444,444,972,996,853,561
Jul 20 08:56:15 ethereumonarm-f93a22f29 geth[79761]: WARN [07-20|08:56:15.719] Unexpected trienode heal packet          peer=f21696a2         reqid=6,136,919,150,236,356,465```

[Feature Request] support Erigon dashboard

Erigon has --metrics option according to: https://github.com/ledgerwatch/erigon/blob/devel/cmd/prometheus/Readme.md

just like geth, so I think it should be great to add a erigon dashboard on grafana.

Cannot access through SSH

I flashed my SD card and got about 33% through the sync when I got an error and I couldn't get it running again. No problem I said, Ill just re-flash and wait a few more hours.

I have now re-flashed via the same process and cannot login through ssh anymore. I have formatted the card 3 times and retried each time following the docs. The only deviation (that I made once) was adding an empty file named ssh in root for access.

Any advice?

Password being used: ethereum

Link to image is broken

Getting 404 when trying to download the image.

Rock5b sudo apt update doesn't support architecture armhf

When running sudo apt update on a fresh install on a rock5b using the latest image file ethonarm_rock5b_22.12.00.img.zip, there is an error message encountered that reads:

N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://apt.ethraspbian.com focal InRelease' doesn't support architecture 'armhf'

What I am curious to know is if this message is something that can be ignored or if this is something that needs to be investigated or fixed

Incorrect default `geth` config

Hi, I've followed the tutorial and used the downloads from this page to set up my rpi4 as an Eth 2.0 validator.

I noticed that prysm-beacon was logging errors about not being able to connect to eth1, even though geth was running - I even waited for it to finish syncing. The solution for me was to edit the geth.conf file to include the --http flag and restart the service. It seems this argument should already be there by default.

Invalid signature for http://apt.ethraspbian.com repo

root:~# apt update
Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease
Hit:2 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease
Hit:3 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease
Hit:4 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease
Hit:5 http://apt.ethraspbian.com focal InRelease
Hit:6 https://packages.grafana.com/oss/deb stable InRelease
Err:5 http://apt.ethraspbian.com focal InRelease
  The following signatures were invalid: EXPKEYSIG 8A584409D327B0A5 Diego Losada Eth On ARM <[email protected]>
Reading package lists... Done
Building dependency tree
Reading state information... Done
24 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://apt.ethraspbian.com focal InRelease: The following signatures were invalid: EXPKEYSIG 8A584409D327B0A5 Diego Losada Eth On ARM <[email protected]>
W: Failed to fetch http://apt.ethraspbian.com/dists/focal/InRelease  The following signatures were invalid: EXPKEYSIG 8A584409D327B0A5 Diego Losada Eth On ARM <[email protected]>
W: Some index files failed to download. They have been ignored, or old ones used instead.

Cannot access Pi through SSH

I flashed my SD card and got about 33% through the sync when I got an error and I couldn't get it running again. No problem I said, Ill just re-flash and wait a few more hours.

I have now re-flashed via the same process and cannot login through ssh anymore. I have formatted the card 3 times and retried each time following the docs. The only deviation (that I made once) was adding an empty file named ssh in root for access.

Any advice?

Password being used: ethereum

Screen Shot 2022-01-17 at 11 29 33 AM

Thanks!

Just came to say thanks!

This older tutorial over here using what seems like diglos/pi-gen didn't work for me. The image somehow wouldn't complete set-up. Then I found the ethonarm twitter, the docs, and this repo. Works great! Looooooving the grafana dashboard too.

So thanks 🙏 ! She's purring like a happy kitty 😄 . If I see you in the next gitcoin round you'll have my support!!

Does this work on OrangePi 5 Plus?

It looks to be running through the setup correctly at first, but then it times out with rk3x-i2c fec800000.i2c: timeout, ipd: 0x80, state: 3 indefinitely.

This is with an NVME that I have formatted with a single partition before attempting this setup with the ethonarm_orangepi5_23.04.00.img.zip image flashed to an SD card.