Search results

Hatte versehentlich eine etwas frühere Version verscreenshottet, die aber das gleiche Problem, wie die aktuellste Version hat. Habe Windows 10 von einem aktuellen ISO in einer VM neu installiert, da tritt das Problem nicht auf. Irgendwas ist an dem Windows also nicht mehr in Ordnung.

Finally I found the (stupid) solution... While writing the 2 last posts I pushed myself in the right direction... somehow through copy-pasting the script there got two newlines right at the beginning, so the Shebang ("#!/bin/bash") wasn't at the very first position in the file where it has to be...

Yes, its in HBA mode, otherwise ZFS would make problems as far as I know. What I'm really wondering is the GUIs error message "Exec format error"... how can a Shell Script have an "exec format error"? And why doesn't it make any problems at cmdline but it does when called from the GUI?

As the last line you (and so me either) added to the script is "exit 0" it's not very surprising, "echo $?" shows "0" after running... For me it looks like the script doesn't even start at all when called from the GUI...

Hallo zusammen, wollte heute die neuen VirtioGuestTools von hier in einem Windows 10 Gast installieren: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso Die Installation per "virtio-guest-tools.exe" schlug fehl. Wie sich herausstellte, klappte fast...

@ccg @udotirol For me this didn't help. Edited the wrapper script as ccg did but GUI stillt doesn't work. Columns "S.M.A.R.T." and "Wearout" remain empty: Clicking on "Show S.M.A.R.T. values" Button leads to the same error: Using the shown command at cmdline just works:

As I am also using P420 controllers I am also affected with "unknown" smart values in the gui. Tried @udotirol s wrapper script as described, which works fine at the console. But the GUI remains in "unknown". When selecting one disk and click "Show S.M.A.R.T Values" an error is shown in the...

BTW: Der GarbageCollect läuft mittlerweile seit 3 Tagen... Sind zwar auch 8-10TB Daten, aber kommt mir trotzdem irgendwie lange vor

Sorry, mußte das erst in Erfahrung bringen... an die Hardware komme ich persönlich nicht direkt ran.... 7x HDD SATA 2,5 2TB hängen an 2x HP Smart Array P420 - 1GB 633542-001 6Gb 2-Port SAS Controller Standard Profile - aktuelle firmware Die Controller sind im HBA Mode Dazu eine SSD für ZFS log...

Irgendwas ist da auf jeden Fall nicht ganz koscher... es ist ja schon allein ungewöhnlich, dass bei einem raidz1 - ZFS Pool aus 7 Platten mehrere Dateien so kaputt sind, dass noch nicht mal ZFS davor geschützt hat. Und es waren backups, die an komplett unterschiedlichen Tagen erstellt - sprich...

Das passierte reproduzierbar dann, so lange defekte idx Files im ZFS vorhanden waren. Seitdem die raus sind, läuft der GC durch. Wenn es Hardware wäre, dürfte es ja nicht so exakt reproduzierbar sein bzw. jetzt auch nicht ohne Probleme durch laufen. Im dmesg Output finden sich solche Einträge...

Es gibt ein paar minuten vorher nichts im Log, ich hatte den Startzeitpunkt bei journalctl ja auf 22:20 gesetzt, trotzdem ist der erste Eintrag erst um 22:31. Hier auch noch mal der entsprechende Auszug direkt aus "/var/log/syslog.1": Jan 20 22:09:29 backup proxmox-backup-proxy[1429759]: write...

Du meinst das systemd Journal (journalctl)? Hab dafür einen passenden Zeitraum zum Screenshot oben genommen: root@backup:~# journalctl -S "2022-01-20 22:20:00" -U "2022-01-20 22:35:00" -- Journal begins at Sat 2021-12-25 20:40:10 CET, ends at Tue 2022-01-25 17:35:47 CET. -- Jan 20 22:31:33...

Nein, wenn es zu diesem Problem kommt, bricht der Job hart ab, es erscheint ein Prompt. Nachdem ich die defekten .idx Files gelöscht hatte, hab ich den Job auf der Commandline neu gestartet, danach lief er normal über den Punkt hinaus weiter. Man kann auch in der GUI die abgebrochenen Jobs...

Nein, der bricht wirklich hart ab und hängt nicht fest. Es erscheint wieder ein normaler Prompt...

Ja, da kommt tatsächlich nichts mehr. Im syslog steht auch nichts auffälliges. Allerdings habe ich die Ursache offenbar - zufällig - gefunden. Der Backup DataStore liegt auf einem ZFS Pool. Und ein Blick in "zpool status" offenbarte, dass offenbar 3 .idx Dateien unreparierbar defekt sind. Da...

Hallo zusammen, ich habe festgestellt, dass seit einiger Zeit die Garbage Collection des Backup Servers fehl schlägt. Zum Testen starte ich die per Hand auf der Konsole: root@backup:~# proxmox-backup-manager garbage-collection start backup mit dem Ergebnis, dass die Phase1 plötzlich und ohne...

Macht nix, man kann doch nicht immer an alles denken :) ja, klingt für mich auch schlüssig .... Kann man die Chunk Size eines bestehenden Pools ändern? Hab hier: https://forum.proxmox.com/threads/thin-lvm-and-zeroing-chunk-size.56262/ gelesen, dass das mit "lvconvert --type thin-pool -c ..."...

Vllt. hab ich eine Ahnung, worans liegt ... die Chunksize des Thin Pools von Server A ist 64K , die Chunksize für den Pool auf Server B 1MB ... Bei Server A sind somit wahrscheinlich viel mehr Blöcke bei gleicher Speichermenge nötig, was logischerweise mehr Metadaten erfordert.. könnte Sinn ergeben

Wenn ich das richtig verstanden habe, wird Metadata nicht nur für Snapshots gebraucht, sondern ganz allgemein dafür, welche Blöcke im ThinPool von welchem LV belegt sind. Es existiert kein einziger Snapshot, der ThinPool ist auch gerade neu, es gibt nur 2 VMs.