Conflicto entre paquetes tras un fallo en la actualización del sistema con dnf

En los últimos días he tenido dos problemas que me han traído —un poco, tampoco hay que exagerar— por la calle de la amargura. Uno ya está solucionado y hablaremos de ese. Al segundo aun le estoy dando vueltas.

El viernes 16 de julio lancé la orden de actualización

su -c 'dnf -y update'

    passwd

y cuando empezaba a actualizar el sistema saltó. Bien, no le dí más importancia y al reiniciar el sistema intenté actualizar de nuevo y me apareció este mensaje, cortando la actualización,

...

Ejecutando verificación de operación
Verificación de operación exitosa.
Ejecutando prueba de operaciones
Los paquetes descargados se han guardado en caché para la próxima transacción.
Puede borrar los paquetes de la caché ejecutando 'dnf clean packages'.
Error: Error de prueba de transacción:
  el archivo /usr/share/doc/libdrm/README.rst de la instalación de libdrm-2.4.107-1.fc34.i686 entra en conflicto con el archivo del paquete libdrm-2.4.105-1.fc34.x86_64
  el archivo /usr/share/libdrm/amdgpu.ids de la instalación de libdrm-2.4.107-1.fc34.i686 entra en conflicto con el archivo del paquete libdrm-2.4.105-1.fc34.x86_64
  el archivo /etc/odbcinst.ini de la instalación de unixODBC-2.3.9-3.fc34.i686 entra en conflicto con el archivo del paquete unixODBC-2.3.9-2.fc34.x86_64
  el archivo /usr/share/doc/unixODBC/README.dist de la instalación de unixODBC-2.3.9-3.fc34.i686 entra en conflicto con el archivo del paquete unixODBC-2.3.9-2.fc34.x86_64
  el archivo /usr/share/doc/pango/NEWS de la instalación de pango-1.48.7-1.fc34.i686 entra en conflicto con el archivo del paquete pango-1.48.5-1.fc34.x86_64
  el archivo /usr/share/man/man1/pango-view.1.gz de la instalación de pango-1.48.7-1.fc34.i686 entra en conflicto con el archivo del paquete pango-1.48.5-1.fc34.x86_64

Es decir, libdrm-2.4.107, unixODBC-2.3.9 y pango-1.48.7 habían quedado como duplicados y se cortaba la actualización.

Mi primer intento instintivo fue instalar esos paquetes por encima,

su -c 'dnf install libdrm-2.4.107 unixODBC-2.3.9 pango-1.48.7'

pero esa orden me daba un mensaje similar. Intenté con --allowerasing y luego--skip-broken, pero nada. Como había muchas cosas que hacer lo dejé correr y estuve trabajando sin actualización. Ayer por la noche, 25 de julio, día de Santiago, con más tiempo libre, decidí mirar por la red una solución. A la primera salió (véase aquí). La primera idea era la buena, pero estaba mal escrita. La solución es REinstalarlo de nuevo. O sea,

su -c 'dnf reinstall libdrm'

su -c 'dnf reinstall pango'

Sin embargo, no funcionó con 

su -c 'dnf reinstall unicODBC', seguía diciendo que chocaban entre unixODBC-2.3.9-3.fc34.i686 y unixODBC-2.3.9-2.fc34.x86_64 y esta no quedó más remedio que escribir

su -c 'dnf reinstall unicODBC-2.3.9-3'

Y listo, ya se pudo actualizar.

El segundo problema es más extraño. De repente, la BIOS de uno de mis ordenadores ha dejado de reconocer el ssd que contiene el sistema como unidad de arranque, con lo que ese ordenador arranca siempre en la BIOS y tengo que decirle por donde tiene que arrancar. Al intentar decirle a la BIOS el orden de los dispositivos, ese no aparece para reconfigurarlo y tengo que recurrir al F8 en cada arranque. Pero eso será otra historia, si encuentro la solución.

Actualizando a Fedora 34 por terminal

[ACTUALIZACIÓN] El problema del icono de Dropbos ya está solucionado (27 de mayo, kernel 5.12.6)

Durante esta semana he instalado Fedora 34 en mis tres ordenadores de uso diario. Esta vez he realizado una actualización por terminal, que ha funcionado en los tres. Las instrucciones para hacerlo están en esta página, por si lo necesitáis.

Primero actualicé el portátil, mientras estaba trabajando con otras cosas en otro ordenador, por lo que no fui atendiendo a los diferentes pasos, tiempos... Era una prueba inicial para ver como iba todo. Una vez terminado, actualicé el principal de casa y luego el del trabajo. Estos sí que los fui controlando y vamos a exponer la tabla de tiempos. El ordenador de casa tiene ya 9 años, con una placa Intel DZ77BH-55K, i7-3770, 24GB RAM DDR3 1600 y discos sdd (sistema WD 250GB y home Samsung 860 2TB. El del trabajo es más moderno, algo más de 4 años, con una placa ASUS X99-A, i7-6850K, 64 GB RAM DDR4 PC2400 y dos discos m2 WD Black de 512GB sistema y 1 TB home). Teóricamente, debido a la diferencia de equipo, debiera terminar mucho antes el del trabajo. Veremos:

ACCIÓN	CASA	TRABAJO
Actualización (dnf upgrade --refresh)	7:10h	13:00h
Instalación plugin (dnf install dnf-plugin-system-upgrade)	7:12h	13:06h
Descarga paquetes (dnf system-upgrade download --releasever=34)	7:13h	13:08h
Repetición añadiendo --allowerasing	7:14h (3205 paquetes; 3,9GB)	13:19h (3220 paquetes, 3,9GB)
Aceptar llave Fedora 34	7:18h	13:28h
Reinicio y actualización (dnf system-upgrade reboot)	7:21h	13:30h
Limpiando	7:36h	13:42h
Scriptlets (tiempo necesario sobre todo en Selinux)	7:41h	13:47h
Verificación	7:45h	13:50h
Fin	7:51h	13:56h
TOTAL	41minutos	56 minutos

En primer lugar, la única dificultad, que exigió --allowerasing en los tres ordenadores fue un problema entre iptables y una librería. Todo queda solucionado actualizando los paquetes al terminar la instalación. Al actualizar todo queda configurado y en marcha, salvo las extensiones. Muchas dejan de funcionar, y algunas no son necesarias, por ejemplo la desactivación de la esquina superior izquierda se puede deshabilitar en retoques (por lo que podemos prescindir de No Topleft hot corner, por ejemplo).

Otras no funcionan. Por ejemplo Topiconsplus puede ser sustituida por TopIcons Fix, pero lo que me importaba, el icono de Dropbox, no se puede ver ni manejar (por ahora, espero). La instalación es sencilla, rápida y Fedora 34 va como la seda. Recomendable cambiar a 34, con el nuevo gnome y algunas sorpresas.

La segunda cuestión es la "carrera" entre los ordenadores. Si bien es cierto que en la primera parte, la que depende de la red, el de casa solo necesitó 11 minutos (más actualizado y una red de 500Mbits toda para él), frente a los 30 minutos del ordenador de trabajo (red con mayor capacidad, pero decenas de ordenadores trabajando sobre el mismo armario de reparto), la segunda parte me ha sorprendido mucho. La actualización y sustitución de paquetes ha supuesto para el de casa 30 minutos, frente a los 24 del otro. Sorprende gratamente la capacidad de trabajo de un ordenador hasta cierto punto obsoleto. Y no, no hay grandes diferencias en el software actualizado, por que uso el mismo software en casa y el trabajo, salvo emule. En mi mente estaba la idea de cambiarlo, y hasta ahora se había salvado por el precio tan alto de algunos componentes, debido a tanto minero sacando bitcoins. Pues ahora pienso mantenerlo hasta que ya no sea capaz de hacer algo imprescindible para mi. Me conformaré con ponerme un monitor de 27 pulgadas, 4k y a 144Hz.

Actualización a Fedora 31 por comandos. Esta vez sí

Esta vez, al contrario que cuando lo intenté para hacer el salto Fedora 29 a 30, todo ha ido como la seda. Los mismos comandos de siempre:

su - # Terminal  en administrador para evitar teclear demasiado

dnf upgrade --refresh # Actualización del sistema (reboot, por que cambió kernel...)

dnf install dnf-plugin-system-upgrade # Plugin de actualización

dnf system-upgrade download --releasever=31 # Inicia la actualización y baja el software

dnf system-upgrade reboot # Reinicia y actualiza todo

Dos ordenadores; el primero alrededor de 2890 paquetes, 4,4GB, bajo los paquetes en 7 minutos (11MB/s, aproximadamente) y el segundo más de 2900 paquetes, 4,3 GB en 3 minutos y 20 segundos (23MB/s). Luego el primero tardó un total de 30 minutos en terminar toda la actualización. El segundo, a sabiendas de que iba a tardar más, por que es más viejo y lento, lo dejé con los comandos enlazados (&& si y solo si ha terminado bien el primero, ejecuta el segundo)

dnf system-upgrade download --releasever=31 && dnf system-upgrade reboot

y lo deje a su aire, con lo que no medí el tiempo. Los dos arrancan bien y el único defecto son algunas extensiones de gnome

y que no hay manera de ver el icono de Dropbox en el panel superior.

Solo me falta el portátil. Si hay alguna variación, actualizaré la entrada.

Ventajas: rápido, fácil, software instalado, no hay que modificar configuraciones...
Inconveniente: con lo que nos divierte instalar desde cero, particionar discos, faltarle al respeto a los programadores...
Sin un solo fallo. Casi vale la pena aplicar la actualización grafica para dummies en la aplicación software.

[ACTUALIZACIÓN:] El portátil igual de bien

Actualización de Fedora 28 a 29... pero por terminal

Siguiendo las indicaciones de Fedora Magazine, hoy he actualizado Fedora 28 a 29. Eso si, al contrario de su primera indicación, de realizarlo sobre Software, he preferido hacerlo en el terminal, con los comandos habituales desde la primera vez:

su -c 'dnf upgrade --refresh'
su -c 'dnf install dnf-plugin-system-upgrade'
# su -c 'dnf system-upgrade download --releasever=29' Este comando necesito ser:
su -c 'dnf system-upgrade download --allowerasing --releasever=29'
su -c 'dnf system-upgrade reboot'

Ese allowerasing se debe a una incompatibilidad de vlc y una librería. Al acabar la actualización simplemente he instalado vlc. Ejecuté los comandos en unos minutos y lo dejé reiniciando mientras comía.
Listo.
PD. Lo único que me falta son un montón de fondos de pantalla que tendré que volver a poner (o no).

Cuando se acaba la batería en el medio de la actualización

Es la primera vez que me pasa algo así. Tengo un portátil que uso en mi trabajo, y como en general dispongo de aulas con equipos fijos, y para que no se vea diferente a los que ven los alumnos —Linux vs. Windows—, rara vez lo uso. Aun así lo suelo llevar como equipo de reserva, por si falla algo. Como tenía la intención de probar todo en todos los sistemas, me puse a actualizar el portátil para luego actualizarlo a Fedora 27 mediante dnf. El problema es que el enchufe libre está al otro lado de la mesa, y mientras estaba trabajando con más equipos, me olvidé de enchufarlo. Debido a su edad, esta batería solo tiene carga para 45 minutos, y entre una cosa y otra en al medio de una actualización de más de 700 paquetes se acabó la batería. Al reiniciar el ordenador —esta vez enchufado—, y ejecutando otra vez el comando de actualización previa al cambio a Fedora 27

su -c 'dnf -y upgrade --refresh'

la respuesta fue múltiples líneas de

el archivo X de la instalación de X-2.3.5-2.fc26.i686 entra en conflicto con el archivo del paquete X-2.3.4-5.fc26.x86_64

Es común que aparezcan estos conflictos  de las versiones 32 y 64 bits, pero por qué al actualizarse. ¿No debieran haber entrado las versiones de 64 bits similares a las anteriores? ¿Es un problema de que no ha dado tiempo a eliminar por que se ha cortado en el medio?
La reparación es la eliminación de la versión i686, pero en este caso hablamos de mas de 200 paquetes duplicados, con lo que habría que repetir un comando más de 200 veces con un resultado final incierto; se acaba antes instalando de nuevo. Los pasos siguientes fueron:

1. Primero intentamos detectar los duplicados y eliminarlos luego en una sola orden:

# dnf repoquery --duplicated
# dnf remove $(dnf repoquery --duplicated)

pero no fue posible por que nos daba un error de salida

Error:
 Problema 1: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 2: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 3: The operation would result in removing the following protected packages: dnf, kernel-core, sudo

Es decir, no nos dejaba eliminar paquetes protegidos

2. Intentar la eliminación tratando de quitar la protección a esos paquetes, orden con resultado incierto:

# dnf --disableplugin=protected_packages remove $(sudo dnf repoquery --duplicated)

pero nos devolvía el mismo error:
Error:
 Problema 1: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 2: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 3: The operation would result in removing the following protected packages: dnf, kernel-core, sudo

3. Intenté la actualización con las opciones --allowerasing y luego --best

# dnf update --allowerasing
# dnf update --best

pero el comando enseñaba la misma colección de conflictos que upgrade

4. Intento baldío de ejecutar un distro-sync

# dnf distro-sync

por que nos respondía con los mismos conflictos

5. Intento baldío también de volver hacia atrás los ficheros duplicados con downgrade

# dnf downgrade $(dnf repoquery --duplicated)

con respuestas como esta para todos los duplicados

Hay paquetes para LibRaw-0:0.18.5-1.fc26.x86_64, pero no instalados.
Ya está instalada la versión más baja del paquete LibRaw, no se puede revertir.

6. Sustitución mediante rpm de los ficheros duplicados

# rpm -Uvh --replacefiles $(dnf repoquery --duplicated)

y es todos los paquetes aparecía la misma respuesta de error

error: la apertura de PAQUETE-x.fc26.x86_64 falló: No such file or directory

7. Antes de rendirnos a una instalación nueva y limpia de Fedora 27 recurrí a la opción que mostraba software de actualizarse a la versión 27 de manera gráfica. Parecía funcionar:

Pero al reiniciar el ordenador el sistema mostró una pantalla en negro con el cursor del ratón congelado y de ahí no volvió a salir.

Resultado final, instalación limpia de Fedora 27 desde dispositivo USB de 2GB. Esta vez, debido a la antigüedad del ordenador, sin necesidad de UEFI; 1 hora y todo listo.

PD. Y no los 5 días de instalación de un Windows 7 que he tenido desde el jueves de la semana pasada; 2 o 3 horas de instalación, 5 días de actualización. Cuando estaba por el reinicio número 20, y amenazando con 14 actualizaciones más ya le dije al compañero que se lo llevara y que lo acompañara en sus sentimientos.

Algunas maravillas desconocidas de dnf: dnf info

Hay una pregunta continua en el uso del terminal, ¿cómo sé si tengo instalado una librería o programa? La respuesta es muy sencilla, dnf info

Por ejemplo, cada vez que instalo una distribución de Fedora dudo si tengo nano, así que

dnf info nano

y la respuesta es

Sabemos así si está instalado o no, como señalan las líneas rojas. Pero el programa tiene una información adicional muy interesante cuando estamos instalando alguna librería y no sabemos para que es, o si dudamos cual es la función de un programa. Por ejemplo,

dnf info octave

octave es un programa que nos permite hacer en software libre lo que matlab en privativo. Bien clarito que lo explica.
Cuando tengamos que instalar algo, por ejemplo en un infierno de dependencias o una recomendación de la que no estamos seguros, la primera vía para conoce lo que es cada paquete es el último párrafo de dnf info paquete.

Cada día me gusta más dnf. De hecho, solo actualizo con dnf.

Fedora 26 Beta liberada

y en estos momentos estoy actualizando el portátil utilizando dnf system upgrade (ver aquí y aquí). Siempre experimentos con gaseosa. Si funciona bien, como siempre, actualizaré todos, incluido el principal, en el que estoy teniendo un problema con vlc desde la última actualización.

[ACTUALIZACIÓN]: Como suele pasar siempre, el portátil perfecto, a pesar de que hubo que aplicar allowerasing (14 paquetes eran incopatibles). Mi ordenador de trabajo, el más potente, se actualizó a gran velocidad y ... NO ARRANCÓ. Tuve que instalar desde una versión live, por que desde netinst fue imposible leer los espejos. El de casa, la joya de la corona, esperará hasta versión estable.

[ACTUALIZACIÓN 2]: No me he podido controlar y he actualizado también el de casa. 30 minutos y listo.

[ACTUALIZACIÓN 3]: los dos sobremesas que utilizo habitualmente se están comportando de manera diferente. El de mi despacho, instalado 26 beta desde un DVD con la imagen de versión live funciona perfectamente y no me ha dado ningún fallo destacable; este ordenador está encendido de lunes a viernes y con 6-8 horas de uso diario. El de mi casa, encendido de forma continua, y con 2 o 3 horas de uso personal, ya ha tenido dos saltos de gnome-shell que ha supuesto un reinicio del sistema. Uno fue sin estar presente, así que no sé a que se debió y el segundo al pedir la visión de un vídeo. En ese ordenador gnome-documents está siempre activo consumiendo recursos (un simple top y se ve directamente que es la aplicación que más consume) y con un funcionamiento continuo de los discos duros.

Fedora 25 beta

En cuanto he podido disponer de unos minutos he instalado Fedora 25 beta de la manera más sencilla y rápida, actualizado a través de dnf, con los comandos ya habituales

su -c 'dnf -y update --refresh'

su -c 'dnf install dnf-plugin-system-upgrade' # (En mi caso no hizo falta, por que ya lo tengo instalado)

su -c 'dnf system-upgrade download --refresh --releasever=25'

su -c 'dnf system-upgrade reboot'

Sin problemas; algún mensaje de error que me ha obligado a arrancar primero en Xorg system pero luego ya he podido arrancar con Wayland.  Ahora a probarlo; si hay algún problema importante, lo pondremos en esta u otras entradas.

Ahora intentaré la instalación de Fedora 25 beta en RaspberryPi, a ver como va.

Actualización Fedora 23 a 24. Todas las posiblidades

Y así ha sido. He actualizado 3 equipos. El primero fue el portátil en la versión Fedora 24 Beta, y quitando algunas dificultades (véase aquí) hemos podido actualizar con siguiendo los pasos indicados aquí en la wiki de Fedora. En resumen,

1.  Copia de seguridad, si hay algo que salvar

2. Actualización del sistema:
      su -c 'dnf -y update --refresh'

3. Instalación del plugin de actualización del sistema (si no lo has hecho antes en la actualización anterior)
      su -c 'dnf install dnf-plugin-system-upgrade'

4.  Descarga de paquetes (desactivar antes dropbox si lo tenéis - killall dropbox)
     su -c 'dnf system-upgrade download --refresh --releasever=24'


5. Actualizar el sistema
     su -c 'dnf system-upgrade reboot'

Como podéis ver en la actualización en el portátil he tenido que añadir algunos "arreglos" antes de la descarga de los paquetes, en concreto --allowerasing y --no-downgrade

su -c 'dnf system-upgrade download --refresh --allowerasing --no-downgrade --releasever=24'

El segundo equipo fue el de trabajo. Por más que lo intenté, eliminando paquetes con problemas, fue imposible la actualización, por lo que recurrí a una instalación desde cd con la versión netinst, que suele instalarse más rápido y actualizada.

Por último, mi ordenador personal más potente donde está todo lo importante. Fue la actualización más sencilla y rápida, y solo hubo que incluir --allowerasing debido a algunos problemas de dependencias de avidemux. En 30 minutos todo en marcha. La verdad es que con las mejoras que está teniendo el sistema de actualización de Fedora nos estamos acercando a la comodidad de un "rolling release" sin que sea así.

DNF system upgrade: actualización de Fedora 22 a 23

Como ya hemos descrito, la actualización de Fedora se puede —podía— realizarse de manera sencilla con fedup —no voy a poner enlaces sobre ello, por que ya no lo necesitamos—, incluso en ordenadores remotos a través de ssh. Sin embargo el cambio de yum a DNF ha incluido también una nueva aplicación de actualización —DNF system upgrade— que facilita la actualización.
De los diferentes dispositivos que utilizo, he ido cambiando uno a uno de diferentes maneras, pero ninguno mediante esta nueva aplicación. Me quedaba el portátil, así que lo he realizado hoy. He seguido las instrucciones sencillas que nos da este enlace de la revista de Fedora. Si más,

1. Actualización del sistema

$ su -
# dnf upgrade

2. Instalar el plugin de dnf

# dnf install dnf-plugin-system-upgrade

3. Descarga de paquetes (en este caso 2226)

# dnf system-upgrade download --releasever=23

Sencillo y rápido, aunque depende de la red disponible. En WIFI tardó en este caso unos 20 minutos para algo más de 2GB, con una velocidad de bajada alrededor de 2MB/s.

4. Reiniciar y actualizar

# dnf system-upgrade reboot

Una vez ordenada, me fui a tomar un café, y al volver estaba terminando la comprobación final.

Conclusión: más sencillo que nunca, con solo 4 comandos, muy rápido, en función de la red disponible y como dificultades solo ha supuesto el bloqueo del repositorio de Dropbox. Una vez actualizado, todo funciona adecuadamente, incluyendo Dropbox, las aplicaciones de wine y todo lo demás. Aun no he descubierto ningún paquete con problemas ni dependencias no resueltas.

RECOMENDADO.

Problema con dnf: 'ascii' codec can't decode...

De repente me encontrado con un error extraño. Necesitaba una conversión de audio y decidí instalar soundkonverter

su -c 'dnf install soundkonverter'

y la respuesta del comando fue

Así que buceando en la red encontré en minilsegundos la respuesta. En esa página dice "El problema está relacionado con la actualización del paquete dnf-plugin-system-upgrade. En la última actualización, este paquete trae un fichero de idiomas con errores." Este error afecta ma todas las opciones de dnf que probé. La solución es simple

1. Ir a la carpeta: /usr/share/locale/es/LC_MESSAGES como administrador

2. Renombrar el fichero dnf-plugin-system-upgrade.mo

mv dnf-plugin-system-upgrade.mo dnf-plugin-system-upgrade.mo.bak

y listo.

Error al actualizar Fedora 22

Al intentar actualizar Fedora 22, con una simple orden

su -c 'dnf -y update'

el sistema empezó a bajar las nuevas versiones y cuando estaba a punto de terminar se cortó la orden y apareció un error parecido a

...  [=== 76% ...
Error: Error al descargar los paquetes:
  Cannot download google-chrome-stable-45.0.2454.99-1.x86_64.rpm: All mirrors were tried

y no había forma de que continuara.
Como sabemos, la opción --skip-broken ya no está presente en dnf, ya que está incluida, teóricamente, en la orden básica.
Después de mucho mirar leí en esta página que probablemente el sistema estaba intentando actualizarse a una versión anterior a la que había en ese momento, probablemente pon un cambio rápido de versión en el repositorio. La recomendación era limpiar los ficheros de paquetes en actualización

dnf clean metadata

y luego repetir

su -c 'dnf -y update'

Perfecto. 

PD. Sí, sí. Aunque casi siempre uso Firefox, también tengo instalado Chrome

Fedora 18 en el equipo principal

Finalmente he tenido tiempo para poner Fedora 18 en mi equipo principal. Este equipo no tenía nada más que gnome, asi que lo más sencillo ha sido, tras hacer una copia de seguridad con rsync, utilizar FedUp. Tras bajar 2093 paquetes, más otros 936 de dependencias y de avisar que el repositorio de Dropbox no está disponible, se actualiza por si mismo tras reiniciar. No lleva mucho tiempo -o quizás lleve mucho, según se mire- y luego se arranca en Fedora 18 directamente. Como actualiza lo anterior, lo único necesario es cambiar el repositorio de Dropbox,

$ su -
   contraseña
# gedit /etc/yum.repos.d/dropbox.repo

y añadir (cambiar) la url del repositorio

[Dropbox]
name=Dropbox Repository
# baseurl=http://linux.dropbox.com/fedora/$releasever/
baseurl=http://linux.dropbox.com/fedora/17/
gpgkey=http://linux.dropbox.com/fedora/rpm-public-key.asc

ya que dropbox aun no tiene arreglado el repositorio para Fedora 18 (véase aquí).

Tras eso solo nos queda instalar gnome-tweak-tools

# yum -y install gnome-tweak-tool

# yum -y install dconf-editor (si es que no lo tenemos ya)

y retocar las extensiones de gnome shell, muchas de las cuales no estarán actualizadas para gnome 3.6. Entre las más interesantes que podemos  añadir/actualizar están
- Backslide: que nos permite cambiar el fondo de pantalla cada 5 minutos
- Hide Dash: que oculta el dash izquierdo
- Hide top bar: que nos permite ocultar el panel superior, que se muestra al tocar la tecla Super
- No Topleft Hot Corner: anula que se active al tocar la esquina izquierda la visión de las ventanas, aplicaciones y dash.

Esto permite tener un escritorio limpio, con un fondo que cambia según nuestros gustos cada 5 minutos, como por ejemplo,

A ellas añadiría, al menos,
- Trash- nos muestra la papelera en el panel superior
- Monitor Status Indicator, que nos permite configurar la pantalla en un acceso en el panel  superior
- Removable Drive Menu- nos da acceso a los dispositivos externos pra desmontarlos directamente

Un último cambio, para aquellos que no les guste el nuevo y minimalista nautilus

pueden instalar nemo, que es un fork del anterior nautilus (yum install nemo).

Como podemos ver, mantenemos la posibilidad de usar la distribución en árbol y también conectar a un ordenador desde el menú de archivo.

Y con ello, calculando entre 2 y 4 horas, según la red y equipo disponible, tenemos Fedora 18 listo para trabajar. Para los equipos que estén sobrecargados de escritorios, creo que sería más adecuado instalar de nuevo usando Anaconda, y eliminar cinnamon y kde, como me pasa a mi en el último ordenador que me falta por actualizar.

Nos queda probar DNF, el futuro sustitutivo de yum, pero eso lo dejamos para la siguiente, por que por lo que parece, aun presenta un bug.