Common F25 bugs/es

In other languages: English (en) español (es) [edit]

Esta página documenta problemas comunes en Fedora 25 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 25 y las notas de lanzamiento de Fedora 25 para obtener información específica sobre los cambios en Fedora 25, 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

No se puede cambiar la disposición del teclado mediante combinación de teclas en Wayland

enlace directo a este elemento - Bugzilla: #1389959

Si usa el medio vivo de Fedora Workstation y configura varios idiomas en el instalador, no podrá cambiar entre ellos mediante la combinación de teclas de sistema (normalmente ⊞ Win+Espacio o Alt+⇧ Shift). Sí podrá seguir usando el ratón con el indicador de idioma del instalador.

No afecta a otros medios de instalación (imagen viva de KDE, DVD ni netinst).

La inicialización de discos en el instalador puede llevar mucho tiempo si hay sistemas ext muy grandes

enlace directo a este elemento - Bugzilla: #1170803

Al comprobar los discos antes de la instalación, se ejecuta e2fsck (comprobación de la consistencia del sistema de archivos) sobre los sistemas de archivos ext2/3/4. Para discos muy grandes (varios TBs) con gran cantidad de ficheros, esta comprobación puede llevar horas. No hay nada que indique que se está llevando a cabo esta tarea, pero si en su equipo hay sistemas de archivos de este tipo y el instalador aparenta estar parado al inicio, esta puede ser la causa.

Normalmente esa comprobación no es necesaria. Si no va a hacer cambios sobre los sistemas de archivos existentes, o si sabe que están consistentes, puede usar una imagen de actualización que elimina la comprobación. Para ello edite los parámetros de arranque desde la pantalla del gestor de arranque y añada inst.updates=https://www.happyassassin.net/updates/1170803.0.img.

El arranque dual con Windows falla con error 'relocation failed' en algunos sistemas UEFI

enlace directo a este elemento - Bugzilla: #1347291

En algunos sistemas no se puede iniciar Windows (tal vez tampoco otros sistemas operativos) desde el menú de GRUB cuando se arranca sobre UEFI (no ocurre en el modo BIOS). El mensaje que aparece es error: relocation failed. Aún se está investigando la causa.

Como apaño puede usar su menú de arranque UEFI, al que se suele acceder con alguna tecla especial (Esc, F8, F11, F12, etc).

Los usuarios avanzados pueden instalar grub2-2.02-0.25.fc23 (grub2 de Fedora 23), que debería corregir el problema. Sin embargo, si lo hacen, la versión de grub2 de Fedora 25 se ofrecerá en cada actualización del sistema, y tendrá que excluirla manualmente cada vez. También hay una versión de prueba para Fedora 25 con un parche que debería solucionar el problema, pero no está firmada para su uso en entorno de arranque seguro, por lo que no podrá usarla si lo tiene activado.

No aparece la opción de Windows en grub cuando se instala en RAID por firmware en sistema UEFI

enlace directo a este elemento - Bugzilla: #1347273

Cuando se instala Fedora junto a Windows en RAID por firmware en un sistema UEFI puede que no aparezca la opción para arrancar Windows en el menú de grub.

Como apaño puede usar su menú de arranque UEFI, al que se suele acceder con alguna tecla especial (Esc, F8, F11, F12, etc).

Sólo ocurre cuando se usa UEFI y RAID por firmware. Por lo tanto los sistemas BIOS y los discos normales (o con RAID por firmware desactivado) no deberían estar afectados.

Fedora no se instala en algunas configuraciones RAID

enlace directo a este elemento - Bugzilla: #1333131 - Bugzilla: #1259953 - Bugzilla: #1382274

Hay casos en los que anaconda falla al intentar instalar Fedora sobre RAID.

• Si en la instalación intenta crear un conjunto RAID en un equipo que ya tuviera otro usando las unidades del conjunto existente, el nuevo no se genera correctamente y no se puede usar (y el que había y ha borrado ya no está ahí, claro). Tendrá que reiniciar y volver a crear el conjunto RAID, esta vez usando espacio libre.
• El instalador puede fallar al inicio con ciertos sistemas RAID que no son de intel. Por el momento no hay más detalles.

El instalador no reconoce las particiones cifradas de OS X ni Windows, y al reducirlos se pierden sus datos

enlace directo a este elemento - Bugzilla: #1033778

Parece que el instalador permite reducir el espacio de volúmenes cifrados de OS X (con Apple Core Storage) y de Windows (con Bitlocker), pues muestra el correspondiente botón y otros elementos para indicar tamaño tanto en la pantalla de particionamiento automático como en la manual. Sin embargo, si se pide al instalador que cambie el tamaño y se continúa con la instalación se perderán todos los datos del volumen. Si necesita cambiar el tamaño del volumen para instalar Fedora, hágalo con la utilidad de discos del sistema operativo propietario del mismo.

El instalador de la versión viva falla si se intenta añadir un destino iSCSI

enlace directo a este elemento - Bugzilla: #1395620

Si intenta añadir un destino iSCSI como dispositivo de almacenamiento en una instalación desde la imagen viva de Fedora Workstation 25 (probablemente también con otras imágenes vivas), es fácil que falle con el error TypeError: Argument 1 does not allow None as a value. El error se debe a una dependencia no instalada. Puede evitarlo ejecutando sudo dnf install storaged-iscsi desde la consola antes de empezar con la instalación.

El instalador de la versión de 32 bits no calcula bien el espacio que quedará disponible al eliminar dispositivos de almacenamiento

enlace directo a este elemento - Bugzilla: #1375732

Si usa una imagen de Fedora 25 de 32 bits e intenta liberar espacio para la instalación eliminando sistemas de archivos o dispositivos de almacenamiento, puede que el instalador no calcule correctamente el espacio que quedará disponible y se niegue a continuar asumiendo que no habrá suficiente.

Puede evitar este problema liberando el espacio con otra herramienta antes de ejecutar el instalador, por ejemplo con gnome-disks, blivet-gui o parted, ya sea desde la imagen viva o desde un entorno de rescate.

Recuerde que desde Fedora 24 los errores que sólo se dan en la arquitectura i686 no bloquean los nuevos lanzamientos. Recomendamos usar x86_64 si es posible.

Problemas de actualización

DNF upgrade podría eliminar paquetes de sistema si ha usado antes PackageKit (GNOME Software, KDE Apper)

enlace directo a este elemento - Bugzilla: #1259865

Se da el caso de que en las últimas ediciones de Fedora PackageKit y DNF no estaban de acuerdo en ciertos elementos de gestión de los paquetes instalados. Si instaló algo mediante PackageKit (usado en GNOME Software y KDE Apper), esos paquetes no quedaron marcados como "instalados por el usuario" en la base de datos de DNF. Igualmente, si actualizó su sistema con PackageKit (mediante actualizaciones en modo desconectado de GNOME o Apper), la marca se borró de los paquetes actualizados que la tuvieran. Esa marca se usa para diferenciar los paquetes instalados por el usuario de los que se instalan por dependencias, de modo que en operaciones de limpieza se pueden eliminar estos últimos si ya no hay ningún otro que dependa de ellos. Cuando en la siguiente transacción (o al pedírselo con sudo dnf autoremove) DNF intente eliminar paquetes innecesarios, es posible que seleccione paquetes centrales del sistema que ya no ve marcados como instalados por el usuario, algo que podría ocurrir durante la actualización a Fedora 25.

Fedora 25 no se ha visto afectada por este problema, que se solucionó en Fedora 23 y 24 con libhif-0.2.2-3. El uso actual de PackageKit (GNOME Software, Apper) debería ser seguro. Sin embargo, si usó cualquiera de esas herramientas antes de que se corrigiera el problema, le recomendamos encarecidamente que arregle la base de datos antes de actualizar a Fedora 25:

1. Primero asegúrese de tener una versión corregida de libhif:

   rpm -q libhif

   Si no es la indicada anteriormente o una posterior, actualícela y vuelva a comprobarlo:

   sudo dnf --refresh update libhif

   Reinicie tras la actualización.
2. Luego marque todos sus paquetes como instalados por el usuario:

   rpm -qa --qf '%{NAME}\n' | xargs sudo dnf mark install

Tenga en cuenta que esta solución es excesiva, pues va a marcar todos los paquetes que tenga y ninguno se eliminará ya por ser una dependencia que no se necesita. Sin embargo es la única forma de asegurarse de que no va a estar afectado por este problema y el coste es relativamente pequeño. Los usuarios avanzados pueden adaptar esta solución a sus necesidades.

Bloqueo con una pantalla gris al iniciar sesión tras actualizar

enlace directo a este elemento - Bugzilla: #1394755

Ocurre si tiene instalada la extensión EasyScreenCast y actualiza. Es el mismo problema que el de la grabación de pantalla, en esa sección se ofrece una descripción más detallada, así como el modo de evitar el problema.

La entrada a la sesión falla cada dos intentos en algunas configuraciones

enlace directo a este elemento - Bugzilla: #1384508

Si ha actualizado su sistema tal vez le ocurra que uno de cada dos intentos de entrada a la sesión falle devolviéndole a la pantalla de selección del usuario sin mostrar ningún error. Ocurre en sesiones Wayland, no en X11. Parece que puede deberse a que el valor de org.gnome.SessionManager auto-save-session sea true en lugar del predeterminado false. Puede ver el valor actual con:

$ gsettings get org.gnome.SessionManager auto-save-session

y cambiarlo ejecutando:

$ gsettings set org.gnome.SessionManager auto-save-session false

Si está afectado, puede que se le muestre una notificación de error que apunte al informe #1384508. Esa notificación, y el informe, son en realidad sobre un fallo en la pantalla "Oh no!" que GNOME intenta mostrar cuando falla un componente principal, no tratan el fallo de gnome-session. Esto ha causado cierta confusión, pues el mismo problema en la pantalla "Oh no!" se puede dar por varias otras razones, y hay gente con problemas diferentes siguiendo el mismo informe. Hay más detalles en la sección sobre ese problema. El informe #775463 de GNOME es el específico para este fallo de auto-save-session.

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

enlace directo a este elemento - Bugzilla: #1395686

Al actualizar desde Fedora 23 o Fedora 24 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.

Problemas de sistema

Denegaciones de acceso por SELinux en el uso normal de Postfix

enlace directo a este elemento - Bugzilla: #1383867

Si usa el agente de correo Postfix, como es habitual en Fedora, es probable que note muchas denegaciones de acceso de SELinux. En un sistema personal verá notificaciones, en otros casos las encontrá en los registros. En general son del tipo SELinux está negando a (un proceso de Postfix) de '(algo)' el acceso a lnk_file log.

Creemos que se deben a intentos de escritura sobre /dev/log, y que la consecuencia sería la pérdida de algunos de los mensajes del registro. Por lo demás, parece que Postfix funcionaría sin problemas.

Estamos trabajando para corregir el problema. Mientras tanto, puede pasar de los avisos o bien usar audit2allow para generar una regla que permita los accesos.

Errores en la base de datos de RPM tras actualizar libdb

enlace directo a este elemento - Bugzilla: #1460303 - Bugzilla: #1394862

Los cambios realizados en libdb para evitar un problema en la actualización a Fedora 26+ pueden provocar errores en la base de datos de RPM al actualizar el propio libdb. Cuando esto ocurre lo más probable es que fallen las operaciones siguientes relacionadas con gestión de paquetes, con algún error indicando que hay problemas con la base de datos de RPM.

Por ahora todos los casos que se han encontrado pueden corregirse de forma completa y segura ejecutando sudo rpm --rebuilddb o, si eso no fuera suficiente, sudo rm -rf /var/lib/rpm/__db* y después sudo rpm --rebuilddb.

Problemas de Wayland

Wayland reemplaza a X11 en la capa de visualización. Aunque el desarrollo ha sido rápido y ya se puede usar Wayland en la mayoría de los casos, aún hay algunos problemas. Puede obtener más información visitando las siguientes páginas:

• Estado del desarrollo de Wayland
• Problemas conocidos en Wayland
• Informes de errores relacionados con Wayland

Si sufre algún problema, compruebe primero la lista por si ya se ha informado de él. En caso de duda, abra uno nuevo.

Por ahora es la opción predeterminada sólo para GNOME. Si quiere desactivarlo, elija la sesión GNOME en Xorg cuando entre al sistema (sólo verá esta pantalla si ha definido que debe indicar la clave para entrar):

Las aplicaciones en ejecución fallan al salir de una sesión de GNOME en Wayland

enlace directo a este elemento - Bugzilla: #1366897 - Bugzilla: #1394937

Cuando sale de una sesión de GNOME en Wayland, las aplicaciones que estén en marcha pueden fallar. Esto es debido a algunos problemas de orden y sincronización en el cierre de varios componentes de GNOME cuando se ejecutan en Wayland. Para evitar consecuencias desagradables, debe guardar todo su trabajo antes de salir, e incluso mejor cerrar las aplicaciones manualmente.

Hay algunos informes de problemas similares en sesiones bajo Xorg, en discusión en RHBZ #1394937, pero los detalles de ese caso aún no están claros.

El servidor vino (escritorio remoto) falla al iniciar sesión en Wayland

enlace directo a este elemento - Bugzilla: #1394599

Si ha configurado un servidor de escritorio remoto con vino-server (por ejemplo desde configuración de GNOME), verá un aviso de error cada vez que entre a una sesión Wayland. Aún no hay soporte en Wayland para el escritorio remoto. Puede desactivar el servidor de escritorio remoto (Configuración -> Compartir -> Compartición de pantalla) o bien usar la sesión Xorg si necesita ese servicio.

La mayoría de las aplicaciones Qt 5 fallan en Wayland al mostrar el cuadro de diálogo de archivo si no tiene instalado qgnomeplatform

enlace directo a este elemento - Bugzilla: #1392605

Si ha actualizado desde Fedora 23 o versiones anteriores, tal vez no tenga el paquete qgnomeplatform instalado. En ese caso, las aplicaciones Qt 5 fallarán en Wayland al mostrar el cuadro de diálogo de archivos. Debe instalar el paquete qgnomeplatform:

$ sudo dnf install qgnomeplatform

GNOME se cuelga en Wayland cuando hay 3 monitores

enlace directo a este elemento

Se producen en GNOME cuelgues frecuentes cuando se usan 3 monitores a la vez. Se ha confirmado el problema al menos en varios portátiles ThinkPad con gráficos Intel. Para obtener más detalles acuda al informe de error 774557 en GNOME.

Actualmente la única solución es usar una sesión X11 en lugar de Wayland, o bien no conectar más de 2 monitores.

No se pueden ejecutar aplicaciones con privilegios de administrador (como gparted) en Wayland

enlace directo a este elemento - Bugzilla: #1274451

En Wayland no se pueden ejecutar aplicaciones gráficas con privilegios de administrador. No es en realidad un error, sino una decisión de diseño; forma parte del plan para hacer Wayland más seguro que X. En general, las aplicaciones que necesitan privilegios para ciertas operaciones deberían estar hechas de forma que las aplicaciones mismas no necesiten ejecutarse con esos privilegios, sino que usen un mecanismo como PolicyKit para solicitarlos sólo para la parte los necesita.

Así que no puede ejecutar, por ejemplo, sudo gedit /etc/archivodeconfig.conf ni sudo gvim /etc/archivodeconfig.conf para editar un archivo que necesite permisos de administrador para escritura. Tampoco funciona gparted, ya que está diseñada para ejecutarse como administrador. Hay varias formas de solucionar estos problemas.

Para las aplicaciones que usan la capa de acceso a archivos Gvfs de GTK+ hay disponible un indicador de recurso: admin:///. Así puede ejecutar, por ejemplo, gedit admin:///etc/archivodeconfig.conf. En el futuro este mecanismo estará mejor integrado en las aplicaciones, de forma que no sea necesario indicarlo manualmente. Este sistema no vale para aplicaciones que no usan Gvfs, como gvim.

En otros casos puede usar otras aplicaciones que también dispongan de la funcionalidad que necesite. Por ejemplo, Discos (gnome-disks desde la consola) puede hacer lo que quería hacer con gparted.

También puede, para aplicaciones que no sean nativas de Wayland, ejecutar lo siguiente desde la consola con su usuario: xhost +si:localuser:root. Es un cambio general, no sólo una ejecución de una aplicación, que permitirá la conexión como usuario root al servidor X local interno, es decir, para las aplicaciones que no son de Wayland y se ejecutan bajo XWayland.

Si ninguna de estas opciones le sirve, le queda la opción de usar X.org en lugar de Wayland, cambiando el tipo de sesión como se indica más arriba.

La sesión Wayland de GNOME no ejecuta un entorno de entrada, por lo que no procesa .bash_profile, .bashrc, etc.

enlace directo a este elemento - Bugzilla: #1149905

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.

Al contrario que con Xorg, la sesión de GNOME en Wayland no se ejecuta mediante un login shell. Esto hace que algunos guiones de configuración que se leen para los entornos de entrada, como /etc/profile, /etc/profile.d/*, ~/.bash_profile y ~/.bashrc no se ejecutan en la sesión de GNOME, y a la mayoría de las aplicaciones no se les aplicarán los ajustes de esos guiones. De manera predeterminada, el Terminal de GNOME sí leerá por sí mismo ~/.bashrc, que incluye /etc/bashrc, que también integra /etc/profile.d/*. Sin embargo no accederá a ~/.bash_profile ni a /etc/profile.

• Puede establecer los valores de variables de entorno en /etc/environment (con un formato simple ENVVAR=valor).
• Hay también algunas alternativas a hacer los ajustes con esos guiones, como ejecutar lo que sea necesario al inicio de sesión con archivos desktop en ~/.config/autostart o /etc/xdg/autostart.

Puede encontrar una discusión más detallada de las consecuencias de este cambio y de algunas alternativas en el informe de GNOME.

Bajo ciertas condiciones, la grabación de pantalla bloquea GNOME

enlace directo a este elemento - Bugzilla: #1394755

Si activa la grabación de pantalla en GNOME (Ctrl+Alt+⇧ Shift+R) su sesión puede bloquearse (sólo puede salir usando SysRq o entrando desde otro equipo con ssh y matando la sesión). Este problema está relacionado con el archivo de caché del registro de gstreamer (~/.cache/gstreamer-1.0/registry.x86_64.bin): cuando cambia (por actualización de alguna extensión o si lo borra) se activa el problema. No ocurre sólo con la grabadora integrada en GNOME, también con extensiones o herramientas como EasyScreenCast. En este último caso el bloqueo ocurre durante el inicio de sesión.

El remedio actual es elegir Xorg en el tipo de sesión (vea #Problemas de Wayland) y entrar al menos una vez. Con eso se arregla el archivo de caché y después se puede usar la sesión Wayland. También ayuda eliminar la extensión EasyScreenCast si la tiene instalada, y el paquete clutter-gst2 (aunque algunas aplicaciones podrían depender de éste).

Problemas de Fedora Workstation

La pantalla "Oh no!" de GNOME (que se muestra cuando falla un componente principal de GNOME) falla

enlace directo a este elemento - Bugzilla: #1384508

Cuando falla un componente principal de GNOME (como gnome-session o gnome-shell), GNOME intenta ejecutar gnome-session-failed, que muestra una pantalla con el mensaje "Oh no! Something has gone wrong". En Fedora 25 el mismo gnome-session-failed falla a menudo. Cuando esto sucede, puede generar un informe de error que lleva al informe #1384508. En él se trata el fallo de la pantalla "Oh no!", no la causa inicial que hizo que se intentara mostrar esa pantalla. En el informe parece que se han encontrado varias causas para ese error inicial, una de ellas esta, que tiene que ver con el guardado de la sesión, pero está claro que hay más casos.

Si se encuentra con este error, vea si puede encontrar la causa inicial, la razón por la que se intentó ejecutar gnome-session-failed, pues ese es el problema que realmente le interesa corregir. Puede ser de ayuda ejecutar journalctl -b como el usuario para el que surgió el problema, pues la sesión de GNOME debería enviar al registro un mensaje del error del componente interno. Después vea si ya existe un informe sobre ese problema, y abra uno nuevo en Fedora o GNOME si no.

Desde luego intentaremos encontrar una solución para el problema de la pantalla "Oh no!", pero eso no resolverá lo que sea que cause que se intente mostrar esa pantalla.

Algunas aplicaciones Qt 5 (VLC, Calibre) cambian de tamaño cuando no deberían

enlace directo a este elemento - Bugzilla: #1381828

Algunas aplicaciones Qt 5, como VLC o Calibre, usan cambios de escala de ventana para monitores de alta resolución. Sin embargo, la implementación cambia las proporciones incluso en algunos monitores estándar (Full HD). También ajusta la escala si usa varios monitores. El resultado final es que puede acabar con fuentes y elementos demasiado grandes o pequeños.

Puede evitarse ejecutando la aplicación con la variable de entorno QT_SCALE_FACTOR=1 de esta forma:

QT_SCALE_FACTOR=1 comando

Es necesario un reinicio para mostrar nuevos tipos de sesiones en GDM tras instalar otros escritorios

enlace directo a este elemento - Bugzilla: #1398770

Si instala algún entorno de escritorio después de instalar Fedora Workstation y sale de la sesión de usuario, el nuevo escritorio no tendrá aún su opción en el selector de sesión de la pantalla de inicio. La causa es que gdm está en ejecución (incluso cuando hay una sesión abierta, para aceptar otras sesiones) y no hay ninguna señal para indicarle que se ha instalado un nuevo entorno de escritorio, por lo que no se entera hasta que se reinicia. Se puede reiniciar GDM sin reiniciar el sistema, pero es más sencillo simplemente reiniciar el sistema, o apagar y volver a encender.

En algunos elementos de texto no se usa el tamaño correcto si se selecciona Texto grande o se usa un factor de escala para el texto

enlace directo a este elemento

Debido a un problema con ciertos elementos de visualización de texto, cuando se usa un 'factor de escala de texto' en GNOME, hay casos en los que esa escala no se aplica adecuadamente, haciendo que el texto salga demasiado pequeño. La escala se puede activar seleccionando Texto grande en Aceso universal o bien manualmente con gnome-tweak-tool.

Se sabe que afecta al menos a gedit (en el texto del documento que se está editando, no en la interfaz de usuario). Al editor de correo de Evolution le pasaba algo parecido (de nuevo, en el texto del correo y no en la interfaz de usuario), aunque por una causa diferente ya corregida en la versión 3.22.2 de Evolution; si actualiza a esa versión o alguna posterior, el caso de Evolution estará arreglado. En los elementos afectados el texto aparece como si no hubiera escala, en lugar de usar la elegida por el usuario.

En gedit puede cambiar las propiedades del texto en las Preferencias y usar un tamaño mayor hasta que se arregle el problema. Para otras aplicaciones pueden existir apaños similares.

Problemas de Plasma (KDE)

En máquinas virtuales (controlador QXL), al salir de la segunda sesión de usuario de KDE se cierra también la primera

enlace directo a este elemento - Bugzilla: #1382001

Si usa el cambio de usuario sin cierre de sesión, al cerrar la sesión del segundo usuario también se cierra la del primero. Sólo pasa con el controlador QXL que se usa en máquinas virtuales (cajas GNOME, virt-manager).

Problemas de hardware

No se desconectan las pantallas externas después de desacoplar

enlace directo a este elemento - Bugzilla: #1392885

Si usa una estación de acoplamiento, tiene conectada una pantalla externa y desacopla el portátil, el sistema creerá que la pantalla aún está conectada, por lo que se seguirá "usando", aunque no podrá ver su contenido. Puede eliminarla manualmente desde la configuración de pantallas.

Este problema sólo afecta a los medios vivos y las instalaciones limpias (con kernel-4.8.6-300.fc25). Se ha corregido en kernel-4.8.7-300.fc25, que está disponible en las actualizaciones.

La salida de sonido a jack no funciona tras actualizar desde F24

enlace directo a este elemento - Bugzilla: #1387676

La salida de sonido al sistema jack puede dejar de funcionar tras actualizar de F24 a F25. Puede recuperarla borrando .config/pulse y .pulse-cookie del directorio de usuario y reiniciando la sesión.

Problemas de Fedora Server

Las aplicaciones web de PHP generan muchos rechazos SELinux de 'execmem'

enlace directo a este elemento - Bugzilla: #1398474

Si ejecuta aplicaciones web PHP en Fedora Server 25 es probable que vea muchas denegaciones de SELinux para la acción execmem en el servidor HTTP. La causa parece estar en una nueva característica de PHP 7, que hace compilación JIT (en tiempo de ejecución) de PCREs (expresiones regulares compatibles perl).

Hay dos soluciones por el momento. Puede permitir a los servidores HTTP la acción execmem mediante el comando setsebool -P httpd_execmem 1. Con ello conseguirá que las aplicaciones PHP funcionen sin cambios, si bien reducirá la seguridad. La otra opción es desactivar la nueva característica de PHP, añadiendo la línea pcre.jit=0 a algún archivo de configuración en /etc/php.d.

Además del informe en Fedora, hay otro del mismo pcre haciendo seguimiento del problema.

SELinux no permite a SpamAssassin (spamd) el acceso a /var/spool/mail

enlace directo a este elemento - Bugzilla: #1398437

Este problema se puede dar en servidores de correo con Fedora Server 25. Si está usando SpamAssassin con una configuración típica, puede que vea que SELinux evita que spamd y sus procesos (identificados en los informes por una larga cadena alfanumérica, como 7370616D64206368696C64) accedan a /var/spool/mail. Si controla su sistema y mira los informes de auditoría, podrá ver mensajes de tipo AVC denegando a procesos con contexto system_u:system_r:spamd_t:s0 el acceso a rutas con contexto system_u:object_r:mail_spool_t:s0: son casos relacionados con el mismo problema.

Aunque no hemos investigado en profundidad las consecuencias de estas denegaciones de acceso, es probable que algunas características de SpamAssassin no funcionen como se espera. Sí sabemos que hacen que la extensión Razor no funcione correctamente.

Se puede evitar este problema sin necesidad de poner SELinux en modo permisivo, generando reglas propias con audit2allow. Un archivo .te como este debería valer:

module bz1398437-arreglo 1.0;

require {
        type mail_spool_t;
        type spamd_t;
        class dir { add_name create getattr open read remove_name search write };
        class file { append create getattr ioctl open read unlink write };
}

#============= spamd_t ==============
allow spamd_t mail_spool_t:dir { add_name create getattr open read remove_name search write };
allow spamd_t mail_spool_t:file { append create getattr ioctl open read unlink write };

Otros problemas

La hibernación no funciona desde una instalación normal

enlace directo a este elemento - Bugzilla: #1206936

El generador systemd-hibernate que se usa para continuar al salir del estado de hibernación espera encontrar resume=/path/to/swap en los parámetros del núcleo. Anaconda no lo añade a /etc/default/grub y dracut no lo pone en la línea del núcleo, así que systemd no puede encontrar la imagen para la salida de la hibernación.

Para arreglarlo, obtenga la ruta a la zona de intercambio con swapon -s, añádala a la línea GRUB_CMDLINE_LINUX en /etc/default/grub y regenere el archivo grub.cfg:

• Mediante grub2-mkconfig:
  • Para sistemas BIOS:

    grub2-mkconfig -o /boot/grub2/grub.cfg

  • Para sistemas EFI:

    grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

• Mediante grubby:

  grubby --args=resume=/ruta/a/swap --update-kernel=$(grubby --default-kernel)

El arranque de otras distribuciones Linux UEFI puede no funcionar desde el arrancador de Fedora

enlace directo a este elemento - Bugzilla: #1353026

Hay varios informes de gente con otras distribuciones de Linux instaladas en modo UEFI en discos GPT que indican que no pueden arrancar las otras distribuciones desde el gestor de arranque de Fedora. Si a usted le sucede lo mismo, cuéntenoslo en RHBZ #1353026. Para usar sus otros sistemas, acceda al menú de UEFI (pulsando alguna tecla especial al inicio, como F8, F10, F11, F12 o Esc) y elija ahí con cuál quiere arrancar. Eso arrancará su sistema sin pasar por el gestor de arranque de Fedora. También puede probar a seleccionar su sistema en el gestor de arranque de Fedora, pulsar e para editar el menú, cambiar linux e initrd por linuxefi e initrdefi, y después pulsar Ctrl+x o F10 para arrancar.

Problemas resueltos

Fedora Media Writer muestra de forma predeterminada Fedora 24 en lugar de Fedora 25

enlace directo a este elemento - Bugzilla: #1397461

Corrección publicada
Corregido a partir de la versión 4.0.7 de Fedora Media Writer. Ya se ha publicado una actualización para todas las versiones de Fedora que aún se encuentran en mantenimiento, y también se ofrece en la descarga para Windows y macOS en getfedora.org, por lo que los nuevos usuarios de Fedora 25 no deberían sufrir el problema.

Fedora Media Writer es la nueva herramienta para la creación de medios de instalación (normalmente unidades USB). En la versión 4.0.4, que aparecía en getfedora.org en el momento del lanzamiento, si elige Fedora Workstation la versión predeterminada será Fedora 24 y no Fedora 25. Puede pulsar sobre "Versión 24" para cambiarla. Para el resto de ediciones (Fedora Server, KDE Plasma Desktop, etc.), aparece Fedora 25 correctamente. (Y si elige una de esas otras ediciones y vuelve a Fedora Workstation, también saldrá F25 para ésta.)