Bekannte Probleme bei Roving Edge

Derzeit sind öffentliche SDK- und öffentliche Terraform-Versionen nicht für die Datensynchronisierung verfügbar.

Details

Öffentliches SDK und Terraform werden derzeit nicht unterstützt, es sind unterstützte Versionen verfügbar.

Workaround

Verwenden Sie die folgenden unterstützten SDK- und Terraform-Versionen für Datensynchronisierungsvorgänge:

• Oracle Cloud Infrastructure-SDK für Python

• Oracle Terraform

Wenn Sie beim Erstellen einer EdgePeerConnection eine falsche peerSerialNumber eingeben, kann der Erstellungsjob unbegrenzt im Status ACTIVE verbleiben. Für die Wiederherstellung ist eine manuelle Stornierung erforderlich.

Details

Wenn EdgePeerConnection mit falschen Peerverbindungsparametern erstellt wird (meistens ein ungültiges peerSerialNumber), kann der Workflow beim Warten auf das Hochfahren des Tunnels stehen bleiben, sodass das zugehörige Arbeitselement unbegrenzt in den Status "Aktiv" versetzt wird. Beispiel: "Prüfen, ob der Tunnel verbunden ist". Je nachdem, wo die Fehleroberflächen liegen, kann ein Rack später während des Vertrauensaustauschs mit einem expliziten seriennummernbezogenen Fehler ausfallen, während das andere möglicherweise nie ausfällt und beim Erstellen/Aktiv hängen bleibt.

Workaround

Brechen Sie das aktive Arbeitselement manuell ab. Löschen Sie nach dem Abbruch die unvollständige EdgePeerConnection, und erstellen Sie sie mit den richtigen Peerparametern neu.

1. Erfassen Sie die ID des verzögerten Jobs mit dem Befehl getallactiveJobs.

2. Erfassen Sie das aktive Arbeitselement in diesem Job mit dem Befehl show job id=<jobId>.

3. Zeigen Sie die Details des Arbeitselements mit dem Befehl showworkItem id=<workItemId> an.

4. Brechen Sie das aktive Arbeitselement mit dem Befehl cancelworkItem id=<workItemId> ab.

5. Löschen Sie die EdgePeerConnection mit der delete EdgePeerConnection id=<Id>

6. Erstellen Sie die EdgePeerConnection mit dem richtigen peerSerialNumber neu.

Derzeit wird die Sessionpersistenz des Load Balancers für dieses Release nicht unterstützt.

Details

Sessionpersistenzoptionen, wie Cookie-basierte oder IP-basierte Quellpersistenz, sind derzeit im Load Balancer für dieses Release nicht verfügbar.

Workaround

Wir arbeiten an einem Fix für dieses Problem.

VCN-Netzwerkressourcen hängen möglicherweise in den Status PROVISIONING oder FAIL fest, da der OVN-Zugriffsobjektpool erschöpft ist.

Details

Möglicherweise tritt ein Fehler "Northbound database access connection object" auf, wenn der OVN-(Open Virtual Network-)Zugriffsobjektpool erschöpft ist. In diesem Fall können API-Aufrufe wiederholt fehlschlagen, und VCN-Netzwerkressourcen hängen möglicherweise in den Status PROVISIONING oder FAIL fest.

Workaround

Erhöhen Sie die Poolgröße für OVN Northbound-Datenbankzugriffsverbindungen von 32 auf 64.

Derzeit kann die Aktivierung von OKE-Add-ons über mehrere Clusterkonfigurationen hinweg fehlschlagen.

Details

Kunden können sehen, dass Add-on-Aktivierungsvorgänge unabhängig von Clustertyp oder Knotenausprägung nicht erfolgreich sind. Dieses Verhalten wurde bei Flannel-Clustern mit Nicht-GPU-Worker-Knotenausprägungen beobachtet und kann sich auch auf andere Konfigurationen auswirken.

Wenn Sie den POD-Status des Knotens im OKE-Namespace anzeigen, wird der OKE-Add-on-Controller möglicherweise wiederholt neu gestartet. Das ist ein bekanntes Problem.

Workaround

Wir arbeiten an einer Lösung.

Derzeit können yum-Vorgänge in PCA-Umgebungen nicht erfolgreich ausgeführt werden, wenn das uln-pca-Oracle-Linux-7.9-2025.07.21_0.oci-Image verwendet wird, weil Oracle Linux 7 Extended Lifecycle Support-(ELS-)Repositorys standardmäßig aktiviert sind.

Details

Im aktuellen OL7.9-Image sind ELS-Repositorys (z.B. ol7_UEKR6_ELS) standardmäßig aktiviert. Diese Repositorys werden möglicherweise in yum.oracle.com aufgelöst, wenn der ELS-Inhalt nicht veröffentlicht wird. Dies führt zu 404 Not Found-Fehlern für Repository-Metadaten (z.B. repodata/repomd.xml) und führt dazu, dass yum nicht erfolgreich verläuft.

Workaround

Deaktivieren Sie ELS-Repositorys, wenn Sie yum ausführen.

Details

Ab Version 2.18 wird möglicherweise der folgende Fehler angezeigt, wenn Sie ein Gerät neu starten oder ausschalten:

Version          : *** Unknown ***System Time UTC     : 2025-08-28 18:14:31
Boot Time                  : 2025-08-28 17:39:18
Device Serial Id           : Unexpected Error!
Unlock Status              : Unexpected Error!
Auto Unlock Status         : Unexpected Error!
Diag Mode                  : *** Unknown ***
Red API Services Status    : *** Unknown ***
Red HW Services Status     : *** Unknown ***
Press ENTER to return... 

Workaround

Starten Sie das Gerät neu, bis der Fehler nicht mehr angezeigt wird. Siehe Roving Edge Device neu starten.

Das Booten einer Oracle Linux 9-Instanz kann länger als 4 Minuten dauern.

Workaround

1. Führen Sie in der Instanz den folgenden Befehl aus, um zu prüfen, ob der Bootloader-Eintrag eine netroot-Einstellung enthält, die auf ein iscsi-Ziel gesetzt ist:

   grep "netroot=iscsi" /boot/loader/entries/*$(uname -r).conf

2. Wenn der Befehl ein Ergebnis zurückgibt, entfernen Sie mit diesem Befehl die Option netroot aus den Bootloader-Einträgen:

   sed -i 's/netroot=iscsi:[^ ]\+ / /' /boot/loader/entries/*.conf