23.1. -> 23.7 Update und danach funktioniert nix mehr

[werom-IT]

Hi!
Leider so viel Linux hab ich nicht wirklich drauf, aber zumindest einen Screenshot konnte ich machen.
Update läuft sauber.
Sobald ich das Update von 23.1.1 auf 23.7., also das nächste Update, das mir in der Weboberfläche angezeigt wird, wird das Update brav runtergeladen und installiert und die Neustarts enden dann in einem Endlos-Loop.

Mehr versteh ich nicht, was kann ich dabei tun? Ich hab die Maschine noch im kaputten Zustand und hab mir zwischenzeitlich das Ganze als Backup mit der 23.1.1 wiederhergestellt und die funktioniert. Sobald aber das Update wieder gemacht wird, selbes Verhalten danach.

Was tun? Alles neu aufsetzen und Config von OpnSense einspielen?


search by image on phone

[Patrick M. Hausen]

Linux KnowHow würde dir auch nichts nützen, OPNsense ist kein Linux.

Was für ein Hypervisor ist das? Wie ist die virtuelle Hardware konfiguriert?

[werom-IT]

Hi!

Du siehst windows hyper-v dort, glaub version 2016. der HV tut aber was er soll, es funktioniert ja wie es soll mit 23.1.
Nur das Update danach bringt ihn in die Knie.

mit 23.7. startet alles normal wie immer, ich bekomm auch das Startbild von Opnsense zu sehen mit dem neuen Logo aber danach, ganz zu schluss schreibt er diese ganzen Zeilen an und startet neu, im Loop-Modus.

Was kann ich da tun, wenn sowas passiert mit Opnsense? Irgendwas anderes booten oder 2 oder 3 auswählen beim Bootvorgang? Safemode wenns einen gibt oder irgendwas?

Oder gibts irgendwelche Pre-Steps bevor ich das Update auf 23.7. mache? Vllt Speicher irgendwas löschen oder Protokolle löschen oder irgendwas?

[Patrick M. Hausen]

Das ist eine Kernel Panic. Und FreeBSD in Hyper-V wird m.W. nicht wirklich unterstützt. Daher meine Frage nach HV und virtueller Hardware.

Und "nicht unterstützt" heißt eben "kann funktionieren - so lange bis es das nicht mehr tut". Evtl. lässt sich durch Änderung der VM-Konfiguration aber noch was drehen, daher führ die doch mal bitte auf.

[werom-IT]

Danke dir für die Rückmeldung.
Also ich hab dasselbe bei sehr vielen anderen Kunden, hab dort überall das Update gemacht und überall gehts.

Dass somit der Hypervisor schuld wär oder was damit zu tun hätte, würde ich sehr stark bezweifeln. Dieselbe Konfig ist bei anderen auch. Daher hab ich bei diesem einen Kunden ebenso das Update gemacht nur bei bei diesem einen Kunden happerts und kommt sowas.

Kann man rausfinden, wie ein Kernel-Error oder sowas zustande kommt? Oder hieße das, dass das Update nicht richtig durchläuft? Oder ist das zuviel Aufwand herauszufinden und einfacher, Opnsense neu aufzusetzen und Konfig einspielen?

Ich würde nicht verstehen, was hier anders ist als bei anderen Kunden. Es gibt 1x LAN, 1x WAN und ein paar Nat-Regeln. Aus-Ende, also nix großartiges sondern super simpel.
Mainboard ist ein Supermicro wie bei anderen, Cpu ein Xeon wie bei anderen, Ram ist Ram und Ssd bleibt Ssd. Und die Hardware ist eh nur zweitrangig weil durch Hyper-V bekommt jede Maschine nur eine Hyper-V-Hardware und die ist eigentlich sogut wie auch überall die gleiche.

Mich würde das schon sehr interessieren, was hier los ist. Alle übrigen Hyper-V Maschinen laufen wie immer, alles gut, alles normal.
Sowas wie SFC /SCANNOW gibts in Opnsense vermutlich nicht, aber kann man Integrität oder irgendwie irgendwas prüfen ob mit Opnsense alles OK ist?

[franco]

Vielleicht IPsec am Laufen?


Grüsse
Franco

[Patrick M. Hausen]

Was für ein emuliertes Netzwerk-Interface für LAN? Was für ein emuliertes Netzwerk-Interface für WAN? Was für ein emulierter Controller für die virtuelle Festplatte? Das sind genau die Dinge, die bei einer Panic in einem Hypervisor eine Rolle spielen können und nach denen ich jetzt zum dritten Mal frage.

"Ein LAN" sagt halt ganz genau gar nichts.

[Tuxtom007]

Was tun? Alles neu aufsetzen und Config von OpnSense einspielen?

Wenn du ordentlich Config-Backups hast, geht das meist am schnellsten.

Kontrolliere mal deine VM-Einstellungen: Ist Secure-Boot aktiviert ?
Wenn ja schalte das aus

[werom-IT]

Hi!

Die Fragen hier beziehen sich irgendwie auf die Software von OpnSense und weniger auf den Kernel-Fehler, der mit Opnsense ja nix zu tun hat?
Auch die Frage zur Virtualisierung ist deplatziert kommt mir vor - wenn jetzt alles funktioniert und bisher die Updates funktioniert haben, hats doch damit nix zu tun.

Eine Neuinstallation und Einspielen der Konfig hat das Problem gelöst.
Insofern hats irgendwas mit der bestehenden Maschine zu tun. Entweder Festplatte voll oder irgendeine unix-Einstellung nicht richtig oder sonst etwas.

Es ist Generation1, kein Uefi, sondern MBR. Alles low-level und simple. Alles standard installiert, also mit Option1.

Daher war meine Frage eher, ob ich irgendwas überprüfen kann, wenn so ein Kernel-Fehler ist oder irgendwas an der Maschine checken kann, bevor ich das Update mache.
So ein Kernel-Fehler hat ja nix mit Opnsense zu tun als mit dem dahinterliegenden Betriebssystem und da hätt ich keine Ahnung was da los ist. War bisher auch die einzige Opnsense-Maschine von mittlerweile 10 Updates bei 8 unterschiedlichen Kunden.

Schade, dass ich da hilflos bin und nicht weiter weiß und das nicht nur auf mich zutrifft. Ist kein Vorwurf an die anderen, danke für die Rückmeldungen, aber die einzige passende Rückmeldung war dann eher die Neuaufsetzen und Konfig einspielen auch wenn mich die andere Seite zum Rausfinden des Fehlers mehr interessiert hätte.

Thema damit gelöst, Neu-Installation war nötig.
Vielleicht hat jemand sonst dasselbe Problem und dann kann mans rausfinden, aber für mich war mal die Option die Lösung.

[vpx23]

Ist nur ein Verdacht aber führ auf dem Windows Server 2016 bitte mal "msinfo32" aus und wähle alle Zeilen ab "Virtualisierungsbasierte Sicherheit", dann kopieren mit Strg-C.

Beispiel:

Code Select Expand

Virtualisierungsbasierte Sicherheit Wird ausgeführt...
Virtualisierungsbasierte Sicherheit – erforderliche Sicherheitseigenschaften
Virtualisierungsbasierte Sicherheit – verfügbare Sicherheitseigenschaften Allgemeine Virtualisierungsunterstützung, Sicherer Start, DMA-Schutz, UEFI-Code Readonly, SMM Security Mitigations 1.0, Modusbasierte Ausführungssteuerung, APIC-Virtualisierung
Virtualisierungsbasierte Sicherheit – konfigurierte Dienste Durch Hypervisor erzwungene Codeintegrität
Virtualisierungsbasierte Sicherheit – ausgeführte Dienste Durch Hypervisor erzwungene Codeintegrität, Hardware-erzwungener Stapelschutz (Kernel-Modus)
Windows Defender-Anwendungssteuerungsrichtlinie Erzwungen
Windows Defender-Anwendungssteuerungs-Richtlinie für den Benutzermodus Aus
Unterstützung der Geräteverschlüsselung Erweiterung zum Anzeigen erforderlich
Es wurde ein Hypervisor erkannt. Features, die für Hyper-V erforderlich sind, werden nicht angezeigt.


Unterscheiden sich die Dienste zu den Servern auf denen alles läuft?

[werom-IT]

Hi,
danke für deine Antwort. Habe mich beim OS verschaut, es ist ein Win2012R2 als Hyper-V.
Da gibts das Feature noch nicht. In den Rollen/Features ist auch derartiges nicht verfügbar.
Es scheint beim Arbeitsspeicher jedoch so eine Ram-Funktion aktiviert zu sein:

0x80200000-0x85F7FFFF   Software Guard Extensions Device   OK

Falls es etwas derartiges sein könnte, wüsste ich nicht bescheid. Ins Bios des Servers kommt ich leider nicht, das Management-Interface wurde damals nicht aufgesetzt/initialisiert bzw. das Login-Pwd wurde mir nicht mitgeteilt. Kommt dank deines Posts auf die Todo-Liste, das hatte ich bisher nicht weiter verfolgt.

Ob es eine Ram-Protection sein könnte?

Unterschied zu anderen Servern: Es wird meinerseits immer nur ein nackter Win-Server aufgesetzt und nach ein paar Updates sofort Hyper-V aktiviert, mit dem dann weiter alles gemacht wird. Insofern gäbe es sonst keine Einstellungen. Auf diesem Server speziell ist noch ein Raid-Controller installiert, jedoch die virtuelle Festplatte liegt nicht auf dem Raid-Controller. Die Opnsense-Vhdx liegt auf einer Samsung-SSD-EVO mit SATA-Anschluss ohne Raid-Option.
Unterschiede dürfte es damit auch keine nennenswerten geben.

[vpx23]

Das Intel SGX könnte das Problem sein. OPNsense 23.7 basiert ja auf FreeBSD 13.2 und da wurde laut Release Notes Address Space Layout Randomization (ASLR) aktiviert.

Address Space Layout Randomization (ASLR) is enabled for 64-bit executables by default. It can be disabled as needed if applications fail unexpectedly, for example with segmentation faults.

https://www.freebsd.org/releases/13.2R/relnotes/

Aber bei dem Server 2012 R2 läuft sowieso am 10. Oktober der Support für Sicherheitsupdates aus. Das wäre doch der perfekte Zeitpunkt um auf Proxmox als Hypervisor umzusteigen.  :)

[Emma2]

Das wäre doch der perfekte Zeitpunkt um auf Proxmox als Hypervisor umzusteigen.  :)

... oder gleich ein schlankes Linux aufzusetzen und sich vom Hyper-V als Virtualisierungsplattform zu verabschieden...
Wenn der Server ausschließlich als Virtualisierungshost genutzt wird, spricht aus meiner Sicht nichts für Windows/Hyper-V mit dem ganzen Windows-Overhead und der Sperrigkeit des Hyper-V (und ich spreche da aus eigener leidvoller Erfahrung).

[werom-IT]

als Lösung:
Habe OpnSense neu aufgesetzt und Config eingespielt. Funktioniert wieder tadellos. Somit Update damit übergangen und funktioniert wieder.
Ob das wegen dem SGX war ist eine gute Vermutung, werden wir eher nicht erfahren weils schon gelöst wurde und die Option für mich nicht umgestellt werden konnte weil kein Bios-Zugriff möglich war.