Cambiando el disco /home en Fedora 31. Ni siquiera fue necesario editar fstab

Como había dicho el otro día, había varias cosas pendientes sin hacer en las que me ocuparía si encontraba tiempo en este aislamiento físico y psicológico en el que estamos. Me había propuesto cambiar el disco que contiene /home en mi ordenador. He mirado los recibos y compré un SSDV-NAND SSD 860 QVO SATA 6Gb/s de 2 TB el 19 de noviembre de 2019, hace 4 meses y medio. Estaba esperando a la liberación de Fedora 32, pero he estado pensando que ahora dependemos del teletrabajo, así que probablemente no instale Fedora 32 hasta que pasen unos dos meses de su salida, cuando esté más estable y con menos necesidad de "pulido". Además, el equipo funciona perfectamente y tiene todo lo que necesito, y la instalación limpia siempre lleva a que la primera semana estemos añadiendo cosas que nos hemos olvidado de incorporar en la lista de instalación inicial. De esta manera, cuando se libere el nuevo Fedora, simplemente actualizando en unos 60 a 90 minutos estará todo preparado. Al terminar de trabajar la noche anterior, para hacerlo lo más rápido posible y perdiendo poco tiempo de trabajo, extraje el disco home —mi equipo tiene todos los magnéticos en posición frontal para sacar incluso en caliente, aunque en mi caso no es posible, ya que forman todos parte del equipo—; era ese hueco que queda arriba, ya que están colocados por orden sdb, sdc, sdd y sde. El sda es otro sólido que es el sistema y está fijo en posiciones inferiores.

Ahora había que clorar el disco. Siempre se podría haber acudido al raspbeerypi que preparé ayer y clonar con una orden dd, pero por suerte tengo una caja lectora de discos duros SATA modelo TOOQ TQDS-802B, que permite clonar un disco sobre otro sin usar un ordenador; ya la he usado más veces. Funciona perfectamente, clona rápidamente —siempre con el cuidado de poner el origen en A y el destino en B, o adios muchachos, todo perdido—, como vemos en la foto; se aprieta el botón frontal unos segundos, y corren los colores hasta que termina.

Por la mañana ya esta el nuevo SSD clonado (luces estáticas). Lo inserto en el ordenador, y yo estaba esperando tener que editar fstab, ya que teóricamente ha cambiado el UUID que define el disco y el sistema en teoría, no debería arrancar, como aquí.
Sorprendentemente, arrancó a la primera, como si no hubiera pasado nada; bueno, en mi opinión arranca más rápido, ya que la lectura de la configuración la tiene que hacer en /home/usuario, donde está todo anotado, y tarda unos segundos menos. Otro cambio es el sonido del equipo, que ha disminuido. Ahora mismo aun tiene 3 discos magnéticos, pero dos son de almacenamiento de lo que ya está terminado, modelos WD Red 8TB, a 5400 rpm, que no hacen demasiado ruido y queda aun un WD Green 4TB a 7200 rpm, donde mantengo lo del intercambio de pares. Simplemente se nota un cierto silbido en el ambiente.
Respecto al comportamiento, sí que puedo recomendar cambiar los discos de trabajo a SSD, no solo el del sistema, si no también el /home, para aquellos que tengan discos diferentes para cada función. Respecto al almacenamiento, en mi caso cambiar 20TB que dispongo es prohibitivo, ya que los discos sólidos de 4TB están cerca de 500€, y los de 8TB suben de ese precio en marcas poco conocidas y mucho más si nos fijamos en WD, Sandisk o Samsung. En resumen, bueno, bonito y fácil —lo de barato es relativo, ya que me compré el disco en una oferta de esas de amazon de compra en 4h59 minutos o despídete de este precio y no me quejo—. El equipo, el sistema y el usuario lo agradecen pero el cambio total a sólido aun va a tardar.

PD. Y de paso, desmonté alguna cosa, hice hueco y le pasé la aspiradora por dentro al equipo, que esta algo polvoriento. Por suerte, no fumo, y el polvo no se adhiere a la "machina".

PDD. Ahora queda libre un WD Black, con 7 años de uso ininterrumpido 24x7. Habría que darle un retiro respetuoso, pero con 2TB de volumen, poca utilidad puede tener. Eso si, cuando lo compré, costó más que su sustituto; de aquella eras un disco de servidor, y en que te has quedado...

90 segundos de retraso en el arranque mientras el sistema busca un UUID inexistente

En las últimas semanas he tenido dos problemas en el ordenador y una curiosidad. La curiosidad la dejamos para después y los problemas los he solucionado ayer. ¿Dos problemas?, si el título solo habla de uno. Al solucionar uno ha desaparecido el otro. Los problemas eran, primero, que el ordenador mostraba ciertos momentos de congelación en fases cada determinado tiempo —20-30 segundos—; el segundo, que solo lo notaba al reiniciar el ordenador, lo que pasa solo por actualización de kernel, era que el sistema se paraba 1 minuto y 30 segundos buscando un dispositivo con un UUID —Identificador Único Universal— inexistente en mi sistema. Al arrancar notaba un tiempo en vacío; si le damos a ESC, en vez de verse el logo de Fedora aparece el protocolo de arranque y ahí se podía leer:

A start job is running for /dev/disk/by-uuid/9013.... (34s / 1 min 30s)

y tenía 90 segundos para leer el mensaje hasta que seguía el arranque, que si no fuera por esto tarda unos 30s. Al apagar también tardaba y aparecía el mensaje

A stop job is running for Disk Manager (7s / 1 min 30s)

Lo primero que hice fue comprobar los UUID de los dispositivos del equipo, así que edité fstab

su -c 'nano -$ /etc/fstab'

y ninguna de las particiones del disco del sistema (/, /boot, /boot/efi) ni los otros 4 discos duros tienen ese UUID.
Ademas, lo comprobé de nuevo con blkid, que muestra los atributos de los dispositivos:


su -c 'blkid'

así como

su -c 'lsblk -ff'

que lo deja más claro, ya que dibuja un árbol mejor distribuido. Y, como debería ser, tampoco coincide ningún dispositivo con ese UUID. Revisando la red en muchos sitios se achaca este problema a un cambio de swap y que el UUID nuevo no haya sustituido al antiguo. Sin embargo mi partición swap muestra el UUID que se le asigna por fstab y la swap funciona como podemos ver

Entonces, si no estaba en fstab, y no era un problema de swap, ¿de dónde venía la orden de buscar ese dispositivo? Me puse a buscar parte de la cadena en los ficheros del sistema

su -c 'grep -lir "9013ddb2" /'

y el resultado fue nulo. Luego revisé los logs, y tampoco apareció nada. Miré todo lo que pude sobre systemd, y nada. Así que finalmente acabé en /boot/efi/EFI/fedora/grub.cfg y ahí estaba:

... resume=UUID=9013ddb2-...

Primero, ¿por qué el sistema no me lo había mostrado al pedírselo?; será que el administrador no puede entrar en EFI...
Segundo, el grub.cfg no se debe editar directamente, como dice el mismo,

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

así que revisamos el fichero /etc/default/grub y los del directorio /etc/grub.d. Ninguno contenía ese UUID, así que ejecutamos

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

y reiniciamos y arrancó en un suspiro.

El segundo problema era la congelación temporal del sistema. En algunos sitios había observado que se podía deber a mutter, y que ere error se había corregido para la versión 3.34.1.11, pero era la que tenía y seguía congelándose. Sin embargo, al reiniciar después de haber cambiado grub.cfg el sistema dejo de estar congelado, asi que asumo que cada 20 o 30 segundos el sistema seguía buscando un dispositivo inexistente.

Queda por satisfacer la curiosidad, que es sobre sudo. Si me pongo a ello, lo pondré en otra entrada.

El sistema no puede arrancar. UUID ha cambiado. Solución rápida

Me he encontrado en esta situación mientras instalaba alguna de las versiones Live de los sistemas en la entrada anterior. Cuando usamos Fedora Media Writer hay que estar atento de que dispositivo señala como diana; por ejemplo véase aquí.

En algún momento, más atento al café que a la ejecución de las órdenes, Media writer fijó su puntero en mi disco 5 (imagen anterior) y al dar la orden lo que hice fue "reparar" el disco duro, en vez de copiar la iso en el USB. El resultado fue que el disco fue formateado y cambió su UUID —identificador único universal—. La definición de las unidades en estos momentos no se hace simplemente mediante sda1..., sino que se identifican por ese identificador. Véase por ejemplo /etc/fstab en el ordenador donde estoy escribiendo:

El siguiente rearranque el sistema no pudo lanzar el escritorio gráfico y dejó una pantalla en texto sin arranque de sistema, ya que no era un disco externo, formaba parte del sistema.
Tenemos dos soluciones; la lenta y costosa en tiempo, aunque más sencilla, y la rápida, algo trabajosa, pero solucionable en unos minutos. La más lenta es instalar de nuevo el sistema manteniendo todos los discos sin formatear salvo el de sistema. La más rápida nos lleva a editar /etc/fstab.
Nunca me había atrevido a editar fstab por que estaba convencido que también tendría que editar grub, y todos sabemos que desde que tenemos grub 2 no se edita en ficheros de texto plano. Sin embargo la necesidad de recuperar rápidamente el ordenador me obligó a intentarlo. Dividamos la ejecución en partes:

1. Cuando aparece en la pantalla de arranque los diferentes kernels disponibles, que en Fedora suelen ser tres, debajo existe una posibilidad de entrar en recuperación. Elegimos esa posibilidad.

2. Nos lleva a una pantalla completamente en texto. Nos identificamos como administrador y ponemos su palabra clave.

3. Detectamos la nueva UUID de la unidad que ha cambiado. Para ello usamos el comando blkid

# blkid

que nos indica todos los UUID

y debemos apuntarlo a mano o hacer una foto con el teléfono. Existen formas de copiar un trozo de texto, pero son muy complicadas y suponen un esfuerzo excesivo para escribir 36 caracteres.

4. Editamos /etc/fstab. Estamos en un entorno de texto, así que no podemos usar gedit ni otros editores gráficos. Para los que dominen vi/m, adelante. Los demás podemos usar nano

nano -$ /etc/fstab

La opción -$ permite un "soft wrapping", una alineación "suave", lo que permite ver entera la línea aunque el ancho de la ventana sea menor. ¡Cuidado! Esta opción debe ir como la última o por separado si se usan más opciones —véase aquí—.
Cambiamos el UUID del dispositivo por el nuevo. Guardamos

5. Reinicio. Si todo va bien, listo. En mi caso, así ha sido.

Este caso particular se puede ampliar a cambios de discos. En concreto el sistema de esa máquina permite el cambio en caliente. Si queremos cambiar un disco interno identificado en el arranque podríamos aplicar este sistema para poder hacer cambios rápidos en minutos.

Sistema no arranca... a la primera. ¿kaslr disable o algo más?

Las cosas son así. Mi ordenador de trabajo no arranca al primer intento desde hace bastante tiempo, y suele arrancar después de un reset —a veces más de uno—, detectando la BIOS y siguiendo el patron natural de arranque. Por supuesto, se debe a que tiene 10 años, un disco de arranque WD raptor a 10.000rpm, una joya en su momento pero ahora con un sector erróneo y con avisos de muerte continuos, todo debido a falta de presupuesto. Por ello no me extraño al tener que resetear el equipo los lunes —solo lo apago los viernes, al terminar la semana de trabajo—. Sin embargo la semana pasada apareción un nuevo mensaje, de manera muy fugaz, apareciedo unos milisegundos antes de quedar la pantalla en negro

kasrl disable

Este mensaje se debe a un bug conocido en Fedora desde la actualización del kernel a 4.7.2-200.fc24. kasrl de refiere a la localización en memoria del kernel —Kernel Address-space layout randomization KASLR—. Una localización aleatoria dificulta el ataque sobre el kernel.

En mi caso dudo que que mi problema esté en este bug, ya que depende de que esté admitido la hibernación, que no es el caso; además, con uno o más resets arranca, así que lo mío sigue siendo "achaques de edad".

Modificar las particiones que incluyen swap

El problema es el siguiente. En máquinas antiguas, con un solo disco duro, al instalar el sistema —en general, debian-xfce—, solía dividir el disco duro en una primera partición primaria de 10GB y una lógica con swap y home. El problema es que 10Gb son poca cosa en los días que corren —sí, recuerdo cuando los discos eran de 20MB, pero los tiempos cambian— y se acaban llenando de kernels, logs y otras cosas, hasta que el sistema no arranca por falta de sitio. La solución parece sencilla. Arrancamos desde un USB —si se puede— o un CD-live con una distribución que lleve gparted —o lo instalamos en memoria— y redimensionar las particiones. Sin embargo, esta vez la partición lógica no permitía la redimensión. ¿por qué? Por que swap está activo.

Es la segunda vez que me pasa. La primera fue hace tiempo y pensé que se debía a algún bug de gparted, pero la realidad es que la distribución, en este caso Ubuntu, está utilizando el swap del disco duro, o el swap se activa por que sí. El asunto es que después de desactivar el intercambio, ya se pudo separar de la partición los sectores que se habían liberado antes

y pasarlos a la partición primaria. Arranque y listo.

Sí, las particiones son algo raras. Son la herencia de un disco que tenía Windows con Linux; y así había quedado después de la eliminación de Windows.

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!

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.

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".

https://commons.wikimedia.org/wiki/File:EMule_mascot.png

[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.

Y cuando las fregonas controlaron el mundo...

Las fregonas... ¿Por qué?
Por que he tardado una semana en reparar mi ordenador después de que una fregona libertaria —o libertina, según se mire— golpeara la regleta de alimentación del SAI del ordenador de trabajo, que nadie se diera cuenta del estruendo de alarma —era medio día, todo el mundo comiendo— y se apagara de mala manera el dispositivo. Resultado final, un arranque con errores:

Como podemos ver en la segunda imagen, el problema de arranque se debe a una inconsistencia en uno de los discos. Erróneamente, culpé al disco de arranque, un WD Raptor de 10.000 rpm, que ya está muy baqueteado, con más de 8 años de uso, y con un sector erróneo por otro apagado sorpresa. Empecé la reparación sustituyendo el primer disco por un sólido, pero me aparecía el mismo error tras la instalación del sistema. Eso me obligó a reconsiderar que el error estaba en el segundo disco, un WD Caviar Green de 1TB, que actúa como /home y que solo tiene 6 años de uso. La prueba smart indicó que no había errores físicos, pero no había tabla de partición. En resumen, todos los datos y configuraciones perdidos.
Instalación nueva, reutilizando los discos originales, con Fedora 23Beta (30 minutos) y recuperación de /home desde una copia de seguridad (varias horas). En resumen, entre unas cosas y otras 3 días seguidos trabajando a medias con un portátil. Peor aun, la copia de seguridad, aunque contiene todo, tiene la estructura del ordenador de casa, no la del trabajo, con lo que hay que cambiar la estrategia mental de localizar las cosas.
Una pérdida lamentable de tiempo, aunque sin coste económico, y unas entradas de retraso por una fregona.

Aplicaciones específicas de un S.O. o distribución? Solución en Fedora: Cajas

En ocasiones nos encontramos con que algunas aplicaciones solo pueden ser utilizadas en un Sistema Operativo —S.O.— o distribución, y nos obliga a usar un dispositivo solo para eso; véase aquí, por ejemplo. Para evitar esos problemas, lo mejor, más rápido y sencillo es utilizar cajas en Fedora.
En este caso el problema nació en las dificultades que presentan muchos lectores de CDs o DVDs viejos a la hora de leer las unidades regrabables que usamos para ahorrarnos gastar un CD o DVD cada vez que hay que instalar o arreglar un dispositivo con alguna distribución. Para evitarlo, lo más sencillo es llevar un dispositivo USB de arranque con un sistema múltiple, y si el ordenador puede arrancar en USB, todo resuelto. En mi caso suelo utilizar una unidad Kingston R500 de 16GB con un sistema con Fedora, Ubuntu, Knoppix, Debian, Hiren's Boot, Ultimate Boot CD, Rescue Disk 10, Avira y Clamad AV, todos arrancables. La aplicación que me permite generar ese dispositivo es Multisystem, pero que solo funciona en Ubuntu, como ya sabemos de antes. Multisystem permite eliminar distribuciones del lápiz y volver a instalar las versiones más moderna, pero en este momento no dispongo de ese notebook que había utilizado en el pasado. La solución más sencilla ha sido instalar un Ubuntu 15.04 en cajas, simplemente aplicando una iso sobre una caja nueva.

Una vez instalado Ubuntu, incorporamos el dispositivo USB en caliente,

instalamos Multisystem y ya podemos trabajar sobre la unidad USB. Podemos eliminar sistemas operativos (1) para luego poner versiones nuevas simplmente arrastrando las isos en el cajetín marcado como 2.

Listo. Ya tenemos todo actualizado.

Errores al introducir un nuevo dispositivo [ACTUALIZADO]

Como decía en la entrada anterior, la moda multimedia me ha generado un problema... De repente me ha faltado espacio. Mi sistema principal está distribuido de la siguiente manera:
sda - disco duro sólido de 64 GB. Es root, y contiene solo el sistema
sdb - caviar black de 2TB. Contiene solo mi carpeta personal
sdc - caviar black de 1TB. Tiene material multimedia
sdd - caviar green de 3TB. Es la copia interna del resto del equipo. Duplica el material importante.

No está distribuido, probablemente, de la mejor manera posible, pero está así dispuesto por razones históricas, ya que al cambiar de ordenador no cambio de discos y suelo mantener desde hace años un sistema similar. Sin embargo, podemos decir que la capacidad de almacenaje debería ser suficiente. Pero debido a que guardo en el interior del sistema los trabajos almacenados desde 1990, no he tenido sitio para hacer la última copia de seguridad en el disco interno.

Por supuesto, la solución más sencilla sería cambiar el disco de 3 TB por uno de 4TB, pero no me han parecido adecuado los costes, superiores a 150€.

Entre los discos que tengo "aparcados" para diferentes usos según el momento tenía uno de 1,5TB -un caviar black-, y como aun me quedaba una conexión SATA sin ocupar, lo he incorporado como quinto disco. Lo he conectado en caliente de forma frontal, formateado (era un antiguo home con una carpeta personal antigua), configurado para arranque al encender el ordenador.

Cuando todo parecía listo, una de mis aplicaciones lo identificaba mediante su UUID, ya que no le había puesto una etiqueta, y le añadí un nombre. Luego actualicé el ordenador y lo reinicié; bueno, lo intenté, por que esta fue la respuesta:

Simplemente, estaba identificado por su UUID y, supongo, al haberle cambiado la etiqueta, ya no era identificado.

Las soluciones posibles eran
1. La primera que se me pasó por la cabeza; instalar de nuevo el sistema, integrando los discos a mi gusto. Tendría una mejora añadida; librarme de kde, que aunque cumple mis necesidades, no me gusta.

2. Dos, mucho más delicada; editar con un LiveCd fstab.

Por suerte, suelo empezar por la versión más barata o que exija menos tiempo. Simplemente extraje el disco, arranque el equipo -funcionó-, volví a introducir el disco en caliente y lo configuré de nuevo. MUCHO más fácil.

Como consejo, evitar configuraciones tras la adaptación de nuevos dispositivos antes de reiniciar.

Además de añadir un disco, apliqué tune2fs para intentar aumentar el volumen disponible, pero eso lo dejamos para un tercer episodio.

[ACTUALIZACIÓN]: Al final no quedó más remedio que editar los fstab

virt-manager: episodio 3. Cambios internos

Mientras estaba disfrutando de unas mini-vacaciones en Semana Santa me asaltó una duda que no pude comprobar (en el portátil no llevo máquinas virtuales). ¿Cuál será la respuesta de Windows al cambiar entre una imagen raw a qcow o al revés? ¿Seguirá detectando cambio de software?
La lógica nos dice que no debiera ser, ya que el "hardware" virtual está condicionado por qemu, y no debiera cambiar. Para asegurarme, hice una prueba. Transforme una imagen raw que funcionaba correctamente a formato qcow

Luego generé una nueva máquina con la imagen nueva

Sin olvidarse de configurar correctamente el nuevo formato qcowen el disco virtual

Y el resultado fue el esperado; funcionamiento perfecto.

Solo quedaba por comprobar que también funcionaran correctamente al copiar las imágenes en ordenadores diferentes. He copiado las imágenes y las he utilizado en un ordenador muy diferente (AMD-Intel; placa ASUS-placa INTEL...) con una instalación similar de Fedora 18 y virt-manager. Las imágenes funcionan perfectamente.
Adiós VirtualBox, aunque de hecho ya no lo usaba salvo necesidades de trabajo especiales (algoritmo CHAID que no está desarrollado en ningún paquete de R).

De VirtualBox a virt-manager. Episodio 2. De pantallazo azul a un arranque correcto

En la entrada anterior habíamos dejado una máquina virtual con un disco virtual de Windows XP convertido desde vdi a img o qcow en un pantallazo azul continuo. Pero como decíamos al final, esto tiene solución. Simplemente debemos reparar la instalación de Windows. Necesitamos una ISO de Windows XP (seguro que con un CD también funciona, pero no lo he probado).
Partimos desde virt-manager y generamos una nueva máquina virtual, pero en vez de importar imagen de disco externo pedimos un medio de instalación local, como si fueramos ha hacer un disco virtual nuevo.

Le indicamos dónde está la ISO de Windows XP,

y luego decidimos como antes cuanta RAM dedicamos a la máquina virtual, y no nos olvidemos en la configuración de indicar que el almacenamiento tiene el formato qcow (de ser así; si es raw, no hace falta). En la etapa 4 de la creación, al habilitar el almacenamiento escogemos uno ya existente, donde indicamos nuestro disco convertido (img o qcow)

El sistema arrancará en la ISO de Windows y seguimos todos los pasos como si fueramos a instalarlo. NUNCA seleccionar la primera reparación, ya que eso nos dejaría en un terminal sin comandos adecuados para lo que queremos.

Seguimos la instalación hasta que se detecte la instalación de Windows que ya está en el disco virtual. Ahí pedimos la reparación.

En el caso de que no nos detecte Windows instalado y nos diga que la partición está vacía, probablemente estamos en un dosco con formato qcow y no se lo hemos indicado a virt-manager, y qemu no es capaz de leer. Cancelamos y volvemos hacia la configuración de la máquina virtual. Una vez pedida la reparación, Windows comienza una instalación, pide el número (se requiere una licencia de Windows para usarlo, aunque sea en una máquina virtual), etc...

En todas las pruebas que he realizado termina correctamente y acaba en una pantalla como para arrancar diciendo espere

Sin embargo he dejado dos ordenadores toda una noche y sigue así por la mañana, así que lo mejor es forzar el apagado de la máquina virtual y arrancarla de nuevo. En todas las pruebas, una con una imagen en bruto img y otra con qcow2 ha arrancado correctamente

y el sistema funciona adecuadamente, conservando la configuración y las aplicaciones.

En resumen. ¿Es necesario hacer todo esto o lo instalamos de nuevo?
Depende. Si en ese disco virtual tenéis aplicaciones o el certificado digital u otras cosas que nos lleve mucho tiempo preparar, ganamos tiempo convirtiendo los discos virtuales existentes para VirtualBox. Si no necesitamos nada de lo anterior, acabamos antes instalando de nuevo en virt-manager o con Box-Cajas.
LA conversión es rápida, dependiendo del volumen del disco, claro. el arreglo lleva el mismo tiempo que una instalación de Windows; nos ahorramos la instalación de todo lo demás.
Espero que haya quedado claro, por si alguien se encuentra en algún momento en un caso parecido al mío.

Netbook que no arranca desde USB

Me han pasado para arreglar un Eee Pc 1001 HA que presentaba un comportamiento "extraño".
Es una máquina muy bonita, de acabado estilo Asus, muy correcto; el teclado es muy fácil de usar, sin problemas de espacio reducido para dedos masculinos. En resumen, una máquina interesante dentro de su categoría. Como es natural, en principio presenta solo los dos problemas comunes a la mayor parte de los netbooks, es decir, solo 1GB de RAM y Windows como SO.

Como me dieron mano libre, decidí instalar Linux, a ver si el único problema era Windows. Descubrí dolorosamente que este netbook no arranca desde un lápiz USB. Entonces empecé desde el principio:
1. Actualización de la BIOS. A pesar de ello no arranca desde lápiz USB.
2. Lector de CD externo a través de USB. Como no dispongo de uno diseñado así, genero uno con un cable conceptronics. A pesar de ello sigue sin arrancar desde USB, aunque sea CD.

3. En la BIOS inhabilito el disco duro como unidad de arranque, y por fin arranca desde el CD. Como es para un usuario de Windows, decido ponerle una versión light de Linux, así que como disponía de un CD Live de Ubuntu 10.10, ese instalé. Por supuesto se debe a que a un usuario novel de Linux, que viene de muchos años de Windows, es mejor dejarle un tiempo de menús tradicionales, hasta que se acostumbre. No es recomendable meterle directamente en gnome shell o unity.

Curiosamente, en ningún caso fui capaz de hacerlo arrancar  desde una unidad flash USB. La BIOS la detecta, la activa e inmediatamente salta la configuración de la BIOS y no permite el arranque. Un comportamiento bastante extraño. ¿Para que sirve un netbook que no arranque desde USB?

Colateralmente, descubrí que no le funcionan algunas teclas (la z y la flecha hacia atrás), lo que genera algún que otro trastorno al funcionar; nada que no se pueda arreglar con un teclado USB (lo he comprobado).

En resumen, que lástima que un netbook con una pantalla de 10' y tan bien terminado tenga estas limitaciones, que aun no me acabo de creer.

Lápiz USB multiarranque desde LINUX

El otro día mi amigo hckorootx me enseñó un lápiz USB multi-arranque con muchas aplicaciones útiles para poder reparar daños de software y hardware en los ordenadores. La primera pregunta fue si es necesaria una herramienta así, y concluimos que probablemente no lo fuera para ordenadores con Linux. Sin embargo sí es muy necesaria para los que tengan instalado Windows. La segunda pregunta fue ¿cómo lo has hecho? Simplemente con yumi, una aplicación para Windows que genera USBs con arranque múltiple a cualquier tipo de ISOs (que sea autoarrancables). Como estoy en un momento en que me niego de forma sistemática a usar Windows, prometí preparar uno similar sin recurrir a nuestro querido ventanitas. Por pasos fue así:
1. Primer intento: usar yumi en wine. yumi funciona, pero wine aun no tiene solucionado el reconocimiento de los dispositivos USB, así que tras varios intentos de configuración, lo intentamos de otra forma.
2. Esa misma gente que prepara yumi nos ofrece una página donde señala la existencia de una herramienta para poder preparar un multiboot USB desde Linux, creada por http://liveusb.info/. La herramienta es un script de instalación para Ubuntu. Por supuesto primero lo intenté con Fedora, pero con un error inmediato, ya que no encontraba apt-get (obviamente). Como también estoy un poco reacio al uso de Ubuntu, lo intenté con Debian 6.05, pero aparecieron errores de localización de ficheros y de configuración (es de suponer que Ubuntu cambia las localizaciones de algunas cosas sobre el original de Debian).
3. Finalmente lo instalé sobre un Ubuntu 10.04 en mi Aspire One en un lápiz Kingston HyperX 8GB (el azul de la foto; los intentos previos en Kingston DT109 de 8GB significaba una velocidad muy baja al realizar cualquier acción en el sistema.

La aplicación se instala ejecutando directamente el script
./install-depot-multisystem.sh

y precisa la palabra de administrador (salvo que se haga sobre un live).

Una vez instalado se ejecuta desde el menú de Aplicaciones - Accesorios -MultiSystem.
A partir de ahí, lo único que hay que hacer es arrastrar las ISOs

desde el directorio en el que están, si las hemos descargado previamente para luego prepararlas más rápidamente; si no, la propia aplicación nos dirige a través del navegador a las direcciones de descarga a muchas de las ISOs que tiene previamente indicadas. En mi caso la cosa estaba complicada, ya que este netbook carece de disco duro, así que además de un USB con Ubuntu 10.04 como sistema y un DT R500 de 16 GB para generarlo como multiboot, necesité un tercero de 32GB -otro DT R500- que hizo de disco duro con un directorio con las ISOs (los tres en la primera foto)

Como el ordenador solo tiene 3 puertos USB, y además bastante cerca dos de ellos, la cosa fue algo complicada. En el caso de querer generarlo en estas circustancias, o con menos USB, mejor llevar un hub.
Una vez arrastradas las ISOs, se abren y la aplicación las distribuye en el lápiz USB (que debe ir formateado FAT32), genera el sistema de arranque, que va configurando cada ISO que vamos añadiendo.
Para esta prueba introduje ISOs de CD Live de Debian 6.05, Puppy, 5.4, Fedora 17 y Ubuntu 12.10, que sirven para instalar en los ordenadores. Añadí un Knopixx 7.04 por las aplicaciones de reparación que lleva generalmente. Como otras ISOs interesantes para desinfección y limpieza de ordenadores incluí Avira rescue system y Kaspersky Rescue Disk 10. Finalmente, para incluir aplicaciones de todo tipo para recuperar software y hardware, incluí Ultimate Boot CD 5.11 y el novísimo Hiren's Boot 15.2.
Las he probado todas y funcionan perfectamente. Tuve un error inicial de arranque en el Kaspersky Rescue Disk; lo achaqué a que, siendo un arranque Linux, está incluida en el arranque GRUB4DOS, como Hiren's y Ultimate Boot CD, pero realmente se debió a un ISO dañado, y todo funcionó perfectamente al sustituirlo por uno correcto.
Esto nos da la posibilidad de llevar en una unidad USB todas las herramientas necesarias en los muchos "arreglos" que tenemos que ir haciendo por ahí a esos amigos que solo conocemos junto a las averías de sus ordenadores... y dejar la caja de CDs que tanto pesa. ¡Y no he tocado Windows!, salvo el miniXP de Hiren's Boot, y solo para comprobar que funciona.
Yo recomendaría:
- Tener las ISOs descargadas previamente y comprobadas (MD5 y SHA mediante md5sum y shasum). Puede ser que el ordenador que usemos para generar el dispositivo tenga una conexión lenta. Eso si, tiene que estar conectado, ya que el script instala de los repositorio.
- Usar unidades USB rápidas, o al menos suficientemente rápidas, para que lo que hagamos no nos lleve mucho tiempo. Si usamos nuestra peor unidad, menos útil nos será.
- Si lo hacemos con un sistema instalado en una unidad USB, como fue mi caso, si el lápiz es muy lento, es mejor hacerlo con una distribución live que una instalada (la cosa lleva hora y media si es del estilo DT109 con un Ubuntu instalado).

Para mejorar esto, hckorootx ha prometido hacer un USB con las ISOs autoarrancables sin aplicación alguna, tocando solo manualmente el GRUB. Carezco de conocimientos para saber si es posible, pero en caso de que lo logre, nos explicará los pasos para que incluso un dummie como yo pueda hacerlo.

Fallo en el arranque: kernel 3.5.4-1

En estos momentos trabajo diariamente con 4 ordenadores en los que tengo instalado Fedora 17. Por alguna circunstancia extraña, desde la actualización del kernel a 3.5.4-1 he tenido un error en el arranque del único ordenador en el que tengo instalada la versión de 32 bits. Al intentar arrancar surge un mensaje de error como este

y en el se queda. Por suerte, arranca si elijo la versión anterior, 3.5.3-1. La verdad es que estoy tan ocupado que no me ha dado tiempo ni de buscar este error en la red ni de enviar el mensaje de error a Fedora. Sin emabargo, desde la actualización a 3.5.4-2 todo vuelve a funcionar, así que no me voy a preocupar más. Alguien con el mismo error y con más precupación por los demás ha enviado el mensaje adecuado. Gracias, a quien haya sido.

Fedora sobre Ubuntu. Esta vez con fotos

Como digo en el título de esta entrada, esta vez estaba con el móvil sacando fotos a todo lo que se movía. No son de mucha calidad, pero nos aporta alguna información más sobre el error debido al directorio home de Ubuntu. Intenté repetir las mismas condiciones de ayer en otro ordenador (el ordenador principal de trabajo). Es un ordenador nuevecito, mucho más potente, y con la diferencia fundamental de que dispone de dos discos duros, unos para sistema más swap (Western Digital Raptor 10.000rpm de 34GB) y otro (WD Caviar Green 1TB) con una sola partición para home. Para no cambiar nada más, instalé Fedora 16 con el mismo CD Live i686 que usé ayer en el otro ordenador. la instalación se hizo de nuevo sobre las mismas particiones/discos de Ubuntu, y como se ve solo se formatea la partición sda1 de sistema

Después continuo en una instalación normal

hasta que termina correctamente.

A continuación, después del reinicio, comienza la configuración inicial

hasta que nos avisa, al igual que ayer, de que ya existe un directorio con el mismo nombre en home y tenemos que decidir si lo utilizaremos -y así haremos para recrear el mismo error- o si escogemos otro nombre de usuario. Al no ser así, cambia los atributos del directorio:

Nos permite arrancar

Pero nos aparece el mismo error

En la parte inferior del monitor surge un mensaje de error que pido que nos muestre

El problema es que no me lo enseña directamente. Sin embargo consigo tocando en la parte superior que me muestre la imagen de la aplicación Security alert (activa, como se ve en la parte superior del monitor) y la imagen de lo que está detrás del icono del error

Sin embargo no puedo activar los detalles, ya que realmente no he arrancado el sistema y solo es una imagen de lo que está detrás.

La instalación correcta la realicé simplemente cambiando el nombre del directorio desde el propio CD Live para no cambiar el nombre del usuario. Una vez montado el disco, se localiza en /media identificado por su UUID. Un simple mv nombre_antiguo nombre_nuevo y se instaló perfectamente. Luego se mueven los datos importantes de uno a otro (por ejemplo, en este ordenador está la copia con todos los correos de Thunderbird) y el sistema arranca y se configura de forma normal.

Parece como si el demonio de dbus no pudiera lanzar algo de lo que depende el arranque. Seguiré buscando información, pero yo pensaba que los ficheros icc eran de niveles de color.