Common F23 bugs/es

In other languages: English (en) español (es) русский (ru) [edit]

Esta página documenta problemas comunes en Fedora 23 y, si se conocen, correcciones o formas de evitarlos. Dado que los problemas que se listan ya son conocidos, si encuentra el suyo en esta página no lo reporte, a menos que se indique que lo haga. Donde aplica, se incluyen referencias a los informes de Bugzilla.

Notas de lanzamiento

Lea el anuncio de lanzamiento de Fedora 23 y las notas de lanzamiento de Fedora 23 para obtener información específica sobre los cambios en Fedora 23, así como información general.

Mi problema no aparece en la lista

No todos los problemas están en esta página, pero en Bugzilla debería encontrar todos los problemas conocidos. Esta página es una muestra de los problemas que más aparecen en los foros y listas de correo.

Para comprobar si ya se ha informado de su problema, puede buscarlo en Bugzilla. Si nadie lo ha hecho antes, le animamos a que informe de su problema para así mejorar Fedora tanto para usted como para los demás. Se ha preparado una guía sobre informes de errores y peticiones de mejoras para ayudarle.

Si cree que alguno de los errores existentes debe añadirse a esta página por ser bastante común, puede:

• Añadirlo usted mismo, si tiene acceso a edición. Las instrucciones para las páginas de errores comunes le ayudarán a realizar esta adición correctamente, pero lo más importante es asegurarse de que se añade el problema a la lista. No se preocupe si el formato no es exactamente el correcto, eso se puede arreglar después.
• O añadir la palabra clave CommonBugs en el informe de error. Alguien del equipo de aseguramiento de la calidad revisará el informe para ver si debe aparecer como problema común. Para acelerar su solicitud, por favor añada un comentario al informe que incluya:
  1. un resumen del problema
  2. cualquier solución provisional conocida
  3. una evaluación del impacto a los usuarios de Fedora

Como referencia, puede buscar en Bugzilla los informes con la marca CommonBugs:

• CommonBugs? (marcados como CommonBugs pero todavía no tienen un enlace a esta página)
• CommonBugs+ (marcados como CommonBugs y tienen un enlace a esta página)

Problemas de instalación

Los ficheros Kickstart que incluyen repositorios sólo por nombre no se procesan correctamente

enlace directo a este elemento - Bugzilla: #1277638

Se supone que en una instalación kickstart se pueden activar repositorios presentes en /etc/anaconda.repos.d que no están activados por defecto (como updates-testing) incluyendo una línea que simplemente indica el nombre del repositorio:

repo --name=updates-testing

Por desgracia la inclusión de una comprobación excesivamente celosa en Fedora 23 se ha cargado esta característica. Si el instalador se ejecuta en modo gráfico, un fichero que la use provocará una parada en la pantalla del concentrador de elementos, con un error en el de ORIGEN DE LA INSTALACIÓN. Si se ejecuta en modo texto, causará una terminación anormal.

Hay una imagen de actualización del instalador con una corrección. Si necesita una línea de ese tipo, puede usar la actualización añadiendo el parámetro inst.updates=https://fedorapeople.org/groups/qa/updates/1277638.img al núcleo al arrancar el instalador. También puede descargar la actualización y usar cualquier otro de los mecanismos de uso disponibles.

El instalador borra la partición de sistema EFI incluso cuando hay otros sistemas instalados

enlace directo a este elemento - Bugzilla: #1183880

Si tiene varios sistemas operativos instalados que usan UEFI para el arranque (arranque desde ESP - EFI System Partition), entra en la pantalla de particionamiento manual del instalador y selecciona para borrar uno de los sistemas, la partición de sistema EFI se borrará también, aunque la necesite alguno de los otros sistemas operativos instalados.

En una instalación de esas características, no seleccione para borrar todo el árbol de particiones bajo el sistema que quiera eliminar. Borre una a una, por separado, todas las particiones del mismo excepto la ESP (y cualesquiera otras que pueda compartir con otros sistemas).

En ocasiones el instalador no calcula correctamente el tamaño mínimo de partición necesario

enlace directo a este elemento - Bugzilla: #1224048

El instalador usa un conjunto de reglas para calcular el tamaño mínimo que necesitan las particiones para que quepa la instalación. Hay casos en los que, si tiene muy mala suerte o está intentando que las particiones sean lo más pequeñas posible, el instalador puede dar por bueno un tamaño insuficiente, con lo que la instalación falla al poco de comenzar, tras la creación y formateo de las particiones.

Para evitar este problema no intente usar tamaños extremadamente pequeños para la partición raíz (ni ninguna otra de sistema, como /usr, si es que define otras). Deje siempre al menos 500 MB libres en esas particiones. De todas formas, en la mayoría de los casos querrá dejar mucho más para un uso normal.

No se pueden descrifar en el arranque los sistemas de archivos con claves que usan caracteres cirílicos, árabes u otros con cambios en la disposición del teclado

enlace directo a este elemento - Bugzilla: #681250

Si la disposición del teclado de consola en su idioma es 'alternada' (usa una combinación de teclas para alternar entre caracteres latinos y los propios), no podrá realizar el cambio al introducir las claves. Por lo tanto sólo podrá usar claves con la disposición del teclado por defecto, que normalmente es la de caracteres latinos.

El sistema arranca con un núcleo antiguo en lugar del último

enlace directo a este elemento - Bugzilla: #1261569

Este problema sólo afecta a sistemas instalados con una versión previa al lanzamiento de Fedora 23 (anteriores a Fedora 23 RC2). Si ha usado la versión final para la instalación (o para actualizar desde una Fedora anterior), no está afectado por el mismo.

Los sistemas afectados no arrancan con el núcleo actualizado, sino con una versión anterior. Se arregla manualmente cambiando una línea en /etc/sysconfig/kernel de:

 DEFAULTKERNEL=b'kernel-core'

a

 DEFAULTKERNEL=kernel-core

Además, para cambiar la versión utilizada por defecto sin esperar a la siguiente actualización del núcleo, deberá actualizar el menú de GRUB2.

Las instalaciones de Workstation y desde medios vivos no reconocen dispositivos previos de RAID por software (mdraid)

enlace directo a este elemento - Bugzilla: #1225184

La instalación de Fedora Workstation o desde medios vivos no reconoce los dispositivos de RAID por software (mdraid) que haya de instalaciones previas. Aparecen como "Desconocido" (tamaño 0 bytes) y no se pueden usar en la selección de dispositivos, haciendo imposible la instalación de Fedora 23 manteniendo los datos.

Fedora Server, sin embargo, no muestra este problema, y puede usarse para instalar Fedora Workstation por red.

El problema existe desde Fedora 22 y hay varios informes sobre el mismo aún sin cerrar. Tal vez Fedora Workstation ya no sea la distribución adecuada para sistemas con dispositivos RAID por software.

Problemas de actualización

System-upgrade no funciona en chino, japonés, alemán y probablemente otros idiomas

enlace directo a este elemento - Bugzilla: #1278031

No se puede efectuar una actualización de sistema a la nueva versión en algunos idiomas. Por ahora hay informes con chino, japonés y alemán, pero es probable que otros también estén afectados. Hasta que se resuelva, la solución más sencilla es cambiar el sistema temporalmente a inglés, actualizar y volver al idioma anterior. Primero, compruebe el idioma que está usando:

$ localectl

Entre otras cosas, debería sacar algo como LANG=zh_CN.UTF-8 (en este caso, para chino). Anótelo. Luego cambie el sistema a inglés:

$ sudo localectl set-locale LANG=en_US.UTF-8

Reinicie. Si vuelve a ejecutar localectl, esta vez verá LANG=en_US.UTF-8. Compruebe también el idioma de su sesión:

$ locale

Si fuera diferente, deberá cambiarlo también a inglés, usando por ejemplo el centro de control de gnome. Ahora ya puede actualizar siguiendo las instrucciones. Una vez haya acabado y ya esté ejecutando Fedora 23, vuelva a poner el idioma de sistema original:

$ sudo localectl set-locale LANG=EL_QUE_ANOTÓ_ANTES

y reinicie. No olvide cambiar también el idioma de su sesión, si estaba usando uno diferente al de sistema.

Se borran los paquetes descargados para la actualización si se realiza alguna transacción de paquetes antes de la actualización

enlace directo a este elemento - Bugzilla: #1276886

Para actualizar el sistema primero es necesario descargar los paquetes y después ejecutar el proceso de actualización. Si realiza cualquier transacción de paquetes entre esas dos acciones (por ejemplo por un problema de dependencias o porque decide instalar o eliminar algún paquete antes de la actualización) se borrará toda la caché de paquetes, y eso incluye los descargados para la actualización de sistema. Si después inicia la actualización obtendrá un mensaje de error que no es que ayude mucho precisamente: Error: el sistema no está listo para la actualización. Tendrá que usar dnf system-upgrade download ... para volver a descargar los paquetes.

Si ya ha hecho la descarga y necesita realizar alguna transacción antes de la actualización, use la opción --setopt=keepcache=True con DNF. De esa forma mantendrá la caché de paquetes y no tendrá que volver a descargarlos.

No se puede actualizar Vagrant (se ha elimando rubygem-celluloid)

enlace directo a este elemento - Bugzilla: #1275030

Se ha eliminado el paquete rubygem-celluloid en Fedora 23, pero no se ha publicado ninguno para reemplazarlo. Si lo tiene instalado y no usa --allowerasing al actualizar, no se podrán resolver las dependencias. Le recomendamos que use --allowerasing, permitiendo así a DNF eliminar rubygem-celluloid para continuar con la actualización, pero por favor compruebe la lista de paquetes que se eliminarán y asegúrese de que no necesita ninguno.

Problemas de infraestructura

A veces la configuración inicial se ejecuta en modo texto en lugar de en modo gráfico

enlace directo a este elemento - Bugzilla: #1185447

En ocasiones, la herramienta de configuración inicial que se ejecuta en el primer arranque si no se crea ninguna cuenta de usuario durante la instalación, lo hace en modo texto. Aparte de la sorpresa, la herramienta funciona también en modo texto y la pantalla de inicio se mostrará correctamente cuando acabe.

Problemas con GNOME

La creación inicial de usuario lleva a la pantalla de inicio (no al escritorio) y no puede salir a la primera

enlace directo a este elemento - Bugzilla: #1273112 - Bugzilla: #1272706

GNOME incluye su propia herramienta de 'primer arranque', gnome-initial-setup. Si instala Fedora Workstation y no crea una cuenta de usuario en el proceso de instalación, la herramienta de GNOME se ejecutará en el primer arranque para que lo haga entonces. Al terminar debería llevar directamente al escritorio con la cuenta recién creada, pero en ocasiones lo que se muestra es la pantalla de inicio. Cuando esto ocurre e ingresa usted al sistema, al intentar salir la primera vez vuelve de nuevo al escritorio en lugar de a la pantalla de inicio.

Por lo visto hay un problema de sincronización por el que gnome-initial-setup no daría correctamente el control a la sesión de escritorio que genera, quedándoselo la pantalla de inicio. Cuando después usted entra y sale de su sesión, va a la creada por gnome-initial-session.

Este problema ocurre una sola vez y no tiene más consecuencias. Una vez sale de la segunda sesión todo funciona normalmente.

Problemas de red

No hay conexión de red en máquinas virtuales cuando tanto la máquina virtual como el anfitrión se instalan desde una imagen viva

enlace directo a este elemento - Bugzilla: #1146232

Si instala Fedora desde una imagen viva, crea una máquina virtual e instala también en ella Fedora desde una imagen viva, es probable que la red de la máquina virtual no funcione. La razón es que los rangos de direcciones de red virtual de libvirt son los mismos en anfitrión y máquina virtual, y entran en conflicto. Esto no ocurre si instala después los paquetes libvirt en la máquina virtual manualmente (se detecta en la instalación de paquetes), sólo cuando instala desde medio vivo.

Si no necesita libvirt en la máquina virtual, puede eliminar su red en la misma ejecutando sudo virsh net-destroy default && sudo virsh net-undefine default y después renovando la conexión en NetworkManager. En caso de usar libvirt en la máquina virtual tendrá que editar los archivos de configuración y asignarla otro rango de IP.

Problemas de hardware

Inestabilidad y problemas de pantalla al usar tres monitores con GPU Intel

enlace directo a este elemento - Bugzilla: #1275770

Desde la versión 4.2 del núcleo hay varios informes de problemas con unidades gráficas de Intel con tres o más monitores conectados. Pueden ir desde el reinicio del entorno de escritorio a la reconfiguración de la distribución de pantallas, o a que algún monitor no vuelva al estado normal después de entrar en suspensión o bloqueo.

En caso de estar afectado puede instalar un núcleo 4.1 o bien esperar a que se arregle en una futura actualización del núcleo.

Problemas con Fedora Server

La interfaz web FreeIPA (y tal vez otras aplicaciones web) no funciona: SELinux evita un acceso 'execmem'

enlace directo a este elemento - Bugzilla: #1277224

Este es un problema complejo que se da en Fedora 23 con la interfaz web de FreeIPA y puede que otras aplicaciones web escritas en Python. En Fedora SELinux está configurado por defecto para evitar que los procesos de servicios web ejecuten memoria sin protección de escritura (el acceso 'execmem'). Se ha visto que el uso de la versión que hay en Fedora 23 del módulo python-cryptography conlleva accesos de ese tipo. En particular, el popular módulo python-requests carga python-cryptography si el paquete python-ndg_httpsclient está instalado. Este paquete era una dependencia de python-urllib3 en Fedora 21, por lo que es habitual tenerlo.

El resultado de todo esto es que es probable que se encuentre con fallos en cualquier aplicación web en Python que use python-requests si tiene instalado python-ndg_httpsclient. Verá la denegación de acceso 'execmem' de SELinux en los registros del sistema, y probablemente también haya mensajes en los registros del servidor web indicando que el proceso ha fallado. Es seguro que afecta al menos a la interfaz web de FreeIPA (el servidor web intentará continuamente lanzar nuevos procesos, y todos fallarán).

El código problemático parece estar en realidad en el módulo python-cffi o en la biblioteca libffi que éste usa. Estamos trabajando con los desarrolladores en este informe de errores.

Una forma de evitar el problema es desinstalar el paquete python-ndg_httpsclient. Tenga en cuenta que si lo hace SNI dejará de funcionar en las aplicaciones basadas en python-requests. Otra posibilidad es permitir el uso de 'execmem' a los procesos de los servicios web, pero hay muy buenas razones para esa restricción, y saltársela reduce la protección frente a ciertos ataques; de hacerlo, asegúrese de que entiende perfectamente las consecuencias del cambio. Para conseguirlo debe ejecutar el siguiente comando con privilegios de administrador: setsebool -P httpd_execmem 1.

FreeIPA no arranca si estaba instalado con Fedora 21 o anterior

enlace directo a este elemento - Bugzilla: #1323400

Entre Fedora 21 y Fedora 22, FreeIPA pasó de guardar los perfiles de certificados en fichero a una base de datos. Los servidores FreeIPA anteriores a Fedora 22 deben migrar el almacenamiento de fichero a base de datos cuando se actualizan a Fedora 22 o posterior.

Las pruebas indican que esta migración no siempre se lleva a cabo correctamente durante la actualización. Con las versiones de pki-core tras 10.2.6-12.fc22 (Fedora 22), 10.2.6-16.fc23 (Fedora 23), o 10.3.0.a1-2 (Fedora 24+), este error hace que FreeIPA no arranque correctamente. Con versiones anteriores FreeIPA arrancará, pero algunas operaciones con certificados pueden fallar.

Hay disponible una actualización que corrige el proceso de migración. Si tiene un servidor y todavía no lo ha actualizado a Fedora 22 ni posterior, espere a que se publique el arreglo o bien asegúrese de obtenerlo activando el repositorio updates-testing, para que la migración se realice correctamente.

Si ya actualizó su sistema, no bastará con actualizar el paquete. Puede detectar si está afectado porque el servicio pki-tomcatd@pki-tomcat.service no arranca en la inicialización de FreeIPA. Si ejecuta ipactl -d, verá varios intentos de conexión a https://(serverhostname):8443/ca/admin/ca/getStatus, todos fallidos.

Si está afectado, primero actualice el paquete: ejecute sudo dnf install yum y sudo yum-deprecated --enablerepo=updates-testing update --advisory=FEDORA-2016-188c172b10. Edite el archivo /etc/pki/pki-tomcat/ca/CS.cfg y cambie subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem por subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem. Para acabar, ejecute sudo ipa-server-upgrade.

Problemas con Fedora Cloud

Las imágenes Atomic tienen permisos incorrectos en el directorio /tmp

enlace directo a este elemento - Bugzilla: #1276775

Los permisos para el directorio /tmp en las imágenes Atomic de Fedora 23 son 755, cuando deberían ser 777. Esto provoca problemas a todo lo que quiera escribir en tmp y no tenga permisos. Para arreglarlo ejecute: chmod 1777 /sysroot/tmp. Las imágenes Atomic se actualizan con regularidad, y este problema debería estar resuelto en las nuevas.

Problemas resueltos

FreeIPA no se actualiza correctamente

enlace directo a este elemento - Bugzilla: #1274905

Corrección publicada
Se ha publicado una actualización que resuelve el problema. Tras actualizar su sistema del modo habitual y tal vez reiniciar, ya no debería estar afectado por el mismo.

Corrección publicada
Se ha publicado una actualización que resuelve el problema. Tras actualizar su sistema del modo habitual y tal vez reiniciar, ya no debería estar afectado por el mismo.

Si actualiza un sistema con FreeIPA a Fedora 23, FreeIPA no se ejecutará en el sistema actualizado. Los registros indicarán que hay que ejecutar el procedimiento de actualización: Upgrade required: please run ipa-server-upgrade command. Sin embargo, si se ejecuta el comando que se distribuyó con los paquetes originales de Fedora 23, no funcionará y FreeIPA seguirá sin arrancar.

Le recomendamos que active el repositorio updates cuando actualice servidores FreeIPA a Fedora 23, y que se asegure de que las actualizaciones indicadas anteriormente están incluidas.

Si ejecutó el guion de actualización antes de que las correcciones estuvieran disponibles y se topó con los errores, tal vez pueda conseguir que FreeIPA funcione de la siguiente forma (no todo el que lo ha probado lo ha conseguido):

• Edite /etc/dirsrv/slapd-(DOMAIN)/schema/99user.ldif
• Busque la entrada que comienza por: attributeTypes: ( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey' (está distribuida en tres líneas)
• Cámbiela por:

attributeTypes: ( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey' DESC '
 IPA vault public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.1
 21.1.40 X-ORIGIN ( 'IPA v4.2' 'user defined' ) )

• Ejecute pki-server migrate --tomcat 8
• Ejecute systemctl start pki-tomcatd@pki-tomcat.service
• Vuelva a ejecutar el guion de actualización: ipa-server-upgrade

Algunos temas de plymouth dan problemas durante la actualización

enlace directo a este elemento - Bugzilla: #1267949

Corrección publicada
Se ha publicado una actualización que resuelve el problema. Tras actualizar su sistema del modo habitual y tal vez reiniciar, ya no debería estar afectado por el mismo.

Algunos temas de plymouth (la pantalla de arranque) tenían un comportamiento erróneo en el entorno de actualización del sistema. Los problemas conocidos se daban en los temas script y spinner. Para el primero, la información de progreso se salía de la pantalla y no se desplazaba para hacerse visible. Con el segundo la pantalla se quedaba completamente en negro durante la actualización. En ambos casos no había información de progreso y parecía que se había producido un cuelgue, pero no era así y en realidad, si se dejaba, la actualización se ejecutaba correctamente. Si actualiza sin haber aplicado las correcciones y usa esos temas, no fuerce un reinicio ni apague el dispositivo; tenga paciencia y espere a que la actualización termine y se reinicie automáticamente.

Tras instalar la corrección puede ejecutar sudo dracut -f para regenerar el disco de arranque. Si no lo hace, el arreglo sólo empezará a tener efecto a partir de la siguiente actualización del núcleo.

También puede cambiar al tema por defecto antes de empezar la actualización:

sudo dnf install plymouth-theme-charge
sudo plymouth-set-default-theme charge
sudo dracut -f

Denegación de acceso de SELinux al fallar una aplicación

enlace directo a este elemento - Bugzilla: #1276305

Corrección publicada
Se ha publicado una actualización que resuelve el problema. Tras actualizar su sistema del modo habitual y tal vez reiniciar, ya no debería estar afectado por el mismo.

Había un problema en las políticas de SELinux en Fedora 23 que provocaba una denegación de acceso cuando fallaba una aplicación. SELinux estaba impidiendo que la herramienta de informes ABRT hiciera algo que necesitaba hacer para analizar el fallo. El mensaje era del estilo de SELinux está evitando que abrt-hook-ccpp use accesos 'sigchld' sobre un proceso.

El sistema reinicia en lugar de apagarse

enlace directo a este elemento - Bugzilla: #1257131

Corrección publicada
Se ha publicado una actualización que resuelve el problema. Tras actualizar su sistema del modo habitual y tal vez reiniciar, ya no debería estar afectado por el mismo.

En algunas placas Intel el sistema se reiniciaba tras unos segundos en vez de apagarse.