[i] UPDATES

---

02/19/2020: Tezos is a great project that unfortunately took a path that RPI3 cannot follow anymore. If you believe that RPI4 can be a viable alternative, there are a couple of very good places to get started:
https://asbjornenge.com/tezpi/
https://www.tezos.org.sg/the-berry-good-guide-to-setting-up-tezos-node-baker-using-raspberry-pi-ubuntu/

I wish all the best to Tezos!

p.s. RPI3 is alive and well baking on the Dune network

---

10/18/2019: New Tezos protocol. The Tezos software must be upgraded (some instructions on page [c]).
This wiki will be revised soon. In the meantime, replace the baker and endorser commands, tezos-baker-004-Pt24m4xi and tezos-endorser-004-Pt24m4xi with tezos-baker-005-PsBabyM1 and tezos-endorser-005-PsBabyM1

Originated accounts (KT accounts) are not necessary anymore to make a delegation. More on this will follow. Some info here

---

09/02/2019: Small update to completely disable bluetooth and wifi on boot page [b], F-6).

---

05/10/2019: Changes in the scheduler with the release of the new linux kernel 5.x.x. More info on page [f]

See also page [f] for replacing the external HDD with a SSD

---

03/27/2019: Essential requirements to improve the RPI3 performance running Tezos on page [f]

---

01/04/2019 (revised 01/27/19): The current Tezos on the mainnet is quite demanding in terms of memory and disk I/O resources. Until the new release that hopefully will mitigate the problem, here are few hints to keep the RPI3 node synced while running the baking/endorsing daemons.

• apply the kernel parameters listed on page [b], point F-21)
• enable zram (point F-18)
• use the parameters listed in the config.json file shown on the same page, point F-22)
• modify the fstab file, points F-18 and F-23 (set the flag -o noatime for the root filesystem and disable the physical swap).
• mount the external storage unit with the flag -o noatime (see page [f])
• disable the journal feature on the ext4 filesystem of the external data storage unit. With the unmounted storage unit, type as a root:
  tune2fs -O ^has_journal /dev/sda1
  assuming the storage ext4 filesystem is /dev/sda1. Then type the following to check that the filesystem is ok:
  e2fsck -f /dev/sda1
  and mount the device as usual (see page [f]):
  mount -o noatime /dev/sda1 /media/hd
  assuming the mounting point is /media/hd. Now typing mount the device should be listed like this:
  /dev/sda1 on /media/hd type ext4 (rw,noatime,block_validity,delalloc,nojournal...........

       This is a permanent change that can be reversed by repeating the procedure starting with the command:
      tune2fs -O has_journal /dev/sda1

• start the baking and endorsing daemons ONLY after the node is fully synced (to find out, use the command ./tezos-client bootstrapped)

• sometimes clearing the cache memory, dentries and inodes helps to put the node on the right path
  sync ; echo 3 > /proc/sys/vm/drop_caches

Note: at the present time, the zeronet network is out of reach, the RPI3 cannot sync with the zeronet blockchain that moves 3X faster than the mainnet (pending further news, it is not a dead end yet).

---

11/25/2018: Mainnet new protocol (tag: 003_PsddFKi3) will replace the old one (002-PsYLVpVv) starting from block 204762. See Tezos official note here, and updated instructions on page [c]

---

11/22/2018: Simple instructions to update (synchronize) the local Tezos repository on the RPI3 (mainnet or zeronet branch), see page [c].

---

11/09/2018: There have been reports of problems during booting, the screen going black with no further video output. The problem seems to be not specific to any particular OS. The excellent post on Reddit by u/AtmosFear explains how to fix this issue.
If this is not the first initiation of the OS, the booting process does get to the end, the problem is just the lost video signal. If the RPI3 was previously set to allow ssh access, the remedy posted by u/AtmosFear can be also applied from a remote machine without the need to use a second display.
The solution seems to work well also for a different problem, the X11 windows (Motif) occasionally may freeze. The solution outlined here is also reported on page [b].

---

11/04/2018: As the blockchain keeps growing (~29GB currently), the use of an external SD card to store the data is not more economically viable. The following storage setup has been tested for about a couple of weeks:

• 3.5 hard disk, 500GB, Serial ATA III, data transfer 6Gb/s, 7200rpm, buffer 32 MB (~€35)
• SATA/USB adapter with external power unit (external power needed only for 3.5 HDD) (~€10)

so far the system is extremely effective, the nodes are up to speed, no delays or any other trouble. There is only one precaution to avoid compromising the stored data. When the node is stopped, type the command sync (twice) to make sure all the data in the cache/ram/buffer are transferred to the physical drive.

---

09/24/2018: The problems to keep the RPI3 synced and fully functional on the mainnet network are solved by simply store the blockchain data on an external USB storage device, either an HDD or a SD card with a USB card reader. The improvement of the Tezos performance on RPI3 is outstanding. It is still unclear whether it is because the blockchain date are stored on a different filesystem, or partition or entirely separate physical device (more tests are needed).

The setup of the external storage unit is fairly simple, see page [f]

---

09/01/2018: RPI3 B+ seems to be supported by the latest Fedora OS and other major linux distros, as well the latest kernel and firmware. Although it has been reported by some users a problem during the first boot which may be related to the video connection. Best solution so far is to try booting few times, wait for a minute or two before trying again. Once the boot is completed, expand the image file to take the full SD card space, and upgrade the OS immediately with dnf upgrade and the firmware with rpi-firmware-update

---

09/01/2018: At the moment (Sep/01), RPI3 is not doing well on the betanet. Here is a summary report for RPI3 B on the betanet and zeronet networks with aarch64/armv8 and aarch32/armv7 Fedora OS.

aarch64
Betanet: The tezos node runs without too many errors but the performance is extremely sluggish, the chain moves inconsistently over time, for example, nothing happens for 2-4 minutes then it advances all at once, which means that baking/endorsing is not possible because the operations run of time (not in sync with the top head). It is a problem that started about a couple of weeks ago, before then, the baking and endorsing operations were quite successful.
Zeronet: Tezos is working well, including baking/endorsing. Why such difference with the betanet? possibly because at the present time the chains is ~1/2 smaller, or maybe some new tezos software improvements not yet pushed on the betanet.

aarch32:
Betanet: it seems to work better, more responsive but for some reasons the node cannot be synced. It is not related to the internet speed. I think it means that the RPI3 simply cannot perform fast enough. As far as I can tell the problem is not the cpu or the write/read speed on the SD card, but the load/unload of the cache/buffer memory.
Zeronet: same as for aarch64, almost all good, fast and responsive, baking/endorsing both work well, but there is one issue, for some reason the tezos-baker crashes with different kind of errors at random times, sometimes after 1 hr, sometimes after longer time but never while baking a block. It could be a problem related to the SD card that is wearing out (read/write failure).

---