Problèmes connus pour UEK R7
dracut-install : ERROR : l'installation de 'virtio' peut être affichée lors de l'installation UEK R7
Dans UEK R7, virtio n'est pas construit en tant que module, mais est directement intégré au noyau. Par conséquent, vous n'avez pas besoin de spécifier virtio dans le fichier de configuration dracut pour l'ajouter à initramfs. Si vous aviez précédemment une configuration dracut qui incluait ce module, tenter d'installer UEK R7 affiche l'erreur dracut suivante :
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
Cette erreur est affichée, que vous utilisiez la commande yum ou rpm pour installer UEK R7.
Pour contourner le problème, avant d'installer UEK R7, supprimez le texte "virtio" du fichier de configuration dracut. Veillez à supprimer uniquement le texte "virtio", en laissant intactes toutes les autres entrées "virtio_*", par exemple :
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 "
Utilisez la commande suivante pour vérifier que virtio est intégré au noyau :
grep CONFIG_VIRTIO= /boot/config-5.15.0-0.30.4.el8uek.x86_64
Si virtio est intégré au noyau, la sortie doit être la suivante :
CONFIG_VIRTIO=y
(ID bogue 33834972)
La mise à niveau de UEK R6 vers UEK R7 sur la plate-forme ARM peut échouer si la taille de page par défaut RAID 5 diffère de la taille de bande par défaut
Depuis UEK R7, la taille de page par défaut sur la plate-forme Arm est passée à 4 Ko, par rapport à la précédente valeur par défaut de 64 Ko. Cette modification de la taille de page peut entraîner l'échec d'une mise à niveau de UEK R6 vers UEK R7 sur des systèmes configurés pour RAID 5 lorsque la taille de page par défaut diffère de la taille de segment par défaut.
Pour cette raison, avant de passer de UEK R6 à UEK R7, sauvegardez et reformatez les volumes RAID 5. Dans les cas où il est préférable de conserver la même configuration RAID 5, nous vous recommandons de continuer à exécuter UEK R6.
Voir Taille de page par défaut sur la plate-forme ARM modifiée à 4 Ko pour plus d'informations.
(ID bogue 33858264)
Les partitions de permutation créées sur la plate-forme Arm à l'aide d'une version UEK antérieure ne fonctionnent pas après la mise à niveau vers UEK R7
La version UEK R7 comprend une modification importante pour la plate-forme Arm en ce qui concerne la taille de page par défaut, qui est passée à 4 Ko, par rapport à la précédente valeur par défaut de 64 Ko. Toutes les partitions de swap créées sur la plate-forme Arm à l'aide d'une version UEK antérieure, par exemple UEK R6, ne fonctionnent pas après la mise à niveau vers UEK R7.
Ce problème s'applique à la plate-forme Arm, quel que soit le type de système de fichiers.
Lors du premier démarrage dans UEK R7 après une mise à niveau, la défaillance de service systemd suivante est indiquée :
systemctl list-units --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
dev-mapper-ol_myhost\x2dswap.swap loaded failed failed
/dev/mapper/ol_myhost-swap
Pour contourner ce problème, vous devez réinitialiser le périphérique de swap avec la nouvelle taille de page après la mise à niveau vers UEK R7. Utilisez la commande swapon comme suit et spécifiez l'emplacement du swap :
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
Dans la commande précédente, /dev/mapper/ol_myhost-swap est un exemple d'emplacement de swap standard que vous pouvez spécifier.
Pour plus d'informations sur la modification importante de la taille de page par défaut pour la plate-forme ARM dans UEK R7, voir Taille de page par défaut pour la plate-forme ARM modifiée à 4 Ko.
(ID bogue 34322552)
Cloud-init et systemd-udevd ne parviennent pas à renommer les interfaces réseau mlx5_core lors de la mise à niveau de UEK R6 vers UEK R7
Lors d'une mise à niveau d'UEK R6 vers UEK R7 sur une instance d'infrastructure Oracle, cloud-init et systemd-udevd utilisent de nouveau l'ancien schéma d'attribution de nom de périphérique UEK R6 (ifcfg-ens300f0) pour l'interface réseau mlx5_core, plutôt que de renommer correctement le périphérique avec le nouveau schéma d'attribution de nom de périphérique UEK R7 (ens300f0np0).
Pour vous assurer que l'interface réseau mlx5_core n'utilise pas de nouveau l'ancien schéma d'attribution de nom de périphérique UEK R6, effectuez les opérations suivantes une fois la mise à niveau vers UEK R7 terminée, avant de redémarrer le système :
-
Supprimez l'ancien fichier de configuration réseau, par exemple :
sudo rm /etc/sysconfig/network-scripts/ifcfg-ens300f0 -
Supprimez toutes les données mises en cache enregistrées par cloud-init :
sudo cloud-init clean -
Redémarrez l'instance pour que les modifications prennent effet.
(ID bogue 34146775)
Nom de l'interface NIC Mellanox sujet à changement après la mise à niveau de UEK R6 vers UEK R7
Lors d'une mise à niveau du noyau de UEK R6 vers UEK R7, le nom du périphérique mlx5_core peut être modifié, de ens2f0 (UEK R6) à ens2f0np0 (UEK R7).
Vous pourriez rencontrer ce problème dans les circonstances suivantes :
-
Lors de la mise à niveau d'un système Oracle Linux 8 qui exécute UEK R6 vers UEK R7.
-
Lors de la mise à niveau d'un système Oracle Linux 8 qui exécute UEK R6 vers Oracle Linux 9 (qui est livré avec UEK R7 par défaut).
-
Lors de la mise à niveau d'un système Oracle Linux 8 qui exécute déjà UEK R7 vers Oracle Linux 9.
Note
Dans le cas où un système Oracle Linux 8 exécute déjà UEK R7, si vous avez précédemment configuré le système pour utiliser des noms de périphérique rétrocompatibles (
ens2f0), vous devrez peut-être appliquer la solution de rechange qui suit à votre configuration GRUB une fois la mise à niveau vers Oracle Linux 9 terminée.
Notez que les nouvelles installations d'UEK R7 sur Oracle Linux 8 et Oracle Linux 9 utilisent la convention d'attribution de nom par défaut pour UEK R7 (enp2s0f0np0).
Pour conserver les noms de périphérique rétrocompatibles (UEK R6) pour la carte d'interface réseau (NIC) basée sur un pilote mlx5_core, effectuez la solution de rechange suivante après la mise à niveau vers UEK R7, avant de redémarrer votre système. Il est recommandé de sauvegarder votre fichier grub.cfg existant avant d'effectuer cette modification.
-
Modifiez le fichier
/etc/default/grubet ajoutez la fin de la ligne dans le moduleGRUB_CMDLINE_LINUX=comme suit :GRUB_CMDLINE_LINUX="console=xxxx mlx5_core.expose_pf_phys_port_name=0" -
Après avoir modifié le fichier, localisez le fichier
grub.cfgsur votre système, puis exécutez la commande pour mettre à jour la configuration GRUB, selon le cas :-
Sur les systèmes basés sur le BIOS, le fichier de sortie/cible
grub.cfgse trouve généralement sous/boot/grub2/grub.cfget vous exécutez la commande suivante :sudo grub2-mkconfig -o /boot/grub2/grub.cfg -
Sur les systèmes basés sur l'UEFI, le fichier de sortie/cible
grub.cfgpeut être situé à l'adresse/etc/grub2-efi.cfgou/boot/efi/EFI/redhat/grub.cfg. Selon l'emplacement du fichier, vous exécutez l'une des commandes suivantes :sudo grub2-mkconfig -o /etc/grub2-efi.cfgsudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
-
-
Redémarrez le système pour que les modifications prennent effet.
(Bug IDs 34103369, 34145887)
Problème aléatoire d'utilisation élevée d'UC rencontré avec le programme de référence de base de données
Un problème aléatoire d'utilisation élevée d'UC a été rencontré avec le programme de référence de base de données exécuté sur une machine virtuelle de 192 unités centrales dans Azure. Ce problème a été initialement découvert dans Oracle Linux 8.4 et Ubuntu 20.04 (azure 5.11.0-1022); toutefois, un correctif complet pour le problème n'est pas encore disponible dans les noyaux en amont.
Ce problème se manifeste généralement par un pic d'utilisation de la CPU > 90% toutes les 1 à 2 minutes et d'une durée d'environ 5 à 20 secondes, ce qui dégrade considérablement les performances du système. Lorsque le pic d'utilisation de l'UC se produit, chacune des 192 UC %sys augmente jusqu'à 60 % et le %si augmente jusqu'à 30 %. Dans certains cas, le pic d'utilisation de l'UC >90 % a été observé 100 % du temps.
Pour éviter de rencontrer ce problème, définissez le paramètre de noyau dm_mod.dm_mq_queue_depth=256.
(ID bogue 33665982)
(aarch64) Invite de mot de passe de chiffrement de disque non affichée au démarrage du système
Si vous installez Oracle Linux avec interface graphique sur un disque chiffré, par exemple, en choisissant Serveur avec interface graphique lors de l'étape d'installation et que VGA est activé, l'invite de mot de passe n'apparaît pas sur la sortie VGA au démarrage du système. Par conséquent, le processus de démarrage ne peut pas être terminé. L'invite n'apparaît que sur une console série. Par conséquent, vous devez passer à une console série pour y fournir le mot de passe.
Ce problème est spécifique aux systèmes de la plate-forme Arm uniquement et se produit que vous utilisiez un démarrage sécurisé ou non. En outre, le problème s'applique aux systèmes Oracle Linux 8 ou Oracle Linux 9 qui utilisent UEKR6 ou UEKR7.
Pour que l'invite de mot de passe de l'interface graphique pour le chiffrement du disque apparaisse au démarrage sur la sortie VGA sans utiliser de console série, ajoutez plymouth.ignore-serial-consoles à la ligne de commande du noyau dans la configuration GRUB. Pour obtenir des instructions, voir Gestion des noyaux et démarrage du système sur Oracle Linux.
(ID bogue 35034465)
L'option de montage XFS DAX n'est pas compatible avec Oracle Linux 9 avec Reflink activé
Sur Oracle Linux 9 avec UEK R7, l'option de montage DAX du système de fichiers dax=always est incompatible avec les systèmes de fichiers XFS activés pour reflink. Par exemple, l'exécution de la commande sudo mount -o dax=always /dev/pmem1 /mnt affiche l'erreur suivante :
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.
(ID bogue 35991195)
xdp-tools sur Oracle Linux 9 est incompatible avec UEK R7
L'ensemble Oracle Linux 9 xdp-tools qui contient les commandes xdp-monitor et xdp-bench est incompatible avec UEK R7. Les erreurs suivantes s'affichent lorsque ces commandes sont exécutées sur un système Oracle Linux 9 exécutant UEK R7 :
– 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
Si vous avez besoin de cet ensemble, utilisez Oracle Linux 8 avec xdp-tools v1.2.10-1.el8 ou une version antérieure.
(ID bogue 36014171)