8.3. Problemas conocidos

Los siguientes son problemas conocidos que puede encontrar al actualizar de RHEL 7 a RHEL 8.

  • Actualmente, la agrupación de redes no funciona cuando la actualización in situ se realiza mientras Network Manager está desactivado o no está instalado.
  • Si utiliza un proxy HTTP, Red Hat Subscription Manager debe estar configurado para utilizar dicho proxy, o el comando subscription-manager debe ser ejecutado con la opción --proxy <hostname>. De lo contrario, la ejecución del comando subscription-manager falla. Si utiliza la opción --proxy en lugar del cambio de configuración, el proceso de actualización falla porque Leapp no puede detectar el proxy. Para evitar que ocurra este problema, edite manualmente el archivo rhsm.conf como se describe en Cómo configurar el proxy HTTP para la gestión de suscripciones de Red Hat. (BZ#1689294)
  • Si su sistema RHEL 7 está instalado en un número de unidad lógica (LUN) FCoE y está conectado a una tarjeta de red que utiliza el controlador bnx2fc, el LUN no se detecta en RHEL 8 después de la actualización. En consecuencia, el sistema actualizado no puede arrancar. (BZ#1718147)
  • Si su sistema RHEL 7 utiliza un controlador de dispositivo proporcionado por Red Hat pero que no está disponible en RHEL 8, Leapp inhibe la actualización. Sin embargo, si el sistema RHEL 7 utiliza un controlador de dispositivo de terceros que no está incluido en la lista de controladores eliminados (ubicada en /etc/leapp/repos.d/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt), Leapp no detecta dicho controlador y procede con la actualización. En consecuencia, el sistema podría no arrancar después de la actualización.

  • No se puede realizar una actualización in situ cuando se utilizan los módulos de Samba winbind y wins en el archivo /etc/nsswitch.conf en este momento. La transacción de actualización falla con los siguientes mensajes de error y Leapp inhibe la actualización: 

    upgrade[469]: STDERR:
upgrade[469]: Error in PREIN scriptlet in rpm package unbound-libs
upgrade[469]: Error: Transaction failed
upgrade[469]: Container el8userspace failed with error code 1.
unbound-libs has a PREIN failure

    Para solucionar este problema, configure el sistema para que sólo utilice proveedores locales para las bases de datos user, groups y hosts durante la actualización:

    1. Abra el archivo de configuración del sistema /etc/nsswitch.conf y busque las entradas que contengan las cadenas winbind o wins.
    2. Si encuentra estas entradas, cree una copia de seguridad de /etc/nsswitch.conf.
    3. Edite /etc/nsswitch.conf y elimine winbind o wins de las entradas que los contienen.
    4. Realiza una actualización in situ.

    5. Después de la actualización, añada las cadenas winbind y wins a las entradas respectivas en /etc/nsswitch.conf, según los requisitos de configuración de su sistema.

      (BZ#1410154)

  • La utilidad Leapp no cambia la configuración de autenticación personalizada durante el proceso de actualización. Si utilizó la utilidad obsoleta authconfig para configurar la autenticación en su sistema RHEL 7, es posible que la autenticación en RHEL 8 no funcione correctamente. Para asegurarse de que su configuración personalizada funciona correctamente en el sistema RHEL 8, vuelva a configurar su sistema RHEL 8 con la utilidad authselect.

    Importante

    Durante la actualización in situ, se eliminan los módulos de autenticación enchufables (PAM) obsoletos pam_krb5 o pam_pkcs11. En consecuencia, si la configuración de PAM en su sistema RHEL 7 contiene los módulos pam_krb5 o pam_pkcs11 y si estos módulos tienen los valores de control required o requisite, la realización de la actualización in situ podría provocar el bloqueo del sistema. Para solucionar este problema, reconfigure su sistema RHEL 7 para que no utilice pam_krb5 o pam_pkcs11 antes de iniciar el proceso de actualización.

  • En los sistemas IBM Z, Leapp siempre espera que haya un disco DASD conectado. En consecuencia, si el archivo /etc/dasd.conf no existe, la actualización in situ falla. Para solucionar este problema, cree un archivo dasd.conf vacío utilizando el comando touch > /etc/dasd.conf. (BZ#1783248)

  • Si el nombre de un paquete de terceros (no firmado por Red Hat) instalado en su sistema es el mismo que el de un paquete proporcionado por Red Hat, la actualización in situ falla. Para evitar este problema, elija una de las siguientes opciones antes de actualizar:

    1. Eliminar el paquete de terceros
    2. Sustituya el paquete de terceros por el paquete proporcionado por Red Hat
  • Durante una actualización in situ, el paquete docker se elimina sin previo aviso. Si utiliza contenedores en RHEL, migre a Podman antes de actualizar a RHEL 8. Para obtener instrucciones, consulte ¿Cómo puedo migrar mis contenedores Docker a Podman antes de pasar de Red Hat Enterprise Linux 7 a Red Hat Enterprise Linux 8?(BZ#1858711)

  • Por motivos de seguridad, se ha eliminado la compatibilidad con los tipos de cifrado Single-DES (DES) y Triple-DES (3DES) en RHEL 8.3.0. Sin embargo, RHEL 7 Identity Management (IdM) sigue siendo compatible con el cifrado 3DES.
    La actualización de un entorno IdM de RHEL 7 a RHEL 8 es posible porque ambas versiones de RHEL prefieren tipos de cifrado AES más fuertes por defecto:

    Versión de IdMTipos de encriptación por defectoOtros tipos de cifrado admitidos

    RHEL 7

    aes256-cts
    aes128-cts

    camellia256-cts
    camellia128-cts
    des3-hmac
    arcfour-hmac

    RHEL 8

    aes256-cts
    aes128-cts

    aes256-sha2
    aes128-sha2
    camellia256-cts
    camellia128-cts
    arcfour-hmac [a]

    [a] El cifrado RC4 ha sido obviado y deshabilitado por defecto en RHEL 8, ya que se considera menos seguro que los nuevos tipos de cifrado AES-128 y AES-256. Para obtener más información sobre cómo habilitar el soporte de RC4 para la compatibilidad con los entornos de Active Directory heredados, consulte Garantizar el soporte de los tipos de cifrado comunes en AD y RHEL.

    Si ha configurado manualmente un Centro de Distribución Kerberos (KDC) que no sea IdM, algún servicio o algún usuario para que only utilice el cifrado DES o 3DES, es posible que experimente interrupciones del servicio después de actualizar a los últimos paquetes Kerberos en RHEL 8, como por ejemplo:

    • Errores de autenticación de Kerberos
    • unknown enctype errores de codificación
    • Los KDC con claves maestras de base de datos cifradas con DES (K/M) no se inician

    Red Hat recomienda que no utilice el cifrado DES o 3DES en su entorno. Para obtener más información sobre la recodificación de las entidades de crédito de Kerberos para utilizar tipos de cifrado más potentes, consulte Retirar DES en la documentación de MIT Kerberos.