Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar

Die nutzen gar kein BSD mehr, sondern buildroot um flexibler die verscheidenen Platformen zu unterstützen.
Aber als FS kommt ext4 zum Einsatz und das kann TRIMM, also mit der discard Option umgehen.
 
  • Like
Reactions: CoolTux
Mit ext4 ist doch sogar das verkleinern relativ problemlos möglich. Müsste man mal schauen wie die Partitionierung genau ist.

Aber Falk hat Recht, eigentlich ist es nur ein kosmetisches Ding.
 
Ich würde am HAOS nicht so viel basteln, da er z.B. zwei Partitionen für den Kernel und zwei für das OS hat. Die machen A/B switch bei Updates.
 
  • Like
Reactions: CoolTux
Moin !

Ich hatte leider wieder das Problem, dass mein "local" voll war.

Mit
Code: 
root@proxmox:~# journalctl --disk-usage

habe ich dieses mal das hier bekommen:
Code: 
Journal file /var/log/journal/27a75f85666348ada3dad0aff5ce8b9a/system.journal is truncated, ignoring file.

Trotzdem habe ich dann mit
Code: 
journalctl --vacuum-size 1G

das System "local" dann wieder von rund 30GB auf 6.1GB reduzieren können.

Wie bekomme ich genauer raus was da jedes mal mit der Zeit den log Ordner voll müllt ?
Kann mich da jemand genauer anleiten und evtl. irgendwie nach der Ursache forschen ?


Auch bei meinen beiden LXC Containern hatte ich danach noch geschaut und gesehen, dass die "Bootdisk Größe" rot war.
Hier habe ich dann eben falls 15.2GB beim ersten bzw. 8.2GB beim zweiten Container frei machen können.
Beide melden aber ebenfalls:
Code: 
Journal file /var/log/journal/a55811e5e7dd471c8828522cf3772105/system.journal is truncated, ignoring file.
bzw.
Code: 
Journal file /var/log/journal/b63388389bb241bc9e5317b71cd5ae20/system.journal is truncated, ignoring file.
Was heißt das?
 
Last edited:
Ich hatte leider wieder das Problem, dass mein "local" voll war...
Und wieder führte das dazu, dass nach einem Stromausfall nix mehr ging.
Erst gingen Zigbee Geräte nicht mehr, dann war kein Reboot mehr möglich.

Wer kann mir helfen herauszufinden warum „local“ immer voll läuft ??
 
Wenn du wieder Zugriff auf die Konsole hast, würde ich zB mit

du -sh * | sort -hr

die Order der Größe nach anzeigen lassen. Danach kann man schauen, welche Dateien darin erstellt sind und hat so ev. einen Rückschluss wer sie produziert bzw woher sie kommen.

Ev. noch ncdu installieren und mit diesem Programm schauen.

apt install ncdu
 
Ich musste halt mal wieder mit
journalctl --vacuum-size 1G
Click to expand...
den log Ordner leer machen. Danach lief dann wieder alles.

Also das was voll ist ist der Journal Ordner, das weiß ich ja schon…
Nur weiß ich eben nicht warum.
Post in thread 'Proxmox Oberfläche nach Stromausfall nicht mehr erreichbar'
https://forum.proxmox.com/threads/p...fall-nicht-mehr-erreichbar.150913/post-683158

In der datei /etc/systemd/journald.conf steht mittlerweile auch SystemMaxUse = 750M
Ich verstehe daher nicht wieso der ordner /var/log/journalüberhaupt volllaufen kann…
 
Last edited:
Und gerade habe ich noch ein backup problem bei den containern (VM geht)
Und auf der Backup Platte ist auch platz…

Code: 
INFO: starting new backup job: vzdump --compress zstd --mode snapshot --mailnotification always --storage Backup --notes-template '{{guestname}}' --node proxmox --quiet 1 --prune-backups 'keep-daily=14' --all 1
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2025-11-23 00:00:03
INFO: status = running
INFO: CT Name: InfluxDB2
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
snapshot create failed: starting cleanup
no lock found trying to remove 'backup'  lock
ERROR: Backup of VM 100 failed - lvcreate snapshot 'pve/snap_vm-100-disk-0_vzdump' error:   Cannot create new thin volume, free space in thin pool pve/data reached threshold.
 
Last edited:
Du könntest so etwas probieren und zu sehen welcher Service am meisten loggt
Bash: 
journalctl --output=cat --output-fields=UNIT | grep ".service" | sort | uniq -c | sort -nr | head -n50
Generell hat das Journal aber ein Limit und sollte nicht voll laufen.
Für das andere Problem Teile bitte
Bash: 
lvs
pct fstrim 100
lvs
 
Hallo @lethuer,

anhand deines Screenshots lässt sich der Backup-Fehler (reached threshold) gut erklären:

Du hast eine massive Überprovisionierung (Overprovisioning) vorliegen.Dein Speicher-Pool (data) ist physikalisch nur <80,24 GB groß.Du hast den VMs/Containern aber virtuellen Speicher von weit über 160 GB zugewiesen (allein vm-135-disk-1 ist mit 128 GB größer als dein ganzer Server-Speicher).

Der Pool ist real zu 70,13% gefüllt. Wenn du ein Backup im Modus "Snapshot" startest, benötigt LVM freien Platz im Pool, um Änderungen während des Backups zwischenzuspeichern. Da der Pool aber schon recht voll ist und rechnerisch völlig überbucht, verweigert Proxmox den Snapshot aus Sicherheitsgründen, um zu verhindern, dass der Pool vollläuft und alles abstürzt.

Lösungsschritte:
  1. Backup-Modus: Stelle den Backup-Job temporär von "Snapshot" auf "Stop" um. Dabei wird der Container kurz heruntergefahren, es wird aber kein LVM-Snapshot-Platz benötigt. Das sollte funktionieren.
  2. Warnung: Die 128 GB Disk auf dem 80 GB Speicher ist ein hohes Risiko. Wenn diese VM anfängt, den Platz wirklich zu nutzen, läuft dein Host voll (data auf 100%) und alle VMs bleiben stehen oder das Dateisystem wird read-only.
  3. Logs/Root-Partition: Dein Screenshot zeigt nur die LVM-Ebene (lvs). Um das Problem mit dem vollen "local" Speicher (Logs) zu prüfen, fehlt noch die von @Impact angefragte Ausgabe von df -h. Nur dort sehen wir, wie voll / (pve-root) auf Dateisystem-Ebene wirklich ist.
Das fstrim Ergebnis (0 Bytes) bedeutet, dass im Container entweder kein Platz zum Freigeben gefunden wurde oder die Daten dort tatsächlich belegt sind.
 
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom