Posts by andreas.

  • Wiederholte Windows-Server-Abstürze auf RS/KVM: MEMORY_MANAGEMENT 0x1A / PAGE_HASH_ERRORS_0x1a_3f / Verdacht auf Storage-/VirtIO-/Host-Problem

    Da es wahrscheinlich ein VirtIO-Storage-Treiberproblem mit der Version 0.1.285 / 100.101.104.28500 geben wird, würde ich an deiner Stelle mal folgendes ausprobieren:

    • Backup/Snapshot erstellen
    • VirtIO Storage-Treiber auf 0.1.271 downgraden

    Wenn nach der Systembeobachtung weiterhin solche oder auch ähnliche Fehler wie PAGE_HASH_ERRORS_0x1a_3f auftreten, würde ich an deiner Stelle netcup mit Dumps, Treiberversionen und Zeitstempeln kontaktieren und Host-/Storage-Node-Migration verlangen.

  • Wiederholte Windows-Server-Abstürze auf RS/KVM: MEMORY_MANAGEMENT 0x1A / PAGE_HASH_ERRORS_0x1a_3f / Verdacht auf Storage-/VirtIO-/Host-Problem

    Quote from miksbl

    Meine Fragen an die Community: ...

    Damit dir eventuell auch einer aus dem Forum helfen kann:
    Auf welchen Server Type bzw. Produktbezeichnung (z.B. RS 4000, G 12) tritt dieses Problem auf? Denn einfach RS/KVM reicht leider nicht aus, da der Provider Netcup mehrere verschiedene Produktvarianten auf diesen Hypervisor betreibt.

  • Erneute Preisanpassung eines Mitbewerbers zum 15.06.2026

    Quote from SnowBerryZ

    Ja die Setup-Gebühren sind echt heftig, aber allgemein die Preiserhöhung bei Subnetzen, Hardware usw. sind ja auch nicht ohne ...

    Meines Wissens sind bei denen die Subnetze nicht angehoben worden. Denn von denen ist man als Kunde es gewohnt, als Betroffener vorher diese Preisanpassungen auf sein schon bestehendes Produkt, wie z.B. dem Subnetz, auch persönlich mitgeteilt zu bekommen.

  • Erneute Preisanpassung eines Mitbewerbers zum 15.06.2026

    Am 27.05.2026 hat ein Mitbewerber aus Falkenstein in seinem Kundenforum unter der Überschrift Standardisierung und Preisanpassung unserer Server-Produkte ab 15. Juni 2026 eine kurzfristige Preisanpassung angekündigt.

    Details dazu findet man im entsprechenden Forum des Anbieters.

    Für einige Kundinnen und Kunden könnte das insbesondere dann interessant sein, wenn sie dort beispielsweise eine Storage Box zur Datensicherung nutzen - etwa für Backups eines Netcup Servers.

  • [gelöst] spontaner Reboot

    Quote from mro

    doch, aber das mache ich ungern ohne Not auf Verdacht in's Blaue. Wäre mein erster 15er, .0 vermeide ich normalerweise und IPv6-only ist auch etwas speziell, aber irgendeiner ist ja der Erste.

    P.S.: im Nachhinein ärgerlich, erst kürzlich ging ich 14.3 -> 14.4.

    Also eine Version, die mit .0 endet, würde ich auch erst einmal vermeiden zu installieren und eher den derzeitigen Kernel auf eine neuere Version, die nicht auch mit .0 endet, hochziehen.

    Dennoch habe ich noch mal meine lokale KI befragt, deren Sprachmodell vor ca. 9 Stunden das letzte Mal aktualisiert / trainiert wurde. Und deren Hinweis auf die Ursache sieht heute wie folgt aus:

    Display Spoiler

    Das ist ein klassischer UFS/Softdep-Korruptionscrash unter FreeBSD. Der Backtrace zeigt:

    Code
    #3  softdep_disk_io_initiation+0x12ae
#4  ffs_geom_strategy+0x13b
...
#9  ffs_fsync+0x22

    FreeBSD versucht, UFS-Metadaten auf die Platte zu schreiben (via ffs_fsync → softdep), und trifft dabei auf einen ungültigen Eintrag mit dem Typ jnewblk, der im Softdep-Log nicht erwartet wird.

    Mögliche Ursachen

    UrsacheBeschreibung
    Disk-Fehler / Bad BlocksDefekte Sektoren korrumppieren Metadaten oder den Softdep-Journal
    Zu wenig RAMSoftdep benötigt viel Arbeitsspeicher — bei zu wenig wird der Cache korruptiert
    Host-Storage-ProblemeBei VMs: falsch konfigurierte VirtIO/SCSI, unzuverlässiger Host-Speicher
    Bug in FreeBSD 14.4p2Möglicher Softdep-Bug in dieser Release

    Vorgehensweise

    1. Sofort: Metadumps holen, bevor sie verloren gehen:

    Code
    # Wenn das System wieder hochfährt und die Partition lesbar ist:
disklabel ad0s1 > /var/tmp/disklabel.txt 2>/dev/null || true
dumpfs -u /dev/ad0s1a > /var/tmp/dumpfs_a.txt 2>/dev/null || true
dumpfs -u /dev/ad0s1b > /var/tmp/dumpfs_b.txt 2>/dev/null || true
# ... für alle Partitionen

    2. RAM-Tests: Memtest86+ laufen lassen — Softdep-Crash sind häufig ein Symptom von Speicherfehlern.

    3. VM-Storage prüfen:

    • VirtIO-Disks unter QEMU/KVM können Probleme machen, wenn iothread=on nicht gesetzt ist oder die Host-Platte langsam
    • SCSI statt VirtIO probieren als Workaround

    4. Dateisystem prüfen:

    Code
    # Einmalig und mit -y für automatische Reparatur:
fsck_ufs /dev/ad0s1a

    5. Falls es sich wiederholt: Auf FreeBSD 14.3 zurückgehen oder ein Upgrade auf 15.x in Betracht ziehen (Softdep wurde dort teilweise überarbeitet).

    Kurzantwort

    Am wahrscheinlichsten ist entweder ein defekter Speicherlaufwerk im Host/VM, RAM-Defekt oder Storage-Latenz der VM-Disks. Starte mit Memtest und fsck.

    Die Frage "Würde ein Upgrade von der derzeitigen Version auf 15.0 das Problem lösen?" wurde wie folgt beantwortet:

    Display Spoiler

    Ja, ein Upgrade auf FreeBSD 15.0 hat gute Chancen, das Problem zu lösen — aber mit wichtigen Einschränkungen.

    Warum es helfen könnte

    In FreeBSD 14.x wurde der Softdep-Mechanismus mehrfach mit Bugs gelandet. In 15.0 gab es folgende relevante Änderungen:

    • FFS2/Softdep-Fixes: Mehrere Patches für Metadaten-Korruption und Race Conditions in softdep
    • Disk I/O Path Refactoring: Der gesamte Writeback-Pfad wurde überarbeitet (verwandte Commit-Reihen)
    • Zahlreiche jnewblk-bezogene Bugs gefixed, die genau diesen Crash verursachen

    Aber: Es ist kein Garant

    Der Softdep-Crash mit jnewblk hat sehr oft eine unterliegende Hardwareursache:

    TypLösung durch 15.0?
    Defekte Platte / Host-Storage❌ Nein — Problem bleibt
    RAM-Bugs im System/Host❌ Nein
    VirtIO-Gast-Treiber Bug⚠️ Möglicherweise (neuer Treiber)
    Softdep-Race Condition✅ Wahrscheinlich gelöst

    Empfohlener Weg

    1. Speicher & Hardware prüfen — falls ein physisches Problem vorliegt, bringt das Upgrade nichts:
      • Memtest86+ auf dem Host oder Gast
      • SMART-Checks der virtuellen Disks (Host-Seite)

    2. Upgrade auf 15.0, aber mit Vorsicht:

      Code
      freebsd-update upgrade -r 15.0-RELEASE
# ... nach Installation
freebsd-update install
# ... Neustart und nochmal
freebsd-update install
    3. Optional: Falls die VM noch nicht kritisch ist, eine saubere Neuinstallation mit 15.0 versuchen (falls das Problem nicht wiederkehrt → war Softdep-Bug, sonst Hardware).

    Fazit

    Ein Upgrade auf 15.0 löst es in ~60-80% der Fälle, wenn die Ursache ein reiner Softwarebug war. Bei Storage-/RAM-Problemen bleibt der Crash gleich — nur unter Umständen mit einer anderen Fehlermeldung. Prüfe also zuerst die Hardware, dann upgrade.

  • [gelöst] spontaner Reboot

    Quote from mro

    Nein, woran denkst Du?

    Es gibt im SCP unter dem Menüpunkt "Medien" auch eine Unterfunktion "Speicher optimieren", die sich auch auf dem Host auswirkt und dazu führen kann, dass das Hostsystem erkennt, dass es für deine VM die Quota anpassen muß und somit deiner VM wieder mehr Festplattenspeicher freigibt.

  • [gelöst] spontaner Reboot

    Quote from mro
    Display Spoiler


    Tips?

    Ich habe mal meine KI zu deinem Problem gefragt.
    Sie teilt dazu folgendes mit:

    Display Spoiler

    Die Fehlermeldung zeigt einen Kernel-Panic in FreeBSD 14.4 im Bereich des UFS-Dateisystems mit aktiviertem Journaling. Hier ist eine Einordnung, was der Fehler bedeutet und wie du damit umgehen kannst:

    🔍 Was sagt die Fehlermeldung?

    • panic: handle_disk_io_initiation: Unexpected type jnewblk
      Der FreeBSD-Kernel stieß während einer Festplatten-I/O-Operation auf einen unerwarteten Blocktyp jnewblk (Journal-New-Block). Dieser gehört zum UFS-Journaling (softdep), ist an dieser Stelle im Code aber nicht korrekt behandelt worden → führt zum sofortigen Kernel-Panic.
    • Der Backtrace zeigt, dass der Fehler während eines periodischen Sync-Vorgangs (sched_sync → ffs_fsync → bufwrite → softdep_disk_io_initiation) ausgelöst wurde. Das passt zur Uptime von ~23 Minuten (typischer Sync-Intervall).

    🐛 Hintergrund & Bekannte Issues

    • Dies ist ein bekannter Bug in FreeBSD 14.x im softdep-Subsystem des UFS-Journalings. Er wurde in der FreeBSD-Community und im Bugzilla mehrmals gemeldet.
    • Er tritt oft unter Last, bei vielen kleinen Schreiboperationen oder bei spezifischen Storage-Backends auf (KVM kann hier durch Latenz oder Queue-Management den Auslöser liefern, ist aber selten die direkte Ursache).
    • FreeBSD 14.4-RELEASE-p2 enthält möglicherweise noch keine vollständige Korrektur. Neueere Patch-Level oder 15.x haben das Problem oft behoben.

    ✅ Empfohlene Maßnahmen

    1. Sofortiger Workaround: UFS-Journaling deaktivieren

    Code
    # Runtime (bis zum nächsten Neustart):
sysctl vfs.ffsjournal=0

# Persistente Deaktivierung:
echo 'vfs.ffsjournal="0"' | sudo tee -a /etc/rc.conf

    ⚠️ Hinweis: Du verlierst damit den Schutz vor inkonsistenten Dateisystemen bei einem unerwarteten Powerloss. Für VMs mit zuverlässigem Storage oft akzeptabel.

    2. FreeBSD auf den neuesten Patch-Level bringen

    Code
    freebsd-update fetch
freebsd-update install

    Prüfe die FreeBSD Errata nach Einträgen zu softdep oder ffs journaling für 14.4-RELEASE.

    3. Storage & KVM-Backend prüfen

    • Prüfe /var/log/messages oder dmesg auf vorangehende umass, ahci, virtio-blk oder timeout-Warnungen.
    • Stelle sicher, dass der KVM-Storage-Backend (qcow2, raw, LVM, Ceph etc.) keine Latenzspikes oder Queue-Overflows meldet.
    • Falls möglich: Storage-Polling-Intervalle oder virtio-blk-Queue-Größe anpassen (-drive ...,iothread=1 oder cache=none,io=native).

    4. Langfristige Alternative

    Falls Journaling nicht zwingend erforderlich ist, wechsle auf ZFS (zfs create -o compression=on -o mountpoint=/... rpool/...). ZFS ist auf FreeBSD standardmäßig integriert, stabiler im KVM-Context und umgeht das softdep-Problem komplett.

    📌 Zusammenfassung

    Es handelt sich um einen Software-Bug im FreeBSD-Kernel (UFS-Journaling), nicht zwingend um Hardware oder KVM-Fehler. Deaktiviere vorübergehend das Journaling, aktualisiere das System und prüfe Storage-Latenzen. Bei wiederholten Panics nach Update-Einspielung lege einen Bugreport an FreeBSD Bugzilla mit dmesg, sysctl vfs.ffs* und der KVM-Storage-Konfiguration.

    Eventuell hilft es dir weiter.

  • Server 2. IP - ist das so richtig?

    Quote from darkstar

    Ich habe jahrelang Proxmox auf eigener Hardware gehabt aber würde nie versuchen, das selbst auf virtuellen Servern zu installieren (der RS ist ein VPS mit garantierten Ressourcen). denn es macht keinen Sinn KVM im KVM genested laufen zu lassen.

    Proxmox ist nicht nur dazu da, um VM´s auf Dedicated Server zu nutzen, sondern wird hier von einigen Kunden auch dazu genutzt, um LXC´s innerhalb eines VPS / RS zu betreiben.

    Weiterhin kann Proxmox auch im Zusammenspiel mit dem Proxmox Backup Server zur deutlichen Erhöhung der Verfügbarkeit beitragen, da alles vollautomatisiert von Proxmox im Hintergrund erledigt wird.

    Und wenn man Proxmox auf mehreren VPS´s / RS´s zum Betreiben seiner LXCs innerhalb seines vLAN nutzt, kann man sogar die einzelnen LXC´s von VPS / RS zu VPS / RS vollautomatisiert verschieben lassen.

  • KRITISCH: Gehacktes Webhosting – Support reagiert nicht

    hackuni :

    Da ich eine lokale KI betreibe, habe ich mal deine Frage meiner lokalen KI übergeben und innerhalb von ca. 2 Sekunden deine Frage wie folgt beantwortet bekommen.

    Ob diese Antwort nun zu deiner Lösung beitragen wird, habe jetzt nicht geprüft. Klingt aber doch schon sehr glaubwürdig.

    Die Antwort der KI innerhalb von 2 Sekunden:

    Display Spoiler

    Das ist eine echt unangenehme Situation, aber erst einmal ein ganz wichtiger Hinweis vorab: Setz die Rechte bitte auf keinen Fall auf 777! Das bedeutet "jeder darf alles lesen, schreiben und ausführen". Damit öffnest du dem Virus (und anderen Angreifern) die Tür sperrweit auf. Setz Ordner zurück auf 755 und Dateien auf 644.

    Dass du nichts löschen kannst, liegt vermutlich an einem von zwei Gründen:

    1. Immutable-Flag: Professionelle Malware setzt oft ein spezielles Attribut (chattr +i), das selbst dir als Besitzer verbietet, die Datei zu löschen oder zu ändern.
    2. Cronjobs/Auto-Recreation: Der Virus hat einen Zeitplan (Cronjob) im System hinterlegt. Sobald du eine Datei löschst, wird sie innerhalb von Sekunden durch ein verstecktes Skript neu erstellt.

    Hier ist dein Schritt-für-Schritt-Plan, was du jetzt tun solltest:

    1. Die schnellste Lösung: Backup wiederherstellen

    Netcup erstellt in der Regel automatische Backups. Wenn die Infektion erst kürzlich passiert ist oder du ein sauberes Backup von vor Oktober hast, ist das der sicherste Weg.

    • Schau im Kundenpanel (CCP) oder im Control Panel deines Webspaces nach, ob du eine Sicherung aus einer Zeit wiederherstellen kannst, in der deine Seite noch sauber war.
    • Achtung: Wenn du ein Backup von November oder Dezember nimmst, ist der Virus höchstwahrscheinlich schon darin enthalten.

    2. Passwörter sofort ändern (Überall!)

    Bevor du aufräumst, musst du die "Eintrittstüren" schließen, sonst infiziert sich das System sofort wieder:

    • Ändere dein Passwort für das CCP.
    • Ändere dein Passwort für das Plesk Control Panel.
    • Lösch alle FTP/SFTP-Benutzer und leg sie mit starken Passwörtern neu an.
    • Ändere die Passwörter deiner Datenbanken.
    • Falls du WordPress, Joomla etc. nutzt: Ändere sofort die Administrator-Passwörter.

    3. Analyse und manuelle Reinigung (Schwierig)

    Wenn ein Backup nicht möglich ist, musst du tiefer graben:

    • Cronjobs prüfen: Schau im Control Panel unter "Geplante Aufgaben" oder "Cronjobs". Such nach Einträgen, die du nicht kennst (oft kryptische Namen oder Pfade zu /tmp oder versteckten Ordnern). Lösch diese als Erstes!
    • Versteckte Dateien: Achte auf Dateien, die mit einem Punkt beginnen (z.B. .hidden_shell.php).
    • Wenn diese Tipps nicht weiterhelfen, Netcup Support kontaktieren: Schreib ein Ticket an den Support. Erklär ihnen, dass dein Account kompromittiert wurde und du keine Dateien löschen kannst. Die Admins haben Root-Zugriff und können sehen, ob das immutable-Flag gesetzt ist oder welche Prozesse im Hintergrund laufen.

    4. Der "Nuclear Option" (Empfohlen bei schwerem Befall)

    Wenn ein System einmal so tief infiziert ist, dass Dateien blockiert werden, findet man oft nie alle Hintertüren ("Backdoors"). Der sicherste Weg ist:

    1. Daten sichern: Sichere dir nur die absolut notwendigen Daten (z.B. die Datenbank-SQL-Datei und den /uploads-Ordner mit deinen Bildern). Lade auf keinen Fall .php Dateien aus dem Backup wieder hoch!
    2. Komplette Löschung: Lösch alle Dateien auf deinem Webspace (oder lass das vom Support machen/setz den Account komplett zurück).
    3. Neuinstallation: Installiere dein CMS (z.B. WordPress) komplett neu aus einer frischen, offiziellen Quelle.
    4. Updates: Aktualisiere sofort alles (PHP-Version, Plugins, Themes) auf die neueste Version.

    Zusammenfassung: Was machst du jetzt?

    1. Stopp den Versuch mit chmod 777.
    2. Ändere alle Passwörter.
    3. Prüfe, ob ein altes Backup (vor Oktober) existiert → falls ja: Wiederherstellen.
    4. Falls nein: Schreib ein Ticket an den Netcup Support und bitte um Hilfe beim Löschen der blockierten Dateien.
    5. Für die Zukunft: Installiere ein Sicherheits-Plugin (z.B. Wordfence bei WordPress), nutze starke Passwörter und aktiviere 2FA, wo immer es geht.

    Warum ist das passiert? Meistens passiert das durch veraltete Plugins, Themes oder zu schwache Passwörter. Der Virus nutzt eine Sicherheitslücke aus, installiert einen "Bot" und sichert sich so ab, dass du ihn als normaler Nutzer nicht mehr entfernen kannst.

  • Debian 13 - Boot Meldung "RDSEED32 is broken"

    Quote from mango

    Ich habs gerade mal probiert und eingefügt bei GRUB_CMDLINE_LINUX_DEFAULT="quiet rdseed=0"
    Danach habe ich gemacht.

    sudo update-grub
    sudo reboot

    Seltsamerweise wird die Meldung immernoch beim Booten angezeigt.

    Und wie verhält sich deine VM, wenn du den Kernelparameter von der Reihenfolge wie folgt setzt?

    GRUB_CMDLINE_LINUX_DEFAULT="rdseed=0 quiet"

    und dann die VM mit dem Befehl poweroff herunterfährst und danach neu startest?

    Quote from mango

    Ich weiß nicht ob ich das RDSEED überhaupt brauche, bin damit noch nie in Kontakt gekommen.

    In einer VM emuliert der Hypervisor die Hardware. RDSEED ist eine echte CPU-Funktion des physischen Prozessors und VM´s haben keinen direkten Zugriff auf echte CPU-Features wie RDSEED.

    Was ist RDSEED? RDSEED ist eine CPU-Instruction, die vom Prozessor echte Zufallszahlen aus physikalischen Quellen erzeugt, anstatt pseudo-zufällige Zahlen zu berechnen.

    Wenn RDSEED auf dem Hypervisor defekt ist, können folgende Probleme für die VM entstehen:

    • Sicherheitsrisiko: Kryptografische Schlüssel könnten vorhersagbarer sein.
    • Performanceeinbußen: Der Kernel muss auf langsame Software-RNGs ausweichen.
    • Potenzielle Blockaden: Bei hoher Last kann /dev/random blockieren, wenn nicht genug Entropie verfügbar ist.

  • Debian 13 - Boot Meldung "RDSEED32 is broken"

    Quote from mango

    Okay, danke für die Antwort, dann ist das also kein kritisches Problem. Anscheinend kann bei virtualisierten CPUs RDSEED durch den Hypervisor falsch durchgereicht werden, aber da kann ich ja nichts machen. Oder?

    Und den Befehl "apt upgrade linux-firmware" habe ich gerade probiert, aber scheint nicht zu gehen.

    Es gibt noch eine Alternative: Wenn der o.g. Befehl bei einer VM nicht funktioniert, so könnte auch der Kernelparameter rdseed=0 in der Datei grub zur Umgebungsvariable GRUB_CMDLINE_LINUX_DEFAULT hinzugefügt werden. Denn damit wird zwar das ursprüngliche Problem nicht gelöst, welches auf dem Hypervisor zu suchen ist, aber die o.g. Ausgabe wird während des Systemstarts zukünftig unterbunden.

  • Debian 13 - Boot Meldung "RDSEED32 is broken"

    Diese Meldung [0.084436] RDSEED32 is broken. Disabling teh corresponding CPUID bit ist kein kritischer Systemfehler – sie wird lediglich als Warnung ausgegeben.

    Der Linux-Kernel hat erkannt, dass deine CPU bzw. der RDSEED-Befehl fehlerhaft ist und entsprechende Funktionen deaktiviert.

    Abhilfe könnte aufgrund einer fehlerhaften Firmware der Befehl apt upgrade linux-firmware bringen.

  • RS 1000 G12 kein Netzwerk nach Ubuntu Installation

    Quote from TrashGordon

    auch im Rettungssystem "Destination Host Unreachable"

    kein unsichtbares Steuerzeichen

    Für uns Kunden wäre mal interessant zu wissen, ob Netcup noch Support für diese Produkte in ausreichender Qualität anbietet. Von daher könntest du auch für dein Problem über den Notfall-Support über dessen Telefon-Nr. +49 721 754 0 755 5 ein Ticket aufgeben und uns deine Erfahrungen damit mal mitteilen. Denn die Kosten entstehen ja nur, wenn das Problem auf deiner Seite zu suchen ist, aber nicht, wenn es über dem Rettungssystem sich genauso unerwünscht verhält, wie unter dem installiertem OS.

  • RS 1000 G12 kein Netzwerk nach Ubuntu Installation

    Vor längerer Zeit hatte ich auch unter Ubuntu den Fall, dass aufgrund eines unsichtbaren Steuerzeichens im Netplan keine Netzwerkverbindung zustande kam, aber über dem von Netcup gestellten Rettungssystem die Netzverbindung wie gewünscht funktionierte.

    Das Problem war in meinem Fall, dass sich im Netplan ein unsichtbares Steuerzeichen eingeschlichen hatte, welches ich mit Hilfe von vi und dem Befehl : set list zuerst sichtbar gemacht und danach beseitigt hatte, gelöst war.

    Nach dem Neustart des Netzwerkdienstes, lief dann auch die Netzwerkverbindung wie gewünscht wieder.