Esta página documenta problemas comunes en Fedora 26 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 26 y las notas de lanzamiento de Fedora 26 para obtener información específica sobre los cambios en Fedora 26, 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:
- un resumen del problema
- cualquier solución provisional conocida
- 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.
Hay un fichero de actualización en el comentario 92 que esperamos que arregle este problema o al menos mejore la situación. Si está afectado por el mismo, por favor pruebe esa actualización y cuéntenos el resultado. Gracias.
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.
No se puede arrancar macOS desde grub
enlace directo a este elemento - Bugzilla: #893179
Si instala Fedora en un Mac con arranque múltiple, Fedora genera varias entradas "Mac OS X" en el menú de grub que debería permitirle arrancar macOS. Esas entradas son incorrectas y no podrá usarlas. Para arrancar macOS use el menú UEFI que aparece manteniendo pulsada la tecla ⌥ Opt (o Alt derecha) al encender el equipo.
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 de las versiones vivas no ofrece iSCSI
enlace directo a este elemento - Bugzilla: #1395620 - Bugzilla: #1429132
En las imágenes vivas de Fedora 26 Alfa el instalador no tiene funcionalidad iSCSI (no aparecerá el botón "Añadir destino iSCSI" en la pantalla de 'Discos especializados y de red'). Puede obtener la funcionalidad ejecutando sudo dnf install storaged-iscsi desde la consola antes de empezar con la instalación, o instalando desde un imagen dedicada de instalación en lugar de usar la imagen viva.
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 26 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 de Fedora 24 a Fedora 26.
Fedora 25 y 26 no se han visto afectadas 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 26:
- 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. - 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.
La actualización de Fedora 26 a 27 o superior falla si alguno de los paquetes tiene dependencias tipo with
enlace directo a este elemento - Bugzilla: #1551543
Hay una actualización candidata a resolver el problema en el repositorio updates-testing para pruebas. Se recomienda a los usuarios afectados por este problema que prueben la actualización e informen de los resultados en Bodhi. Para probar la actualización ejecute el siguiente comando:
sudo dnf install yum && sudo yum-deprecated --enablerepo=updates-testing update --advisory=FEDORA-2018-d4cacdf9bcEntre Fedora 26 y Fedora 27 se añadió soporte a RPM para la declaración with en dependencias enriquecidas. Como la versión de RPM de Fedora 26 no entiende este tipo de dependencias, falla la actualización de paquetes que las usan en su nueva versión. La forma más fácil de resolver el problema es usar la versión de RPM que ya está disponible en pruebas.
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 - bug GNOME #775463
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. Tanto la notificación como 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 puede bloquearse si no se hace con libdb-5.3.28-21 o libdb-5.3.28-23+
enlace directo a este elemento - Bugzilla: #1397087 - Bugzilla: #1394862
En las pruebas de actualización a Fedora 26 se ha visto que algunos scriptlets (guiones de comandos que se ejecutan en transacciones RPM) pueden hacer que RPM se bloquee si la transacción también actualiza glibc o libpthread de un modo que afecte a la base de datos RPM (esto no es más que un resumen muy basto de un asunto bastante complejo, si quiere conocer los detalles técnicos consulte los informes de errores).
Los cambios para evitar este problema se enviaron al repositorio estable de Fedora 24, 25 y 26 con libdb-5.3.28-21. Sin embargo después llegaron informes indicando que la actualización a esa versión del paquete puede provocar en algunos casos problemas (con solución) en la base de datos de RPM (más información en este otro apartado). Se decidió entonces dar marcha atrás al cambio y se envió una nueva versión -22 a updates-testing. Al final, por diversas razones, se ha retirado la -22 y aparecerá en breve la -23 con el cambio y con otra corrección relacionada con las actualizaciones.
En definitiva: cuando actualice a Fedora 26, asegúrese de tener libdb-5.3.28-21, libdb-5.3.28-23 o una versión posterior instalada y que en la actualización se cogerán libdb-5.3.28-21.fc26, libdb-5.3.28-23.fc26 o posterior. Recomendamos no intentar actualizar el sistema con libdb-5.3.28-20 o anteriores ni con libdb-5.3.28-22. Debido a la posibilidad de error o confusión, creemos que no debe actualizar a Fedora 26 ningún equipo importante hasta que se haya enviado libdb-5.3.28-23 al repositorio estable de todas las versiones de Fedora.
Para asegurarse de que tiene la versión de libdb correcta antes de actualizar, ejecute dnf --disablerepo=updates-testing distro-sync. Desactivar el repositorio updates-testing durante la actualización también debería asegurar que se recoge la versión correcta para el nuevo sistema. Si en algún momento se producen errores en la base de datos de RPM, ejecute rpm --rebuilddb para resolverlos. Tenga en cuenta que regenerar la base de datos RPM manualmente puede hacer que los archivos se queden con una etiqueta SELinux incorrecta. Para arreglarlo, ejecute restorecon -RFv /var/lib/rpm como root tras regenerar la base de datos.
Los fondos de escritorio de GNOME pueden desaparecer en la actualización
enlace directo a este elemento
La colección de fondos de escritorio de GNOME ha pasado a gnome-backgrounds-extras. Si un usuario tiene uno de estos fondos instalados, es probable que tras la actualización le salga un fondo vacío. La solución es instalar el nuevo paquete con dnf install gnome-backgrounds-extras.
Problemas de sistema
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
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. Tenga en cuenta que regenerar la base de datos RPM manualmente puede hacer que los archivos se queden con una etiqueta SELinux incorrecta. Para arreglarlo, ejecute restorecon -RFv /var/lib/rpm como root tras regenerar la base de datos.
Fedora 26 Workstation no arranca como huésped VMware
enlace directo a este elemento - Bugzilla: #1468321
Parece que es habitual que Fedora 26 Workstation no llegue a cargar el escritorio cuando se arranca como huésped en VMware. Varias personas han informado del problema con huéspedes Fedora 26 Workstation bajo VMware 12, cuando Fedora 25 arranca correctamente. Aún no sabemos si la causa está en Fedora o en VMware. Seguimos investigando este problema y trabajando con VMware para resolverlo.
El proceso de inicio es muy lento y parece bloquearse a partir del núcleo 4.16.4
enlace directo a este elemento - Bugzilla: #1572944
A partir de la versión 4.16.4, el núcleo es más estricto al indicar si está preparado para proporcionar números aleatorios. No se trata de un cambio específico de Fedora, viene de origen. Antes bastaba con que pudiera responder con cierto nivel de aleatoriedad, pero tras el cambio el generador debe proporcionar la aleatoriedad necesaria para uso criptográfico. El cambio se consideró como un problema de seguridad.
Si alguna parte del proceso de inicio espera a que el generador de números aleatorios esté listo, a partir de ese cambio puede retrasar el inicio mucho más. Afectará con más fuerza a los sistemas sin un generador de números aleatorios por hardware y sin fuentes internas de entropía, lo que quiere decir que será bastante común en máquinas virtuales e instancias de nube. En casos graves puede incluso ocurrir que caduque algún tiempo de espera y el sistema no llegue a iniciar completamente.
Si su sistema parece arrancar bien con los núcleos anteriores y el arranque es muy lento o parece colgarse a partir del 4.16.4, es probable que se deba a este cambio. Pruebe a pulsar teclas al azar durante el arranque, pues eso sirve de fuente de entropía. Si el arranque continúa tras unos segundos de tecleo, está claro que este es el problema. Teclear puede servir como apaño en algunos casos, pero no en todos.
Para máquinas virtuales y de nube se produce una mejora significativa si se permite al obtener entropía del anfitrión, sobre todo si tiene un generador hardware configurado como fuente. La forma de hacerlo depende del tipo de nube y sistema de virtualización. En esta página encontrará instrucciones para OpenStack. Aquí se incluye información para libvirt. Este otro sitio lo explica para qemu. Puede que otros sistemas de virtualización usen también virtio-rng.
Una forma especialmente fuerte de este problema se manifiesta si arranca con un initramfs generado teniendo sudo dracut -f para volver a generar el initramfs. Este caso podría darse con imágenes Fedora, pero por lo que sabemos aún no hay ninguna oficial ni semioficial con esta casuística.
Problemas de GNOME
Problemas de Wayland
enlace directo a este elemento
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):
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
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
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.
Totem no puede reproducir vídeo en Wayland desde máquinas virtuales
enlace directo a este elemento - Bugzilla: #1467368
Totem (Vídeos) no reproduce vídeo cuando se usa una sesión Wayland en una máquina virtual (las predeterminadas libvirt, no en VirtualBox). Se oye el audio pero no aparecen el vídeo ni la ventana de totem. Si necesita reproducir vídeo en un entorno de ese tipo, use una sesión X11 o bien un reproductor diferente.
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.
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 podrá 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 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
En Wayland no se envían a las máquinas virtuales eventos de desplazamiento del dispositivo señalador
enlace directo a este elemento - Bugzilla: #1386602
El envío de los eventos de desplazamiento a máquinas virtuales en Wayland funciona bien si se está usando un ratón, pero no con un panel táctil o un puntero. Si lo necesita, cambie a la sesión Xorg en el anfitrión.
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), anjuta y latexila.
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.
La pantalla de inicio se bloquea con el controlador VESA en sistemas de vídeo Intel
enlace directo a este elemento - Bugzilla: #1467278
Si arranca GNOME con un sistema gráfico Intel usando el controlador VESA (modo gráfico básico), puede que obtenga una pantalla gris en lugar del gestor de inicio de sesión (GDM). Si es posible use un modo gráfico acelerado (debería funcionar bien con gráficas Intel). Si no, tiene las siguientes opciones:
- Si lo permite su sistema, cambie del modo BIOS a UEFI. El controlador UEFI no parece tener estos problemas.
- Arranque en el runlevel 3, edite
/etc/gdm/custom.confy active (elimine la marca de comentario)#WaylandEnable=false.
Problemas de Plasma (KDE)
Los sistemas instalados desde KDE Live no arrancan en modo gráfico en ciertas configuraciones de red (p.ej. libvirt)
enlace directo a este elemento - Bugzilla: #1370222
En ciertas configuraciones de red (en particular en el modo NAT predeterminado de libvirt, como al usar virt-manager o gnome-boxes), una instalación hecha desde el medio vivo de KDE arrancará la primera vez, pero los inicios posteriores acabarán en una pantalla negra sin ventana gráfica de identificación. Esto está provocado por un fallo en sddm (el gestor de inicio de KDE) al recibir un cambio de nombre de máquina del servidor dhcp durante el arranque.
Puede evitarlo de cualquiera de las siguientes formas:
- En el instalador ponga un nombre fijo a la máquina (algo distinto de localhost).
- Instale desde la imagen de instalación completa por red en lugar de con la imagen viva de KDE.
Si ya ha instalado y está afectado, puede:
- Cambiar a TTY2 y poner un nombre fijo (distinto de localhost) mediante
$ sudo hostnamectl set-hostname HOSTNAME
- Cambiar la dirección MAC del controlador de red, o retirar el dispositivo y volverlo a añadir si está usando una máquina virtual (eso hará que cambie su MAC).
- Eliminar los nombres de equipo recordados por libvirt, que se encuentran en algún lugar de /var/lib/libvirt/dnsmasq/.
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 red
Problemas de hardware
Las sesiones Wayland fallan con algunos dispositivos NVIDIA, en los logs aparece el error fifo: read fault
enlace directo a este elemento - Bugzilla: #1457626
Varios usuarios han informado de errores con gráficas NVIDIA en Fedora 26 que hacen que la sesión GNOME Wayland (la predeterminada en la edición de escritorio) falle al poco de iniciarse. Si comprueba el registro, encontrará un error con el texto fifo: read fault más o menos cuando cae la sesión.
Puede desactivar Wayland editando el archivo /etc/gdm/custom.conf y quitando el carácter # de la línea #WaylandEnable=false. Por el momento es el único método conocido para evitar el problema.
Se han recibido informes de este error para:
- GeForce GTX 960 (GM206)
- Quadro K4200 (GK104GL)
- GeForce GTX 650 (GK107)
- GeForce GTX 760 (GK104)
- Quadro 4000 (GF100GL)
- Quadro 5000 (GF100GL)
- GeForce GTX 770 (GK104)
Problemas de aplicaciones
Problemas de ARM
Problemas de Fedora Server
Problemas de Fedora Cloud
Problemas de Fedora Atomic
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:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
- Para sistemas EFI:
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
- Para sistemas BIOS:
- Mediante grubby:
sudo 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.
livemedia-creator no puede crear imágenes a partir de archivos kickstart con repositorios metalink (ni siquiera los kickstart oficiales)
enlace directo a este elemento - Bugzilla: #1464843
Si intenta usar la herramienta oficial livemedia-creator para crear una imagen viva mediante un archivo kickstart basado en uno de los oficiales (del repositorio fedora-kickstarts o del paquete
Esto es debido a que la combinación livemedia-creator+anaconda no puede actualmente gestionar bien los kickstart que usan URL metalink para indicar los repositorios. Si se pregunta cómo han podido entonces generarse las imágenes oficiales, la respuesta es que las definiciones de repositorios se modifican en vivo en el sistema de composición de Fedora antes de generarse las imágenes, para usar un repositorio local en disco que forma parte del proceso.
Por ahora, para evitar el problema, cambie la definición de los repositorios en sus archivos kickstart para usar una URL directa o de lista de espejos.
Problemas resueltos
La actualización puede fallar por un conflicto entre componentes gstreamer
enlace directo a este elemento - Bugzilla: #1467136
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.
Por un tiempo, los paquetes
Error: Error en la verificación de operación: el archivo /usr/lib64/gstreamer-1.0/libgsttranscode.so de la instalación de gst-transcoder-1.12.0-1.fc26.x86_64 entra en conflicto con el archivo del paquete gstreamer1-plugins-entrans-1.0.3-2.fc26.x86_64
Este error podía darse durante el proceso de dnf system-upgrade download, si en Fedora 25 tenía tanto gstreamer1-plugins-entrans (fuera con dnf system-upgrade download fallaba incluso con la opción --allowerasing. El problema podía solucionarse eliminando temporalmente uno de los dos paquetes, pero ya no debería ser necesario hacerlo.
La pantalla "Oh no!" de GNOME (que se muestra cuando falla un componente principal de GNOME) falla
enlace directo a este elemento - Bugzilla: #1384508
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.
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 26 el mismo gnome-session-failed fallaba a menudo. Cuando esto sucedía se generaba un informe de error que llevaba al informe #1384508. En ese informe se trata el fallo de la pantalla "Oh no!", no la causa inicial que hace que se intente 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.
Discover falla al iniciarse
enlace directo a este elemento - Bugzilla: #1468239
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.
El gestor de software Discover incluido en la edición KDE fallaba al inicio. La actualización mencionada arregla el problema, pero obviamente la aplicación seguirá fallando si se lanza desde una imagen viva sin actualizar. Hay varias formas de de resolver este problema, tal vez la más sencilla sea instalar el paquete sudo dnf install flatpak. O puede usar dnfdragora, otro gestor incluido también en la edición.
Los juegos que usan el motor Unity se bloquean con una pantalla negra
enlace directo a este elemento - Bugzilla: #1440287
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.
La ejecución de un juego propietario de Steam u otras fuentes podía quedarse bloqueada con una pantalla negra. Si está intentando hacerlo desde una imagen viva sin actualizar, puede encontrar una solución que no requiere actualización en el informe de errores.