Oracle AI Database 26ai-FREE con APEX 26.1 ejecutándose en DOCKER sobre Oracle Linux UEK10: Porqué el kernel UEK?

Productiva tarde del sábado, invirtiéndo 3 horas y media, en crear un ambiente de Oracle AI Database 26ai Free, APEX 26.1 y ORDS ejecutándose en un docker en un servicio desplegado en la nube de Oracle -OCI- con 1 OCPU, 12 GB RAM y 200GB de bootdisk.

Eso si para hacerlo más interesante, mi servicio estaba en Oracle Linux V9.7 ya que lo había creado hace unos días atrás, entonces antes procedí a migrar a Oracle Linux 10 utilizando LEAPP - "Legacy Application".

Un detalle interesante, es que la herramienta no soporta una migración hacia Oracle Linux 10, desde Oracle Linux 9, si el kernel que se utiliza de facto, no es UEK.

Cuando ejecutas el comando: uname -a, puedes validar si utilizas:

• -UEK (Unbreakable Enterprise Kernel)
• -RHCK (Red Hat Compatible Kernel)

Si el kernel de facto es compatible con el sombrero rojo y ejecutas la prevalidación de la migración con la herramienta LEAPP, te aparece dentro de los inhibidores el siguiente:

Risk Factor: high (inhibitor)

Title: BTRFS used, confirm UEK as default boot kernel in OL9

Summary: Upgrade process was interrupted because btrfs is enabled and need to confirm UEK as default boot kernel in OL9

Remediation: [hint] Confirm UEK kernel install and default boot

Key: ba493fb6524e939f518a2448dc93aa10817ddb44

Para estar completamente seguro del kernel de facto, puedes hacer lo siguiente:

[root@serverprod01 opc]# awk -F\' '$1=="menuentry " {print $2}' /etc/grub2.cfg

[root@serverprod01 opc]# awk -F\' '$1=="menuentry " {print $2}' /boot/efi/EFI/redhat/grub.cfg

Luego con el comando "GRUBBY" puedes desplegar todos los kernel disponibles que puedes utilizar.

[root@serverprod01 opc]# grubby --info=ALL | grep ^kernel

kernel="/boot/vmlinuz-6.12.0-108.64.6.3.el9uek.x86_64"

kernel="/boot/vmlinuz-5.14.0-611.34.1.el9_7.x86_64"

kernel="/boot/vmlinuz-0-rescue-5317e565ff83fadfe174b7ef8815fd20"

kernel="/boot/vmlinuz-6.12.0-202.76.4.2.el9uek.x86_64"

kernel="/boot/vmlinuz-5.14.0-611.55.1.el9_7.x86_64"

kernel="/boot/vmlinuz-0-rescue-e3bea40a02e64e458672cddd21ddbb2e"

Procede a configurar el kernel UEK más moderno.

[root@serverprod01 opc]# grubby --set-default /boot/vmlinuz-6.12.0-202.76.4.2.el9uek.x86_64

The default is /boot/loader/entries/e3bea40a02e64e458672cddd21ddbb2e-6.12.0-202.76.4.2.el9uek.x86_64.conf with index 3 and kernel /boot/vmlinuz-6.12.0-202.76.4.2.el9uek.x86_64

[root@serverprod01 opc]# grubby --default-kernel

/boot/vmlinuz-6.12.0-202.76.4.2.el9uek.x86_64

[root@serverprod01 opc]#

Después de esto, ya no existe el problema con la validación del kernel.

Lo más interesante como dice un compañero de trabajo: "Hasta sirve".