jueves, 26 de noviembre de 2015

DD con errores, actualización de la BIOS y otras tribulaciones

He tenido varios problemas en cadena desde la instalación de Fedora 23, aunque la culpa no es del sistema. En esa instalación había introducido un quinto disco para que funcionara como contenedor de un conjunto de ficheros "persistentes" que no cambian nunca y solo van aumentando. Eso permitiría liberar parte del disco espejo que es la primera copia de seguridad. Para ello, en vez de comprar un disco nuevo, había recurrido a uno de los que voy desechando y están en los cajones, olvidados. Pues ese disco (WD Caviar Green 1,5TB; 5 años de uso intenso hasta ser abandonado) empezó a dar el primer problema; primero cambiaba aleatoriamente a "solo lectura" hasta que terminó mostrando un sector erróneo y no poder ser detectado por el sistema.


Eso supone que el Fedora no arranca por que no encuentra el disco que espera encontrar.



Para evitar el problema reinstalé de nuevo Fedora con otro disco sustituto (otro desechado; Caviar Black 1,5TB, antes sistema en un ordenador, ahora sustituido por un disco sólido). Y aquí surge el segundo problema. El sistema no encuentra el disco de arranque, y había que entrar el en menú de arranque y señalárselo cada vez que reiniciamos la máquina.


En la placa madre Intel DZ77BH-55K se habían descrito algunos problemas con los discos duros, así que comprobé que versión de BIOS estaba instalada; era la versión 57 de 2012, siendo la última disponible la 100 de finales de 2013. Bien, cambié la BIOS. Y eso nos lleva al tercer problema. A pesar de que la máquina había señalado que el cambio había sido correcto, no arrancaba, daba una serie de pitidos y quedaba con una pantalla en negro que no decía que hacer. Cambio de monitor y cable de señal y unos dedos mejores que los míos consiguieron reparar la instalación de la BIOS y todo vuelve a la normalidad... relativamente. Como Fedora se había instalado de nuevo, hubo que preparar los repositorios, incluir las aplicaciones de uso común (más fácil si seguimos a xenode), inhabilitar otra vez el VGA1 inexistente pero molesto,


habilitar las teclas mágicas, conectarme a Dropbox, activar mis cuentas para poder disponer de drive en nautilus... Es decir, entre una cosa y otra, de jueves a lunes perdiendo el tiempo en todas estas cosas.
¡ESTO ES DIVERSIÓN!

martes, 10 de noviembre de 2015

La necesidad de particionar un disco antes de instalar Fedora

La última instalación que hice, además de todas estas reparaciones y rearreglos que hemos visto, supuso también un cambio de discos duros. El disco de sistema, el disco que actúa como home y uno que utilizo para naterial multimedia son los mismos, pero el disco que funcionaba como copia de seguridad interna se estaba quedando pequeño y quise cambiar por un WD Red NASware de 6TB.


Como el ordenador tiene la posibilidad de conectar 6 unidades, para ocuparlas todas conecté un Caviar Black que tenía por ahí sin usar para ver que todo funcionaba correctamente si los colocábamos bien, es decir, la grabadora de última. En la instalación anaconda me mostró que antes de instalar, hay que formatear los discos. La instalación me permitió introducir todos los discos pero al decidir para que usaremos cada uno no me enseñaba el nuevo de 6TB. En resumen

sda1 /
sdb1 /home
sdc1 /home/multimedia
sdd1 /home/prueba

pero no había la posibilidad de introducir el sde1 para /home/backup por que no existía (lo bueno es que si media el espacio y decía cuantos TB quedaban sin usar).
El problema es que puse el disco directamente desde el estuche, sin formatear y no tenía partición alguna. Simplemente arranqué con un Fedora 22 live y, tras la intalación de gparted, generé una nueva partición y le di formato ext4. Luego ya pudo ser instalado como

sde1 /home/backup

Sí, es una instalación tradicional por unidades y no en volumen lógico (LVM); no estoy seguro de lo que puede pasar cuando se estropee un disco y lo que habría que hacer para recuperar el contenido. Además, no hay swap, por que no quiero poner la swap en sda, ya que es un disco sólido y quiero que dure (Intel 535 con SOLO 3 años de garantía, lo que me tiene algo escamado), y no me atrevo a ponerla en otro disco, por si retrasa el funcionamiento del sistema. Además, con 24GB de RAM no creo que sea estrictamente necesaria.

lunes, 9 de noviembre de 2015

Como inhabilitar VGA1 y evitar el cambio del sistema a un monitor "fantasma"

Mi equipo personal tiene una placa madre Intel DZ77BH-55K, con doble salida gráfica DisplayPort y HDMI y con un i7 con un sistema gráfico integrado HD4000.


A pesar de que está conectada a un Philips 224 mediante DisplayPort, cada vez que el ordenador entra en ahorro de energía o si deja de recibir al monitor (este monitor tiene sensores de presencia y cuando no hay nadie delante, entra en ahorro de energía y se apaga hasta que alguien se pone delante) el ordenador se pasa a la pantalla secundaria VGA1 de 1024x768, lo que hace perder el panel y hay que entrar en la configuración por terminal y cambiar la pantalla principal. Eso en si mismo no es un problema, salvo que esté activado la protección por palabra, ya que no sale visible y no es posible acceder al sistema gráfico activo. Por supuesto, podemos generar uno nuevo en uno de los posibles terminales (con Ctrl-Alt-F2 a Ctrl-Alt-F6 y startx), pero los programas activos están en "otro" sitio, trabajando. Este error apareción en uno de los cambios de kernel, creo que en el primer kernel 4.x, pero tampoco estoy seguro, ya que he encontrado en la red casos similares con fechas anteriores. El problema es que no encontraba una manera de solucionarlo si quería mantener un control de palabra de identificación. El origen está en que para la máquina existe una salida más que el DisplayPort y HDMI. Si ejecutamos xrandr aparece al final un VGA1 (en este caso aparece disconnected, por que esta imagen la tomé DESPUÉS de haberlo arreglado).


¿Como hemos podido desconectarlo? Buscando en el conocimiento colectivo mundial —otra vez Google— encontré una solución aquí y aquí. Tenemos que editar grub

su -c 'gedit /etc/default/grub'

y añadir "video=VGA1:d" en la línea de GRUB_CMDLINE_LINUX line para deshabilitar VGA1


y luego actualizar grub. En el caso de Fedora no se reconoce la orden update-grub, pero sí esta

su -c 'grub2-mkconfig -o /boot/grub2/grub.cfg'

y al reiniciar, aparte de aparecer líneas de comandos que antes no aparecían, VGA1 está deshabilitado como veíamos en el terminal anterior y el sistema no se ejecuta en el monitor "fantasma" cuando te despistas unos minutos.

Solucionado.



viernes, 6 de noviembre de 2015

PLC. Compatibilidad entre HomePlug AV y HomePlug AV2

Desde hace años (desde 2012, como podemos ver aquí) he distribuido la red en mi casa por dispositivos PLC (Power Line Communications). Estos dispositivos permiten la transmisión de señal de red a través de los cables eléctricos. Hasta este momento he utilizado dispositivos dLink DHP-P306AV, que ofrecen un ancho de banda de 200 Mbps según el protocolo HomePlug AV. Si bien es cierto que 200 es la capacidad que tengo contratada de entrada, también es cierto que me he comprado una televisión de 49 pulgadas con resolución 4k. La necesidad de un mayor ancho de banda para vídeos de mayor resolución y, por tanto, de mayor "tamaño" me hizo pensar sobre la posibilidad de transformar la red interna a niveles superiores a esos 200 Mbps (25 MB/s), para transferir desde un disco duro conectado al router hasta la propia televisión. Así que he realizado una prueba cambiando el extensor desde el router y el que sirve a la televisión por dos unidades TP-Link TL-PA4010, que son extensores más modernos, pequeños y muy baratos, pero con una capacidad de 500 Mbps (62,5MB/s).


Y ¿por qué le llamo prueba? Por que el resto de los dispositivos siguen bajo extensores dLink DHP-P306AV. En primer lugar, son de marcas diferentes; segundo, los TP-Link siguen protocolo HomePlug AV2, teóricamente compatible con el HomePlug AV de los dLink. En resumen, quería probar si no había problemas de compatibilidad. Como respuesta puedo decir que funcionan perfectamente sin problemas. Cuando mi proveedor me haya aumentado el ancho de banda, cosa que suele pasar cada año, cambiaré el extensor maestro por uno de 1200 Mbps y usaré los dos de 500Mbps para los dispositivos que más lo necesiten y los otros quedarán con los dispositivos de 200 Mbps.

jueves, 5 de noviembre de 2015

UEFI y las unidades USB arrancables para instalar distribuciones de Linux

La generación del nuevo protocolo de arranque UEFI ("Unified Extensible Firmware Interface") como sustituto de la BIOS tradicional y el control que tiene Microsoft sobre los fabricantes de ordenadores, obligando a poner un arranque seguro ("Secure Boot") con una llave PROPIA nos ha estado provocando muchos problemas a los usuarios de "otros" SO. Muchas placas madre actuales no permiten deshabilitar el arranque seguro, así que es necesario disponer de la llave electrónica en los dispositivos para que en los ordenadores modernos los reconozcan como unidades de arranque. En mi caso aun no es un problema, debido a la antigüedad de mi parque electrónico, pero ahora que he estado instalando Fedora 23, tanto beta como estable, he preparado las unidades USB para que puedan ser utilizadas en todo tipo de máquinas, también las modernas.
Como indican las instrucciones de Fedora, las aplicaciones que hemos utilizado siempre (Unetbootin, MultiSystem...) no son válidas para el sistema de arranque seguro

"Universal USB creation tools such as Unetbootin are a historically popular way to create USB installers from ISOs intended for optical media. They typically function by creating a filesystem on the USB drive, extracting files from the image, and writing syslinux bootloader to the device.
These methods circumvent the bootloader configuration built into Fedora images, which are pre-partitioned and designed to boot on UEFI systems with SecureBoot enabled as well as BIOS systems. They do not produce a consistent result with Fedora's images, especially for use with UEFI systems.
Utilities that use a direct write method, and do not modify the Fedora image, will produce the most consistently successful results."


Es decir, es preferible utilizar otro sistema que nos replique EXACTAMENTE la imagen en el dispositivo. La forma más fácil es la aplicación discos de gnome.


En el menú de la derecha elegimos "restaurar imagen de disco", señalamos el ISO que queramos aplicar y en unos minutos, según la calidad y rapidez del dispositivo, tendremos preparada una unidad arrancable, siempre y cuando la imagen esté preparada para el "Secure boot". Por ejemplo,


Vemos como la ISO incluye diferentes particiones, incluida una EFI, en sistema de archivo FAT-12. Se puede aplicar también la orden dd en terminal, o en el caso de aquellas cuyo escritorio no incluya una aplicación gráfica que permita hacerlo
En ese caso primero hay que saber cual es la unidad del dispositivo, por ejemplo

su -c 'fdisk -l'

y una vez sabido aplicamos dd

su -c 'dd if=/ruta/imagen/Fedora-Workstation-netinst-x86_64-23.iso of=/dev/sdX'


Si bien en principio apliqué la aplicación discos (comando gnome-disks), ya que dd siempre deja libre y sin partición todo lo que sobra del espacio necesario para la imagen, discos también lo hace (usará seguramente dd para ejecutar esta acción) y como podemos ver en las dos imágenes incluidas, en ambos casos queda una parte del dispositivo libre sin particionar (parte azul del último, por ejemplo).

Y así tenemos preparado Fedora, en el primer caso un Live y en el segundo una instalación basada en red.

martes, 3 de noviembre de 2015

Fedora 23 (beta o definitivo); amule no arranca [SOLUCIONADO]

Así es. amule no arranca en Fedora 23, tanto beta como estable. He estado intentándolo en mi ordenador personal en beta y achacaba el error a algún "bug" en la versión beta y por que lo había instalado desde ejecutable externo y no desde rpmfusion, ya que no estaban disponibles. Sin embargo, desde ayer estaba trabajando sobre la versión en distribución estable y con la instalación desde repositorio y seguía sin arrancar. Eliminé la configuración personal, que viene desde mi primer Linux, por si alguna característica particular —directorios cambiados, permisos...— podía provocar que amule no arrancara, y nada. Buceando en la sabiduría colectiva —Google— encontré la solución.
El problema radica en un posible bug en el paquete cryptopp en Fedora 23 (véase aquí), así que la solución, como dicen ahí mismo, es bajar a una versión anterior —"degradar", que dicen los anglosajones—. Bajamos una versión anterior, por ejemplo desde aquí, y ejecutamos la orden

su -c 'dnf downgrade /ruta/hasta/ejecutable/cryptopp-5.6.2-9.fc22.x86_64.rpm'

y listo. Ni beta, ni fallo de compilación ni nada similar; simplemente, una dependencia con un "bug".


[Actualización]. Como se ha indicado en el título, este problema ha desaparecido. La actualización del 10 de noviembre incluía un paquete amule que funciona con el cryptopp de Fedora 23. Un problema menos.