you may need to update your VM Linux image.

I have an Ubuntu VM using VB. I update the guest distribution every couple of weeks or so and have never had a certificate issue with it so it may be as simple as running

sudo apt update
sudo apt upgrade

in the guest OS.

HADSM4.
scheduler request failed; ssl peer certificate or ssh remote key was not ok.
Another problem is. on the first attempt to access the server page, I land somewhere else.
Intermittent service is another.

Just had a hadsm4 zip go through with no problems. if you are still getting problems could you post the output in the event log with http debug enabled please.

KAMasud -

This probably won't solve your problem, but you might want to merge your computers. Do you really have 27 different computers that have contacted the CPDN website in the last 30 days?

Blue screen of death sounds like a non-CPDN issue.

Go to your Homepage on the CPDN website.
Click on Computers on this account.
At the bottom there is a "Merge by name" feature.

After this you might try the "Remove project/Add Project" again

Another possibility, is that you're running Linux in a VM on a Windows machine.

I've found it best not to make life too complicated for a computer running climate models.

That is certainly my experience. I lose a lot more CPDN work units running Ubuntu 20.04.4 under WSL/Win10 than I do on a native Ubuntu 20.04 machine.
And there is nothing wrong with BOINC 7.16.6 for CPDN, or the later ones either (7.18.1, 7.20.2) that I have found.

Layered software, such as VMs, does make for a more complicated life. With an ubuntu VM on VBox/Win10, the finger of blame points towards the automatic monthly Windows updates for the majority of our model crashes. From 88 cpdn models, 71 have completed, 14 have crashed during an unannounced Windoze update, 3 crashed during a hard reboot to recover an unresponsive Windoze. We now pause Windoze updates for as long as possible and once a month ungraciously close the ubuntu VM to do all software updates in one go. This seems to have improved the success rate.

I am still not willing to commit a wholesale massacre of WUs in order to change versions. Also, I am new to the World of Linux. Somebody, whoever it is should keep the updated version of Boinc.

I don't think I have ever had tasks crash as a result of changing versions, as far as I can tell they are no more likely to crash after a BOINC version change than any other instance of stopping and restarting the client.

Actually, it's the responsibility of the software packager (in this case, the Linux repository maintainers) to take an appropriate snapshot of the BOINC source code, and package it in a way that suits their distribution and its management tools. That's the way the Linux world works.

I think the problem may be the BOINC version.

For the BOINC site, it says that version is experimental.

So, where did you get that version version 7.16.6?

We all have our own idiosyncrasy. Water under the bridge.

Still not sure what rule I broke!

[titter] Boinc is a wonderful platform which never ever goes wrong and everything always works perfectly.

hadam4h? I have looked up applications. This "h" seems to be new. Predicted days to completion, 103 days. Any ideas? Whatever it will be fun.

It won't take 103 days.

New machine/BOINC install? That's about what the N216 tasks are estimated to take on "default" performance numbers, before benchmarks have been run. After a while, BOINC will run the benchmarks, and any new tasks downloaded will have a more reasonable estimate, but the ones already present won't update to the new estimate.

It should take 15 days or so, depending on your hardware.