frndc.saschaschroeder.eu

Ich erwäge, den Server nachts abzuschalten und morgens zu starten. Leider gibt es bislang Probleme beim Reboot, wenn das System ein paar Tage gelaufen ist. Ganz zu schweigen davon, dass ich wohl # Quadlets meistern und die automatisierte LUKS-Entschlüsselung sauber hinbekommen müsste. Aber eins nach dem anderen...

Also versuche ich, ob ein UEFI-Upgrade hilft. Also zuerst mal # für # konfiguriert und darüber das Upgrade gemacht. So weit, so gut. :check mark button:

Hab jetzt rausgefunden, dass man das Upgrade von # bei # wohl am Besten via Webinterface aktualisiert. Jetzt scheitere ich daran, dass ein Product Key verlangt wird. Erst mal schauen, wo ich den wieder her bekomme.

Und was habt Ihr heute so gemacht?

# # # # #
gehrke_test
Ne, geht auch ohne WebInterface und Product Key. Muss man nur richtig machen... RTFM!

:check mark button: Firmware Upgrade done

Vorher:
Platform Firmware Information
	Vendor: American Megatrends Inc.
	Version: 2.0b
	Release Date: 12/02/2019


Nachher:
Platform Firmware Information
	Vendor: American Megatrends Inc.
	Version: 3.4
	Release Date: 07/28/2025


Aber hey, ich hab Blut und Wasser geschwitzt, aus Angst, die # zu bricken. Zwar habe ich die nicht selbst bezahlt und sie sind schon etwas älter, aber sie bilden das Herzstück meiner privaten Infrastruktur.

Als der erste mitten im Upgrade für 2 Stunden hing, kam doch schon etwas schlechte Laune auf. Aber ein zweiter Durchlauf war dann erfolgreich.

Foto vom Prozess mit hängendem System

Foto vom Prozess mit Erfolgsmeldung

Daumen drücken, dass damit dann jetzt auch meine eigentlichen Probleme beim # gefixed sind. Das sehe ich vermutlich in 5 Tagen...

# #
gehrke_test
Das Firmware-Upgrade hat leider mein Problem nicht gelöst. Hhmpff!

Heute kam ein Kernelupgrade, danach steht immer Reboot an. Uptime war 5+ Tage und wieder kam die Büchse nicht mehr von alleine hoch, sondern musste manuell powercycled werden.

Bin langsam mit meinem Latein am Ende.
gehrke_test
Mein kleines Refactoring-Projekt der heimischen Infrastruktur zieht immer größere Kreise.

Wenn ich den fetten Server nachts abschalten will, brauche ich 24x7 Ersatz in klein. Dafür habe ich gestern eine APU 1D4 mit # 13 bestückt.

Stellt sich raus, dass ich vor 10 Jahren einen # ebenfalls auf einer APU 1D4 installiert habe, der alle 5 Minuten 24x7 die Zählerstände des digitalen Stromzählers und vom # in eine Datenbank protokolliert. Ach ja, langsam erinnere ich mich wieder.

Die Software dafür läuft im wesentlichen seit dieser Zeit ununterbrochen (ausser Stromausfällen) in meinem hinterletzen Subnetz. Zum Glück hatte ich damals in einem # dokumentiert, was ich damals verbrochen hatte.

$ grep PRETTY /etc/os-release
PRETTY_NAME="CentOS Linux 7 (Core)"


Da muss ich dann jetzt wohl auch mal ran...

#
gehrke_test
Der Tag ist doof!

Ich dachte mir, meinen Plan etwas voranzubringen, den fetten Server für Teile der Nacht runterzufahren, um Energie zu sparen. Dazu müsste ich Teile der dortigen Services auf einen anderen 24x7 Server migrieren, der weniger # schluckt.

Meine prädestinierte # dafür ist die PCEngines APU 1D4, davon habe ich hier noch einige rumliegen. Die sind sparsam und grundsolide, aber auch alt. Performancetechnisch sollten die aber noch ausreichen.

Meine naiven Versuche mit # 10 scheiterten ebenso wie mit Release 9, vermutlich wegen mangelnder Hardwareunterstützung:
* RHEL 9: Anhebung des x86_64-Baselines auf x86-64-v2
* RHEL10/CentOS Stream 10: x86-64-v3 vorausgesetzt

Schade, weil ich mit CentOS viel Erfahrung habe. Aber da kann man wohl nix machen. Ich will aber weder den Plan noch die vorhandene Hardware aufgeben, jedenfalls jetzt noch nicht.

Also gehe ich mal wacker auf die Suche nach einer anderen #.

Kriterien:
* möglichst langer Software-Support (Security)
* Support von #

Die KI sagt, dass vermutlich # 13 am ehesten zu empfehlen ist. Ich bin geneigt, dieser Bewertung zuzustimmen. Debian hatte ich auch schon mehrfach im Einsatz, ein gewisses Grundwissen ist also vorhanden.
Für Debian 13 wird aktuell ein Support bis 30. Juni 2030 genannt.

Entscheidungsmatrix der KI. Reihenfolge: Debian 13, Debian 12, Ubuntu, openSUSE Leap, Alpine Linux

# # # # #
gehrke_test
Die # misst die # mit 5,4 Watt. Das ist ein Bruchteil des abzuschaltenden Servers und somit IMHO völlig OK.

Screenshot Shelly Plug S - Verbrauchswerte

Screenshot APU 1D4 btop - hauptsächlich idle

War doch noch ein guter Tag...
Screenshot Shelly Plug S - Verbrauchswerte
Screenshot APU 1D4 btop - hauptsächlich idle
gehrke_test
@Pascal
Teile der dortigen Services sollen dauerhaft umziehen - diese werden 24x7 benötigt und sollen migriert werden.

Andere sind nachts verzichtbar. Die werden dann mit dem fetten Server abgeschaltet.
neuer älter