Esta mini-entrada es casi testimonial y no por ser corta me parece poco importante.
Acabo de migrar una de mis máquinas virtuales con debian sid de ext3 a ext4. Me prometieron mejoras increíbles en rendimiento...igual es verdad, pero no es ésta una máquina para testear dicho aspecto. Quizá en mi máquina principal, el flamante phenom, buque insignia de la oficina, la que alberga esta imagen virtual la mejora sí se aprecie. Y sabiendo que sería necesaria todavía me resisto a migrar, pero todo se andará.
Resumiendo, se arranca con una knoppix, versión 6.2, para tener la última versión de tune2fs y se ejecuta el siguiente comando sobre la partición a migrar:
# tune2fs -O extents,uninit_bg,dir_index /dev/DEV
Ahora, antes de poder montar la partición debemos chequearla para que se reajuste:
# e2fsck -fDC0 /dev/DEV
Et voilá! Simplemente tendremos que cambiar la entrada en /etc/fstab en nuestro sistema original para que arranque como la seda.
Nota importante: debemos tener instalada una versión moderna de grub, es decir, la 1.97, por ejemplo, para que el arranque funcione, con versiones antiguas la cosa se complica y no es tema de este post.
Esta info está sacada directamente del howto del kernel referente a ext4.
lunes, 15 de noviembre de 2010
miércoles, 27 de octubre de 2010
Malabarismos II
Como lo prometido es deuda, o eso pretendo, ya he podido probar a recuperar una imagen de un ordenador desahuciado para que siga viviendo virtualmente como imagen de virtualbox.
Lo primero que debemos hacer es guardarnos una imagen del disco duro bloque a bloque, es decir:
# dd bs=16MB if=[dispositivo_completo] of=[imagen].dd
y rezar para que no tenga sectores defectuosos. En este caso, con 'dispositivo_completo' nos referimos al nombre del dispositivo y no a ninguna de sus particiones.
Al parecer la mala suerte estaba de nuestra parte y el disco duro estaba dañado. La solución que encontramos fue sacar la imagen de windows mediante ntfsclone, herramienta que sí puede saltarse esos molestos sectores defectuosos. Problema lateral, ahora no tenemos la imagen completa del disco duro. Por esta razón optamos por recrearnos toda la configuración del disco duro antiguo en otro de igual tamaño. Para ello guardamos el MBR y creamos la tabla de partición con los mismos datos del disco duro antiguo mediante cfdisk.
Una vez conseguido, restauramos la imagen de ntfsclone. Resumiendo:
# dd bs=512 count=1 if=[dispositivo_completo_antiguo] of=mbr.dd
# ntfsclone --rescue --save_image --output [particion_antigua].ntfsclone [dispositivo_particion_antigua]
# cfdisk [dispositivo_nuevo]
(recreamos las particiones antiguas)
# ntfsclone --restore-image --overwrite [dispositivo_particion_nueva] [particion_antigua].ntfsclone
# dd bs=512 count=1 if=mbr.dd of=[dispositivo_completo_nuevo]
Con esto ya podemos repetir el primer paso del artículo y obtener, esta vez sí, la imagen necesaria para empezar la transformación. Ésta la conseguiremos siguiendo los pasos de esta página. Básicamente, mediante la siguiente orden:
$ VBoxManage convertfromraw [imagen].dd [imagen].vdi
conseguiremos una imagen lista para usar desde nuestro panel de control de virtualbox. Siguiendo el procedimiento normal al crear una imagen de sistema operativo, pero utilizando esta imagen existente, activando el IO APIC y eligiendo los parámetros que mejor se ajusten a nuestras necesidades ya podremos ejecutar nuestro antiguo windows...
...o no, ya que la detección de hardware de nuestro querido 'sistema operativo' no es muy inteligente y lo más probable es que obtengamos un precioso pantallazo azul. Pero no todo está perdido, resulta que aunque sus sistemas no sean de nuestro agrado, su base de conocimiento nos convence cada día más y siguiendo estos pasos pudimos recuperar nuestro sistema operativo.
Lo único que necesitaremos es ejecutar nuestra imagen virtual con una imagen iso de instalación de su windows xp original, guardarnos los datos relevantes del registro y restaurarlos posteriormente.
Un consejo, para determinar que artículo de la base de conocimiento de microsoft debemos buscar, la habilidad de pausar nuestra máquina virtual es indispensable. Del pantallazo azul que nos dio durante la confección de este artículo obtuvimos este mensaje:
Stop: c0000218 {Error del archivo de Registro} El Registro no puede cargar la sección (archivo): \SystemRoot\System32\Config\SOFTWARE o su registro o alternativo
el cuál nos llevó directamente al artículo referenciado más arriba.
Con estos 'sencillos' pasos ya tenemos nuestra vieja instalación de windows sobreviviendo virtualmente hasta el fin de los tiempos, sin necesidad de depender de un 'cuerpo físico'.
Lo primero que debemos hacer es guardarnos una imagen del disco duro bloque a bloque, es decir:
# dd bs=16MB if=[dispositivo_completo] of=[imagen].dd
y rezar para que no tenga sectores defectuosos. En este caso, con 'dispositivo_completo' nos referimos al nombre del dispositivo y no a ninguna de sus particiones.
Al parecer la mala suerte estaba de nuestra parte y el disco duro estaba dañado. La solución que encontramos fue sacar la imagen de windows mediante ntfsclone, herramienta que sí puede saltarse esos molestos sectores defectuosos. Problema lateral, ahora no tenemos la imagen completa del disco duro. Por esta razón optamos por recrearnos toda la configuración del disco duro antiguo en otro de igual tamaño. Para ello guardamos el MBR y creamos la tabla de partición con los mismos datos del disco duro antiguo mediante cfdisk.
Una vez conseguido, restauramos la imagen de ntfsclone. Resumiendo:
# dd bs=512 count=1 if=[dispositivo_completo_antiguo] of=mbr.dd
# ntfsclone --rescue --save_image --output [particion_antigua].ntfsclone [dispositivo_particion_antigua]
# cfdisk [dispositivo_nuevo]
(recreamos las particiones antiguas)
# ntfsclone --restore-image --overwrite [dispositivo_particion_nueva] [particion_antigua].ntfsclone
# dd bs=512 count=1 if=mbr.dd of=[dispositivo_completo_nuevo]
Con esto ya podemos repetir el primer paso del artículo y obtener, esta vez sí, la imagen necesaria para empezar la transformación. Ésta la conseguiremos siguiendo los pasos de esta página. Básicamente, mediante la siguiente orden:
$ VBoxManage convertfromraw [imagen].dd [imagen].vdi
conseguiremos una imagen lista para usar desde nuestro panel de control de virtualbox. Siguiendo el procedimiento normal al crear una imagen de sistema operativo, pero utilizando esta imagen existente, activando el IO APIC y eligiendo los parámetros que mejor se ajusten a nuestras necesidades ya podremos ejecutar nuestro antiguo windows...
...o no, ya que la detección de hardware de nuestro querido 'sistema operativo' no es muy inteligente y lo más probable es que obtengamos un precioso pantallazo azul. Pero no todo está perdido, resulta que aunque sus sistemas no sean de nuestro agrado, su base de conocimiento nos convence cada día más y siguiendo estos pasos pudimos recuperar nuestro sistema operativo.
Lo único que necesitaremos es ejecutar nuestra imagen virtual con una imagen iso de instalación de su windows xp original, guardarnos los datos relevantes del registro y restaurarlos posteriormente.
Un consejo, para determinar que artículo de la base de conocimiento de microsoft debemos buscar, la habilidad de pausar nuestra máquina virtual es indispensable. Del pantallazo azul que nos dio durante la confección de este artículo obtuvimos este mensaje:
Stop: c0000218 {Error del archivo de Registro} El Registro no puede cargar la sección (archivo): \SystemRoot\System32\Config\SOFTWARE o su registro o alternativo
el cuál nos llevó directamente al artículo referenciado más arriba.
Con estos 'sencillos' pasos ya tenemos nuestra vieja instalación de windows sobreviviendo virtualmente hasta el fin de los tiempos, sin necesidad de depender de un 'cuerpo físico'.
jueves, 7 de octubre de 2010
Recuperando GRUB...2
Después de una larga ausencia vamos a retomar el trabajo, con web nueva es hora de hacer crecer nuestra base de conocimiento.
El tema de hoy es algo muy recurrente en nuestros días, probamos distros nuevas, cambiamos discos duros de sitio, etc. Y claro, pasa lo que tiene que pasar, nuestro nuevo y flamante grub2 desaparece de nuestro MBR. Como explican perfectamente en esta entrada el método es sencillo, simplemente montamos nuestras particiones antiguas y utilizamos su propio grub para restaurarlo. Arrancamos con nuestra distribución live favorita y paso a paso sería como sigue:
# mkdir /mnt/rescate
# mount /dev/sdXY /mnt/rescate
# mount -t proc /proc /mnt/rescate/proc
# mount --bind /dev /mnt/rescate/dev
# chroot /mnt/rescate
Debemos sustituir XY por la letra y número de la partición '/' original. Y si por un casual teníamos '/boot' en otra partición, antes de hacer chroot deberemos montarla en '/mnt/rescate/boot'.
Con esto obtenemos una línea de comandos en nuestro sistema original. Un consejo, para obtener una línea de órdenes más cómoda probad a ejecutar 'su', con knoppix me ha funcionado muy bien.
Ahora sólo nos resta recuperar el grub:
# grub-install /dev/sdX
# update-grub
Creo que la última orden no hace falta, pero para ahorrarnos un reinicio 'live' demás prefiero asegurarme.
Una cosa más, si utilizáis knoppix arrancadla con estas opciones 'knoppix 2 lang=es', es más rápido, ya que el entorno gráfico, para este caso no nos hace falta.
El tema de hoy es algo muy recurrente en nuestros días, probamos distros nuevas, cambiamos discos duros de sitio, etc. Y claro, pasa lo que tiene que pasar, nuestro nuevo y flamante grub2 desaparece de nuestro MBR. Como explican perfectamente en esta entrada el método es sencillo, simplemente montamos nuestras particiones antiguas y utilizamos su propio grub para restaurarlo. Arrancamos con nuestra distribución live favorita y paso a paso sería como sigue:
# mkdir /mnt/rescate
# mount /dev/sdXY /mnt/rescate
# mount -t proc /proc /mnt/rescate/proc
# mount --bind /dev /mnt/rescate/dev
# chroot /mnt/rescate
Debemos sustituir XY por la letra y número de la partición '/' original. Y si por un casual teníamos '/boot' en otra partición, antes de hacer chroot deberemos montarla en '/mnt/rescate/boot'.
Con esto obtenemos una línea de comandos en nuestro sistema original. Un consejo, para obtener una línea de órdenes más cómoda probad a ejecutar 'su', con knoppix me ha funcionado muy bien.
Ahora sólo nos resta recuperar el grub:
# grub-install /dev/sdX
# update-grub
Creo que la última orden no hace falta, pero para ahorrarnos un reinicio 'live' demás prefiero asegurarme.
Una cosa más, si utilizáis knoppix arrancadla con estas opciones 'knoppix 2 lang=es', es más rápido, ya que el entorno gráfico, para este caso no nos hace falta.
viernes, 7 de mayo de 2010
Creando espacios
Alguna vez se han sentido agobiados en una habitación? Hoy vamos a abrir las ventanas para liberarnos...
O mejor dicho para que nuestras bases de datos favoritas no se sientan mal e incluso puedan invadir espacios ajenos que pongan en peligro el buen funcionamiento del sistema. En nuestros sistemas debian, por defecto, los directorios asignados a las bases de datos están en 'var' y si la instalación posee uno muy pequeño y una de estas bases de datos crece por encima de una cantidad determinada puede acarrear problemas graves.
Para solucionar esto optamos por una solución salomónica, vamos a cortar por lo sano. Crearemos una partición aparte con suficiente espacio para manejar gran cantidad de datos. Con un par de decenas de gigas tendremos más que de sobra, e incluso con menos también nos valdría, depende de para lo que vayamos a usar nuestras bases de datos. Si las particiones que tenemos ya ocupan todo nuestro disco duro una posible solución pasaría por hacernos con una knoppix y utilizar el gparted para repartir mejor el espacio. Otra solución puede ser utilizar una partición con suficiente espacio y dentro de ella crearnos un directorio para albergar los datos. Esta última es más aburrida de realizar yo siempre optaría por la más atrevida/divertida, pero claro siempre puede haber pérdida de datos...avisados están.
Sea cuál fuere la solución adoptada, una vez obtenido el espacio simplemente nos creamos un directorio allí y dentro de él uno para cada base de datos con los propietarios correspondientes, 'postgres' y 'mysql'. En un sistema con una 'lenny' los pasos a seguir a partir de aquí serán parar las bases de datos y copiar el contenido de sus directorios a los nuevos, por ejemplo:
# /etc/init.d/postgresql-8.1 stop
# /etc/init.d/mysql stop
# cp -Rp /var/lib/postgresql /opt/bbdd/
# cp -Rp /var/lib/mysql /opt/bbdd/
# cd /var/lib
# rm -Rf mysql postgresql
# ln -s /opt/bbdd/mysql mysql
# ln -s /opt/bbdd/postgresql postgresql
# /etc/init.d/postgresql-8.1 start
# /etc/init.d/mysql start
Un posible problema puede surgir de los permisos de los directorios que contienen a los directorios creados. Para solucionarlo basta con asegurarse que estos permisos son los mismos que poseen 'var' y 'lib', que está contenido en él. Si el sistema nos ha sufrido cambios estos permisos son 'drwxr-xr-x'. Pues bien, en nuestro caso 'opt' y 'bbdd' deben tener estos mismos permisos.
Para curarnos en salud, antes de borrar completamente los directorios originales podemos moverlos a otra ubicación para crear los enlaces simbólicos, probar a arrancar los servidores y si todo funciona correctamente procedemos a borrarlos del todo.
Estas operaciones las he probado sobre una máquina en producción y han funcionado correctamente pero nadie está libre de una pérdida de datos así que recomiendo, antes de probar esta solución, hacer una copia de seguridad de todas las bases de datos mediante las herramientas habituales 'pg_dump' y demás para que nuestra empresa no desaparezca de la noche a la mañana por querer respirar un poco de aire fresco...
O mejor dicho para que nuestras bases de datos favoritas no se sientan mal e incluso puedan invadir espacios ajenos que pongan en peligro el buen funcionamiento del sistema. En nuestros sistemas debian, por defecto, los directorios asignados a las bases de datos están en 'var' y si la instalación posee uno muy pequeño y una de estas bases de datos crece por encima de una cantidad determinada puede acarrear problemas graves.
Para solucionar esto optamos por una solución salomónica, vamos a cortar por lo sano. Crearemos una partición aparte con suficiente espacio para manejar gran cantidad de datos. Con un par de decenas de gigas tendremos más que de sobra, e incluso con menos también nos valdría, depende de para lo que vayamos a usar nuestras bases de datos. Si las particiones que tenemos ya ocupan todo nuestro disco duro una posible solución pasaría por hacernos con una knoppix y utilizar el gparted para repartir mejor el espacio. Otra solución puede ser utilizar una partición con suficiente espacio y dentro de ella crearnos un directorio para albergar los datos. Esta última es más aburrida de realizar yo siempre optaría por la más atrevida/divertida, pero claro siempre puede haber pérdida de datos...avisados están.
Sea cuál fuere la solución adoptada, una vez obtenido el espacio simplemente nos creamos un directorio allí y dentro de él uno para cada base de datos con los propietarios correspondientes, 'postgres' y 'mysql'. En un sistema con una 'lenny' los pasos a seguir a partir de aquí serán parar las bases de datos y copiar el contenido de sus directorios a los nuevos, por ejemplo:
# /etc/init.d/postgresql-8.1 stop
# /etc/init.d/mysql stop
# cp -Rp /var/lib/postgresql /opt/bbdd/
# cp -Rp /var/lib/mysql /opt/bbdd/
# cd /var/lib
# rm -Rf mysql postgresql
# ln -s /opt/bbdd/mysql mysql
# ln -s /opt/bbdd/postgresql postgresql
# /etc/init.d/postgresql-8.1 start
# /etc/init.d/mysql start
Un posible problema puede surgir de los permisos de los directorios que contienen a los directorios creados. Para solucionarlo basta con asegurarse que estos permisos son los mismos que poseen 'var' y 'lib', que está contenido en él. Si el sistema nos ha sufrido cambios estos permisos son 'drwxr-xr-x'. Pues bien, en nuestro caso 'opt' y 'bbdd' deben tener estos mismos permisos.
Para curarnos en salud, antes de borrar completamente los directorios originales podemos moverlos a otra ubicación para crear los enlaces simbólicos, probar a arrancar los servidores y si todo funciona correctamente procedemos a borrarlos del todo.
Estas operaciones las he probado sobre una máquina en producción y han funcionado correctamente pero nadie está libre de una pérdida de datos así que recomiendo, antes de probar esta solución, hacer una copia de seguridad de todas las bases de datos mediante las herramientas habituales 'pg_dump' y demás para que nuestra empresa no desaparezca de la noche a la mañana por querer respirar un poco de aire fresco...
miércoles, 5 de mayo de 2010
Malabarismos
Bueno, esta vez simplemente voy a referir un método que seguro será de utilidad para mucha gente. Quién no ha tenido un ordenador entre sus manos, completamente inutilizado pero sabiendo que todavía puede dar mucho de sí, pero eso sí, arrancando en su propio hardware. Tenemos un par de soluciones, o buscar un hermano gemelo del cadáver o meter la imagen del disco duro en una virtualbox para sacarle todo el jugo.
El segundo paso es complicado, pero según este artículo, el problema parece ser similar a hacer correr esa imagen en otro hardware distinto.
Debo decir que todavía no lo ha probado, en cuanto lo haya hecho lo comentaré por este mismo canal.
El segundo paso es complicado, pero según este artículo, el problema parece ser similar a hacer correr esa imagen en otro hardware distinto.
Debo decir que todavía no lo ha probado, en cuanto lo haya hecho lo comentaré por este mismo canal.
miércoles, 7 de abril de 2010
Empezamos fuerte
Lo primero que vamos a ver es cómo recuperar los datos que nos ofrece el maravilloso Keyfinder, útiles para nuestras migraciones de sistemas operativos, por ejemplo cuando un ordenador de nuestros clientes con Windows XP muere.
Gracias a este proceso podremos recuperar esta información sin necesidad de tener que arrancar el disco duro original en el sistema anfitrión. En este caso nos bastaría con pinchar el disco duro en una carcasa externa a nuestro sistema debian.
El primer paso sería conseguir la herramienta 'dumphive', por lo que he podido ver el paquete debian está en la distribución Guadalinex, de la Junta de Andalucía. Tenemos acceso al código y podremos compilarlo por el método tradicional:
$ tar xfzv
$ cd
$ fakeroot
# dpkg-buildpackage
Con estos sencillos pasos y habiendo instalado las dependencias necesarias, ya podemos instalar nuestro paquete como root ejecutando 'dpkg -i'. Ahora para obtener el registro de windows podremos ejecutar:
$ dumphive/WINDOWS/system32/config/software ../software.reg HKEY_LOCAL_MACHINE
Para los siguientes pasos es imprescindible tener instalado Wine en nuestro sistema:
$ wine regedit.exe
Ahora ya podemos importar el registro que hemos obtenido, mediante los menús del programa 'regedit' y en otra consola ejecutamos el keyfinder obtenido anteriormente que nos desvelará las claves de registro de los diferentes programas instalados en ese sistema. Con éstas ya podremos reinstalar el software necesario en la nueva máquina.
Gracias a este proceso podremos recuperar esta información sin necesidad de tener que arrancar el disco duro original en el sistema anfitrión. En este caso nos bastaría con pinchar el disco duro en una carcasa externa a nuestro sistema debian.
El primer paso sería conseguir la herramienta 'dumphive', por lo que he podido ver el paquete debian está en la distribución Guadalinex, de la Junta de Andalucía. Tenemos acceso al código y podremos compilarlo por el método tradicional:
$ tar xfzv
$ cd
$ fakeroot
# dpkg-buildpackage
Con estos sencillos pasos y habiendo instalado las dependencias necesarias, ya podemos instalar nuestro paquete como root ejecutando 'dpkg -i
$ dumphive
Para los siguientes pasos es imprescindible tener instalado Wine en nuestro sistema:
$ wine regedit.exe
Ahora ya podemos importar el registro que hemos obtenido, mediante los menús del programa 'regedit' y en otra consola ejecutamos el keyfinder obtenido anteriormente que nos desvelará las claves de registro de los diferentes programas instalados en ese sistema. Con éstas ya podremos reinstalar el software necesario en la nueva máquina.
Suscribirse a:
Entradas (Atom)