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-managerdebe ser ejecutado con la opción--proxy <hostname>. De lo contrario, la ejecución del comandosubscription-managerfalla. Si utiliza la opción--proxyen lugar del cambio de configuración, el proceso de actualización falla porqueLeappno puede detectar el proxy. Para evitar que ocurra este problema, edite manualmente el archivorhsm.confcomo 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,
Leappinhibe 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),Leappno 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
winbindywinsen el archivo/etc/nsswitch.confen este momento. La transacción de actualización falla con los siguientes mensajes de error yLeappinhibe 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,groupsyhostsdurante la actualización:-
Abra el archivo de configuración del sistema
/etc/nsswitch.confy busque las entradas que contengan las cadenaswinbindowins. -
Si encuentra estas entradas, cree una copia de seguridad de
/etc/nsswitch.conf. -
Edite
/etc/nsswitch.confy eliminewinbindowinsde las entradas que los contienen. - Realiza una actualización in situ.
Después de la actualización, añada las cadenas
winbindywinsa las entradas respectivas en/etc/nsswitch.conf, según los requisitos de configuración de su sistema.(BZ#1410154)
-
Abra el archivo de configuración del sistema
La utilidad
Leappno cambia la configuración de autenticación personalizada durante el proceso de actualización. Si utilizó la utilidad obsoletaauthconfigpara 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 utilidadauthselect.ImportanteDurante la actualización in situ, se eliminan los módulos de autenticación enchufables (PAM) obsoletos
pam_krb5opam_pkcs11. En consecuencia, si la configuración de PAM en su sistema RHEL 7 contiene los módulospam_krb5opam_pkcs11y si estos módulos tienen los valores de controlrequiredorequisite, 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 utilicepam_krb5opam_pkcs11antes de iniciar el proceso de actualización.
-
En los sistemas IBM Z,
Leappsiempre espera que haya un disco DASD conectado. En consecuencia, si el archivo/etc/dasd.confno existe, la actualización in situ falla. Para solucionar este problema, cree un archivodasd.confvacío utilizando el comandotouch > /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:
- Eliminar el paquete de terceros
- Sustituya el paquete de terceros por el paquete proporcionado por Red Hat
-
Durante una actualización in situ, el paquete
dockerse 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 IdM Tipos de encriptación por defecto Otros tipos de cifrado admitidos RHEL 7
aes256-cts
aes128-ctscamellia256-cts
camellia128-cts
des3-hmac
arcfour-hmacRHEL 8
aes256-cts
aes128-ctsaes256-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 enctypeerrores 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.
