Allgemeiner Plauderchat über das Thema DC Part IV

[MrBad]

Nun habe ich endlich mal rausgefunden wie die Vermurkste BOINC Installation nach dem Upgrade auf Ubuntu 22.04 wieder lauffähig wird. So einfach wie banal:

sudo apt reinstall boinc-client boinc-manager

Alter!
Ich habe hier auch ein paar Tage rumprobiert. Jetzt kann ich endlich wieder keine CP-WUs hochladen.
Besser erstmal nix anfassen.

 

[Ereignishorizont]

Mich stört bereits massiv, dass ich nicht mal lokalisieren kann, wohin das Programm an sich überhaupt installiert wird. var/lib/boinc bzw. boinc-client ist außer den Verknüpfungen (die wiederum ins Leere führen) leer, /etc/boinc-client ist komplett leer. Stattdessen wird im user-Verzeichnis ein Ordner "slots" und ".BOINC" angelegt. Ersterer enthält für jeden Thread einen Ordner, letzter ist mit Ausnahme von zwei txt-Dateien leer. Und dann tummeln sich im user-Verzeichnis noch etliche xml-Dateien (insbesondere die client_state.xml, welche für die Statistik, welche für jedes von mir hinzugefügte Projekt.) Und dann gibts noch einen Ordner "projects", der wiederum Unterordner (die jeweiligen Projekte) hat, über die ich dann auch app_configs erstellen kann.

Ich vermute fast, dass es an boinc selbst liegt. Bei mir wurde Version 7.18.1 (x64) über die Anwendungsverwaltung installiert (übrigens auch über sudo apt install boincmgr boinc-client).

Ganz unten steht >hier<, dass das die Android-Version ist. >Hier< heißt es, dass die Version eigentlich nicht veröffentlicht werden sollte für Linux und für Android ist(?)

Wenn ich den letzten Link richtig verstehe, muss man den client über sudo systemctl start boinc-client manuell starten. Das kann aber auch nur eine Frickel-Lösung sein und erklärt nicht, warum sich boinc über die gesamte Festplatte verteilt...

 

[herby44]

(übrigens auch über sudo apt install boincmgr boinc-client)

Zum installieren auf der Konsole genügt <sudo apt install boinc>, arbeitet man nur mit der Konsole kann man auch
nur den boinc-client installieren das spart einiges an platz.

 

[sompe]

Auf den zweiten Link zum boinc Forum war ich bei meiner Suche auch geraten und unterm Strich scheint die für Ubuntu 22.04 erhältliche Version eine zu sein die wohl so verbugt war das sie nicht freigegeben wurde, daher wohl auch die ganzen Probleme.
Leider bietet boinc selbst aber auch nur eine veraltete Version an.
Über Github scheint es zwar auch neuere Versionen für Linux zu geben aber nur als source code und da bin ich ganz einfach raus.

Releases · BOINC/boinc

Open-source software for volunteer computing and grid computing. - BOINC/boinc

github.com

 

[TAL9000]

über die Fremdpaketquelle von Gianfranco Costamagna

boinc development release : Gianfranco Costamagna

launchpad.net

sudo add-apt-repository ppa:costamagnagianfranco/boinc
sudo apt update

bekommt man die 7.20.5 fertig und auch immer weiter aktualisiert.
Läuft auf ein paar Systemen bis auf eins unauffällig und aus dem einem werde ich bald ein RIP machen

 

[enigmation]

Beende ich es - z. B. gerade wegen einem Kernel-Update und anschließendem Neustart - lässt es sich nicht mehr öffnen. Der Manager bekommt keine Verbindung und es wird eine Fehlermeldung ausgegeben.

Ich kenne das aber auch schon von Mint 20, dass das nicht klappte. Schon mal das versucht:
via Datei-->Computer auswählen und als Rechner localhost eintragen. Passwort kann leer bleiben, auch wenn eine gui_rpc_auth.cfg gepflegt ist.
Ich nutze Boinc Tasks zum Zugriff auf die Linuxkisten, um mich nicht mit den lokalen Boinc-Manager rumzuärgern. Ich hab auch die 7.18.1. Pre-Release. Mit den Gruppenergänzungen und dem Eintrag für den Servicestart aus #1.666 geht es:

sudo usermod -a BENUTZER -G boinc
sudo systemctl enable boinc-client.service
sudo systemctl start boinc-client.service

Ich habe grad eben endlich erfolgreich eine Einstein-WU auf der 680M-GPU des 6850U gerechnet. Das hat mich zwei Monate beschäftigt, schön dass das nun klappt!
An was es letztlich lag? Systemd und boinc-client.service ...
Dort muss in der Datei
/usr/lib/systemd/system/boinc-client.service
ProtectSystem=strict zu ProtectSystem=full geändert werden und PrivateTmp=true eingefügt werden.
Den Tipp hab ich von hier:

not being able to crunch successfully GPU WUs on ArchLInux with default systemd settings · Issue #4948 · BOINC/boinc

Describe the bug I am not being able to complete any GPU task on my ArchLinux based system using an AMD Radeon 5700XT. For some projects, like milkyway@home the task errors out imemdiately, for som...

github.com

Das dürfte auch für alle RDNA-Karten dann gehen, lehne ich mich mal ausm Fenster ....

 

[tomturbo]

@enigmation Es ist allerdings besser das service nicht zu ändern sondern einen "override" zu machen, da wird dann bei einem upgrade nichts überschrieben.

systemd service files mit override anpassen – tech-island.com

Zu Gruppen hinzufügen tu ich lieber mit "gpasswd -a <user> <group>"

 

[enigmation]

@tomturbo ok, und wie stelle ich das an?
Ich habe das so geändert:

sudo nano /usr/lib/systemd/system/boinc-client.service
sudo systemctl daemon-reload
sudo service boinc-client restart

Wie sieht dein Weg aus?

 

[tomturbo]

Habe ich oben reineditiert, @enigmation

 

[enigmation]

Also ein override-File ist besser, da es passieren kann, dass die boinc-client-service überschrieben wird. Ok, verstanden.
Ich habe nun sämtlichen nicht kommentierten Inhalt von hier
/usr/lib/systemd/system/boinc-client.service
in das override-file eingetragen.

Dieses Kommando habe ich dafür ausgeführt:

sudo systemctl edit boinc-client.service

und diesen Inhalt eingefügt:

### Editing /etc/systemd/system/boinc-client.service.d/override.conf
### Anything between here and the comment below will become the new contents of>

Type=simple
ProtectHome=true
ProtectSystem=full
PrivateTmp=true
ProtectControlGroups=true
ReadWritePaths=-/var/lib/boinc -/etc/boinc-client
Nice=10
User=boinc
WorkingDirectory=/var/lib/boinc
ExecStart=/usr/bin/boinc
ExecStop=/usr/bin/boinccmd --quit
ExecReload=/usr/bin/boinccmd --read_cc_config
ExecStopPost=/bin/rm -f lockfile
IOSchedulingClass=idle

anschließend den boinc-Client.Service neu starten

sudo systemctl daemon-reload
sudo service boinc-client restart

Mit

less /etc/systemd/system/boinc-client.service.d/override.conf

kann man die Existenz und den Inhalt des override-Files überprüfen.

Passt das so @tomturbo ?

 

[tomturbo]

Wenns funktioniert passts

 

[enigmation]

Die Primegrid-PPS-WU läuft auch nach dem Neustart, also beantworte ich das mal mit Ja.
SR-Base funktioniert auch, ich bin zufrieden.

 

[Ereignishorizont]

Zwischenzeitlich ist das Problem (hoffentlich) gelöst. Ich musste Linux noch mal neu installieren und habe das Update von 'Vanessa' auf 'Vera' nicht ausgeführt.

Mit der Version 7.20.5 aus #1680 traten Anfangs zwar auch Verbindungsprobleme zwischen Manager und Client auf. Die konnte ich dann aber über die Befehle aus #1667 lösen. Seither kann ich den Client beenden und neu starten. Auch enthalten die jeweiligen Ordner mittlerweile Dateien und nicht nur tote Links.

Mit der ursprünglichen Linux-Installation funktionierte es auch mit der 7.20.5 nicht. Vermutlich war da alles schon zu sehr vermurkst.

Danke an alle für den Input!

 

[FritzB]

Mint 21.1 gibt sich bei BOINC als GNOME 42 und die Benchmarks sind auch nicht so dolle.

Computers belonging to FritzB Universe@Home

universeathome.pl

 

[sompe]

So, System Nummer 4 hat ein Upgrade auf Ubuntu 22.04 bekommen (nur mein alter Athlon 5350) und das zickte mit dem Fehler aus #1.667 rum.
Damit hätte ich jetzt 4 Upgrades und bei jedem System reagierte der BOINC Manager anders darauf, wobei 3 von 4 BOINC Installationen danach nicht mehr liefen und erstmal gefixt werden mußten.
Pre-release merkt man da echt an allen Ecken und Enden.

 

[herby44]

Beim BS Race Einstein haben wir am ersten Tag ganz schön was abgeliefert über 46 Millionen.

 

[FritzB]

Bin gespannt ob da noch von jemandem ein Überraschungsbunker kommt. Im Moment sieht's für uns ja gut aus
Hab noch genug Arbeit bis morgen Abend. Also erstmal nichts neues anfordern.

 

[Ritschie]

Beim BS Race Einstein haben wir am ersten Tag ganz schön was abgeliefert über 46 Millionen.

Die BOINCstats-Races gehen zwar üblicherweise ziemlich an mir vorbei - aber ich hab dann mal für die letzten 24h meine RX 5600XT dazu geschalten.

Gruß
Ritschie

 

[MagicEye04]

Mein Vorrat hat ganz gut gepasst. Das frühzeitige Einlagern hat das Pending dauerhaft sehr niedrig gehalten.

 

[olsen_gg]

SiDock mit seinen long tasks macht mich verrückt.
Die laufen zu lange, um sie auf non-24/7-PCs laufen zu lassen. Bevor sie fertig sind, vergammeln sie.
Auf dem Intel laufen sie auch bei 24/7 nicht durch (<50% nach >3d).
Nur: Short tasks gibt es eben auch keine.

Doppelposting wurde automatisch zusammengeführt: 21.01.2023

Beim BS Race Einstein haben wir am ersten Tag ganz schön was abgeliefert über 46 Millionen.

Die BOINCstats-Races gehen zwar üblicherweise ziemlich an mir vorbei - aber ich hab dann mal für die letzten 24h meine RX 5600XT dazu geschalten.

Gruß
Ritschie

Leider bin ich nach meinen Spar-Umkonfigurationen sowas wie gpu-unfähig geworden.
Eine GTX750 oder GT1030 für ein paar Stunden zuschalten, wäre Unsinn. Aber schön, dass ihr es noch könnt.

 

[herby44]

Auf dem Intel laufen sie auch bei 24/7 nicht durch (<50% nach >3d)

Da wären die MCM von WCG oder TN-Grid besser geeignet, und mit deiner GTX 750 könnte man wenn es
sein muss auch ein paar Amigo Zahlen rechnen, vielleicht auch ein paar Primeln oder SR-Base.

Nur: Short tasks gibt es eben auch keine.

Es könnte sein das es sie zurzeit nur für Raspi's gibt, meine Odroid's N2 hatten damit nur Berechnungsfehler.

 

[JagDoc]

Nur: Short tasks gibt es eben auch keine.

Es könnte sein das es sie zurzeit nur für Raspi's gibt, meine Odroid's N2 hatten damit nur Berechnungsfehler.

Die App für Short-WUs gibt es nur für ARM:

Applications

www.sidock.si

Auf meinen Odroiden N2+, C4 und M1 laufen die ohne Probleme.

Doppelposting wurde automatisch zusammengeführt: 22.01.2023

@herby44 versuch es mal mit:

sudo apt install libgomp1:armhf

 

[Maverick-F1]

Auf einem der C2 laufen long und short problemlos - die Long brauchen vielleicht 0,5 - 1h länger, machen also nicht wirklich einen Unterschied...

 

[JagDoc]

Auf einem der C2 laufen long und short problemlos - die Long brauchen vielleicht 0,5 - 1h länger, machen also nicht wirklich einen Unterschied...

Dein C2 hat bis jetzt nur die kurzen "corona_Sprot_delta_v1" WUs gerechnet.
Die laufen auf den ARMs mit beiden Apps (short und long).

Die langen sind "corona_RdRp_v2" WUs.
Die Langen laufen auf einem 4700U ca 24 - 36 Stunden.

Dein C2 hat jetzt 2 von den "corona_RdRp_v2" achte mal auf die Laufzeiten von denen.
Ich hab auf meinen Odroiden nur noch die Short zugelassen.

 

[olsen_gg]

SiDock Short's nur für Arm ist natürlich doof.
Auf der SiDock-Seite kann ich doch auswählen, welche ich haben möchte - und das unabhängig von der Hardware. Aber dann brauche ich nicht zu warten, ob was kommt. Danke für den Tipp.
O.k., dann bleibt der i7 eben bei TN-Grid (und Radac).
Was ich dann bei Sonne auf den Ryzen7/9 crunchen will, bleibt ein Rätsel.

Doppelposting wurde automatisch zusammengeführt: 22.01.2023

Ach, Schnickschnack, ich mache erstmal ein paar Universen auf dem Linux-R7.