Edomi ProxMox- bzw. LXC-Template

[Timowald]

Wenn ich Edomi im CT starte kommt folgende Meldung"

sync_wait: 34 An error occurred in another process (expected sequence number 7)
__lxc_start: 2107 Failed to spawn container "240"
TASK ERROR: startup for container '240' failed

[jolt19]

Da man angelegte Farben für die Visu ja scheinbar nicht in der Oberfläche von Hintergrundfarben zu Vordergrundfarben (und vice versa) kopieren kann, gab es hier im Forum den Hinweis das kopieren über die SQL Datenbank zu realisieren.

Leider erhalte ich den Fehler "Host is not allowed to connect to this MariaDB server".
starwarsfan du hattest in einem anderen Forum auf diese Anleitung verwiesen um das Problem zu lösen. Ich werde da allerdings nicht schlau draus.
Wenn ich wie dort beschrieben

mysql -u root -p

oder auch

mysql -u mysql -p

eingebe, erhalte ich ERROR 1045 (28000): Access denied for user 'root'@'localhost'


und wenn ich schon dabei bin hätte ich noch eine ganz andere Frage. Wie kann ich auf das neuste Release deines edomi-lxc upgraden?

[starwarsfan]

Hallo miteinander

Das Weis ich nicht. Evtl beim anlegen vom Container. Habe ich mit Debian und Ubuntu probiert.

Also hast Du es eben nicht so gemacht, wie es im ersten Posting dieses Threads steht. Hier geht es um den Edomi-LXC-Container und da muss man sich überhaupt nicht um das verwendete System für Edomi kümmern.

Mit Debian und Ubuntu wird es nicht funktionieren. Nimm Cent OS oder Rocky Linux.....

Bitte nicht einfach irgendwas schreiben, ohne zu wissen worum es geht! Wir sprechen hier vom ProxMox-Template und da spielt ein Hinweis auf die zu verwendende Distribution überhaupt keine Rolle.

[skyacer]

Das Weis ich nicht. Evtl beim anlegen vom Container. Habe ich mit Debian und Ubuntu probiert.

Mit Debian und Ubuntu wird es nicht funktionieren. Nimm Cent OS oder Rocky Linux.....

[Timowald]

Das Weis ich nicht. Evtl beim anlegen vom Container. Habe ich mit Debian und Ubuntu probiert.

[starwarsfan]

Hi

Habe es so gemacht. Container startet auch aber ich erreiche http://<ip>/admin nicht.

Habe es genauso gemacht und es funktioniert problemlos.

Was könnte nun wohl für weitere Hilfestellung fehlen?

[Timowald]

Habe es so gemacht. Container startet auch aber ich erreiche http://<ip>/admin nicht.

[mmarkus]

im ersten Beitrag von diesem Thread steht doch die Anleitung. Ansonnsten, was genau läuft nicht?

[starwarsfan]

Hi

gibt es irgendwo eine Schritt für Schritt Anleitung wie man Edomi auf Proxmox installiert?

Natürlich, erstes Posting in diesem Thread.

[Timowald]

Hallo, gibt es irgendwo eine Schritt für Schritt Anleitung wie man Edomi auf Proxmox installiert? Bekomme es nicht zum laufen.

[saegefisch]

Das ganze entwickelt sich zu einem Proxmox-Lehrstück...
Vielleicht hilft das ja grundsätzlich mal jemand anderem in einem anderen Proxmox-Kontext
LXE-Config findet man an 2 Stellen, den hier interessanten Mount-punkt in der 2.

/etc/pve/local/lxc/<container-ID>.conf​
/var/lib/lxc/<container-ID>/config.​

Damit einen Schritt weiter - theoretisch:
Ändern einer Datei im Container funktioniert per SSH vom gestoppten LXC:

sudo pct mount <container-ID>
sudo nano /var/lib/lxc/<container-ID>/rootfs/etc/systemd/system/edomi.service
sudo pct unmount <container-ID>

Aber das reicht nicht, LXC startet noch immer nicht sauber, weil der andere Hinweis war ja das Update von systemd unter CentOS7. Das sollte gehen mit:

sudo pct mount <container-ID>
sudo pct start <container-ID>
sudo pct enter <container-ID>
wget https://copr.fedorainfracloud.org/coprs/jsynacek/systemd-backports-for-centos-7/repo/epel-7/jsynacek-systemd-backports-for-centos-7-epel-7.repo -O /etc/yum.repos.d/jsynacek-systemd-centos-7.repo
yum update systemd
exit
sudo pct stop <container-ID>
sudo pct unmount <container-ID>

aber nach Start kommt

WARN: old systemd (< v232) detected, container won't run in a pure cgroupv2 environment! Please see documentation -> container -> cgroup version.
Task finished with 1 warning(s)!

und damit kein Netzwerk und damit funktioniert wget auch nicht. Daher wget auf host ausgeführt und an die richtige stelle des gemounteten edomi-LXC verschoben.
Aber natürlich will

yum update systemd

noch mal was laden, das repo enthält ja nur die Abhängigkeiten und Links - vermute ich, damit kenne ich mich nicht aus.

Frage: Was muss ich vorab herunter laden und in den LXC-Container wohin schieben, damit yum update systemd alles nötige findet und daher ohne Netzwerk funktioniert?

Nachtrag: Theoretisch wohl mit

yum update --downloadonly --downloaddir=/var/lib/lxc/<container-ID>/rootfs/var/cache/yum/x86_64/7/??? systemd

, aber der Proxmox-Host kennt kein yum. Und in welchen Pfad GENAU müsste es unter CentOS7 liegen, damit yum es dort ohne Netzwerk findet?

----
Nachtrag 05.10.2022: Wenn niemand mehr eine smarte Idee oder Antworten hat
A) welche Dateien ich (unter CentOS 7) für

yum update systemd

brauchen würde und wie ich
B) die unter Debian (Proxmox Host) herunterladen kann, um sie dann
C) in die edomi-VM zu schieben (welcher genau Pfad braucht yum dort?)
und dort eben yum update systemd offline ausführen zu können... werde ich mich wohl von meiner alten edomi-DEV verabschieden und mit einem frischen LXC anfangen...
Kein (richtiges) Backup, kein Mitleid mit mir selber...

[saegefisch]

Zum Thema Proxmox 6.x auf 7.2.11 eine Frage, weil ich im Vorfeld doof war und etwas nicht geprüft habe bzw. davon ausging (wie bei den anderen cgroup-Themen) dass ich die Änderungen auch nach dem Upgrade machen kann.
* Per Script täglich Backup vom PROD edomi (eigenen HW) auf NAS -> kein Problem
* per Proxmox täglich backup meiner edomi-LXCs (fallback-PROD,DEV) auf NAS -> kein Problem (technisch)

Nach dem Upgrade grade und etwas Justage laufen alle VM/LXCs wieder. Nur die beiden edomis nicht. Werden grün angezeigt, aber keine Konsole, kein SSH, nix. Die prod-fallback VM kann ich jederzeit neu aufbauen aus meinem Echt-System, aber vom DEV habe ich mir vorher schon länger kein edomi-Backup gemacht - weil ich Depp dachte, dass ich die Änderungen später machen kann und ja die täglichen Proxmox-Backups habe. Aber die laufen natürlich genauso wenig, wegen des cgroup2-Gedöns.

Das ist nicht wirklich schlimm, aber ein paar Sachen waren da schon, die ich gerne wieder hätte, weil ich die nur dort entwickelt hatte, aber noch nicht ins PROD gebracht habe und diverse Testszenarien für eigenen LBS. Hose runter! Ich weiß, ich sag's ja selber immer: Kein Backup, kein Mitleid!

Dennoch die Frage, ob man die /etc/systemd/system/edomi.service eines nicht laufenden LXC-Containers irgendwie ändern kann (gemäß Sebastians aka bas29 Hinweisen), um edomi doch wieder starten zu lassen? Wo (Pfad) findet man die auf dem proxmox-Server?

Alternativ: Kann man in einem Backup vzdump...tar.std die /etc/systemd/system/edomi.service direkt ändern und dann das geänderte Backup in Proxmox zurückspielen? Hat das schon jemand erfolgreich gemacht? Vermutlich std entpacken, dann die Zieldatei aus tar exrahieren, ändern, zurück in tar und das dann wieder std-komprimieren und in Proxmox zurückspielen...

[starwarsfan]

Kann es vielleicht sein, dass Du (incrementelle) Snapshots des Containers machst? Die sind dann beim Backup vermutlich auch dabei und das würde erklären, dass das Backup so gross ist...

[trollmar]

Hi,

Danke Yves das du mir das erklärt hast! Ja ist etwas heikel.



Ich finde dazu eigentlich immer das "Sparse Files" wohl schuld ist.
.
https://forum.proxmox.com/threads/so...-of-gbs.78881/
https://unix.stackexchange.com/quest...g-sparse-files

Nur da finde ich bei mir nichts bzw es ist so unübersichtlich mit "find" das ich es nicht erkenne.


Gut die Lösung

dd if=/dev/zero of=zero bs=64k; sync; sync; sync; rm -f zero

War dann eine Adaption von mir ;-)

Nur wie mach ich jetzt weiter?
Könnte natürlich sagen... gut ich steige mal auf Rocky von dir um ..aber ich will ja den Fehler finden 😀

[starwarsfan]

Hallo Sebastian,

mein Edomi-Container wird (wie alle anderen Container auch) regelmässig auf ein NAS gesichert. Das Problem hatte ich noch nie.

Mit dem Befehl schreibst Du in einem dauerhaften Stream NULL-Bytes, also \0 in die Datei "zero". Das wird vermutlich so lange laufen, bis die Disk des Systems voll ist. Danach macht er dreimal "sync", um dann zuletzt diese grosse Datei wieder zu löschen. Was das nun genau bewirkten soll, kann ich so aus dem Stehgreif auch nicht sagen. Vermutlich zielt das so in die Richtung, sämtlichen alten Datenmüll auf der "Platte" des Containers zu löschen, da dieser durch NULL komplett überschrieben wird. Eben bis die Disk voll ist. Unterm Strich eine heikle Operation an einem Produktivsystem. Wo hast Du den Hinweis denn gefunden?