Lonemadmax (talk | contribs) (FreeIPA: migración del almacenamiento de certificados) |
Lonemadmax (talk | contribs) (intel-three-monitors|Inestabilidad y problemas de pantalla al usar tres monitores con GPU Intel|1275770: resuelto) |
||
(5 intermediate revisions by the same user not shown) | |||
Line 59: | Line 59: | ||
== Problemas de actualización == | == Problemas de actualización == | ||
{{Common bugs issue/es| | {{Common bugs issue/es|upgrade-dependency-missing|La actualización desde Fedora 23 falla si no se ha instalado {{package|dnf-plugin-system-upgrade}}|1395686}} | ||
Al actualizar desde Fedora 23 es posible que funcione la preparación de la actualización (el paso {{command|dnf system-upgrade download}}) pero no la actualización (el paso {{command|dnf system-upgrade reboot}}). Esto ocurre si tiene instalado el paquete {{package|python3-dnf-plugin-system-upgrade}} pero no {{package|dnf-plugin-system-upgrade}}. | |||
{{ | El efecto que se observa es que el sistema se inicia pero parece bloquearse. Si pulsa la tecla {{key press|Esc}}, tal vez vea el mensaje {{code|Reached target System Update}}. No habrá información de progreso de la actualización. | ||
Para | 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 | Si tras varias horas no hay ninguna señal de actividad, apague el sistema. Inícielo añadiendo {{code|rd.break}} a los parámetros de arranque, o bien en el modo de rescate, o desde una imagen viva. Después elimine el archivo {{filename|/system-update}} de la raiz de su sistema y vuelva a arrancar normalmente. Instale el paquete {{package|dnf-plugin-system-upgrade}} y ejecute de nuevo el proceso de actualización. | ||
{{Common bugs issue/es|vagrant-upgradepath|No se puede actualizar Vagrant (se ha elimando rubygem-celluloid)|1275030}} | {{Common bugs issue/es|vagrant-upgradepath|No se puede actualizar Vagrant (se ha elimando rubygem-celluloid)|1275030}} | ||
Line 105: | Line 97: | ||
== Problemas de hardware == | == Problemas de hardware == | ||
== Problemas con ARM == | == Problemas con ARM == | ||
== Problemas con Fedora Server == | == Problemas con Fedora Server == | ||
{{Common bugs issue/es|freeipa-upgrade-profiles|FreeIPA no arranca si estaba instalado con Fedora 21 o anterior|1323400}} | {{Common bugs issue/es|freeipa-upgrade-profiles|FreeIPA no arranca si estaba instalado con Fedora 21 o anterior|1323400}} | ||
Line 138: | Line 113: | ||
== Problemas con Fedora Cloud == | == Problemas con Fedora Cloud == | ||
== Otros problemas == | == Otros problemas == | ||
Line 188: | Line 159: | ||
En algunas placas Intel el sistema se reiniciaba tras unos segundos en vez de apagarse. | En algunas placas Intel el sistema se reiniciaba tras unos segundos en vez de apagarse. | ||
{{Common bugs issue/es|system-upgrade-locale|System-upgrade no funciona en chino, japonés, alemán y probablemente otros idiomas|1278031}} | |||
{{Common bugs update released/es|FEDORA-2015-fe6e8b885b}} | |||
{{Common bugs update released/es|FEDORA-2015-45efbec1fe}} | |||
Antes de que se corrigiera este problema, la actualización del sistema fallaba en algunos idiomas, como mínimo chino y japonés. La solución era cambiar a inglés para realizar la actualización y después volver al idioma deseado. Habiéndose resuelto los errores, ya no debería ser necesario. | |||
{{Common bugs issue/es|python-requests-httpd|La interfaz web FreeIPA (y tal vez otras aplicaciones web) no funciona: SELinux evita un acceso 'execmem'|1277224}} | |||
{{Common bugs update released/es|FEDORA-2016-49b6510089}} | |||
Este es un problema complejo que se daba en Fedora 23 con la interfaz web de FreeIPA y puede que otras aplicaciones web escritas en Python. En Fedora SELinux está configurado por defecto para evitar que los procesos de servicios web ejecuten memoria sin protección de escritura (el acceso 'execmem'). Se vio que el uso de la versión que había inicialmente en Fedora 23 del módulo {{package|python-cryptography}} producía muchos accesos de ese tipo. En particular, el popular módulo {{package|python-requests}} carga python-cryptography si el paquete {{package|python-ndg_httpsclient}} está instalado. Este paquete era una dependencia de {{package|python-urllib3}} en Fedora 21, por lo que es habitual tenerlo. | |||
El resultado de todo esto era que era probable que se encontrara con fallos en cualquier aplicación web en Python que usara python-requests si tenía instalado {{package|python-ndg_httpsclient}}. Vería la denegación de acceso 'execmem' de SELinux en los registros del sistema, y probablemente también hubiera mensajes en los registros del servidor web indicando que el proceso había fallado. Afectaba al menos a la interfaz web de FreeIPA (el servidor web intenta continuamente lanzar nuevos procesos, y todos fallan). | |||
Se resolvió con actualizaciones en los paquetes {{package|python-cffi}} y {{package|python-cryptography}}. Si tiene las últimas versiones de estos paquetes no debería estar afectado por este problema. | |||
{{Common bugs issue/es|atomic-bad-tmp-permissions|Las imágenes Atomic tienen permisos incorrectos en el directorio /tmp|1276775}} | |||
{{Common bugs update released/es|FEDORA-2015-dd4760d0fc}} | |||
{{Common bugs update released/es|FEDORA-2015-5f8e9e7d20}} | |||
Los permisos para el directorio {{filename|/tmp}} en las primeras imágenes Atomic de Fedora 23 eran 755, cuando deberían haber sido 777. Esto provocaba problemas a todo lo que quisiera escribir en tmp y no tuviera permisos. Se resolvió con una actualización del paquete {{package|ostree}} con la que además de tener los permisos correctos en las nuevas imágenes, se corrigen los de las instalaciones ya existentes que actualicen el paquete. | |||
{{Common bugs issue/es|upgrade-clean-cache|Se borran los paquetes descargados para la actualización si se realiza alguna transacción de paquetes antes de la actualización|1276886}} | |||
{{Common bugs update released/es|FEDORA-2015-12577}} | |||
Para [[DNF system upgrade/es|actualizar el sistema]] primero es necesario descargar los paquetes y después ejecutar el proceso de actualización. Sin embargo, si realiza con las versiones de DNF anteriores a 1.0.2 cualquier transacción de paquetes entre esas dos acciones (por ejemplo por un problema de dependencias o porque decide instalar o eliminar algún paquete antes de la actualización) se borrará toda la caché de paquetes, y eso incluye los descargados para la actualización de sistema. Si después inicia la actualización obtendrá un mensaje de error que no es que ayude mucho precisamente: {{code|Error: el sistema no está listo para la actualización}}. Tendrá que usar <code>dnf system-upgrade download ...</code> para volver a descargar los paquetes. | |||
El problema se resolvió con DNF 1.0.2, que se incluyó en Fedora 23 en el momento del lanzamiento, y se publicó como actualización para Fedora 22. Por tanto, al actualizar de Fedora 22 a Fedora 23 no debería sufrir este problema si tiene Fedora 22 actualizado, y no debería pasarle nunca al actualizar desde Fedora 23 a otra versión. | |||
Si ya ha hecho la descarga con una versión anterior de DNF y necesita realizar alguna transacción antes de la actualización del sistema, use la opción <code>--setopt=keepcache=True</code> con DNF. De esa forma mantendrá la caché de paquetes y no tendrá que volver a descargarlos. | |||
{{Common bugs issue/es|intel-three-monitors|Inestabilidad y problemas de pantalla al usar tres monitores con GPU Intel|1275770}} | |||
{{Common bugs update released/es|FEDORA-2016-f2f8b12e17}} | |||
Desde la versión 4.2 del núcleo hay varios informes de problemas con unidades gráficas de Intel con tres o más monitores conectados. Pueden ir desde el reinicio del entorno de escritorio a la reconfiguración de la distribución de pantallas, o a que algún monitor no vuelva al estado normal después de entrar en suspensión o bloqueo. | |||
El usuario que abrió la incidencia indica el 2016-05-09 que "Está corregido al menos desde: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64". No hemos recibido nuevas quejas sobre este asunto desde entonces. | |||
[[Category:Spanish translations]] | [[Category:Spanish translations]] |
Latest revision as of 13:19, 4 December 2016
Esta página documenta problemas comunes en Fedora 23 y, si se conocen, correcciones o formas de evitarlos. Dado que los problemas que se listan ya son conocidos, si encuentra el suyo en esta página no lo reporte, a menos que se indique que lo haga. Donde aplica, se incluyen referencias a los informes de Bugzilla.
Notas de lanzamiento
Lea el anuncio de lanzamiento de Fedora 23 y las notas de lanzamiento de Fedora 23 para obtener información específica sobre los cambios en Fedora 23, así como información general.
Mi problema no aparece en la lista
No todos los problemas están en esta página, pero en Bugzilla debería encontrar todos los problemas conocidos. Esta página es una muestra de los problemas que más aparecen en los foros y listas de correo.
Para comprobar si ya se ha informado de su problema, puede buscarlo en Bugzilla. Si nadie lo ha hecho antes, le animamos a que informe de su problema para así mejorar Fedora tanto para usted como para los demás. Se ha preparado una guía sobre informes de errores y peticiones de mejoras para ayudarle.
Si cree que alguno de los errores existentes debe añadirse a esta página por ser bastante común, puede:
- Añadirlo usted mismo, si tiene acceso a edición. Las instrucciones para las páginas de errores comunes le ayudarán a realizar esta adición correctamente, pero lo más importante es asegurarse de que se añade el problema a la lista. No se preocupe si el formato no es exactamente el correcto, eso se puede arreglar después.
- O añadir la palabra clave CommonBugs en el informe de error. Alguien del equipo de aseguramiento de la calidad revisará el informe para ver si debe aparecer como problema común. Para acelerar su solicitud, por favor añada un comentario al informe que incluya:
- 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
Los ficheros Kickstart que incluyen repositorios sólo por nombre no se procesan correctamente
enlace directo a este elemento - Bugzilla: #1277638
Se supone que en una instalación kickstart se pueden activar repositorios presentes en /etc/anaconda.repos.d
que no están activados por defecto (como updates-testing) incluyendo una línea que simplemente indica el nombre del repositorio:
repo --name=updates-testing
Por desgracia la inclusión de una comprobación excesivamente celosa en Fedora 23 se ha cargado esta característica. Si el instalador se ejecuta en modo gráfico, un fichero que la use provocará una parada en la pantalla del concentrador de elementos, con un error en el de ORIGEN DE LA INSTALACIÓN. Si se ejecuta en modo texto, causará una terminación anormal.
Hay una imagen de actualización del instalador con una corrección. Si necesita una línea de ese tipo, puede usar la actualización añadiendo el parámetro inst.updates=https://fedorapeople.org/groups/qa/updates/1277638.img al núcleo al arrancar el instalador. También puede descargar la actualización y usar cualquier otro de los mecanismos de uso disponibles.
El instalador borra la partición de sistema EFI incluso cuando hay otros sistemas instalados
enlace directo a este elemento - Bugzilla: #1183880
Si tiene varios sistemas operativos instalados que usan UEFI para el arranque (arranque desde ESP - EFI System Partition), entra en la pantalla de particionamiento manual del instalador y selecciona para borrar uno de los sistemas, la partición de sistema EFI se borrará también, aunque la necesite alguno de los otros sistemas operativos instalados.
En una instalación de esas características, no seleccione para borrar todo el árbol de particiones bajo el sistema que quiera eliminar. Borre una a una, por separado, todas las particiones del mismo excepto la ESP (y cualesquiera otras que pueda compartir con otros sistemas).
En ocasiones el instalador no calcula correctamente el tamaño mínimo de partición necesario
enlace directo a este elemento - Bugzilla: #1224048
El instalador usa un conjunto de reglas para calcular el tamaño mínimo que necesitan las particiones para que quepa la instalación. Hay casos en los que, si tiene muy mala suerte o está intentando que las particiones sean lo más pequeñas posible, el instalador puede dar por bueno un tamaño insuficiente, con lo que la instalación falla al poco de comenzar, tras la creación y formateo de las particiones.
Para evitar este problema no intente usar tamaños extremadamente pequeños para la partición raíz (ni ninguna otra de sistema, como /usr, si es que define otras). Deje siempre al menos 500 MB libres en esas particiones. De todas formas, en la mayoría de los casos querrá dejar mucho más para un uso normal.
No se pueden descrifar en el arranque los sistemas de archivos con claves que usan caracteres cirílicos, árabes u otros con cambios en la disposición del teclado
enlace directo a este elemento - Bugzilla: #681250
Si la disposición del teclado de consola en su idioma es 'alternada' (usa una combinación de teclas para alternar entre caracteres latinos y los propios), no podrá realizar el cambio al introducir las claves. Por lo tanto sólo podrá usar claves con la disposición del teclado por defecto, que normalmente es la de caracteres latinos.
El sistema arranca con un núcleo antiguo en lugar del último
enlace directo a este elemento - Bugzilla: #1261569
Los sistemas afectados no arrancan con el núcleo actualizado, sino con una versión anterior. Se arregla manualmente cambiando una línea en /etc/sysconfig/kernel de:
DEFAULTKERNEL=b'kernel-core'
a
DEFAULTKERNEL=kernel-core
Además, para cambiar la versión utilizada por defecto sin esperar a la siguiente actualización del núcleo, deberá actualizar el menú de GRUB2.
Las instalaciones de Workstation y desde medios vivos no reconocen dispositivos previos de RAID por software (mdraid)
enlace directo a este elemento - Bugzilla: #1225184
La instalación de Fedora Workstation o desde medios vivos no reconoce los dispositivos de RAID por software (mdraid) que haya de instalaciones previas. Aparecen como "Desconocido" (tamaño 0 bytes) y no se pueden usar en la selección de dispositivos, haciendo imposible la instalación de Fedora 23 manteniendo los datos.
Fedora Server, sin embargo, no muestra este problema, y puede usarse para instalar Fedora Workstation por red.
El problema existe desde Fedora 22 y hay varios informes sobre el mismo aún sin cerrar. Tal vez Fedora Workstation ya no sea la distribución adecuada para sistemas con dispositivos RAID por software.
Problemas de actualización
La actualización desde Fedora 23 falla si no se ha instalado dnf-plugin-system-upgrade
enlace directo a este elemento - Bugzilla: #1395686
Al actualizar desde Fedora 23 es posible que funcione la preparación de la actualización (el paso dnf system-upgrade download
) pero no la actualización (el paso dnf system-upgrade reboot
). Esto ocurre si tiene instalado el paquete python3-dnf-plugin-system-upgrade
pero no dnf-plugin-system-upgrade
.
El efecto que se observa es que el sistema se inicia pero parece bloquearse. Si pulsa la tecla Esc, tal vez vea el mensaje Reached target System Update. No habrá información de progreso de la actualización.
Para asegurarse completamente de que se encuentra en esta situación, espere una cantidad de tiempo considerable (dos o tres horas), por si el sistema realmente se estuviera actualizando, pues reiniciar en medio de una actualización puede dejarlo sistema en un estado inconsistente.
Si tras varias horas no hay ninguna señal de actividad, apague el sistema. Inícielo añadiendo rd.break a los parámetros de arranque, o bien en el modo de rescate, o desde una imagen viva. Después elimine el archivo /system-update
de la raiz de su sistema y vuelva a arrancar normalmente. Instale el paquete dnf-plugin-system-upgrade
y ejecute de nuevo el proceso de actualización.
No se puede actualizar Vagrant (se ha elimando rubygem-celluloid)
enlace directo a este elemento - Bugzilla: #1275030
Se ha eliminado el paquete rubygem-celluloid
en Fedora 23, pero no se ha publicado ninguno para reemplazarlo. Si lo tiene instalado y no usa --allowerasing al actualizar, no se podrán resolver las dependencias. Le recomendamos que use --allowerasing, permitiendo así a DNF eliminar rubygem-celluloid para continuar con la actualización, pero por favor compruebe la lista de paquetes que se eliminarán y asegúrese de que no necesita ninguno.
Problemas de infraestructura
A veces la configuración inicial se ejecuta en modo texto en lugar de en modo gráfico
enlace directo a este elemento - Bugzilla: #1185447
En ocasiones, la herramienta de configuración inicial que se ejecuta en el primer arranque si no se crea ninguna cuenta de usuario durante la instalación, lo hace en modo texto. Aparte de la sorpresa, la herramienta funciona también en modo texto y la pantalla de inicio se mostrará correctamente cuando acabe.
Problemas con GNOME
La creación inicial de usuario lleva a la pantalla de inicio (no al escritorio) y no puede salir a la primera
enlace directo a este elemento - Bugzilla: #1273112 - Bugzilla: #1272706
GNOME incluye su propia herramienta de 'primer arranque', gnome-initial-setup
. Si instala Fedora Workstation y no crea una cuenta de usuario en el proceso de instalación, la herramienta de GNOME se ejecutará en el primer arranque para que lo haga entonces. Al terminar debería llevar directamente al escritorio con la cuenta recién creada, pero en ocasiones lo que se muestra es la pantalla de inicio. Cuando esto ocurre e ingresa usted al sistema, al intentar salir la primera vez vuelve de nuevo al escritorio en lugar de a la pantalla de inicio.
Por lo visto hay un problema de sincronización por el que gnome-initial-setup no daría correctamente el control a la sesión de escritorio que genera, quedándoselo la pantalla de inicio. Cuando después usted entra y sale de su sesión, va a la creada por gnome-initial-session.
Este problema ocurre una sola vez y no tiene más consecuencias. Una vez sale de la segunda sesión todo funciona normalmente.
Problemas con Plasma (KDE)
Problemas de red
No hay conexión de red en máquinas virtuales cuando tanto la máquina virtual como el anfitrión se instalan desde una imagen viva
enlace directo a este elemento - Bugzilla: #1146232
Si instala Fedora desde una imagen viva, crea una máquina virtual e instala también en ella Fedora desde una imagen viva, es probable que la red de la máquina virtual no funcione. La razón es que los rangos de direcciones de red virtual de libvirt son los mismos en anfitrión y máquina virtual, y entran en conflicto. Esto no ocurre si instala después los paquetes libvirt en la máquina virtual manualmente (se detecta en la instalación de paquetes), sólo cuando instala desde medio vivo.
Si no necesita libvirt en la máquina virtual, puede eliminar su red en la misma ejecutando sudo virsh net-destroy default && sudo virsh net-undefine default
y después renovando la conexión en NetworkManager. En caso de usar libvirt en la máquina virtual tendrá que editar los archivos de configuración y asignarla otro rango de IP.
Problemas de hardware
Problemas con ARM
Problemas con Fedora Server
FreeIPA no arranca si estaba instalado con Fedora 21 o anterior
enlace directo a este elemento - Bugzilla: #1323400
Entre Fedora 21 y Fedora 22, FreeIPA pasó de guardar los perfiles de certificados en fichero a una base de datos. Los servidores FreeIPA anteriores a Fedora 22 deben migrar el almacenamiento de fichero a base de datos cuando se actualizan a Fedora 22 o posterior.
Las pruebas indican que esta migración no siempre se lleva a cabo correctamente durante la actualización. Con las versiones de pki-core
tras 10.2.6-12.fc22 (Fedora 22), 10.2.6-16.fc23 (Fedora 23), o 10.3.0.a1-2 (Fedora 24+), este error hace que FreeIPA no arranque correctamente. Con versiones anteriores FreeIPA arrancará, pero algunas operaciones con certificados pueden fallar.
Hay disponible una actualización que corrige el proceso de migración. Si tiene un servidor y todavía no lo ha actualizado a Fedora 22 ni posterior, espere a que se publique el arreglo o bien asegúrese de obtenerlo activando el repositorio updates-testing, para que la migración se realice correctamente.
Si ya actualizó su sistema, no bastará con actualizar el paquete. Puede detectar si está afectado porque el servicio pki-tomcatd@pki-tomcat.service no arranca en la inicialización de FreeIPA. Si ejecuta ipactl -d
, verá varios intentos de conexión a https://(serverhostname):8443/ca/admin/ca/getStatus, todos fallidos.
Si está afectado, primero actualice el paquete: ejecute sudo dnf install yum
y sudo yum-deprecated --enablerepo=updates-testing update --advisory=FEDORA-2016-188c172b10
. Edite el archivo /etc/pki/pki-tomcat/ca/CS.cfg
y cambie subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem por subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem. Para acabar, ejecute sudo ipa-server-upgrade
.
Problemas con Fedora Cloud
Otros problemas
Problemas resueltos
FreeIPA no se actualiza correctamente
enlace directo a este elemento - Bugzilla: #1274905
Si actualiza un sistema con FreeIPA a Fedora 23, FreeIPA no se ejecutará en el sistema actualizado. Los registros indicarán que hay que ejecutar el procedimiento de actualización: Upgrade required: please run ipa-server-upgrade command. Sin embargo, si se ejecuta el comando que se distribuyó con los paquetes originales de Fedora 23, no funcionará y FreeIPA seguirá sin arrancar.
Le recomendamos que active el repositorio updates cuando actualice servidores FreeIPA a Fedora 23, y que se asegure de que las actualizaciones indicadas anteriormente están incluidas.
Si ejecutó el guion de actualización antes de que las correcciones estuvieran disponibles y se topó con los errores, tal vez pueda conseguir que FreeIPA funcione de la siguiente forma (no todo el que lo ha probado lo ha conseguido):
- Edite
/etc/dirsrv/slapd-(DOMAIN)/schema/99user.ldif
- Busque la entrada que comienza por: attributeTypes: ( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey' (está distribuida en tres líneas)
- Cámbiela por:
attributeTypes: ( 2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey' DESC ' IPA vault public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.1 21.1.40 X-ORIGIN ( 'IPA v4.2' 'user defined' ) )
- Ejecute
pki-server migrate --tomcat 8
- Ejecute
systemctl start pki-tomcatd@pki-tomcat.service
- Vuelva a ejecutar el guion de actualización:
ipa-server-upgrade
Algunos temas de plymouth dan problemas durante la actualización
enlace directo a este elemento - Bugzilla: #1267949
Algunos temas de plymouth (la pantalla de arranque) tenían un comportamiento erróneo en el entorno de actualización del sistema. Los problemas conocidos se daban en los temas script y spinner. Para el primero, la información de progreso se salía de la pantalla y no se desplazaba para hacerse visible. Con el segundo la pantalla se quedaba completamente en negro durante la actualización. En ambos casos no había información de progreso y parecía que se había producido un cuelgue, pero no era así y en realidad, si se dejaba, la actualización se ejecutaba correctamente. Si actualiza sin haber aplicado las correcciones y usa esos temas, no fuerce un reinicio ni apague el dispositivo; tenga paciencia y espere a que la actualización termine y se reinicie automáticamente.
Tras instalar la corrección puede ejecutar sudo dracut -f para regenerar el disco de arranque. Si no lo hace, el arreglo sólo empezará a tener efecto a partir de la siguiente actualización del núcleo.
También puede cambiar al tema por defecto antes de empezar la actualización:
sudo dnf install plymouth-theme-charge sudo plymouth-set-default-theme charge sudo dracut -f
Denegación de acceso de SELinux al fallar una aplicación
enlace directo a este elemento - Bugzilla: #1276305
Había un problema en las políticas de SELinux en Fedora 23 que provocaba una denegación de acceso cuando fallaba una aplicación. SELinux estaba impidiendo que la herramienta de informes ABRT hiciera algo que necesitaba hacer para analizar el fallo. El mensaje era del estilo de SELinux está evitando que abrt-hook-ccpp use accesos 'sigchld' sobre un proceso.
El sistema reinicia en lugar de apagarse
enlace directo a este elemento - Bugzilla: #1257131
En algunas placas Intel el sistema se reiniciaba tras unos segundos en vez de apagarse.
System-upgrade no funciona en chino, japonés, alemán y probablemente otros idiomas
enlace directo a este elemento - Bugzilla: #1278031
Antes de que se corrigiera este problema, la actualización del sistema fallaba en algunos idiomas, como mínimo chino y japonés. La solución era cambiar a inglés para realizar la actualización y después volver al idioma deseado. Habiéndose resuelto los errores, ya no debería ser necesario.
La interfaz web FreeIPA (y tal vez otras aplicaciones web) no funciona: SELinux evita un acceso 'execmem'
enlace directo a este elemento - Bugzilla: #1277224
Este es un problema complejo que se daba en Fedora 23 con la interfaz web de FreeIPA y puede que otras aplicaciones web escritas en Python. En Fedora SELinux está configurado por defecto para evitar que los procesos de servicios web ejecuten memoria sin protección de escritura (el acceso 'execmem'). Se vio que el uso de la versión que había inicialmente en Fedora 23 del módulo python-cryptography
producía muchos accesos de ese tipo. En particular, el popular módulo python-requests
carga python-cryptography si el paquete python-ndg_httpsclient
está instalado. Este paquete era una dependencia de python-urllib3
en Fedora 21, por lo que es habitual tenerlo.
El resultado de todo esto era que era probable que se encontrara con fallos en cualquier aplicación web en Python que usara python-requests si tenía instalado python-ndg_httpsclient
. Vería la denegación de acceso 'execmem' de SELinux en los registros del sistema, y probablemente también hubiera mensajes en los registros del servidor web indicando que el proceso había fallado. Afectaba al menos a la interfaz web de FreeIPA (el servidor web intenta continuamente lanzar nuevos procesos, y todos fallan).
Se resolvió con actualizaciones en los paquetes python-cffi
y python-cryptography
. Si tiene las últimas versiones de estos paquetes no debería estar afectado por este problema.
Las imágenes Atomic tienen permisos incorrectos en el directorio /tmp
enlace directo a este elemento - Bugzilla: #1276775
Los permisos para el directorio /tmp
en las primeras imágenes Atomic de Fedora 23 eran 755, cuando deberían haber sido 777. Esto provocaba problemas a todo lo que quisiera escribir en tmp y no tuviera permisos. Se resolvió con una actualización del paquete ostree
con la que además de tener los permisos correctos en las nuevas imágenes, se corrigen los de las instalaciones ya existentes que actualicen el paquete.
Se borran los paquetes descargados para la actualización si se realiza alguna transacción de paquetes antes de la actualización
enlace directo a este elemento - Bugzilla: #1276886
Para actualizar el sistema primero es necesario descargar los paquetes y después ejecutar el proceso de actualización. Sin embargo, si realiza con las versiones de DNF anteriores a 1.0.2 cualquier transacción de paquetes entre esas dos acciones (por ejemplo por un problema de dependencias o porque decide instalar o eliminar algún paquete antes de la actualización) se borrará toda la caché de paquetes, y eso incluye los descargados para la actualización de sistema. Si después inicia la actualización obtendrá un mensaje de error que no es que ayude mucho precisamente: Error: el sistema no está listo para la actualización. Tendrá que usar dnf system-upgrade download ...
para volver a descargar los paquetes.
El problema se resolvió con DNF 1.0.2, que se incluyó en Fedora 23 en el momento del lanzamiento, y se publicó como actualización para Fedora 22. Por tanto, al actualizar de Fedora 22 a Fedora 23 no debería sufrir este problema si tiene Fedora 22 actualizado, y no debería pasarle nunca al actualizar desde Fedora 23 a otra versión.
Si ya ha hecho la descarga con una versión anterior de DNF y necesita realizar alguna transacción antes de la actualización del sistema, use la opción --setopt=keepcache=True
con DNF. De esa forma mantendrá la caché de paquetes y no tendrá que volver a descargarlos.
Inestabilidad y problemas de pantalla al usar tres monitores con GPU Intel
enlace directo a este elemento - Bugzilla: #1275770
Desde la versión 4.2 del núcleo hay varios informes de problemas con unidades gráficas de Intel con tres o más monitores conectados. Pueden ir desde el reinicio del entorno de escritorio a la reconfiguración de la distribución de pantallas, o a que algún monitor no vuelva al estado normal después de entrar en suspensión o bloqueo.
El usuario que abrió la incidencia indica el 2016-05-09 que "Está corregido al menos desde: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64". No hemos recibido nuevas quejas sobre este asunto desde entonces.