Si habéis instalado linux en varios ordenadores y durante varios años, seguro que os habrá surgido algún problema referido a la carga de algún módulo que volvía el sistema del revés. Lo más común suele ser la carga de los módulos correspondientes a la tarjeta de sonido de la placa base y alguna pci que tengáis para escuchar las cosas con cierto nivel de calidad.
El problema realmente puede partir del administrador de sonido del escritorio que por pereza, o desconocimiento, no nos preocupamos de configurar correctamente. Lo más directo siempre ha sido desactivar la tarjeta de sonido de la placa mediante la BIOS. Si no podemos realizar esta acción el problema persiste y cada reinicio se convierte en una lotería, por dónde saldrá el sonido hoy?
Bien, pues para evitar tener que elegir la tarjeta de sonido cada vez que arranquemos vamos a ver un método para borrar de la lista de módulos el que habilita la tarjeta de sonido de la placa. Si el problema se presenta con unas tarjetas de red, o con lo que sea, siempre podremos utilizar este método. Vamos allá...
Siguiendo los pasos descritos en el wiki de debian, primero debemos borrar el archivo '/etc/modules.conf', ya que es una herencia de distribuciones anteriores. Seguramente ya no aparecerá en vuestros sistemas, pero por si acaso lo revisamos.
La forma de añadir un módulo a la blacklist es crear un archivo con el nombre del módulo, dentro del directorio '/etc/modprobe.d/' con la palabra clave 'blacklist', de modo, que si queremos eliminar la carga del módulo con nombre 'prueba', la forma más rápida sería:
# echo "blacklist prueba" > /etc/modprobe.d/prueba.conf
Después de añadir los módulos que precisemos debemos reconstruir la cadena de arranque mediante las siguientes órdenes:
# depmod -ae -F[System.map_del_sistema]
# update-initramfs -u
A la opción -F del depmod, simplemente hay que añadirle la ruta hacia el system.map del kernel actual, que suele encontrarse en el directorio '/boot'.
Reiniciamos y ya no tendremos que lidiar con esa molesta segunda opción que en realidad nunca queremos utilizar.
domingo, 3 de abril de 2011
martes, 15 de marzo de 2011
Miniaporte
Para que la gente no se queje hoy dos posts. Resulta que en las aulas linux que mantenemos cada cierto tiempo el chequeo de los sistemas de archivos da inconsistencias que requieren de la supervisión del administrador.
Esto es un engorro y realmente da igual si se pierden archivos en este tipo de sistemas ya que los datos de los alumnos están centralizados en el servidor. Por ello la reparación automática de los sistemas de archivos que componen los ordenadores de los alumnos, en principio, no es peligrosa y nos ahorraremos bastantes visitas físicas a las aulas.
Para ello, simplemente debemos activar una opción en un archivo al que hemos hecho referencia hoy en el otro post '/etc/default/rcS':
[...]
FSCKFIX=yes
[...]
Y listo.
Esto es un engorro y realmente da igual si se pierden archivos en este tipo de sistemas ya que los datos de los alumnos están centralizados en el servidor. Por ello la reparación automática de los sistemas de archivos que componen los ordenadores de los alumnos, en principio, no es peligrosa y nos ahorraremos bastantes visitas físicas a las aulas.
Para ello, simplemente debemos activar una opción en un archivo al que hemos hecho referencia hoy en el otro post '/etc/default/rcS':
[...]
FSCKFIX=yes
[...]
Y listo.
A long time...
Sí, lo sé, todos pensaréis que el título de la entrada se refiere al tiempo que hace que no escribo, pero en realidad se refiere a algo que explicaré en el artículo. Lo primero que debo decir es que hace tanto tiempo que no escribo por aquí porque me he estado dedicando más a tareas 'administrativas' de la empresa, coordinación, protocolos y demás cosas no directamente relacionadas con mis queridos sistemas.
En fin, a lo que interesa. Nosotros, desde el principio de la empresa tenemos una compartición samba para manejar los documentos comunes. Todo iba bien hasta que los responsables de debian decidieron formalizar más la secuencia de arranque del sistema, gran acierto por otra parte.
Resulta que yo tenía un script muy simple para montar automáticamente esta compartición en la secuencia de arranque. Creo recordar que el enlace simbólico en el nivel 2 debería estar detrás del que hacía referencia a la inicializacón de la red. Pero hete aquí que cuando se introdujo la nueva secuencia de arranque este 'apaño' quedó obsoleto. Ahora tenía que ponerle una cabecera al script con los requerimientos de arranque, los niveles en los que debía iniciarse, etc. Maravilloso, con esta cabecera e invocando a 'insserv' todo sería más fáicl.
El problema es que en mi máquina utilizo el demonio 'wicd' porque de vez en cuando hago pruebas con las llaves wifi que caen en mis manos para ver si funcionan correctamente con linux. Pues bien, resulta que este demonio parece que no comunica bien su inicialización ya que poniendo en los requerimientos de arranque de mi script que se invoque cuando termine el anterior la cosa no funciona.
Me volví loco el par de veces que lo probé hace tiempo, incluso poniendo el tag genérico '$all' la cosa no iba. Hasta que ayer me decidí a solucionar el problema...no lo consideraba importante ya que mi máquina casi no se reinicia y cuando tengo que consultar algo en la compartición y no está simplemente invocaba el script y listo, pero mis socios tenían que hacerlo más frecuentemente.
Lo gracioso es que el script estaba bien, lo que no está bien es el wicd ya que el montaje siempre se intentaba sin la red preparada. Al final la solución ha pasado por volver a la configuración de la red ethernet tradicional, mediante '/etc/network/interfaces' y dejar el tag '$all' al script, aunque con el tag '$network' intuyo que también servirá. Total que el script quedaría de la siguiente forma:
#!/bin/sh
### BEGIN INIT INFO
# Provides: montarHsolucio
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: montar el directorio hsolucio
# Description: montar el directorio hsolucio
### END INIT INFO
mount -t smbfs -o username=...
Y simplemente lo añadiríamos a la secuencia mediante el comando:
# insserv -v -r (para borrarlo)
# insserv -v
Otro dato curioso encontrado por el camino es la paralelización del arranque, que en debian está desactivada por defecto, no he apreciado una mayor velocidad de arranque, pero por ahí se asegura que se consigue. Total, que añadiendo:
CONCURRENCY=startpar
al fichero '/etc/default/rcS' se realiza la acción.
En fin, a lo que interesa. Nosotros, desde el principio de la empresa tenemos una compartición samba para manejar los documentos comunes. Todo iba bien hasta que los responsables de debian decidieron formalizar más la secuencia de arranque del sistema, gran acierto por otra parte.
Resulta que yo tenía un script muy simple para montar automáticamente esta compartición en la secuencia de arranque. Creo recordar que el enlace simbólico en el nivel 2 debería estar detrás del que hacía referencia a la inicializacón de la red. Pero hete aquí que cuando se introdujo la nueva secuencia de arranque este 'apaño' quedó obsoleto. Ahora tenía que ponerle una cabecera al script con los requerimientos de arranque, los niveles en los que debía iniciarse, etc. Maravilloso, con esta cabecera e invocando a 'insserv' todo sería más fáicl.
El problema es que en mi máquina utilizo el demonio 'wicd' porque de vez en cuando hago pruebas con las llaves wifi que caen en mis manos para ver si funcionan correctamente con linux. Pues bien, resulta que este demonio parece que no comunica bien su inicialización ya que poniendo en los requerimientos de arranque de mi script que se invoque cuando termine el anterior la cosa no funciona.
Me volví loco el par de veces que lo probé hace tiempo, incluso poniendo el tag genérico '$all' la cosa no iba. Hasta que ayer me decidí a solucionar el problema...no lo consideraba importante ya que mi máquina casi no se reinicia y cuando tengo que consultar algo en la compartición y no está simplemente invocaba el script y listo, pero mis socios tenían que hacerlo más frecuentemente.
Lo gracioso es que el script estaba bien, lo que no está bien es el wicd ya que el montaje siempre se intentaba sin la red preparada. Al final la solución ha pasado por volver a la configuración de la red ethernet tradicional, mediante '/etc/network/interfaces' y dejar el tag '$all' al script, aunque con el tag '$network' intuyo que también servirá. Total que el script quedaría de la siguiente forma:
#!/bin/sh
### BEGIN INIT INFO
# Provides: montarHsolucio
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: montar el directorio hsolucio
# Description: montar el directorio hsolucio
### END INIT INFO
mount -t smbfs -o username=...
Y simplemente lo añadiríamos a la secuencia mediante el comando:
# insserv -v -r
# insserv -v
Otro dato curioso encontrado por el camino es la paralelización del arranque, que en debian está desactivada por defecto, no he apreciado una mayor velocidad de arranque, pero por ahí se asegura que se consigue. Total, que añadiendo:
CONCURRENCY=startpar
al fichero '/etc/default/rcS' se realiza la acción.
martes, 8 de febrero de 2011
Agárrame esos fantasmas
Uno de nuestros problemas siempre ha sido tener un backup de las cosas importantes, nuestra colección de bases de datos, nuestra pequeña página web personal y muchas otras cosas.
Bien, en este minipost nos ocuparemos de salvar esa pequeña parte de nuestro mundo, nuestra página personal. Hay multitud de herramientas ante nuestros ojos, con interfaces bonitos, feos, cómodos, menos cómodos, pero en el fondo el fantasma que alimenta a todas ellas, o a una gran parte de las mismas, es esa poderosa herramienta llamada 'wget'.
Los más viejos del lugar la seguirán utilizando para descargar esos pdf's pesados o esas imágenes de cd que sabes de buena tinta que el gestor de descargas de firefox no podrá con ellas. Directamente copiamos la ruta del enlace, nos vamos a una consola y escribimos 'wget -c dirección_web', et voilá, archivo al canto.
Pues bien con una ordena tan sencilla como aquella podemos mantener un mirror de nuestra página web, a la que tenemos acceso mediante el ftp de nuestro hosting, es tan simple como esto:
wget --mirror --ftp-user=USER --ftp-password=PASSWORD -Pdirectorio_destino ftp://dirección_ftp
Con esta sencilla orden y una entrada en el cron podríamos configurar un completo sistema de backups sin necesidad de 'complicadas ventanas de configuración'.
Esto último parece una contradicción pero la belleza de la consola de texto es simplemente perfecta.
Bien, en este minipost nos ocuparemos de salvar esa pequeña parte de nuestro mundo, nuestra página personal. Hay multitud de herramientas ante nuestros ojos, con interfaces bonitos, feos, cómodos, menos cómodos, pero en el fondo el fantasma que alimenta a todas ellas, o a una gran parte de las mismas, es esa poderosa herramienta llamada 'wget'.
Los más viejos del lugar la seguirán utilizando para descargar esos pdf's pesados o esas imágenes de cd que sabes de buena tinta que el gestor de descargas de firefox no podrá con ellas. Directamente copiamos la ruta del enlace, nos vamos a una consola y escribimos 'wget -c dirección_web', et voilá, archivo al canto.
Pues bien con una ordena tan sencilla como aquella podemos mantener un mirror de nuestra página web, a la que tenemos acceso mediante el ftp de nuestro hosting, es tan simple como esto:
wget --mirror --ftp-user=USER --ftp-password=PASSWORD -Pdirectorio_destino ftp://dirección_ftp
Con esta sencilla orden y una entrada en el cron podríamos configurar un completo sistema de backups sin necesidad de 'complicadas ventanas de configuración'.
Esto último parece una contradicción pero la belleza de la consola de texto es simplemente perfecta.
lunes, 15 de noviembre de 2010
Aumentando el rendimiento
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.
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.
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.
Suscribirse a:
Entradas (Atom)