Bekannte Probleme mit UEK R7

In UEK R7 wird virtio nicht als Modul erstellt, sondern direkt in den Kernel integriert. Daher müssen Sie virtio nicht in der dracut-Konfigurationsdatei angeben, um es zu initramfs hinzuzufügen. Wenn Sie zuvor eine Dracut-Konfiguration mit diesem Modul hatten, zeigt der Versuch, UEK R7 zu installieren, den folgenden Dracut-Fehler an:

dracut-install: ERROR: installing 'virtio'
dracut: FAILED:  /usr/lib/dracut/dracut-install -D
/var/tmp/dracut.FOKWjy/initramfs --kerneldir
/lib/modules/5.15.0-0.21.1.el8uek.x86_64/ -m xen_netfront xen_blkfront
virtio_blk virtio_net virtio virtio_pci virtio_balloon hyperv_keyboard
hv_netvsc hid_hyperv hv_utils hv_storvsc hyperv_fb ahci libahci
dracut-install: ERROR: installing 'virtio'
dracut: FAILED:  /usr/lib/dracut/dracut-install -D
/var/tmp/dracut.G2XSGh/initramfs --kerneldir
/lib/modules/5.15.0-0.21.1.el8uek.x86_64/ -m xen_netfront xen_blkfront
virtio_blk virtio_net virtio virtio_pci virtio_balloon hyperv_keyboard
hv_netvsc hid_hyperv hv_utils hv_storvsc hyperv_fb ahci libahci

Dieser Fehler wird angezeigt, unabhängig davon, ob Sie UEK R7 mit dem Befehl yum oder rpm installieren.

Um das Problem zu umgehen, entfernen Sie vor der Installation von UEK R7 den Text "virtio" aus der dracut-Konfigurationsdatei. Achten Sie darauf, nur den "virtio"-Text zu entfernen, wobei alle anderen "virtio_*"-Einträge intakt bleiben. Beispiel:

cat /etc/dracut.conf.d/01-dracut-vm.conf

add_drivers+=" xen_netfront xen_blkfront "
add_drivers+=" virtio_blk virtio_net virtio virtio_pci virtio_balloon "
add_drivers+=" hyperv_keyboard hv_netvsc hid_hyperv hv_utils hv_storvsc
hyperv_fb "
add_drivers+=" ahci libahci "

Mit dem folgenden Befehl können Sie prüfen, ob virtio in den Kernel integriert ist:

grep CONFIG_VIRTIO= /boot/config-5.15.0-0.30.4.el8uek.x86_64

Wenn virtio in den Kernel integriert ist, muss die Ausgabe wie folgt lauten:

CONFIG_VIRTIO=y

(Bug-ID 33834972)

Ab UEK R7 wurde die Standard-Seitengröße auf der Arm-Plattform von der vorherigen 64-KB-Standardgröße auf 4 KB geändert. Diese Änderung der Seitengröße kann dazu führen, dass ein Upgrade von UEK R6 auf UEK R7 auf Systemen, die für RAID 5 konfiguriert sind, nicht erfolgreich verläuft, wenn die Standardseitengröße von der Standard-Stripe-Größe abweicht.

Aus diesem Grund sichern und formatieren Sie vor dem Upgrade von UEK R6 auf UEK R7 RAID 5-Volumes. In Fällen, in denen die Beibehaltung der gleichen RAID 5-Konfiguration bevorzugt wird, empfehlen wir, UEK R6 weiterhin auszuführen.

Weitere Informationen finden Sie unter Standardseitengröße auf Arm-Plattform in 4 KB geändert.

(Bug-ID 33858264)

Das UEK R7-Release enthält eine wesentliche Änderung für die Arm-Plattform bezüglich der Standardseitengröße, die von der vorherigen 64-KB-Standardeinstellung auf 4 KB geändert wurde. Swap-Partitionen, die auf der Arm-Plattform mit einem früheren UEK-Release erstellt wurden, z.B. UEK R6, funktionieren nach dem Upgrade auf UEK R7 nicht.

Beim ersten Booten in UEK R7 nach einem Upgrade wird der folgende systemd-Servicefehler angegeben:

systemctl list-units --failed
UNIT LOAD ACTIVE SUB DESCRIPTION 

dev-mapper-ol_myhost\x2dswap.swap loaded failed failed
/dev/mapper/ol_myhost-swap

Um dieses Problem zu umgehen, müssen Sie das Swap-Gerät nach dem Upgrade auf UEK R7 mit der neuen Seitengröße neu initialisieren. Verwenden Sie den Befehl swapon wie folgt, und geben Sie die Swap-Position an:

sudo swapon --fixpgsz /dev/mapper/ol_myhost-swap

swapon: /dev/mapper/ol_myhost-swap: swap format pagesize does not match.
swapon: /dev/mapper/ol_myhost-swap: reinitializing the swap.
mkswap: /dev/mapper/ol_myhost-swap: warning: wiping old swap signature.
Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
no label, UUID=d7ef0a33-403f-447b-863f-d52b7f66c803

Im vorherigen Befehl ist /dev/mapper/ol_myhost-swap ein Beispiel für einen typischen Swap-Speicherort, den Sie angeben können.

Weitere Informationen zur wichtigen Änderung der Standardseitengröße für die Arm-Plattform in UEK R7 finden Sie unter Standardseitengröße auf Arm-Plattform in 4 KB geändert.

(Bug-ID 34322552)

Bei einem Upgrade von UEK R6 auf UEK R7 auf einer Oracle Infrastructure-Instanz verwenden cloud-init und systemd-udevd das ältere UEK R6-Gerätebenennungsschema (ifcfg-ens300f0) für die Netzwerkschnittstelle mlx5_core, anstatt das Gerät korrekt mit dem neuen UEK R7-Gerätebenennungsschema (ens300f0np0) umzubenennen.

Um sicherzustellen, dass die mlx5_core-Netzwerkschnittstelle nicht wieder das frühere UEK R6-Gerätebenennungsschema verwendet, gehen Sie nach dem Upgrade auf UEK R7 folgendermaßen vor, bevor Sie das System neu starten:

1. Entfernen Sie die alte Netzwerkkonfigurationsdatei. Beispiel:

   sudo rm /etc/sysconfig/network-scripts/ifcfg-ens300f0

2. Entfernen Sie alle gecachten Daten, die von cloud-init gespeichert wurden:

   sudo cloud-init clean

3. Starten Sie die Instanz neu, damit die Änderungen wirksam werden.

(Bug-ID 34146775)

Bei einem Kernel-Upgrade von UEK R6 auf UEK R7 kann sich der Gerätename mlx5_core von ens2f0 (UEK R6) auf ens2f0np0 (UEK R7) ändern.

Dieses Problem kann unter folgenden Umständen auftreten:

• Beim Upgrade eines Oracle Linux 8-Systems, auf dem UEK R6 ausgeführt wird, auf UEK R7.

• Beim Upgrade eines Oracle Linux 8-Systems, auf dem UEK R6 ausgeführt wird, auf Oracle Linux 9 (das standardmäßig mit UEK R7 geliefert wird).

• Beim Upgrade eines Oracle Linux 8-Systems, auf dem UEK R7 bereits ausgeführt wird, auf Oracle Linux 9.

  Hinweis
  
  

  Wenn auf einem Oracle Linux 8-System UEK R7 bereits ausgeführt wird und Sie das System zuvor für die Verwendung abwärtskompatibler Gerätenamen (ens2f0) konfiguriert haben, müssen Sie möglicherweise die folgende Problemumgehung auf Ihre GRUB-Konfiguration anwenden, nachdem das Upgrade auf Oracle Linux 9 abgeschlossen wurde.

Beachten Sie, dass für Neuinstallationen von UEK R7 auf Oracle Linux 8 und Oracle Linux 9 standardmäßig die Standardbenennungskonvention für UEK R7 (enp2s0f0np0) verwendet wird.

Um abwärtskompatible (UEK R6-)Gerätenamen für die treiberbasierte Netzwerkschnittstellenkarte (NIC) mlx5_core beizubehalten, führen Sie nach dem Upgrade auf UEK R7 vor dem Neustart des Systems den folgenden Workaround aus. Es wird empfohlen, dass Sie die vorhandene Datei grub.cfg sichern, bevor Sie diese Änderung vornehmen.

1. Bearbeiten Sie die Datei /etc/default/grub, und hängen Sie das Zeilenende im Modul GRUB_CMDLINE_LINUX= wie folgt an:

   GRUB_CMDLINE_LINUX="console=xxxx mlx5_core.expose_pf_phys_port_name=0"

2. Nachdem Sie die Datei bearbeitet haben, suchen Sie die Datei grub.cfg auf dem System, und führen Sie dann den Befehl aus, um die GRUB-Konfiguration zu aktualisieren:

   • Auf BIOS-basierten Systemen befindet sich die Ausgabe-/Zieldatei grub.cfg normalerweise unter /boot/grub2/grub.cfg, und Sie führen den folgenden Befehl aus:

     sudo grub2-mkconfig -o /boot/grub2/grub.cfg

   • Auf UEFI-basierten Systemen kann sich die Ausgabe-/Zieldatei grub.cfg unter /etc/grub2-efi.cfg oder /boot/efi/EFI/redhat/grub.cfg befinden. Je nach Speicherort der Datei führen Sie einen der folgenden Befehle aus:

     sudo grub2-mkconfig -o /etc/grub2-efi.cfg

     sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

3. Starten Sie das System neu, damit die Änderungen wirksam werden.

(Bug-IDs 34103369, 34145887)

Bei dem Datenbankbenchmarkprogramm, das auf einer virtuellen Maschine mit 192 CPUs in Azure ausgeführt wird, ist ein Problem mit einer zufälligen hohen CPU-Auslastung aufgetreten. Dieses Problem wurde zunächst in Oracle Linux 8.4 und Ubuntu 20.04 (5.11.0-1022-azure) entdeckt. Eine vollständige Lösung für das Problem ist jedoch in den Upstream-Kernels noch nicht verfügbar.

Dieses Problem manifestiert sich in der Regel mit einer CPU-Auslastungsspitze von >90%, die alle 1 bis 2 Minuten auftritt und etwa 5 bis 20 Sekunden dauert, was die Systemperformance erheblich beeinträchtigt. Wenn die CPU-Auslastungsspitze auftritt, erhöht sich jede der %sys der 192 CPUs um bis zu 60% und die %si um bis zu 30%. In bestimmten Fällen wurde der Anstieg der CPU-Auslastung von >90% in 100% der Fälle beobachtet.

Um dieses Problem zu vermeiden, legen Sie den Kernel-Parameter dm_mod.dm_mq_queue_depth=256 fest.

(Bug-ID 33665982)

Wenn Sie Oracle Linux mit der grafischen Benutzeroberfläche auf einer verschlüsselten Festplatte installieren, z.B. indem Sie während der Installation "Server mit grafischer Benutzeroberfläche" wählen und VGA aktiviert ist, wird die Kennworteingabeaufforderung beim Booten des Systems nicht in der VGA-Ausgabe angezeigt. Folglich kann der Boot-Prozess nicht abgeschlossen werden. Die Eingabeaufforderung wird nur auf einer seriellen Konsole angezeigt. Daher müssen Sie zu einer seriellen Konsole wechseln, um das Kennwort dort anzugeben.

Dieses Problem gilt nur für Systeme auf der Arm-Plattform und tritt unabhängig davon auf, ob Sie Secure Boot verwenden oder nicht. Darüber hinaus gilt das Problem für Oracle Linux 8- oder Oracle Linux 9-Systeme, die UEKR6 oder UEKR7 verwenden.

Damit der GUI-Kennwort-Prompt für die Datenträgerverschlüsselung beim Booten in der VGA-Ausgabe ohne Verwendung einer seriellen Konsole angezeigt wird, fügen Sie in der GRUB-Konfiguration der Kernel-Befehlszeile plymouth.ignore-serial-consoles hinzu. Anweisungen finden Sie unter Verwalten von Kernels und Systemstart unter Oracle Linux.

(Bug-ID 35034465)

Bei Oracle Linux 9 mit UEK R7 ist die DAX-Mountoption des Dateisystems dax=always nicht mit reflinkfähigen XFS-Dateisystemen kompatibel. Beispiel: Wenn Sie den Befehl sudo mount -o dax=always /dev/pmem1 /mnt ausführen, wird der folgende Fehler angezeigt:

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/pmem1, missing codepage 
    or helper program, or other error.
mount: (hint) your fstab has been modified, but systemd still uses the old version; 
    use 'systemctl daemon-reload' to reload.

(Bug-ID 35991195)

Das Oracle Linux 9 xdp-tools-Package, das die Befehle xdp-monitor und xdp-bench enthält, ist mit UEK R7 nicht kompatibel. Die folgenden Fehler werden angezeigt, wenn diese Befehle auf einem Oracle Linux 9-System ausgeführt werden, auf dem UEK R7 ausgeführt wird:

– END PROG LOAD LOG –
libbpf: prog 'tp_xdp_cpumap_kthread': failed to load: -22
libbpf: failed to load object 'xdp_sample'
libbpf: failed to load BPF skeleton 'xdp_sample': -22

Wenn Sie dieses Package benötigen, verwenden Sie Oracle Linux 8 mit xdp-tools v1.2.10-1.el8 oder früher.

(Bug-ID 36014171)