07-09-2020, 08:36 AM
Running Rosetta@home on a Raspberry Pi with Fedora IoT
<div style="margin: 5px 5% 10px 5%;"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot.png" width="852" height="726" title="" alt="" /></div><div><p>The <a href="https://boinc.bakerlab.org/">Rosetta@home </a>project is a not-for-profit distributed computing project created by the Baker laboratory at the University of Washington. The project uses idle compute capacity from volunteer computers to study protein structure, which is used in research into diseases such as HIV, Malaria, Cancer, and Alzheimer’s. </p>
<p> <span id="more-31313"></span> </p>
<p>In common with many other scientific organizations, Rosetta@home is currently expending significant resources on the search for vaccines and treatments for <a href="https://www.ipd.uw.edu/2020/02/rosettas-role-in-fighting-coronavirus/">COVID-19</a>.</p>
<p>Rosetta@home uses the open source <a href="https://boinc.berkeley.edu/">BOINC</a> platform to manage donated compute resources. BOINC was originally developed to support the <a href="https://setiathome.berkeley.edu/">SETI@home</a> project searching for Extraterrestrial Intelligence. These days, it is used by a <a href="https://boinc.berkeley.edu/projects.php">number of projects</a> in many different scientific fields. A single BOINC client can contribute compute resources to many such projects, though not all projects support all architectures.</p>
<p>For the example shown in this article a Raspberry Pi 3 Model B was used, which is one of the <a href="https://docs.fedoraproject.org/en-US/iot/reference-platforms/">tested reference devices</a> for Fedora IoT. This device, with only 1GB of RAM, is only just powerful enough to be able to make a meaningful contribution to Rosetta@home, and there’s certainly no way the Raspberry Pi can be used for anything else – such as running a desktop environment – at the same time. </p>
<p>It’s also worth mentioning at this point that the first rule of Raspberry Pi computing is to get the recommended power supply. It is important to get as close to the specified 2.5A as you can, and use a good quality micro-usb cable.</p>
<h3 id="getting-fedora-iot">Getting Fedora IoT</h3>
<p>To install Fedora IoT on a Raspberry Pi, the first step is to download the aarch64 Raw Image from the <a href="https://iot.fedoraproject.org/">iot.fedoraproject.org download page</a>.</p>
<p>Then use the <em>arm-image-installer</em> utility (<em>sudo dnf install fedora-arm-installer</em>) to write the image to the SD card. As always, be very sure which device name corresponds to your SD Card before continuing. Check the device with the <em>lsblk</em> command like this:</p>
<pre class="wp-block-preformatted">$ <strong>lsblk</strong>
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 59.5G 0 disk
└─sdb1 8:17 1 59.5G 0 part /run/media/gavin/154F-1CEC
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part
...</pre>
<p>If you’re still not sure, try running <em>lsblk </em>with the SD card removed, then again with the SD card inserted and comparing the outputs. In this case it lists the SD card as <em>/dev/sdb</em>. If you’re really unsure, there are some more tips described in the <a href="https://docs.fedoraproject.org/en-US/iot/physical-device-setup/#_create_a_bootable_sd_card">Getting Started guide</a>.</p>
<p>We need to tell <em>arm-image-installer</em> which image file to use, what type of device we’re going to be using, and the device name – determined above – to use for writing the image. The <em>arm-image-installer</em> utility is also able to expand the filesystem to use the entire SD card at the point of writing the image.</p>
<p>Since we’re not going to use the <a href="https://docs.fedoraproject.org/en-US/iot/ignition/">zezere provisioning server</a> to deploy SSH keys to the Raspberry Pi, we need to specify the option to remove the root password so that we can log in and set it at first boot.</p>
<p>In my case, the full command was:</p>
<pre class="wp-block-preformatted">sudo arm-image-installer --image ~/Downloads/Fedora-IoT-32-20200603.0.aarch64.raw.xz --target=rpi3 --media=/dev/sdb --resizefs --norootpass</pre>
<p>After a final confirmation prompt:</p>
<pre class="wp-block-preformatted">= Selected Image: = /var/home/gavin/Downloads/Fedora-IoT-32-20200603.0.aarc...
= Selected Media : /dev/sdb
= U-Boot Target : rpi3
= Root Password will be removed.
= Root partition will be resized
===================================================== *****************************************************
*****************************************************
******** WARNING! ALL DATA WILL BE DESTROYED ********
*****************************************************
***************************************************** Type 'YES' to proceed, anything else to exit now </pre>
<p>the image is written to the SD Card.</p>
<pre class="wp-block-preformatted">...
= Installation Complete! Insert into the rpi3 and boot.</pre>
<h3 id="booting-the-raspberry-pi">Booting the Raspberry Pi</h3>
<p>For the initial setup, you’ll need to attach a keyboard and mouse to the Raspberry Pi. Alternatively, you can follow the <a href="https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi?rd=Raspberry_Pi#How_do_I_use_a_serial_console.3F">instructions</a> for connecting with a USB-to-Serial cable.</p>
<p>When the Raspberry Pi boots up, just type <em>root</em> at the login prompt and press enter.</p>
<pre class="wp-block-preformatted">localhost login: <strong>root</strong>
[root@localhost~]#</pre>
<p>The first task is to set a password for the <em>root</em> user.</p>
<pre class="wp-block-preformatted">[root@localhost~]# <strong>passwd</strong>
Changing password for user root.
New password: Retype new password:
passwd: all authentication tokens updated successfully
[root@localhost~]#</pre>
<h3 id="verifying-network-connectivity">Verifying Network Connectivity</h3>
<p>To verify the network connectivity, the <a href="https://docs.fedoraproject.org/en-US/iot/network-access/">checklist</a> in the Fedora IoT Getting Started guide was followed. This system is using a wired ethernet connection, which shows as <em>eth0.</em> If you need to set up a wireless connection this can be done with <a href="https://fedoraproject.org/wiki/Networking/CLI"><em>nmcli</em></a>.</p>
<p><em>ip addr</em> will allow you to check that you have a valid IP address.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>ip addr</strong>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b8:27:eb:9d:6e:13 brd ff:ff:ff:ff:ff:ff
inet <strong>192.168.178.60</strong>/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
valid_lft 863928sec preferred_lft 863928sec
inet6 fe80::ba27:ebff:fe9d:6e13/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether fe:d3:c9:dc:54:25 brd ff:ff:ff:ff:ff:ff</pre>
<p><em>ip route </em>will check that the network has a default gateway configured.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>ip route</strong>
default via 192.168.178.1 dev eth0 proto dhcp metric 100 192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.60 metric 100 </pre>
<p>To verify internet access and name resolution, use <em>ping</em></p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>ping -c3 iot.fedoraproject.org</strong>
PING wildcard.fedoraproject.org (8.43.85.67) 56(84) bytes of data.
64 bytes from proxy14.fedoraproject.org (8.43.85.67): icmp_seq=1 ttl=46 time=93.4 ms
64 bytes from proxy14.fedoraproject.org (8.43.85.67): icmp_seq=2 ttl=46 time=90.0 ms
64 bytes from proxy14.fedoraproject.org (8.43.85.67): icmp_seq=3 ttl=46 time=91.3 ms --- wildcard.fedoraproject.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 90.043/91.573/93.377/1.374 ms</pre>
<h3 id="optional-configuring-sshd-so-we-can-disconnect-the-keyboard-and-monitor">Optional: Configuring <em>sshd</em> so we can disconnect the keyboard and monitor</h3>
<p>Before disconnecting the keyboard and monitor, we need to ensure that we can connect to the Raspberry Pi over the network.</p>
<p>First we verify that <em>sshd</em> is running</p>
<pre class="wp-block-preformatted">[root@localhost~]# <strong>systemctl is-active sshd</strong>
active</pre>
<p>and that there is a firewall rule present to allow <em>ssh</em>.</p>
<pre class="wp-block-preformatted">[root@localhost ~]#<strong> firewall-cmd --list-all</strong>
public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client mdns ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: </pre>
<p>In the file <em>/etc/ssh/sshd_config</em>, find the section named</p>
<pre class="wp-block-preformatted"># Authentication</pre>
<p>and add the line</p>
<pre class="wp-block-preformatted">PermitRootLogin yes</pre>
<p>There will already be a line</p>
<pre class="wp-block-preformatted">#PermitRootLogin prohibit-password</pre>
<p>which you can edit by removing the <em>#</em> comment character and changing the value to <em>yes</em>.</p>
<p>Restart the <em>sshd</em> service to pick up the change</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>systemctl restart sshd</strong></pre>
<p>If all this is in place, we should be able to <em>ssh</em> to the Raspberry Pi.</p>
<pre class="wp-block-preformatted">[gavin@desktop ~]$ <strong>ssh [email protected]</strong>
The authenticity of host '192.168.178.60 (192.168.178.60)' can't be established.
ECDSA key fingerprint is SHA256:DLdFaYbvKhB6DG2lKmJxqY2mbrbX5HDRptzWMiAUgBM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? <strong>yes</strong>
Warning: Permanently added '192.168.178.60' (ECDSA) to the list of known hosts.
[email protected]'s password: Boot Status is GREEN - Health Check SUCCESS
Last login: Wed Apr 1 17:24:50 2020
[root@localhost ~]#</pre>
<p>It’s now safe to log out from the console (<em>exit</em>) and disconnect the keyboard and monitor.</p>
<h3 id="disabling-unneeded-services">Disabling unneeded services</h3>
<p>Since we’re right on the lower limit of viable hardware for Rosetta@home, it’s worth disabling any unneeded services. Fedora IoT is much more lightweight than desktop distributions, but there are still a few optimizations we can do.</p>
<p>Like disabling bluetooth, Modem Manager (used for cellular data connections), WPA supplicant (used for Wi-Fi) and the zezere services, which are used to centrally manage a fleet of Fedora IoT devices.</p>
<pre class="wp-block-preformatted">[root@localhost /]# <strong>for serviceName in bluetooth ModemManager wpa_supplicant zezere_ignition zezere_ignition.timer zezere_ignition_banner; do sudo systemctl stop $serviceName; sudo systemctl disable $serviceName; sudo systemctl mask $serviceName; done</strong></pre>
<h3 id="getting-the-boinc-client">Getting the BOINC client</h3>
<p>Instead of installing the BOINC client directly onto the operating system with <a href="https://rpm-ostree.readthedocs.io/en/latest/">rpm-ostree</a>, we’re going to use podman to run the containerized version of the client.</p>
<p>This image uses a volume mount to store its data, so we create the directories it needs in advance.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>mkdir -p /opt/appdata/boinc/slots /opt/appdata/boinc/locale</strong>
</pre>
<p>We also need to add a firewall rule to allow the container to resolve external DNS names.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>firewall-cmd --permanent --zone=trusted --add-interface=cni-podman0 success [root@localhost ~]# systemctl restart firewalld</strong></pre>
<p>Finally we are ready to pull and run the BOINC client container.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>podman run --name boinc -dt -p 31416:31416 -v /opt/appdata/boinc:/var/lib/boinc:Z -e BOINC_GUI_RPC_PASSWORD="blah" -e BOINC_CMD_LINE_OPTIONS="--allow_remote_gui_rpc" boinc/client:arm64v8 </strong>
Trying to pull...
...
... 787a26c34206e75449a7767c4ad0dd452ec25a501f719c2e63485479f...</pre>
<p>We can inspect the container logs to make sure everything is working as expected:</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>podman logs boinc</strong>
20-Jun-2020 09:02:44 [---] cc_config.xml not found - using defaults
20-Jun-2020 09:02:44 [---] Starting BOINC client version 7.14.12 for aarch64-unknown-linux-gnu
...
...
...
20-Jun-2020 09:02:44 [---] Checking presence of 0 project files
20-Jun-2020 09:02:44 [---] This computer is not attached to any projects
20-Jun-2020 09:02:44 Initialization completed</pre>
<h3 id="configuring-the-boinc-container-to-run-at-startup">Configuring the BOINC container to run at startup</h3>
<p>We can automatically generate a systemd unit file for the container with <em>podman generate systemd</em>.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>podman generate systemd --files --name boinc</strong>
/root/container-boinc.service</pre>
<p>This creates a systemd unit file in root’s home directory.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>cat container-boinc.service </strong>
# container-boinc.service
# autogenerated by Podman 1.9.3
# Sat Jun 20 09:13:58 UTC 2020 [Unit]
Description=Podman container-boinc.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target [Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStart=/usr/bin/podman start boinc
ExecStop=/usr/bin/podman stop -t 10 boinc
PIDFile=/var/run/containers/storage/overlay-containers/787a26c34206e75449a7767c4ad0dd452ec25a501f719c2e63485479fbe21631/userdata/conmon.pid
KillMode=none
Type=forking [Install]
WantedBy=multi-user.target default.target</pre>
<p>We install the file by moving it to the appropriate directory.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>mv -Z container-boinc.service /etc/systemd/system</strong>
[root@localhost ~]# <strong>systemctl enable /etc/systemd/system/container-boinc.service</strong>
Created symlink /etc/systemd/system/multi-user.target.wants/container-boinc.service → /etc/systemd/system/container-boinc.service.
Created symlink /etc/systemd/system/default.target.wants/container-boinc.service → /etc/systemd/system/container-boinc.service.</pre>
<h3 id="connecting-to-the-rosetta-stone-project">Connecting to the Rosetta Stone project</h3>
<p>You need to create an account at the Rosetta@home <a href="https://boinc.bakerlab.org/create_account_form.php">signup page</a>, and retrieve your account key from your <a href="https://boinc.bakerlab.org/rosetta/weak_auth.php">account home page</a>. The key to copy is the “Weak Account Key”.</p>
<p>Finally, we execute the <em>boinccmd</em> configuration utility inside the container using <em>podman exec</em>, passing the Rosetta@home url and our account key.</p>
<pre class="wp-block-preformatted"><strong>[root@localhost ~]# </strong>podman exec boinc boinccmd --project_attach https://boinc.bakerlab.org/rosetta/ 2160739_cadd20314e4ef804f1d95ce2862c8f73</pre>
<p>Running<em> podman logs –follow boinc</em> will allow us to see the container connecting to the project. You will probably see errors of the form</p>
<pre class="wp-block-preformatted">20-Jun-2020 10:18:40 [Rosetta@home] Rosetta needs 1716.61 MB RAM but only 845.11 MB is available for use.</pre>
<p>This is because <em>most</em>, but not <em>all</em>, of the work units in Rosetta@Home require more memory than we have to offer. However, if you leave the device running for a while, it should eventually get some jobs to process. The polling interval seems to be approximately 10 minutes. We can also tweak the memory settings using BOINC manager to allow BOINC to use slightly more memory. This will increase the probability that Rosetta@home will be able to find tasks for us.</p>
<h3 id="installing-boinc-manager-for-remote-access">Installing BOINC Manager for remote access</h3>
<p>You can use <em>dnf</em> to install the BOINC manager component to remotely manage the BOINC client on the Raspberry Pi.</p>
<pre class="wp-block-preformatted">[gavin@desktop ~]$ <strong>sudo dnf install boinc-manager</strong></pre>
<p>If you switch to “Advanced View” , you will be able to select “File -> Select Computer” and connect to your Raspberry Pi, using the IP address of the Pi and the value supplied for <em>BOINC_GUI_RPC_PASSWORD</em> in the <em>podman run</em> command, in my case “<em>blah</em>“.</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot.png" alt="" class="wp-image-31324" /><figcaption>Press Shift+Ctrl+I to connect BOINC manager to a remote computer</figcaption></figure>
<p>Under “Options -> Computing Preferences”, increase the value for “When Computer is not in use, use at most _ %”. I’ve been using 93%; this seems to allow Rosetta@home to schedule work on the pi, whilst still leaving it just about usable. It is possible that further fine tuning of the operating system might allow this percentage to be increased.</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot-1.png" alt="" class="wp-image-31325" /><figcaption>Using the Computing Preferences Dialog to set the memory threshhold</figcaption></figure>
<p>These settings can also be changed through the Rosetta@home website <a href="https://boinc.bakerlab.org/rosetta/prefs.php?subset=global">settings page</a>, but bear in mind that changes made through the BOINC Manager client override preferences set in the web interface.</p>
<h3 id="wait">Wait</h3>
<p>It may take a while, possibly several hours, for Rosetta@home to send work to our newly installed client, particularly as most work units are too big to run on a Raspberry Pi. COVID-19 has resulted in a large number of new computers being joined to the Rosetta@home project, which means that there are times when there isn’t enough work to do.</p>
<p>When we are assigned some work units, BOINC will download several hundred megabytes of data. This will be stored on the SD Card and can be viewed using BOINC manager.</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot-2.png" alt="" class="wp-image-31328" /></figure>
</p>
<p>We can also see the tasks running in the Tasks pane:</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot-3.png" alt="" class="wp-image-31329" /></figure>
<p>The client has downloaded four tasks, but only one of them is currently running due to memory constraints. At times, two tasks can run simultaneously, but I haven’t seen more than that. This is OK as long as the tasks are completed by the deadline shown on the right. I’m fairly confident these will be completed as long as the Raspberry Pi is left running. I have found that the additional memory overhead created by the BOINC Manager connection and sshd services can reduce parallelism, so I try to disconnect these when I’m not using them.</p>
<h2>Conclusion</h2>
<p>Rosetta@home, in common with many other distributed computing projects, is currently experiencing a large spike in participation due to COVID-19. That aside, the project has been doing valuable work for many years to combat a number of other diseases.</p>
<p>Whilst a Raspberry Pi is never going to appear at the top of the <a href="https://boinc.bakerlab.org/rosetta/top_hosts.php">contribution chart</a>, I think this is a worthwhile project to undertake with a spare Raspberry Pi. The existence of work units aimed at low-spec ARM devices indicates that the project organizers agree with this sentiment. I’ll certainly be leaving mine running for the foreseeable future.</p>
</div>
https://www.sickgaming.net/blog/2020/07/...edora-iot/
<div style="margin: 5px 5% 10px 5%;"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot.png" width="852" height="726" title="" alt="" /></div><div><p>The <a href="https://boinc.bakerlab.org/">Rosetta@home </a>project is a not-for-profit distributed computing project created by the Baker laboratory at the University of Washington. The project uses idle compute capacity from volunteer computers to study protein structure, which is used in research into diseases such as HIV, Malaria, Cancer, and Alzheimer’s. </p>
<p> <span id="more-31313"></span> </p>
<p>In common with many other scientific organizations, Rosetta@home is currently expending significant resources on the search for vaccines and treatments for <a href="https://www.ipd.uw.edu/2020/02/rosettas-role-in-fighting-coronavirus/">COVID-19</a>.</p>
<p>Rosetta@home uses the open source <a href="https://boinc.berkeley.edu/">BOINC</a> platform to manage donated compute resources. BOINC was originally developed to support the <a href="https://setiathome.berkeley.edu/">SETI@home</a> project searching for Extraterrestrial Intelligence. These days, it is used by a <a href="https://boinc.berkeley.edu/projects.php">number of projects</a> in many different scientific fields. A single BOINC client can contribute compute resources to many such projects, though not all projects support all architectures.</p>
<p>For the example shown in this article a Raspberry Pi 3 Model B was used, which is one of the <a href="https://docs.fedoraproject.org/en-US/iot/reference-platforms/">tested reference devices</a> for Fedora IoT. This device, with only 1GB of RAM, is only just powerful enough to be able to make a meaningful contribution to Rosetta@home, and there’s certainly no way the Raspberry Pi can be used for anything else – such as running a desktop environment – at the same time. </p>
<p>It’s also worth mentioning at this point that the first rule of Raspberry Pi computing is to get the recommended power supply. It is important to get as close to the specified 2.5A as you can, and use a good quality micro-usb cable.</p>
<h3 id="getting-fedora-iot">Getting Fedora IoT</h3>
<p>To install Fedora IoT on a Raspberry Pi, the first step is to download the aarch64 Raw Image from the <a href="https://iot.fedoraproject.org/">iot.fedoraproject.org download page</a>.</p>
<p>Then use the <em>arm-image-installer</em> utility (<em>sudo dnf install fedora-arm-installer</em>) to write the image to the SD card. As always, be very sure which device name corresponds to your SD Card before continuing. Check the device with the <em>lsblk</em> command like this:</p>
<pre class="wp-block-preformatted">$ <strong>lsblk</strong>
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 59.5G 0 disk
└─sdb1 8:17 1 59.5G 0 part /run/media/gavin/154F-1CEC
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part
...</pre>
<p>If you’re still not sure, try running <em>lsblk </em>with the SD card removed, then again with the SD card inserted and comparing the outputs. In this case it lists the SD card as <em>/dev/sdb</em>. If you’re really unsure, there are some more tips described in the <a href="https://docs.fedoraproject.org/en-US/iot/physical-device-setup/#_create_a_bootable_sd_card">Getting Started guide</a>.</p>
<p>We need to tell <em>arm-image-installer</em> which image file to use, what type of device we’re going to be using, and the device name – determined above – to use for writing the image. The <em>arm-image-installer</em> utility is also able to expand the filesystem to use the entire SD card at the point of writing the image.</p>
<p>Since we’re not going to use the <a href="https://docs.fedoraproject.org/en-US/iot/ignition/">zezere provisioning server</a> to deploy SSH keys to the Raspberry Pi, we need to specify the option to remove the root password so that we can log in and set it at first boot.</p>
<p>In my case, the full command was:</p>
<pre class="wp-block-preformatted">sudo arm-image-installer --image ~/Downloads/Fedora-IoT-32-20200603.0.aarch64.raw.xz --target=rpi3 --media=/dev/sdb --resizefs --norootpass</pre>
<p>After a final confirmation prompt:</p>
<pre class="wp-block-preformatted">= Selected Image: = /var/home/gavin/Downloads/Fedora-IoT-32-20200603.0.aarc...
= Selected Media : /dev/sdb
= U-Boot Target : rpi3
= Root Password will be removed.
= Root partition will be resized
===================================================== *****************************************************
*****************************************************
******** WARNING! ALL DATA WILL BE DESTROYED ********
*****************************************************
***************************************************** Type 'YES' to proceed, anything else to exit now </pre>
<p>the image is written to the SD Card.</p>
<pre class="wp-block-preformatted">...
= Installation Complete! Insert into the rpi3 and boot.</pre>
<h3 id="booting-the-raspberry-pi">Booting the Raspberry Pi</h3>
<p>For the initial setup, you’ll need to attach a keyboard and mouse to the Raspberry Pi. Alternatively, you can follow the <a href="https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi?rd=Raspberry_Pi#How_do_I_use_a_serial_console.3F">instructions</a> for connecting with a USB-to-Serial cable.</p>
<p>When the Raspberry Pi boots up, just type <em>root</em> at the login prompt and press enter.</p>
<pre class="wp-block-preformatted">localhost login: <strong>root</strong>
[root@localhost~]#</pre>
<p>The first task is to set a password for the <em>root</em> user.</p>
<pre class="wp-block-preformatted">[root@localhost~]# <strong>passwd</strong>
Changing password for user root.
New password: Retype new password:
passwd: all authentication tokens updated successfully
[root@localhost~]#</pre>
<h3 id="verifying-network-connectivity">Verifying Network Connectivity</h3>
<p>To verify the network connectivity, the <a href="https://docs.fedoraproject.org/en-US/iot/network-access/">checklist</a> in the Fedora IoT Getting Started guide was followed. This system is using a wired ethernet connection, which shows as <em>eth0.</em> If you need to set up a wireless connection this can be done with <a href="https://fedoraproject.org/wiki/Networking/CLI"><em>nmcli</em></a>.</p>
<p><em>ip addr</em> will allow you to check that you have a valid IP address.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>ip addr</strong>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b8:27:eb:9d:6e:13 brd ff:ff:ff:ff:ff:ff
inet <strong>192.168.178.60</strong>/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
valid_lft 863928sec preferred_lft 863928sec
inet6 fe80::ba27:ebff:fe9d:6e13/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether fe:d3:c9:dc:54:25 brd ff:ff:ff:ff:ff:ff</pre>
<p><em>ip route </em>will check that the network has a default gateway configured.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>ip route</strong>
default via 192.168.178.1 dev eth0 proto dhcp metric 100 192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.60 metric 100 </pre>
<p>To verify internet access and name resolution, use <em>ping</em></p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>ping -c3 iot.fedoraproject.org</strong>
PING wildcard.fedoraproject.org (8.43.85.67) 56(84) bytes of data.
64 bytes from proxy14.fedoraproject.org (8.43.85.67): icmp_seq=1 ttl=46 time=93.4 ms
64 bytes from proxy14.fedoraproject.org (8.43.85.67): icmp_seq=2 ttl=46 time=90.0 ms
64 bytes from proxy14.fedoraproject.org (8.43.85.67): icmp_seq=3 ttl=46 time=91.3 ms --- wildcard.fedoraproject.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 90.043/91.573/93.377/1.374 ms</pre>
<h3 id="optional-configuring-sshd-so-we-can-disconnect-the-keyboard-and-monitor">Optional: Configuring <em>sshd</em> so we can disconnect the keyboard and monitor</h3>
<p>Before disconnecting the keyboard and monitor, we need to ensure that we can connect to the Raspberry Pi over the network.</p>
<p>First we verify that <em>sshd</em> is running</p>
<pre class="wp-block-preformatted">[root@localhost~]# <strong>systemctl is-active sshd</strong>
active</pre>
<p>and that there is a firewall rule present to allow <em>ssh</em>.</p>
<pre class="wp-block-preformatted">[root@localhost ~]#<strong> firewall-cmd --list-all</strong>
public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: dhcpv6-client mdns ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: </pre>
<p>In the file <em>/etc/ssh/sshd_config</em>, find the section named</p>
<pre class="wp-block-preformatted"># Authentication</pre>
<p>and add the line</p>
<pre class="wp-block-preformatted">PermitRootLogin yes</pre>
<p>There will already be a line</p>
<pre class="wp-block-preformatted">#PermitRootLogin prohibit-password</pre>
<p>which you can edit by removing the <em>#</em> comment character and changing the value to <em>yes</em>.</p>
<p>Restart the <em>sshd</em> service to pick up the change</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>systemctl restart sshd</strong></pre>
<p>If all this is in place, we should be able to <em>ssh</em> to the Raspberry Pi.</p>
<pre class="wp-block-preformatted">[gavin@desktop ~]$ <strong>ssh [email protected]</strong>
The authenticity of host '192.168.178.60 (192.168.178.60)' can't be established.
ECDSA key fingerprint is SHA256:DLdFaYbvKhB6DG2lKmJxqY2mbrbX5HDRptzWMiAUgBM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? <strong>yes</strong>
Warning: Permanently added '192.168.178.60' (ECDSA) to the list of known hosts.
[email protected]'s password: Boot Status is GREEN - Health Check SUCCESS
Last login: Wed Apr 1 17:24:50 2020
[root@localhost ~]#</pre>
<p>It’s now safe to log out from the console (<em>exit</em>) and disconnect the keyboard and monitor.</p>
<h3 id="disabling-unneeded-services">Disabling unneeded services</h3>
<p>Since we’re right on the lower limit of viable hardware for Rosetta@home, it’s worth disabling any unneeded services. Fedora IoT is much more lightweight than desktop distributions, but there are still a few optimizations we can do.</p>
<p>Like disabling bluetooth, Modem Manager (used for cellular data connections), WPA supplicant (used for Wi-Fi) and the zezere services, which are used to centrally manage a fleet of Fedora IoT devices.</p>
<pre class="wp-block-preformatted">[root@localhost /]# <strong>for serviceName in bluetooth ModemManager wpa_supplicant zezere_ignition zezere_ignition.timer zezere_ignition_banner; do sudo systemctl stop $serviceName; sudo systemctl disable $serviceName; sudo systemctl mask $serviceName; done</strong></pre>
<h3 id="getting-the-boinc-client">Getting the BOINC client</h3>
<p>Instead of installing the BOINC client directly onto the operating system with <a href="https://rpm-ostree.readthedocs.io/en/latest/">rpm-ostree</a>, we’re going to use podman to run the containerized version of the client.</p>
<p>This image uses a volume mount to store its data, so we create the directories it needs in advance.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>mkdir -p /opt/appdata/boinc/slots /opt/appdata/boinc/locale</strong>
</pre>
<p>We also need to add a firewall rule to allow the container to resolve external DNS names.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>firewall-cmd --permanent --zone=trusted --add-interface=cni-podman0 success [root@localhost ~]# systemctl restart firewalld</strong></pre>
<p>Finally we are ready to pull and run the BOINC client container.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>podman run --name boinc -dt -p 31416:31416 -v /opt/appdata/boinc:/var/lib/boinc:Z -e BOINC_GUI_RPC_PASSWORD="blah" -e BOINC_CMD_LINE_OPTIONS="--allow_remote_gui_rpc" boinc/client:arm64v8 </strong>
Trying to pull...
...
... 787a26c34206e75449a7767c4ad0dd452ec25a501f719c2e63485479f...</pre>
<p>We can inspect the container logs to make sure everything is working as expected:</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>podman logs boinc</strong>
20-Jun-2020 09:02:44 [---] cc_config.xml not found - using defaults
20-Jun-2020 09:02:44 [---] Starting BOINC client version 7.14.12 for aarch64-unknown-linux-gnu
...
...
...
20-Jun-2020 09:02:44 [---] Checking presence of 0 project files
20-Jun-2020 09:02:44 [---] This computer is not attached to any projects
20-Jun-2020 09:02:44 Initialization completed</pre>
<h3 id="configuring-the-boinc-container-to-run-at-startup">Configuring the BOINC container to run at startup</h3>
<p>We can automatically generate a systemd unit file for the container with <em>podman generate systemd</em>.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>podman generate systemd --files --name boinc</strong>
/root/container-boinc.service</pre>
<p>This creates a systemd unit file in root’s home directory.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>cat container-boinc.service </strong>
# container-boinc.service
# autogenerated by Podman 1.9.3
# Sat Jun 20 09:13:58 UTC 2020 [Unit]
Description=Podman container-boinc.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target [Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStart=/usr/bin/podman start boinc
ExecStop=/usr/bin/podman stop -t 10 boinc
PIDFile=/var/run/containers/storage/overlay-containers/787a26c34206e75449a7767c4ad0dd452ec25a501f719c2e63485479fbe21631/userdata/conmon.pid
KillMode=none
Type=forking [Install]
WantedBy=multi-user.target default.target</pre>
<p>We install the file by moving it to the appropriate directory.</p>
<pre class="wp-block-preformatted">[root@localhost ~]# <strong>mv -Z container-boinc.service /etc/systemd/system</strong>
[root@localhost ~]# <strong>systemctl enable /etc/systemd/system/container-boinc.service</strong>
Created symlink /etc/systemd/system/multi-user.target.wants/container-boinc.service → /etc/systemd/system/container-boinc.service.
Created symlink /etc/systemd/system/default.target.wants/container-boinc.service → /etc/systemd/system/container-boinc.service.</pre>
<h3 id="connecting-to-the-rosetta-stone-project">Connecting to the Rosetta Stone project</h3>
<p>You need to create an account at the Rosetta@home <a href="https://boinc.bakerlab.org/create_account_form.php">signup page</a>, and retrieve your account key from your <a href="https://boinc.bakerlab.org/rosetta/weak_auth.php">account home page</a>. The key to copy is the “Weak Account Key”.</p>
<p>Finally, we execute the <em>boinccmd</em> configuration utility inside the container using <em>podman exec</em>, passing the Rosetta@home url and our account key.</p>
<pre class="wp-block-preformatted"><strong>[root@localhost ~]# </strong>podman exec boinc boinccmd --project_attach https://boinc.bakerlab.org/rosetta/ 2160739_cadd20314e4ef804f1d95ce2862c8f73</pre>
<p>Running<em> podman logs –follow boinc</em> will allow us to see the container connecting to the project. You will probably see errors of the form</p>
<pre class="wp-block-preformatted">20-Jun-2020 10:18:40 [Rosetta@home] Rosetta needs 1716.61 MB RAM but only 845.11 MB is available for use.</pre>
<p>This is because <em>most</em>, but not <em>all</em>, of the work units in Rosetta@Home require more memory than we have to offer. However, if you leave the device running for a while, it should eventually get some jobs to process. The polling interval seems to be approximately 10 minutes. We can also tweak the memory settings using BOINC manager to allow BOINC to use slightly more memory. This will increase the probability that Rosetta@home will be able to find tasks for us.</p>
<h3 id="installing-boinc-manager-for-remote-access">Installing BOINC Manager for remote access</h3>
<p>You can use <em>dnf</em> to install the BOINC manager component to remotely manage the BOINC client on the Raspberry Pi.</p>
<pre class="wp-block-preformatted">[gavin@desktop ~]$ <strong>sudo dnf install boinc-manager</strong></pre>
<p>If you switch to “Advanced View” , you will be able to select “File -> Select Computer” and connect to your Raspberry Pi, using the IP address of the Pi and the value supplied for <em>BOINC_GUI_RPC_PASSWORD</em> in the <em>podman run</em> command, in my case “<em>blah</em>“.</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot.png" alt="" class="wp-image-31324" /><figcaption>Press Shift+Ctrl+I to connect BOINC manager to a remote computer</figcaption></figure>
<p>Under “Options -> Computing Preferences”, increase the value for “When Computer is not in use, use at most _ %”. I’ve been using 93%; this seems to allow Rosetta@home to schedule work on the pi, whilst still leaving it just about usable. It is possible that further fine tuning of the operating system might allow this percentage to be increased.</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot-1.png" alt="" class="wp-image-31325" /><figcaption>Using the Computing Preferences Dialog to set the memory threshhold</figcaption></figure>
<p>These settings can also be changed through the Rosetta@home website <a href="https://boinc.bakerlab.org/rosetta/prefs.php?subset=global">settings page</a>, but bear in mind that changes made through the BOINC Manager client override preferences set in the web interface.</p>
<h3 id="wait">Wait</h3>
<p>It may take a while, possibly several hours, for Rosetta@home to send work to our newly installed client, particularly as most work units are too big to run on a Raspberry Pi. COVID-19 has resulted in a large number of new computers being joined to the Rosetta@home project, which means that there are times when there isn’t enough work to do.</p>
<p>When we are assigned some work units, BOINC will download several hundred megabytes of data. This will be stored on the SD Card and can be viewed using BOINC manager.</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot-2.png" alt="" class="wp-image-31328" /></figure>
</p>
<p>We can also see the tasks running in the Tasks pane:</p>
<figure class="wp-block-image size-large"><img src="https://www.sickgaming.net/blog/wp-content/uploads/2020/07/running-rosettahome-on-a-raspberry-pi-with-fedora-iot-3.png" alt="" class="wp-image-31329" /></figure>
<p>The client has downloaded four tasks, but only one of them is currently running due to memory constraints. At times, two tasks can run simultaneously, but I haven’t seen more than that. This is OK as long as the tasks are completed by the deadline shown on the right. I’m fairly confident these will be completed as long as the Raspberry Pi is left running. I have found that the additional memory overhead created by the BOINC Manager connection and sshd services can reduce parallelism, so I try to disconnect these when I’m not using them.</p>
<h2>Conclusion</h2>
<p>Rosetta@home, in common with many other distributed computing projects, is currently experiencing a large spike in participation due to COVID-19. That aside, the project has been doing valuable work for many years to combat a number of other diseases.</p>
<p>Whilst a Raspberry Pi is never going to appear at the top of the <a href="https://boinc.bakerlab.org/rosetta/top_hosts.php">contribution chart</a>, I think this is a worthwhile project to undertake with a spare Raspberry Pi. The existence of work units aimed at low-spec ARM devices indicates that the project organizers agree with this sentiment. I’ll certainly be leaving mine running for the foreseeable future.</p>
</div>
https://www.sickgaming.net/blog/2020/07/...edora-iot/