Common F24 bugs/es

In other languages: čeština (cs) English (en) español (es) [edit]

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

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 operativs) 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 24 se ofrecerá en cada actualización del sistema, y tendrá que excluirla manualmente cada vez.

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

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 no reconoce los volúmenes OS X con Apple Core Storage, 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 OS X (Apple Core Storage), 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 indica 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 de OS X.

No se reconocen los dispositivos lógicos LVM de un volumen físico cifrado tras proporcionar la clave

enlace directo a este elemento - Bugzilla: #1348688

Debido a problemas con la nueva API DBus de LVM, el instalador no llega a enterarse de la configuración LVM sobre volúmenes físicos cifrados (LUKS) cuando se hacen accesibles tras proporcionar la clave.

Imagen actualizada disponible
Se ha publicado una actualización del instalador que resuelve este problema. Para usarla, pulse e o Tab ⇆ en el menú de arranque del instalador, entrando así a editar las opciones de arranque, y añada: inst.updates=http://vpodzime.fedorapeople.org/1348688_updates.img

No parece que se dé este problema en las imágenes vivas (al menos en la de Fedora Workstation).

No se reconocen los dispositivos de RAID por software (mdraid) al instalar desde la edición viva de Fedora Workstation

enlace directo a este elemento - Bugzilla: #1225184

Durante la instalación desde la imagen viva de Fedora Workstation no se reconocen los dispositivos preexistentes de RAID por software (mdraid). Aparecen como "Desconocido" (tamaño 0 bytes) y no se pueden usar en la selección de dispositivos, con lo que no es posible instalar Fedora 24 sobre los mismos ni mantener sus datos.

Este problema existe desde Fedora 22; se han enviado varios informes a Bugzilla, pero aún no se ha solucionado.

La imagen Server no sufre este problema y puede usarse en caso de necesidad, haciendo una instalación mínima y usando después dnf para instalar los paquetes del grupo "Workstation" por red. El resultado no es exactamente el mismo que con la instalación desde la imagen Workstation y posteriormente pueden ser necesarios pequeños ajustes manuales.

Problemas de actualización

Los paquetes de rpmfusion impiden la actualización de Fedora

enlace directo a este elemento

En el momento del lanzamiento, los paquetes de rpmfusion estaban bloqueando las actualizaciones con un mensaje del estilo de:

Error: El paquete a52dec-0.7.4-19.fc24.x86_64.rpm no está firmado

Se trataba de un problema en un repositorio externo sobre el que Fedora no tiene ningún control. Desde mediados de julio los paquetes ya están firmados.

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

enlace directo a este elemento - Bugzilla: #1395686

Al actualizar desde 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

DNF 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 24.

Ya está corregido en Fedora 24 (desde libhif-0.2.2-3.fc24) y Fedora 23 (desde libhif-0.2.2-3.fc23). El uso futuro de PackageKit debería ser seguro. Sin embargo, si lo ha usado en el pasado debería corregir las marcas antes de empezar a usar DNF:

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.

X falla cuando se actualiza systemd-udev en sistemas con varios adaptadores gráficos (gráficos híbridos)

enlace directo a este elemento - Bugzilla: #1341327 - Bugzilla: #1378974

Corrección publicada
Se ha publicado una actualización que resuelve el problema. Sin embargo, dado que el problema se manifiesta antes de que pueda actualizar el sistema, tal vez tenga que aplicar las medidas indicadas para sortearlo.

Si su sistema incluye varios dispositivos gráficos (como los portátiles con 'gráficos híbridos') y actualiza el paquete systemd-udev con el sistema X en ejecución, es muy probable que X falle.

Esto puede provocar un problema grave si está ejecutando la actualización desde las propias X (por ejemplo, desde un terminal en el escritorio). El cuelgue de X se llevará por delante el proceso de actualización sin haber terminado este, pudiendo dejar la base de datos de paquetes en un estado inconsistente difícil de arreglar, con consecuencias variables dependiendo del momento en el que muriera el proceso.

El fallo ocurre al reiniciar el servicio systemd-udev-trigger.service, por lo que cualquier otra acción que lo haga puede provocar el mismo problema.

En general siempre se ha recomendado no actualizar desde un terminal gráfico. La forma segura de realizar actualizaciones en Fedora es el 'modo desconectado', que antes de aplicar los cambios reinicia en un entorno mínimo y exclusivo, y después vuelve a reiniciar al entorno habitual.

Si actualiza mediante la aplicación GNOME Software o pulsando en la notificación automática de 'reiniciar para instalar actualizaciones', ya está usando el 'modo desconectado' y no le afecta este problema.

En otro caso, puede hacerlo de la siguiente manera:

sudo pkcon refresh force && \
sudo pkcon update --only-download && \
sudo pkcon offline-trigger && \
sudo systemctl reboot

Si no quiere usar el método sin conexión, le recomendamos hacer las actualizaciones desde la consola y no desde una aplicación de terminal gráfica. Pulse Ctrl+Alt+F3, identifíquese y actualice. Si sigue con X, estas fallarán al actualizar el paquete systemd-udev, pero el proceso de actualización continuará sin problemas.

Se ha publicado una actualización para resolver este problema, pero debido a cómo sucede, esa misma actualización puede provocarlo, y sólo lo evitará para las actualizaciones posteriores. Debe tener cuidado al actualizar al menos hasta que haya instalado systemd-229-16.fc24, pero siempre es mejor seguir las indicaciones dadas aquí al realizar actualizaciones.

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 GNOME

Las actualizaciones fuera de línea en GNOME dejan de funcionar tras instalar Google Chrome

enlace directo a este elemento - Bugzilla: #1344643

Si instala Google Chrome, intentará instalar una clave GPG para su repositorio, pero no podrá. Con esto se estropea la funcionalidad de "actualización fuera de línea" de GNOME Software, el modo en el que las actualizaciones se instalan durante un reinicio. No hay problema con DNF, que simplemente pedirá confirmación de la clave GPG en la siguiente actualización de google-chrome.

Para arreglar esto tendrá que confirmar la clave del repositorio de google-chrome. Puede hacerlo con DNF al actualizar google-chrome:

$ sudo dnf update 'google-chrome*'

También puede descargar la clave e importarla a la base de datos de RPM, sin necesidad de esperar a una actualización de google-chrome:

$ curl -O 'https://dl.google.com/linux/linux_signing_key.pub'
$ sudo rpmkeys --import ./linux_signing_key.pub

Los cambios de configuración de red hechos desde la configuración de GNOME no siempre se aplican inmediatamente

enlace directo a este elemento - Bugzilla: #1344788

Puede que los cambios de configuración de red hechos en la configuración de GNOME (control-center) no surtan efecto tras pulsar el botón Aplicar. Apague la conexión y vuelva a encenderla para que se cargue la nueva configuración.

Una de las opciones afectadas es "Usar esta conexión sólo para los recursos en su red", que se puede usar cuando uno quiere usar normalmente la red inalámbrica, pero conectarse por cable a los equipos de la red local.

Problemas de Plasma (KDE)

Caída de Plasma al cambiar usuarios en máquinas virtuales cuando se usa el controlador QXL

enlace directo a este elemento - Bugzilla: #1293167

Si intenta cambiar de usuario en Plasma desde una máquina virtual que use el controlador QXL, es probable que Plasma falle. No parece que ocurra con otros controladores de vídeo ni en máquinas reales (que no usan QXL). La solución es usar otro controlador.

Problemas de aplicaciones

Firefox ya no usa gstreamer para H264, sino ffmpeg

enlace directo a este elemento - Bugzilla: #1331496

Desde Firefox 46, éste ya no usa gstreamer para la reproducción de formatos multimedia que no son libres (en general H264), sino ffmpeg. En lugar de gstreamer1-libav, ahora necesita tener instaladas ffmpeg-libs si quiere reproducir ese contenido en Firefox. Tenga en cuenta que ffmpeg no se distribuye con Fedora y debe obtenerlo e instalarlo usted mismo si quiere usarlo.

Docker no ejecuta nada si se ha usado alguna vez docker-1.10.3-3

enlace directo a este elemento - Bugzilla: #1322909

Se ha informado de un problema en docker-1.10.3-3 que tiene como resultado que no se puede usar docker. El problema continúa aunque se actualice docker. Se corrige parando docker, eliminando el directorio /var/lib/docker e instalando una nueva versión de docker. Los usuarios de agrupaciones disgregadas de lvm tendrán que regenerarlas debido al borrado de /var/lib/docker. Más información en RHBZ1322909#c21.

Problemas de ARM

bananapi: no se puede arrancar mediante pxe

enlace directo a este elemento - Bugzilla: #1329613

Algunos usuarios tienen problemas con la instalación gráfica mediante PXE en Banana Pi. Probablemente se deba a problemas de memoria cuando 1G de RAM no es suficiente. La solución es añadir inst.text a la línea de ejecución del núcleo y hacer la instalación en modo texto, o bien instalar el sistema mediante VNC.

Problemas de Fedora Server

FreeIPA no arranca si estaba instalado con Fedora 21 o anterior

enlace directo a este elemento - Bugzilla: #1323400

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.

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

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

Se ha publicado una actualización que corrige el proceso de migración. Si tenía un servidor con Fedora 21 y esperó a esa corrección para actualizarlo, no debería estar afectado por este problema.

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

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

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)

Problemas resueltos

Fedora Media Writer no muestra el progreso de escritura en Fedora 22

enlace directo a este elemento - Bugzilla: #1328462

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

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

Al usar una versión antigua de Fedora Media Writer (antes liveusb-creator) en Fedora 22 para generar un USB de arranque, no se mostraba información de progreso durante la escritura del dispositivo. Había que esperar hasta que saliera el aviso de finalización. Este problema se resolvió con la versión 3.93.2; que salió para Fedora 22 el 2016-04-26. El 2016-06-23 se publicó la 3.95.2.

La instalación de KDE (excepto desde su imagen viva específica) instala también Cinnamon

enlace directo a este elemento - Bugzilla: #1349743

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

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

Debido a ciertas interacciones entre las definiciones de grupos de paquetes y el resolutor de dependencias libsolv, al instalar el conjunto KDE desde una imagen que no fuera la viva de KDE o bien tras la instalación inicial con sudo dnf groupinstall kde-desktop-environment o similar, además de KDE también se instalaba Cinnamon.

Debería estar resuelto desde aproximadamente septiembre de 2016 en las instalaciones por red y al instalar el grupo kde-desktop-environment en sistemas existentes. Si estuvo afectado por este problema, los paquetes extras no se desinstalarán automáticamente, deberá eliminarlos manualemnte si así lo desea.