From Fedora Project Wiki
mNo edit summary
(intel-three-monitors|Inestabilidad y problemas de pantalla al usar tres monitores con GPU Intel|1275770: resuelto)
 
(6 intermediate revisions by the same user not shown)
Line 59: Line 59:
== Problemas de actualización ==
== Problemas de actualización ==


{{Common bugs issue/es|system-upgrade-locale|System-upgrade no funciona en chino, japonés, alemán y probablemente otros idiomas|1278031}}
{{Common bugs issue/es|upgrade-dependency-missing|La actualización desde Fedora 23 falla si no se ha instalado {{package|dnf-plugin-system-upgrade}}|1395686}}


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:
Al actualizar desde Fedora 23 es posible que funcione la preparación de la actualización (el paso {{command|dnf system-upgrade download}}) pero no la actualización (el paso {{command|dnf system-upgrade reboot}}). Esto ocurre si tiene instalado el paquete {{package|python3-dnf-plugin-system-upgrade}} pero no {{package|dnf-plugin-system-upgrade}}.
$ localectl
Entre otras cosas, debería sacar algo como <code>LANG=zh_CN.UTF-8</code> (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 <code>localectl</code>, esta vez verá <code>LANG=en_US.UTF-8</code>. 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.


{{Common bugs issue/es|upgrade-clean-cache|Se borran los paquetes descargados para la actualización si se realiza alguna transacción de paquetes antes de la actualización|1276886}}
El efecto que se observa es que el sistema se inicia pero parece bloquearse. Si pulsa la tecla {{key press|Esc}}, tal vez vea el mensaje {{code|Reached target System Update}}. No habrá información de progreso de la actualización.


Para [[DNF system upgrade/es|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: {{code|Error: el sistema no está listo para la actualización}}. Tendrá que usar <code>dnf system-upgrade download ...</code> para volver a descargar los paquetes.
Para asegurarse completamente de que se encuentra en esta situación, espere una cantidad de tiempo considerable (dos o tres horas), por si el sistema realmente se estuviera actualizando, pues reiniciar en medio de una actualización puede dejarlo sistema en un estado inconsistente.


Si ya ha hecho la descarga y necesita realizar alguna transacción antes de la actualización, use la opción <code>--setopt=keepcache=True</code> con DNF. De esa forma mantendrá la caché de paquetes y no tendrá que volver a descargarlos.
Si tras varias horas no hay ninguna señal de actividad, apague el sistema. Inícielo añadiendo {{code|rd.break}} a los parámetros de arranque, o bien en el modo de rescate, o desde una imagen viva. Después elimine el archivo {{filename|/system-update}} de la raiz de su sistema y vuelva a arrancar normalmente. Instale el paquete {{package|dnf-plugin-system-upgrade}} y ejecute de nuevo el proceso de actualización.


{{Common bugs issue/es|vagrant-upgradepath|No se puede actualizar Vagrant (se ha elimando rubygem-celluloid)|1275030}}
{{Common bugs issue/es|vagrant-upgradepath|No se puede actualizar Vagrant (se ha elimando rubygem-celluloid)|1275030}}
Line 105: Line 97:


== Problemas de hardware ==
== Problemas de hardware ==
{{Common bugs issue/es|intel-three-monitors|Inestabilidad y problemas de pantalla al usar tres monitores con GPU Intel|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 ARM ==
== Problemas con ARM ==
== Problemas con Fedora Server ==
== Problemas con Fedora Server ==


{{Common bugs issue/es|python-requests-httpd|La interfaz web FreeIPA (y tal vez otras aplicaciones web) no funciona: SELinux evita un acceso 'execmem'|1277224}}
{{Common bugs issue/es|freeipa-upgrade-profiles|FreeIPA no arranca si estaba instalado con Fedora 21 o anterior|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.


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 {{package|python-cryptography}} conlleva accesos de ese tipo. En particular, el popular módulo {{package|python-requests}} carga python-cryptography si el paquete {{package|python-ndg_httpsclient}} está instalado. Este paquete era una dependencia de {{package|python-urllib3}} en Fedora 21, por lo que es habitual tenerlo.
Las pruebas indican que esta migración no siempre se lleva a cabo correctamente durante la actualización. Con las versiones de {{package|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.


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 {{package|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).
Hay disponible una [https://bodhi.fedoraproject.org/updates/FEDORA-2016-188c172b10 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.


El código problemático parece estar en realidad en el módulo {{package|python-cffi}} o en la biblioteca {{package|libffi}} que éste usa. Estamos trabajando con los desarrolladores en [https://bitbucket.org/cffi/cffi/issues/231/ este informe de errores].
Si ya actualizó su sistema, no bastará con actualizar el paquete. Puede detectar si está afectado porque el servicio {{code|pki-tomcatd@pki-tomcat.service}} no arranca en la inicialización de FreeIPA. Si ejecuta {{command|ipactl -d}}, verá varios intentos de conexión a {{code|<nowiki>https://(serverhostname):8443/ca/admin/ca/getStatus</nowiki>}}, todos fallidos.


Una forma de evitar el problema es desinstalar el paquete {{package|python-ndg_httpsclient}}. Tenga en cuenta que si lo hace [https://es.wikipedia.org/wiki/Server_Name_Indication 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: {{command|setsebool -P httpd_execmem 1}}.
Si está afectado, primero actualice el paquete: ejecute {{command|sudo dnf install yum}} y {{command|1=sudo yum-deprecated --enablerepo=updates-testing update --advisory=FEDORA-2016-188c172b10}}. Edite el archivo {{filename|/etc/pki/pki-tomcat/ca/CS.cfg}} y cambie {{code|1=subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem}} por {{code|1=subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem}}. Para acabar, ejecute {{command|sudo ipa-server-upgrade}}.


== Problemas con Fedora Cloud ==
== Problemas con Fedora Cloud ==
{{Common bugs issue/es|atomic-bad-tmp-permissions|Las imágenes Atomic tienen permisos incorrectos en el directorio /tmp|1276775}}
Los permisos para el directorio {{filename|/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: {{command|chmod 1777 /sysroot/tmp}}. Las imágenes Atomic se actualizan con regularidad, y este problema debería estar resuelto en las nuevas.


== Otros problemas ==
== Otros problemas ==
Line 176: Line 159:


En algunas placas Intel el sistema se reiniciaba tras unos segundos en vez de apagarse.
En algunas placas Intel el sistema se reiniciaba tras unos segundos en vez de apagarse.
{{Common bugs issue/es|system-upgrade-locale|System-upgrade no funciona en chino, japonés, alemán y probablemente otros idiomas|1278031}}
{{Common bugs update released/es|FEDORA-2015-fe6e8b885b}}
{{Common bugs update released/es|FEDORA-2015-45efbec1fe}}
Antes de que se corrigiera este problema, la actualización del sistema fallaba en algunos idiomas, como mínimo chino y japonés. La solución era cambiar a inglés para realizar la actualización y después volver al idioma deseado. Habiéndose resuelto los errores, ya no debería ser necesario.
{{Common bugs issue/es|python-requests-httpd|La interfaz web FreeIPA (y tal vez otras aplicaciones web) no funciona: SELinux evita un acceso 'execmem'|1277224}}
{{Common bugs update released/es|FEDORA-2016-49b6510089}}
Este es un problema complejo que se daba 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 vio que el uso de la versión que había inicialmente en Fedora 23 del módulo {{package|python-cryptography}} producía muchos accesos de ese tipo. En particular, el popular módulo {{package|python-requests}} carga python-cryptography si el paquete {{package|python-ndg_httpsclient}} está instalado. Este paquete era una dependencia de {{package|python-urllib3}} en Fedora 21, por lo que es habitual tenerlo.
El resultado de todo esto era que era probable que se encontrara con fallos en cualquier aplicación web en Python que usara python-requests si tenía instalado {{package|python-ndg_httpsclient}}. Vería la denegación de acceso 'execmem' de SELinux en los registros del sistema, y probablemente también hubiera mensajes en los registros del servidor web indicando que el proceso había fallado. Afectaba al menos a la interfaz web de FreeIPA (el servidor web intenta continuamente lanzar nuevos procesos, y todos fallan).
Se resolvió con actualizaciones en los paquetes {{package|python-cffi}} y {{package|python-cryptography}}. Si tiene las últimas versiones de estos paquetes no debería estar afectado por este problema.
{{Common bugs issue/es|atomic-bad-tmp-permissions|Las imágenes Atomic tienen permisos incorrectos en el directorio /tmp|1276775}}
{{Common bugs update released/es|FEDORA-2015-dd4760d0fc}}
{{Common bugs update released/es|FEDORA-2015-5f8e9e7d20}}
Los permisos para el directorio {{filename|/tmp}} en las primeras imágenes Atomic de Fedora 23 eran 755, cuando deberían haber sido 777. Esto provocaba problemas a todo lo que quisiera escribir en tmp y no tuviera permisos. Se resolvió con una actualización del paquete {{package|ostree}} con la que además de tener los permisos correctos en las nuevas imágenes, se corrigen los de las instalaciones ya existentes que actualicen el paquete.
{{Common bugs issue/es|upgrade-clean-cache|Se borran los paquetes descargados para la actualización si se realiza alguna transacción de paquetes antes de la actualización|1276886}}
{{Common bugs update released/es|FEDORA-2015-12577}}
Para [[DNF system upgrade/es|actualizar el sistema]] primero es necesario descargar los paquetes y después ejecutar el proceso de actualización. Sin embargo, si realiza con las versiones de DNF anteriores a 1.0.2 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: {{code|Error: el sistema no está listo para la actualización}}. Tendrá que usar <code>dnf system-upgrade download ...</code> para volver a descargar los paquetes.
El problema se resolvió con DNF 1.0.2, que se incluyó en Fedora 23 en el momento del lanzamiento, y se publicó como actualización para Fedora 22. Por tanto, al actualizar de Fedora 22 a Fedora 23 no debería sufrir este problema si tiene Fedora 22 actualizado, y no debería pasarle nunca al actualizar desde Fedora 23 a otra versión.
Si ya ha hecho la descarga con una versión anterior de DNF y necesita realizar alguna transacción antes de la actualización del sistema, use la opción <code>--setopt=keepcache=True</code> con DNF. De esa forma mantendrá la caché de paquetes y no tendrá que volver a descargarlos.
{{Common bugs issue/es|intel-three-monitors|Inestabilidad y problemas de pantalla al usar tres monitores con GPU Intel|1275770}}
{{Common bugs update released/es|FEDORA-2016-f2f8b12e17}}
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.
El usuario que abrió la incidencia indica el 2016-05-09 que "Está corregido al menos desde: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64". No hemos recibido nuevas quejas sobre este asunto desde entonces.


[[Category:Spanish translations]]
[[Category:Spanish translations]]

Latest revision as of 13:19, 4 December 2016

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

La actualización desde Fedora 23 falla si no se ha instalado dnf-plugin-system-upgrade

enlace directo a este elemento - Bugzilla: #1395686

Al actualizar desde Fedora 23 es posible que funcione la preparación de la actualización (el paso dnf system-upgrade download) pero no la actualización (el paso dnf system-upgrade reboot). Esto ocurre si tiene instalado el paquete python3-dnf-plugin-system-upgrade pero no dnf-plugin-system-upgrade.

El efecto que se observa es que el sistema se inicia pero parece bloquearse. Si pulsa la tecla Esc, tal vez vea el mensaje Reached target System Update. No habrá información de progreso de la actualización.

Para asegurarse completamente de que se encuentra en esta situación, espere una cantidad de tiempo considerable (dos o tres horas), por si el sistema realmente se estuviera actualizando, pues reiniciar en medio de una actualización puede dejarlo sistema en un estado inconsistente.

Si tras varias horas no hay ninguna señal de actividad, apague el sistema. Inícielo añadiendo rd.break a los parámetros de arranque, o bien en el modo de rescate, o desde una imagen viva. Después elimine el archivo /system-update de la raiz de su sistema y vuelva a arrancar normalmente. Instale el paquete dnf-plugin-system-upgrade y ejecute de nuevo el proceso de actualización.

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 con Plasma (KDE)

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

Problemas con ARM

Problemas con Fedora Server

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

Otros problemas

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.

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

enlace directo a este elemento - Bugzilla: #1278031

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.

Antes de que se corrigiera este problema, la actualización del sistema fallaba en algunos idiomas, como mínimo chino y japonés. La solución era cambiar a inglés para realizar la actualización y después volver al idioma deseado. Habiéndose resuelto los errores, ya no debería ser necesario.

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

enlace directo a este elemento - Bugzilla: #1277224

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.

Este es un problema complejo que se daba 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 vio que el uso de la versión que había inicialmente en Fedora 23 del módulo python-cryptography producía muchos 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 era que era probable que se encontrara con fallos en cualquier aplicación web en Python que usara python-requests si tenía instalado python-ndg_httpsclient. Vería la denegación de acceso 'execmem' de SELinux en los registros del sistema, y probablemente también hubiera mensajes en los registros del servidor web indicando que el proceso había fallado. Afectaba al menos a la interfaz web de FreeIPA (el servidor web intenta continuamente lanzar nuevos procesos, y todos fallan).

Se resolvió con actualizaciones en los paquetes python-cffi y python-cryptography. Si tiene las últimas versiones de estos paquetes no debería estar afectado por este problema.

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

enlace directo a este elemento - Bugzilla: #1276775

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.

Los permisos para el directorio /tmp en las primeras imágenes Atomic de Fedora 23 eran 755, cuando deberían haber sido 777. Esto provocaba problemas a todo lo que quisiera escribir en tmp y no tuviera permisos. Se resolvió con una actualización del paquete ostree con la que además de tener los permisos correctos en las nuevas imágenes, se corrigen los de las instalaciones ya existentes que actualicen el paquete.

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

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.

Para actualizar el sistema primero es necesario descargar los paquetes y después ejecutar el proceso de actualización. Sin embargo, si realiza con las versiones de DNF anteriores a 1.0.2 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.

El problema se resolvió con DNF 1.0.2, que se incluyó en Fedora 23 en el momento del lanzamiento, y se publicó como actualización para Fedora 22. Por tanto, al actualizar de Fedora 22 a Fedora 23 no debería sufrir este problema si tiene Fedora 22 actualizado, y no debería pasarle nunca al actualizar desde Fedora 23 a otra versión.

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

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

enlace directo a este elemento - Bugzilla: #1275770

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.

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.

El usuario que abrió la incidencia indica el 2016-05-09 que "Está corregido al menos desde: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64". No hemos recibido nuevas quejas sobre este asunto desde entonces.