Started receiving tasks after a few days without and after a restart, and now getting a load of errors.

https://www.mlcathome.org/mlcathome/results.php?userid=3183&offset=0&show_names=0&state=6&appid=

There are 2 pending start in BOINC which I'll check in the AM but any ideas why this may occur would be great.

Thanks

Sam

Started receiving tasks after a few days without and after a restart, and now getting a load of errors.

The old tasks were for architecture arm-unknown-linux-gnueabihf, the new ones are for aarch64-unknown-linux-gnu. Sorry I can't comment on the reason. Maybe some local configuration change. You could check what the BOINC startup messages say on architecture(s).

Hmm, ill take another look. I am going to move to raspberry pi os 64 bit soon so will see if that solves.

Thanks for the response.

That is odd. We have not changed anything on the server side related to this.

That is odd. We have not changed anything on the server side related to this.

It's probably something I have done :) I think zero'ing the OS and starting from scratch is likely the best solution!

Thanks

Sam

I feel your pain, man. I've had my fair share of "fun" with Pi's.

If you are running 64 bit, be sure to add these to your cc_config.xml to be able to also receive 32 bit apps/tasks:

<alt_platform>arm-unknown-linux-gnueabihf</alt_platform>
<alt_platform>armv7l-unknown-linux-gnueabihf</alt_platform>

---

Reno, NV
Team: SETI.USA

HI there,
Thanks for the additional information - I have added them however still getting computation errors. The file it tried to start also had a 12day estimate so something super hinky here.

Here's the file contents

<cc_config>
<log_flags>
<task>1</task>
<file_xfer>1</file_xfer>
<sched_ops>1</sched_ops>
</log_flags>
<options>
<alt_platform>aarch64-unknown-linux-gnu</alt_platform>
<alt_platform>arm-unknown-linux-gnueabihf</alt_platform>
<alt_platform>armv7l-unknown-linux-gnueabihf</alt_platform>
</options>
</cc_config>

In terms of BOINC, I've had better luck using Ubuntu server 64-bit. Ubuntu server is headless by default, so it uses a lot less RAM compared to having a desktop. I use the open-server SSH function to remotely control the headless BOINC-client.

Maybe unrelated, but if you're running the Pi from a slow SD card, it may queue up write tasks, and error.
The best you can do, is find a way to boot it off of an SSD (USB TO SATA).
It's not only faster, but more reliable too.

Thank you for all the feedback. At this time I've decided to "give up" on trying to get it to work alongside the other projects.

I'll try again with ubuntu server which I have tried twice now, on a 128gb brand new Sandisk pro SD, and wifi won't work so not viable...

I'll be back

Hey, sorry for not focusing on this, we've been focused on the cuda clients at the moment with ARM taking a back seat. It'll probably take a week or two before we're able to look at this again.

It's no problem :) ARM likely doesn't provide the largest benefit to you guys so I totally get it!

I'll keep checking back in and reasing the forums anyway so fingers crossed!

(I have some RPI 3B+ about to be put into use and I think they will work out the box so should be back soon).

Yeah, don't give up on us yet! Just focused on GPU at the moment. We want to support ARM, and the Pi in particular, because its a great (cheap!) way to get enthusiasts engaged!

Yeah, don't give up on us yet! Just focused on GPU at the moment. We want to support ARM, and the Pi in particular, because its a great (cheap!) way to get enthusiasts engaged!

Nice! Got one of the Pi3's up over weekend and it's got a few Universe@Home to finish then a single test MLC so fingers crossed! If works and is reasonable times I'll get three more Pi3s on MLC too. Not much i know but every little helps right?

Yeah, don't give up on us yet! Just focused on GPU at the moment. We want to support ARM, and the Pi in particular, because its a great (cheap!) way to get enthusiasts engaged!

Nice! Got one of the Pi3's up over weekend and it's got a few Universe@Home to finish then a single test MLC so fingers crossed! If works and is reasonable times I'll get three more Pi3s on MLC too. Not much i know but every little helps right?

Ok so I have an error code: https://www.mlcathome.org/mlcathome/result.php?resultid=2768161

RPi 3's only have 1gb of RAM which appears to be the error.

Would ZRAM solve this?

https://haydenjames.io/raspberry-pi-performance-add-zram-kernel-parameters/

Yeah, don't give up on us yet! Just focused on GPU at the moment. We want to support ARM, and the Pi in particular, because its a great (cheap!) way to get enthusiasts engaged!

Nice! Got one of the Pi3's up over weekend and it's got a few Universe@Home to finish then a single test MLC so fingers crossed! If works and is reasonable times I'll get three more Pi3s on MLC too. Not much i know but every little helps right?

Ok so I have an error code: https://www.mlcathome.org/mlcathome/result.php?resultid=2768161

Anyone know how to get around this?


pi@raspberrypi:~ $ sudo modprobe fuse
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.4.51-v7+/modules.dep.bin'
modprobe: FATAL: Module fuse not found in directory /lib/modules/5.4.51-v7+

pi@raspberrypi:~ $ sudo apt install fuse
Reading package lists... Done
Building dependency tree
Reading state information... Done
fuse is already the newest version (2.9.9-1+deb10u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Are you running a custom kernel that doesn't enable the fuse filesystem module? That's the only reason I can see.

Now, I spent some time reading up rpath last night, so I may finally be able to drop appimage/fuse as a requirement. Look for an update in the mlds test channel over the next few days (no promises though, I have a lot going on right now, but I want to get some new clients without appimage out sooner rather than later).

Are you running a custom kernel that doesn't enable the fuse filesystem module? That's the only reason I can see.

Now, I spent some time reading up rpath last night, so I may finally be able to drop appimage/fuse as a requirement. Look for an update in the mlds test channel over the next few days (no promises though, I have a lot going on right now, but I want to get some new clients without appimage out sooner rather than later).

Only thing I can think of is that another lib I installed is conflicting. Not intentionally blocked/disabled fuse and its defi there, I saw the other post on aarch64 and testing and followed those parts.

An update would be amazing. I'll defo keep checking back in!!

So we're working on a version of the client that doesn't need appimage support. It requires some manual linker games to make libraries look in the current directory first, but that should help with memory usage and remove the fuse dependency (of course, it may cause other issues...)

Also, if you're getting mldstest WUs, those currently have larger ram requirements (not really, they're set higher for testing the CUDA clients, which need more), and an RPi won't have enough memory to work on them.

Still won't solve the fuse dependency issue though. It's been a while since I checked my personal development arm systems to see how they're doing. I have a RPi4, RPi3, and a CuBox-i4. I'll try to check them all this weekend and see if there's anything obvious that's been broken lately.