martes, 23 de diciembre de 2014

Actualización con FedUp. Espacio en las particiones

En este caso describo los problemas que he tenido en un portátil. Este ordenador tiene instalados Windows 7 y Fedora.


Debido a que ya tiene unos años, el disco duro es un TOSHIBA MK3263GSX de 320GB, dividido en 5 particiones. Las dos primeras sda1 y sda2 son las originales del sistema que venían de fábrica (sda1 NTFS de 500MB de reparación para Windows y sda2 donde viene instalado Windows 7). Sobre esa sda2 extraje un espacio vacío que he rellenado con una partición (sda3 NTFS) para datos de Windows, y la extendida sd5 (ext4) para /, sd7 (ext4) para /home y sd6 swap.
El problema generado en la actualización surgió del hecho de que sd5 / nació siendo de 14GB. Siempre fueron suficientes estos GB para sistema; sin embargo la carga de los paquees necesarios para actualizarse, más el espacio necesario para instalarlos antes de borrar los anteriores significo la falta absoluta de espacio, con el mensaje de que eran necesarios 2GB libres más en sd5. Es decir, los 34GB que se ven en la imagen fueron gestionados por gparted live, instalado a través de unetbootin en un dispositivo USB.
Conclusión: antes de empezar con FedUp, comprueben que tienen libres más de 5GB en /, por que si no tendrán que generarlos antes de la actualización.

PD. Sí, la alteración gráfica de las particiones no ha  sido perfecta y deja rastros, como esas zonas vacías sin uso. Sí, también en Windows, por que aproveché para aumentar c:\.

PDD. Si, llevo un rato bastante largo

viernes, 19 de diciembre de 2014

Formatos propietarios imposibles de abrir. CPT

Con los programas comerciales hemos topado. En ocasiones he comentado los cientos (o miles, que no nos vamos a poner a contar ahora) de gráficas realizadas en Harvard Graphics hasta el año 1995 (y unas cuantas decenas de presentaciones en las últimas versiones) que somos incapaces de abrir hoy en día. En este caso no encontramos posibilidad alguna, ni siquiera en Windows y programas comerciales.
Bien, en esta última semana hemos encontrado un segundo caso de dependencias rotas. En la época de PhotoShop 2.5 (ya llovió y nevó) éramos incapaces de imprimir de forma adecuada las fotos editadas con ese software con el hardware del que disponíamos. Por esa razón comenzamos a utilizar PhotoPaint, del que disponíamos como añadido de Corel Draw 3 (lo incluían como un plus en el paquete). Ese inicio por necesidad se acabó convirtiendo en una costumbre, y como siempre venía añadido en el paquete Corel, seguimos usándolo hasta que nos pasamos a software libre (unos 17 años). Y esta pequeña introducción, ¿dónde nos lleva?
Nos lleva a cientos de fotos editadas en formato cpt que no somos capaces de abrir. En concreto esta semana he necesitado una y no he sido capaz de encontrar un paquete que sea capaz de abrir o importar un fichero cpt. La lista ha sido:
- GIMP
- convert de image magick en terminal
- image magick a través de gthumb (GUI)
- Krita
- irfanview a través de wine
- XnConvert, versión de Windows a través de wine, ya que la versión de linux mostró varios errores en su instalación y no pudo terminarse.


No profundicé más, entre otras cosas por que no tenía tiempo, y preferí ir al material y hacerlas de nuevo. De todas maneras es una asignatura pendiente, por que como ya dije disponemos de mucho material en cpt. Obviamente, no estamos en un caso tan grave como Harvard Graphics. Llegado el caso sería posible adquirir una licencia de Paint Shop Pro a Corel o una versión de prueba y convertir las imágenes en una orden bash (o como sea posible) para recuperarlas, aunque está posibilidad no es segura (ver aquí) .

COROLARIO: el que con software propietario se acuesta...


jueves, 18 de diciembre de 2014

Fedora 21 a través de FedUp. Solución para las "broken dependencies"

Como había señalado en la entrada anterior, la actualización por FedUp había funcionado "casi" perfectamente, y que en la propia actualización, antes de empezar la sustitución de paquetes, la aplicación avisaba de cuáles presentan dependencias rotas, con el desalentador aviso de que instalásemos bajo nuestra responsabilidad ("Continue with the upgrade at your own risk").
A pesar de ello, todo va como la seda... hasta que llamas a uno de esos paquetes, en mi caso R, que es parte intrínseca de mi trabajo. La respuesta es:


Es decir, hemos tropezado con la dependencia rota.

Para solucionarlo simplemento desinstalé a través de yumex (YumExtender) R (R-core, R-core-devel, R-devel, R-java-devel) y luego reinstalé con yum

su -c 'yum install R-core R-devel' # suficiente; los otros son dependencias

Y con eso ya funcionaba. Eso sí, en vez de ser la versión 3.1.2 "Pumpkin Helmet" que ya estaba instalada en Fedora 20, la que está ahora es la 3.1.1 "Sock it to Me".


Es decir, la preparación de Fedora 21 quedó congelada antes de alguna de las actualizaciones de Fedora 20 y hay alguna "regresión" de versión.

Este problema solo me ha aparecido en R, Virtual Manager (virt-manager) y HandBrake. Los dos primeros se han corregido de la misma manera (desinstalación y vuelta a instalar) y handbrake no lo he necesitado, así que no lo he vuelto a instalar (aun).

Y de todas maneras dos días después ya se ha actualizado R a 3.1.2. en Fedora 21.

jueves, 11 de diciembre de 2014

Fedora 21. Actualizacion con FedUp

Aunque el trabajo no nos da tregua, aproveché unos milisegundos libres para actualizar Fedora a su versión 21. Hay razones varias, Gnome 3.14, Libreoffice 4.3 y muchas más, pero la más importante era comprobar que mi ordenador principal funcionaba correctamente con gnome y podía dejar KDE. Para acelerar las cosas y consumir el menor tiempo posible decidí usar fedup. Y esta vez, de lo más sencillo, siguiendo las recomendaciones de Fedora:

1. Actualización completa de sistema

su -c 'yum -y update'

2. Instalación de Fedup

su -c 'yum install fedup'

3. Comprobar que no queda nada sin actualizar

su -c 'yum update fedup fedora-release'

que en todos los casos ha dado que no quedaba nado por actualizar

4. Preparación de la actualización

sudo fedup --network 21 --product=workstation

En mi caso es workstation, aunque hay otras dos posibilidades, según sea la función del ordenador actualizado (server, cloud). Eso supone la bajada de los paquetes nuevos a actualizar (en mi caso, entre 2570 a 2685, según máquina, entre 2,4 a 2,5GB). En función de la red disponible, supone 8-15 minutos a varias horas.

Aquí llegan los avisos de posibles errores, por ejemplo en este ordenador en concreto fueron dependencias de handbrake-gui, icedtea-web y R-core


Lo mejor es el mensaje

Continue with the upgrade at your own risk

Una vez terminada la descarga, al reiniciar se ejecuta fedup y comienza la instalación de los nuevos paquetes y luego limpieza del sistema. Según la potencia del ordenador (de los que yo he probado), entre 30 minutos a 1 hora.
El resultado ha sido Fedora 21 funcionando, salvo algunos detalles que ya nos había avisado el sistema(R, handbrake).

Para terminar, habilitar el plugin "Gnome Shell Integration" de Firefox


para poder manipular las extensiones de Gnome shell y actualizarlas.

Finalmente nos queda el problema de que, de nuevo, no esta activo el repositorio de Dropbox, lo que impide la actualización del sistema.


Para solucionarlo, el arreglo que hacíamos siempre no ha funcionado, pero siguiendo las instrucciones de la página de los repositorios adicionales de Fedora hemos podido lograr que no tenga en cuenta el repositorio cuando no esta disponible y nos permita actualizar sin problemas. Para ello editamos dropbox.repo

su -c 'nano -$ /etc/yum.repos.d/dropbox.repo'

y añadimos las 3 últimas líneas

enabled=1
skip_if_unavailable=1
gpgcheck=1

Listo. Reinicio y Fedora 21 en marcha.

PD. Y sí, ¡gnome funciona en mi ordenador principal!