Common F27 bugs/es

In other languages: English (en) español (es) français (fr) [edit]

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

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.

El instalador de las versiones vivas no ofrece iSCSI

enlace directo a este elemento - Bugzilla: #1395620 - Bugzilla: #1429132

En algunas imágenes vivas de Fedora 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 una imagen dedicada de instalación en lugar de usar la imagen viva.

Problemas de actualización

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

La actualización de GRUB puede fallar si /boot está en un sistema XFS

enlace directo a este elemento - Bugzilla: #1227736

Si tiene /boot en un sistema de archivos XFS y actualiza su sistema puede acabar con una consola mínima de GRUB (sin opciones interactivas de arranque) tras la actualización. El problema se debe a que el sistema se reinicia cuando XFS tiene un estado intermedio y no ha grabado aún todos los cambios del sistema de archivos.

Para evitarlo puede probar a desactivar plymouth (eliminando la opción rhgb en el arranque) durante la actualización o desinstalarlo primero (son soluciones que no se han probado).

Si ya le ha ocurrido, debería poder arreglarlo arrancando desde una imagen viva o de rescate y montando el sistema de archivos problemático (que volverá a ejecutar el diario del sistema de archivos), tal vez ejecutando xfs_repair para asegurarse de que no queda ningún problema latente. En el peor de los casos también tendrá que reinstalar grub.

Problemas de sistema

Pulseaudio no se inicia si se cierra la sesión y se vuelve a abrir rápidamente

enlace directo a este elemento - Bugzilla: #1510301

En ocasiones Pulseaudio (el servidor de sonido predeterminado en Fedora) no se inicia correctamente cuando el usuario cierra la sesión y vuelve a entrar inmediatamente. El resultado es que la captura y reproducción de sonido no funciona correctamente.

Este problema se puede evitar espeerando un tiempo (unos 30 segundos) entre accesos. También puede que sirva reducir el valor de exit-idle-time en /etc/pulse/daemon.conf.

Errores Non-ASCII characters found en la actualización de paquetes y otras acciones

enlace directo a este elemento - Bugzilla: #1502009

En el uso de Fedora 27 puede encontrarse con mensajes de error como el siguiente:/etc/selinux/targeted/contexts/files/file_contexts.bin: line 1 error due to: Non-ASCII characters found en actualizaciones, el arranque del sistema y en otras situaciones. Estos mensajes no indican ningún problema serio y se pueden descartar. El equipo de SELinux está al tanto y espera arreglarlo con una actualización de selinux-policy.

Cambios en el intérprete de comandos para algunas actualizaciones desde versiones prelanzamiento

enlace directo a este elemento - Bugzilla: #1193590

Algunos usuarios que instalaron Fedora 27 entre la beta y la versión definitiva pueden notar cambios no deseados en el intérprete de comandos tras actualizar. Lo primero que salta a la vista es que el saludo de la línea de comandos no es el típico de Fedora, sino el del proyecto original, algo así como bash-4.4$. Pero el problema va más allá. El intérprete no está leyendo /etc/bashrc, por lo que todo lo que está implementado mediante ese archivo no llega a ejecutarse (entre otras cosas, la carga de los guiones de perfiles de /etc/profile.d, que contienen los alias predeterminados, con lo que cambia el comportamiento esperado de algunos comandos).

Sólo ocurrirá con los usuarios dados de alta con la versión 4.4.12-11 de bash cuando se actualice a la 4.4.12-12. Esa versión estuvo en updates-testing para Fedora 27 entre el 2017-09-11 y el 2017-09-30, y pasó al repositorio estable el 2017-09-30. La 4.4.12-12 entró en updates-testing el 2017-10-31 y en el estable el 2017-11-08. Por tanto, si instaló Fedora 27 o creó cuentas de usuario en Fedora 27 entre el 2017-09-11 y el 2017-11-08, puede que le afecte este problema (depende de la imagen que usara, los repositorios que tuviera activos, cuándo actualizara, etc).

No deberían estar afectadas las instalaciones de Fedora 27 Final ni las actualizaciones a Fedora 27 realizadas a partir del 2017-11-08.

Si sufre este problema puede solucionarlo añadiendo lo siguiente al principio de ~/.bashrc para cada una de las cuentas afectadas (incluyendo la de root):

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

Normalmente está entre las líneas # .bashrc y # User specific aliases and functions. Con eso quedaría resuelto por completo.

La causa fue un cambio en la inclusión de /etc/bashrc que no se pensó muy bien. Antes de 4.4.12-11 la plantilla que hay en Fedora para ~/.bashrc incluía las líneas de más arriba, con lo que los intérpretes de bash leían /etc/bashrc a través de ~/.bashrc. 4.4.12-11 cambió bash para leer /etc/bashrc directamente en cada inicio, y se cambió la plantilla de ~/.bashrc para no incluir las líneas anteriores. Este cambio tuvo unas consecuencias problemáticas que no llegaron a detectarse y comprenderse hasta después de realizado, y que no se pudieron corregir a tiempo para el lanzamiento de Fedora 27.

La única salida que vimos fue revertir los cambios, y eso es lo que hace 4.4.12-12. Sin embargo, como 4.4.12-11 cambió la plantilla de ~/.bashrc, las cuentas de usuario creadas con esa versión no tienen las líneas de inclusión de /etc/bashrc. Los archivos de usuario no pueden tocarse al actualizar el paquete, por el riesgo que eso conlleva y porque puede ser que un usuario haya eliminado esas líneas adrede en su cuenta.

Sentimos mucho las molestias causadas por este problema.

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 dracut-fips instalado. En ese caso el proceso se para muy pronto (cuando se inicia systemd, así que si ve actividad de systemd este no es su caso), y el uso de virtio-rng no sirve de nada, pues aún no se ha cargado. Si se encuentra en esta situación, probablemente lo mejor sea eliminar dracut-fips y ejecutar 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):

La sesión de usuario finaliza si GNOME Shell aborta en Wayland

enlace directo a este elemento - Bugzilla: #1494586 - Bugzilla: #1469129

Una de las diferencias entre GNOME sobre X.org y GNOME sobre Wayland está en lo que ocurre si el propio GNOME Shell falla. Cuando se ejcuta sobre X.org, los fallos severos no suelen finalizar la sesión, GNOME Shell se reinicia automáticamente y la sesión continúa. Normalmente lo que el usuario nota es que el panel y tal vez las ventanas desaparecen y vuelven a aparecer, junto con una notificación de error. Esto es así porque el servidor de pantalla es X.org, con GNOME Shell ejecutándose como una aplicación más sobre el mismo.

Sin embargo en Wayland el propio GNOME Shell es el equivalente a un servidor de pantalla. Por tanto, en caso de fallo severo, toda la sesión muere con él, lo que puede llevar a la pérdida de los datos no guardados.

Se están haciendo grandes esfuerzos en GNOME para separar la parte de compositor del resto de Shell, y hacerla lo más pequeña y fiable posible. Mientras no acabe ese trabajo no hay nada que se pueda hacer desde Fedora.

Durante las pruebas de Fedora 27 ha habido varios informes de fallos severos de GNOME Shell, como #1494586 y #1469129. No estamos seguros de si Shell en Fedora 27 es menos estable que en versiones anteriores, pero parece ser el caso para algunos usuarios y configuraciones. Obviamente, si es usted uno de ellos, perder la sesión por casques frecuentes es muy frustrante.

Nuestra recomendación para los usuarios afectados es que prueben a desactivar las extensiones una a una, para ver si alguna de ellas pudiera ser la causa. Si así fuera, por favor informe al autor de la extensión. Si con eso no es suficiente, considere la posibilidad de usar una sesión Xorg (vea indicaciones más arriba) en lugar de Wayland; con eso al menos evitará que los problemas en GNOME Shell se lleven por delante toda la sesión.

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.

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 clutter-gst2 (aunque algunas aplicaciones podrían depender de éste).

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 colocación de más de dos pantallas no es fiable

enlace directo a este elemento - Bugzilla: #1511638

Actualización disponible en pruebas
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-2017-6d66333885

La herramienta de GNOME para configurar y colocar pantallas (Pantallas) parece no funcionar bien cuando hay más de dos pantallas, incluso si sólo dos están activas (por ejemplo un portátil con dos pantallas externas y con la integrada cerrada). Al intentar cambiar la disposición de las pantallas en la herramienta, estas no cambian o lo hacen pero vuelven rápidamente a la posición inicial.

Algunos de los denunciantes dicen que consiguen el resultado deseado tras varios intentos, o moviendo los monitores de otra forma. También parece que pulsar y soltar una de las pantallas (sin arrastrarla) hace que se aparte y permita el movimiento de las otras.

No se ve el puntero en GDM en máquinas virtuales

enlace directo a este elemento - Bugzilla: #1507931

Al iniciar Fedora 27 Workstation (o cualquier otra Fedora 27 que use GDM) en una máquina virtual con el controlador de vídeo QXL (el predeterminado para virt-manager y Cajas GNOME), no aparecerá el puntero del dispositivo señalador en el gestor de inicio (GDM). Aunque no se muestre, el puntero está presente y activo, si pulsa se ejecutará la pulsación. El puntero sí se mostrará en el escritorio una vez iniciada sesión.

Es sencillo entrar usando sólo el teclado (para acceder con el usuario predeterminado sólo hace falta pulsar 'intro', poner la clave y pulsar 'intro' de nuevo). También puede evitar el problema usando un controlador diferente, como 'virtio'.

A veces no aparece nada en el elemento VPN del menú de estado de GNOME

enlace directo a este elemento - Bugzilla: #1497897

Algunos usuarios de Fedora 27 informan de que en ocasiones no aparecen el texto ni el icono de VPN en el menú de estado de GNOME (el que se abre al pulsar en la zona superior derecha de la pantalla). Normalmente habría un candado con el texto indicando que la VPN no está activa, o información sobre la conexión activa, pero cuando se da el problema la fila está vacía, aunque funciona correctamente.

Aún no hay arreglo, pero no tiene ningún impacto funcional, puede usar la entrada vacía como si el texto estuviera ahí.

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

Fedora 27 puede no arrancar en Surface Book

enlace directo a este elemento - Bugzilla: #1501362

Dos usuarios informan de la imposibilidad de arrancar Fedora 27 en el Surface Book de Microsoft (no está claro el modelo), indicando que puede deberse a una actualización del microcódigo del procesador. Si está intentando instalar o arrancar Fedora 27 en un Surface Book y falla, pruebe a instalar Fedora 26 actualizando después a Fedora 27. También puede probar con una instalación por red de Fedora 27, o usar una de las imágenes vivas no oficiales regeneradas tras el lanzamiento.

La ejecución de máquinas virtuales qemu (virt-manager, gnome-boxes...) con la imagen del disco en una unidad SMB falla con 'Failed to get "write" lock'

enlace directo a este elemento - Bugzilla: #1484130

Si intenta ejecutar iniciar una máquina virtual qemu (eso incluye las de virt-manager y Cajas GNOME en su configuración predeterminada) en Fedora 27 con una imagen de disco que se encuentre en una unidad SMB, fallará con el error 'Failed to get "write" lock'.

Por desgracia la única forma conocida de evitarlo es pasar la imagen al disco local o a otro tipo de unidad de red.

Problemas de aplicaciones

Kerberos no funciona en algunos casos

enlace directo a este elemento - Bugzilla: #1494843

En algunas configuraciones de Fedora 27 Kerberos no funciona, parece que tras actualizar teniendo sssd-kcm instalado. Verá errores del tipo de Internal credentials cache error while getting default ccache. Si está afectado por este problema, puede que borrar el archivo /var/lib/sss/secrets/secrets.ldb y reiniciar ayude.

Problemas de ARM

El archivo de configuración de red de la imagen para AArch64 aparece en las imágenes generadas

enlace directo a este elemento - Bugzilla: #1507676

Se queda un archivo de configuración de red del proceso de creación de imágenes para aarch64 en la imagen generada. Puede eliminarse sin problema para evitar conflictos:

rm /etc/sysconfig/network-scripts/ifcfg-enp1s0

No se puede iniciar sesión en la imagen KDE tras completar Initial-Setup

enlace directo a este elemento - Bugzilla: #1507926

Tras ejecutar la herramienta Initial-Setup en la imagen KDE para armhfp aún tendrá que instalar algunos paquetes para iniciar sesión de escritorio. Conecte al tty2 y entre como root o acceda mediante ssh desde otra máquina, e instale 'KDE plasma desktop':

dnf install plasma-desktop

La clave de root aparece como puesta en el interfaz de texto de Initial-Setup en AArch64

enlace directo a este elemento - Bugzilla: #1507940

Por seguridad la clave de root se 'bloquea' durante la generación de las imágenes de aarch64. La herramienta de configuración inicial cree que se ha puesto una clave y no dice que hace falta introducirla. Los usuarios deberían dar una clave para root o crear una cuenta con permisos de administrador.

No hay red en Pine 64 con las imágenes de AArch64

enlace directo a este elemento

Al arrancar las imágenes AArch64 en el Pine 64 no tendrá conectividad de red. Añada un enlace con nombre 'dtb' al directorio instalado por el núcleo (dtb-4.13.9-300.fc27.aarch64) y reinicie:

cd /boot; ln -sf dtb-4.13.9-300.fc27.aarch64 dtb

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

• 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 fedora-kickstarts), puede que anaconda falle por no poder configurar correctamente el origen de software.

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.