Archivo de la categoría: Sistema

GNU/Linux. Aspectos relativos al sistema operativo.

Monitorizando vuestro equipo con «saidar»

En GNU/Linux existen muchas utilidades para monitorizar los distintos parámetros que miden la actividad y el estado del sistema, como consumo de CPU, de memoria, lectura/escritura en discos, uso de la red, etc.

Normalmente, cada una de estas utilidades monitoriza unos parámetros en concreto, por lo que si queremos ver otros tenemos usar otras utilidades. Esto no tiene por qué ser un problema, porque a uno le puede interesar consultar unos parámetros en un momento y otros en otro. Sin embargo, si queremos ver todos (*) podemos usar una herramienta como «saidar».

Saidar nos muestra en un formato de texto aunque fácilmente legible, consumo de CPU, de memoria, de red, uso de disco duro, entre otros. Para instalarlo, simplemente usar el gestor de paquetes de vuestra distro y lo tendréis. Si no os lo encuentra pensad en cambiar de distro ;-P. Ubuntu y OpenSuse, por ejemplo, lo tienen.

Al ejecutar el comando «saidar», aparecerá algo así:

Salida del comando saidar

Salida del comando saidar

Como vemos, con esta utilidad podemos observar, de un vistazo, algunos de los parámetros más importantes que muestran el estado de nuestro equipo.

Un aspecto a tener en cuenta respecto a la información suministrada sobre la memoria usada/libre: la información es correcta, por supuesto, pero hay que tener en cuenta que Linux usa memoria libre para optimizar procesos del sistema como vimos en el anterior artículo.

El comando se puede dejar lanzado en una terminal y va actualizando cada 2 segundos.

 

(*) Realmente no son todos los parámetros del sistema, sino algunos de los parámetros más significativos.

Consultar memoria usada/libre en GNU/Linux con comandos

Existe una forma sencilla de consultar la memoria ocupada/libre de nuestro sistema GNU/Linux desde la línea de comandos. Para ello tenemos el comando free.

Si lo ejecutamos nos mostrará la cantidad de memoria ocupada/libre que hay en el sistema, pero lo hará en bytes, lo cuál es difícil de leer. Para solucionar esto usaremos el parámetro -m. De esta forma (con «free -m») lo vemos en MB. Ejemplo:

Salida del comando free

Salida del comando free

Si nos fimajos en la segunda fila (-/+ buffers/cache) tenemos 1137 MB de memoria en uso y libres 2818 MB. De estos 2818 MB, 845 se están usando para caché de procesos, 72 MB para buffers de I/O y 1900 MB están libres (el sistema no los está usando para nada). Los 72 MB de «buffers» y los 845 MB de «cached» se pueden usar cuando se necesite memoria para algún programa, por lo que se pueden considerar como libres, sumándolos a los otros 1900 MB (lo que nos dán los 2818 MB que nos indica dicha línea (*)).

GNU/Linux usa toda la memoria para cachear procesos y datos de forma que se le saque partido a la misma. De esta forma se aceleran el uso del sistema y la memoria se considera libre al mismo tiempo, pasando a disposición de cualquier proceso que la necesite.

 

(*) La columna «shared», según se indica en la página del manual, es una información obsoleta y se puede obviar.

Ejecutando comandos como root dentro de un script

A veces, dentro de un script, se necesita ejecutar un comando como superusuario. Una posibilidad es usando el comando sudo, por ejemplo:

sudo ls /root

Si lo ejecutáis sin el sudo (es decir, como vuestro usuario normal del sistema) no os va a dejar porque no tenéis permiso para ver el contenido del directorio /root. Si lo ejecutáis con sudo sí que podréis. Eso sí, os pide vuestro password -para comprobar que no es cualquiera que se ha sentado un momento en vuestro PC y os quiere fastidiar el equipo-.

Para que esto funcione, vuestro usuario tiene que tener permisos de sudo. Esto se hace automáticamente para el usuario que se define en la instalación de sistemas operativos como Ubuntu y derivados.

En cualquier caso, aquí tenéis más información sobre sudo y cómo configurarlo para un usuario.

Así, si en un script necesitáis ejecutar algo con permisos de root podéis usar sudo. Ahora bien, tended en cuenta que os va a pedir el password, por lo que no podéis lanzarlo y marcharos, ya que se quedará esperando que pongáis el password de vuestro usuario. Imaginad que lanzáis un script que hace mogollón de cosas -en las que tarda un tiempo- y luego, al rato, en uno de los comandos que hay en el script, usa sudo para ejecutarse como root. Tendréis que estar sentados todo el rato hasta que os la pida.

Para salvar esto podéis usar la opción -S, que permite que se le pase el password en la línea de comandos. Se usaría así:

echo PASSWORD | sudo -S ls /root

Evidentemente, el comando que ejecutaréis en el sudo, normalmente será algo más complicado que éste ;-P (y más útil).

Por tanto, con sudo -S podemos, bien pedir el password al principio del script (con read) o bien cogerlo de algún sitio. En este último caso hay que tener presente que el password estaría almacenado en claro en ese «sitio», por lo que conviene que tenga permisos de lectura sólo para el propio usuairo (algo como «chmod 600 fichero«, por ejemplo).

Espero que os resulte útil.

Ejecutar scripts al inicio de Linux

A veces es interesante que al arrancar nuestro equipo se ejecuten ciertos scripts.

Si tenemos una distro Ubuntu o basada en ella, podemos usar /etc/rc.local, es decir, meter la llamada a dicho script dentro de este fichero (antes del «exit 0», lógicamente).

Sin embargo, desde que Ubuntu usa Upstart como sistema de arranque no tengo claro que sea una buena forma de iniciar los scripts ya que es posible que no se ejecute correctamente si depende de otros servicios, como podría ser el de red. En otras palabras, que puede que metas un script que haga algo como enviar un mail (en otro artículo veremos este caso) pero que no esté iniciado el servicio de red y no se ejecute. A mí me ha pasado.

Por eso, para estos casos recomiendo que metáis el script dentro de /etc/network/if-up.d. Los scripts que se encuentren en dicho directorio se ejecutarán sí o sí cuando el servicio de red esté operativo.

En openSUSE el directorio es /etc/sysconfig/network/if-up.d.

OJO: los scripts deben ser ejecutables (algo lógico) y no pueden tener extensión, es decir, si tenéis algo como enviar_mail.sh cambiadlo a enviar_mail (me costó un rato de «googleo» para descubrirlo).

En otro artículo veremos cómo enviar precisamente un mail desde un script (usando nuestra cuenta de gmail) para notificarnos cualquier cosa.

Yo, en particular, tengo un script que me envía un mail cada vez que enciendo el PC de casa para saber que está encendido. ¿Para qué me puede servir? Por ejemplo: para saber que el PC está ya operativo tras haberlo encendido remotamente (más info aquí) 😉

Habilitar Nvidia Optimus en openSUSE

La mayoría de las CPUs actuales tienen incorporado un chip gráfico. Por ejemplo, un Intel Core i3, i5 ó i7, posee dentro del propio procesador una tarjeta gráfica integrada también de la compañía Intel.

Por tanto, si os compráis un PC y le ponéis un Core i5, por ejemplo, no necesitáis ponerle aparte una tarjeta gráfica, porque este procesador ya lleva una sencilla (aunque para muchos casos es suficiente) tarjeta gráfica incorporada.

Ahora bien, si alguien necesita más potencia en los gráficos (para disfrutar de los últimos juegos, por ejemplo), puede colocar una tarjeta gráfica pinchándola en una bahía pci express libre. El ordenador sabe (*) que debe usar esa nueva tarjeta más potente y obviar la Intel.

En los portátiles ocurre algo similar, sólo que no es posible pinchar una tarjeta gráfica más potente si es que la necesitamos. De hecho, dado que la capacidad de ampliación de un portátil es mucho más limitada que la de un PC de sobremesa, cuando compras un portátil, debes tener en mente qué uso le vas a dar, porque insisto, no es posible añadir una tarjeta gráfica al mismo.

Sin embargo, te puedes comprar un portátil con una tarjeta gráfica potente incorporada. ¿Cuál es el problema? Que un parámetro importante en los portátiles y que no lo es en los de sobremesa es la batería, y es que una tarjeta gráfica potente consume mucha batería. ¿Qué hacer entonces?

Pues los fabricantes de chips gráficos, y cuando digo los fabricantes me refiero sobre todo a AMD y Nvidia, han desarrollado tecnologías que permiten disfrutar de grandes capacidades de procesamiento gráfico y al mismo tiempo la posibilidad de ahorrar batería. ¿Cómo lo consiguen?

La idea es que el portátil dispone de dos tarjetas gráficas, una es la integrada en el procesador que comentábamos antes (una Intel si es un Core iX o una ATI si es un AMD) y la otra es una tarjeta gráfica discreta (**) más potente instalada en la placa del portátil. Las tecnologías que han implementado las dos compañías (AMD y Nvidia) se basan en que se usa normalmente la tarjeta gráfica sencilla, es decir, la integrada en el procesador, ya que consume mucha menos batería mientras que la tarjeta gráfica discreta está apagada. Por otra parte, cuando se necesita tirar de alto procesamiento gráfico (por ejemplo, para correr un juego exigente), automáticamente activa la tarjeta gráfica discreta y permite jugar sin problemas, consumiendo más batería, lógicamente, pero permitiendo disfrutar de toda la potencia que ofrece dicha tarjeta.

Esta tecnología se conoce con Optimus si la tarjeta discreta es Nvidia, o PowerXpress si se trata de una tarjeta AMD (***).

En particular, mi portátil dispone de la primera (Optimus), teniendo un chip gráfico Nvidia Geforece GT 525M. En Windows, los drivers de Nvidia implementan esta tecnología perfectamente y funciona de forma automática nada más instalarlos.

En Linux, sin embargo, aún tenemos ciertos problemas ya que los grandes fabricantes, aunque ya empiezan a desarrollar drivers para este sistema, aún no son tan completos como los de Windows. En particular, la tecnología Optimus no está completamente soportada con estos drivers. ¿Qué hacer entonces?

Lo de siempre ;-). En Linux tenemos la suerte de que surgen grandes proyectos de gente que aporta su tiempo, ganas y conocimientos para desarrollar mediante distintas técnicas (muchas veces basadas en ingeniería inversa) drivers de gran calidad. Para soportar Optimus en Linux, de hecho, existe un proyecto llamado Bumblebee que permite desconectar la tarjeta gráfica discreta para que el portátil no consuma mucha batería y activarla sólo cuando sea necesario.

Si usáis openSUSE, como yo actualmente, aquí tenéis un enlace a una web que os explica cómo dejarlo configurado en vuestro sistema. Este enlace está enfocado para la versión 13.1 de openSUSE, que es la última en estos momentos, pero también está para la 12.3. Es sólo cuestión de buscar un poco.

Yo lo tengo configurado y se nota y mucho en el consumo de la batería y en el ventilador, que ahora está apagado casi siempre y se agradece. Por el mismo motivo, el portátil se calienta menos.

Esto es debido a que con Bumblebee la gráfica discreta está apagada por defecto. Con la aplicación powertop podemos ver el consumo:

La batería reporta una tasa de descarga de 19.0 W
The estimated remaining time is 1 hours, 47 minutes

Como vemos, la tasa de descarga es de unos 19 W (digo «de unos» porque va variando, pero la media está por los 19-20 W). Esto le da de vida al portátil más de hora y media sin tener que conectarlo a la corriente.

Para comprobar que estamos trabajando con la tarjeta gráfica integrada (no la discreta), podemos ejecutar glxgears, que nos dice la tasa de frames por segundo que es capaz de procesar:

305 frames in 5.0 seconds = 60.797 FPS
300 frames in 5.0 seconds = 59.816 FPS

Para activar la tarjeta discreta usamos el comando «optirun» antes de la aplicación a usar. Así, por ejemplo, para ejecutar glxgears con la tarjeta gráfica discreta ejecutaremos:

optirun glxgears

Esto nos da una tasa de más de 1500 frames por segundo:

7633 frames in 5.0 seconds = 1526.421 FPS
7555 frames in 5.0 seconds = 1510.848 FPS

Sin embargo, si ejecutamos powertop mientras está lanzado este último comando (i.e., con la tarjeta gráfica discreta activada), la tasa de descarga sube bastante:

La batería reporta una tasa de descarga de 62.7 W
The estimated remaining time is 0 hours, 29 minutes

Realmente no es un valor sostenido, luego baja a valores entre 30 y 40, luego vuelve a subir un poco pero, en cualquier caso, se ve que consume mucho más que con la tarjeta gráfica integrada.

 

 

(*) Y si no lo deduce se puede configurar en la BIOS del equipo.

(**) Dado que actualmente ya es muy común encontrar tarjetas gráficas integradas en otros chips, como es el caso de los procesadores Core iX, por ejemplo, se usa el término tarjeta discreta para referirse a la tarjeta gráfica que va pinchada en placa, es decir, la tarjeta gráfica de toda la vida, que es independiente del procesador.

(***) La compañía ATI, competencia directa de Nvidia desde hace años, fue comprada por AMD, por lo que ahora la lucha no es entre Nvidia y ATI sino entre Nvidia y AMD. Intel también fabrica sus propios chip gráficos (los que incluyen en sus procesadores Core iX), pero no están aún a la altura de competir en potencia gráfica con los dos primeros.

Qué es la virtualización

En una entrada anterior (concretamente en ésta) os comentaba cómo virtualizar de forma muy sencilla usando el software VirtualBox.

En aquél artículo comentaba que no iba a entrar a explicar qué era la virtualización, los tipos que hay, etc. Bien, pues eso es lo que os voy a explicar en éste.

En lugar de escribiros un artículo, que puede ser un poco pesado para leer (me suelo enrollar bastante, lo reconozco), me remito a la presentación que hice allá por Julio de 2011 y que expuse en la Universidad durante un pequeño ciclo de charlas de Caldum.

Era una charla corta, así que intenté abreviar pero dejando -o intentándolo, al menos- los conceptos lo más claros posibles. Al final de la misma se explica brevemente cómo usar KVM.

Aquí os pongo el enlace para que los descarguéis la presentación en pdf.

 

Detectando fallos de disco con S.M.A.R.T.

En un anterior artículo os mencioné que existía una tecnología llamada S.M.A.R.T. que sirve para detectar los fallos de los discos duros y poder actuar antes de que sea demasiado tarde. Os comenté que ya os hablaría en otro artículo de ella. Bien, pues ha llegado el momento 😉

Las siglas de S.M.A.R.T. significan Self Monitoring Analysis and Reporting Technology, y como su nombre indica, es una tecnología que sirve para analizar, monitorizar y obtener informes de los parámetros que influyen en la vida de los discos duros.

Para poder usar esta tecnología, ésta debe estar soportada por el disco duro (prácticamente todos los discos duros actuales, si no todos, la soportan) y también por la BIOS (lo que también suele suceder), donde tiene que estar habilitada.

Dado que es una tecnología que sirve para almacenar datos estadísticos de errores y uso del disco duro que os permitirán anticiparos a la pérdida de datos, no hay razón para no activarla. En algún foro leí una vez que la única podría ser que usárais algún tipo de disco flash de los primeros que no soportaran esta tecnología y, por tanto, al estar activada en BIOS, os diera problemas para arrancar (puesto que el disco no la soporta). En cualquier otro caso (que será el 99,99%) os recomiendo que la activéis.

Para consultar los datos que se van guardando sobre el estado del disco duro, existen muchas utilidades (tanto para Linux como para Mac y Windows). En mi caso, me voy centrar en la utilidad para Linux llamada smartmontools.

Para instalarla, ya sabéis (en debian y derivadas):

aptitude install smartmontools (*)

Esto os proporciona el comando smartctl, con el que podréis realizar varios tests y ver la información recogida por S.M.A.R.T. en vuestro disco duro. A continuación vamos a ver algún ejemplo.

smartctl -i /dev/sdx

donde /dev/sdx el disco duro que queréis chequear (/dev/sda, /dev/sdb…; si son IDE: /dev/hda, /dev/hdb…).

Este comando nos da distinta información del disco duro (número de serie, versión del firmware, si está habilitada o no la funcionalidad SMART…):

# smartctl -i /dev/sdb
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.8.0-19-generic] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model: ST9750420AS
Serial Number: 5WS3JZ6F
LU WWN Device Id: 5 000c50 04521203c
Firmware Version: 0002DEM1
User Capacity: 750.156.374.016 bytes [750 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Fri Nov 15 09:56:34 2013 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Otro ejemplo:

# smartctl -H /dev/sdb
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.8.0-19-generic] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Please note the following marginal Attributes:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
190 Airflow_Temperature_Cel 0x0022 067 035 045 Old_age Always In_the_past 33 (0 18 33 24 0)

Este comando muestra información sobre el estado de salud general del disco. Si pone PASSED, como en el ejemplo mostrado, el disco duro está Ok. Si mostrara algo como FAILING, entonces tenemos que pensar en hacer backup inmediatamente.

En concreto, os pongo el ejemplo de otro disco duro que tengo que me ha dado algún que otro problema últimamente:

# smartctl -H /dev/sdl
smartctl 6.2 2013-04-20 r3812 [x86_64-linux-3.11.0-13-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
 5 Reallocated_Sector_Ct 0x0033 001 001 036 Pre-fail Always FAILING_NOW 4095

Como véis, tiene problemas (y no pequeños). El problema es que están fallando muchos sectores (ha habido muchos realojamientos de sectores). Total, que me tengo que comprar otro.

Ahora probemos este comando:

smartctl -A /dev/sdb

Con este comando se muestran diferentes atributos SMART del disco duro (en concreto, se muestran 30):

smartctl_a

En este caso ponemos una captura de pantalla para que se vean más claros los datos del ejemplo.

Aspectos interesantes de los datos aportados por el comando anterior:

  • RAW_VALUE es el valor crudo, es decir, el valor real. Por ejemplo, el número de horas que lleva el disco encendido.
  • VALUE. El valor RAW_VALUE es convertido a un número entre 1 y 253 por un algoritmo ejecutado en el propio firmware del disco. Aquí, los números bajos son malos y los altos son buenos. Si un valor es igual o está por debajo del umbral (columna THRES, de THREShold), diremos que el disco ha fallado y aparecerá en la columna WHEN_FAILED. Si esta columna aparece vacía es que todo va bien (las cosas no están fallando). Si hay valores en sus filas, entonces debemos empezar a pensar en hacer backup y cambiar de disco.
  • TYPE. Vemos dos posibilidades: Pre-fail y Old-age. Quiere decir que si observamos un fallo en algún atributo de tipo Pre-fail, se espera un fallo inminente del disco. Si falla en alguno de Old-age, es que se ha alcanzado el final de la vida del disco.

Además de smartctl se incluye, en el paquete smartmontools, el demonio smartd. Éste se encarga de realizar monitorización periódica de los discos del equipo y tomar las acciones que se le indiquen en su fichero de configuración, como enviar un mail al administrador de sistemas, por ejemplo.

Para más información al respecto podéis visitar la wiki oficial del proyecto aquí.

 

(*) Yo siempre uso aptitude, pero podéis usar igualmente apt-get. También podéis usar la utilidad de vuestra distro para instalar software (Synaptic, Muon…). Si queréis usar aptitude pero no está instalada (en las últimas versiones de Ubuntu/Kubuntu/… ocurre), haced esto:

apt-get install aptitude

Reparar disco duro con sectores defectuosos

Introducción

La vida útil de los discos duros es limitada, y más con el uso que les damos actualmente; ¿quién no se ha comprado un disco de 1 TB y al poco tiempo lo tenía completamente lleno?

Por eso, es bueno hacer copias de seguridad con cierta periodicidad, dependiendo ésta de la criticidad de los datos (del valor que tengan para nosotros) y de la frecuencia de modificación de los mismos.

Si no tenemos la precaución de hacer estas copias de seguridad y ocurre un fallo en el disco duro es probable que perdamos todo, y la recuperación de nuestros archivos, si aún es posible, puede tener un coste que se puede escapar de un bolsillo normal y corriente (como el mío por ejemplo). Vamos, que en estos casos casi merece más la pena hacer de nuevo el viaje al Caribe que enviar el disco a reparar para recuperar las fotos del que hicimos el año pasado.

En ocasiones no se estropea completamente el disco, sino que da fallo en algún sector (sector es la unidad lógica mínima de un disco duro, para entendernos). Esto lo notamos cuando vamos a copiar un archivo a o desde un disco duro y se queda un rato «pensando», dando error de copia al final (normalmente de «redundancia cíclica»).

El que en un disco duro comiencen a fallar los sectores es señal de que es el principio del fin del mismo. Esto no tiene por qué suponer que haya que tirarlo, ni mucho menos, pero yo no dejaría en dicho disco mis fotos más preciadas (al menos, no sin tener un par de copias más en otros lugares).

A pesar de estos pequeños fallos podemos seguir utilizándolo con la particularidad de que cuando vaya a usar ese sector o sectores defectuosos probablemente volverá a dar fallo. ¿Cómo aislamos estos sectores de forma que el sistema operativo no los use más y así no provoque estos fallos? Esto es lo que vamos a tratar de contestar en lo que resta de post, porque vamos a ver cómo hacer esto (en GNU/linux, por supuesto) con distintas herramientas, como badblocks o fsck -entre otras-.

Badblocks

Cito de la Wikipedia (lo explican genial, como siempre): «badblocks es una utilidad disponible para Linux que permite localizar y aislar los sectores defectuosos de una unidad de disco».

Por tanto, ejecutando dicha utilidad (aunque se puede usar también como parte de la utilidad e2fsck) podemos recopilar una lista de sectores defectuosos encontrados. Esta lista la podemos guardar en un fichero de texto plano que luego podemos pasarle como argumento al comando que realiza el formateo para que tenga en cuenta dichos sectores defectuosos y no los use.

Por tanto, primero ejecutaríamos la utilidad badblocks sobre nuestro disco (pongamos que es, por ejemplo /dev/sdb, aunque podemos especificar también una partición, como «/dev/sdb5»):

# badblocks -svn /dev/sdb -o sectores_defectuosos.txt

donde:

-s –> muestra una barra de proceso
-v –> modo verbose (muestra los errores encontrados)
-n –> usa el modo no destructivo
-o –> especifica el fichero donde se guarda la salida

Al ejecutar dicho comando aparecerá algo como:

Revisando los bloques dañados en modo lectura-escritura no destructiva

Esto quiere decir que no se van a borrar los datos que tenemos en el disco. Aparecerá un porcentaje que va subiendo muy lentamente, así que armaros de paciencia porque es un proceso lento (pensad que va sector a sector y en un disco de 500 GB, por ejemplo, tiene más de 1000 millones de sectores (de 512 bytes cada uno).

Ahora formatearíamos el disco duro (o partición). Si lo queremos en fat32, lo haríamos así:

mkdosfs -F32 -v -l sectores_defectuosos.txt -n LABEL /dev/sdb

Si lo queremos en ext4 haríamos esto:

mkfs.ext4 -v -l sectores_defecuosos.txt -L LABEL /dev/sdb

donde:

-v –> modo verbose (muestra toda la salida de mensajes)
-l –> Le indicamos el fichero que contiene la lista de sectores defectuosos
-n/-L –> Especifica la etiqutea (LABEL o nombre de Volumen) del disco o partición (en mkdosfs esta opción es con «-n» y en mkfs.ext4 -en mke2fs en general- se usa la opción «-L»)

Otras posibilidades

Con mkfs.ext4

También se podría hacer ambas cosas al mismo tiempo de esta forma:

mkfs.ext4 -c /dev/sdb

donde:

-c Es para marcar los bloques defectuosos. Si pusiéramos -cc hace una búsqueda pero no destructiva

Con fsck.ext4

También se puede pasar un chequeo (con fsck) y pedirle que repare todos los fallos que encuentre:

fsck.ext4 -c -p /dev/sdb

donde:

-c (ídem del anterior)
-p Busca y repara los errores

Utilidades de los fabricantes de discos duros

Cada marca tiene su propia utilidad (la cuál, en principio, sólo vale para los discos de esa marca). Suelen funcionar bastante bien. En particular, yo he probado la de Seagate en alguna ocasión con buen resultado. En este caso, la utilidad se llama Seatools y tenéis la posibilidad de descargaros una iso con la que podéis arrancar (previo a quemar un CD con ella, obviamente) vuestro equipo y lanzarla directamente para revisar vuestro(s) disco(s) duro(s).

S.M.A.R.T

Por último, comentaros que existe una tecnología llamada SMART que permite monitorizar el estado del disco de forma que se pueda uno anticipar a un fallo grave pudiendo recuperar los datos antes. Pero de esto hablaremos en otro artículo.

Apuntes finales

Con las utilidades badblocks (en windows tendríamos chkdsk, con resultados similares), estamos solucionando el problema a nivel del sistema de ficheros. Esto quiere decir que nosotros lanzamos la utilidad para que se marquen los sectores defectuosos y el sistema operativo será consciente de ello, de forma que la próxima vez que vaya a escribir en los mismos, al verlos marcados, no lo haga y busque otros «sanos».

Sin embargo, es menester comentar -ya para terminar este artículo- que los propios discos duros también realizan su detección de sectores defectuosos, de tal forma que si en una escritura de un sector observan que éste tiene algún problema, directamente lo descartan y usan otro, siendo todo esto transparente al sistema operativo. Mediante S.M.A.R.T. al que hacíamos referencia antes (y del que probablemente hablaremos en un artículo próximo) se pueden consultar estos cambios, de forma que si vemos que se están produciendo muchos, podemos comenzar a plantearnos cambiar de disco duro.

Hay mucha información sobre esto en Internet. En partcicular, os recomiendo empezar por aquí.

Espero que os haya resultado útil el artículo.

Cambiar fondo y color de fuentes en GRUB 2

Cambiar fondo en grub

Aunque hay distros que ya personalizan el fondo (*) de GRUB (como Suse, por ejemplo), otras no lo hacen, dejando el texto sobre un fondo negro.

Si el último es nuestro caso, podemos cambiarlo fácilmente añadiendo esta línea a /etc/default/grub:

GRUB_BACKGROUND=/usr/share/images/grub/Hortensia-1.tga

donde le indicamos cuál será la imagen que mostraremos de fondo en GRUB. En este caso, la imagen tiene por nombre «Hortensia-1.tga». Por defecto, en dicho directorio aparecen varias imágenes ya preparadas para mostrarse correctamente (de 8 bits, RGB), por lo que podemos elegir una de ellas para probar.

Para aplicar los cambios ejecutamos:

update-grub

Tras esto reiniciamos y ya tendremos nuestro fondo de imagen en su sitio.

Si ahora queremos cambiar la imagen de fondo tendremos que editar de nuevo el fichero y volver a ejecutar el comando «update-grub». Para ahorrarnos este paso, podemos crear un enlace simbólico llamado -por ejemplo- «grub.tga» en dicha ruta a cualquiera de los archivos .tga de dicha ruta. En el fichero haremos referencia a este «grub.tga» y cada vez que queramos cambiar el fondo simplemente cambiaremos el enlace simbólico, que apuntará a otra imagen.

Cambiar color fuentes de texto en grub

Para cambiar el color de las fuentes que se muestran (tanto del texto seleccionado como del que no lo está) cambiamos, en /etc/grub.d/05_debian_theme, esto:

if [ -z "${2}" ] && [ -z "${3}" ]; then
 echo " true"
 fi

por esto:

if [ -z "${2}" ] && [ -z "${3}" ]; then
 # echo " true"
 echo " set color_highlight=red/green"
 echo " set color_normal=light-cyan/black"
 fi

donde:

  • en «set color_highlight» especificamos el color y fondo del texto seleccionado
  • en «set color_normal» especificamos el color y fondo del texto no seleccionado

Están soportados estos colores en grub:

black, blue, brown, cyan, dark-gray, green, light-cyan, light-blue, light-green, 
light-gray, light-magenta, light-red, magenta, red, white, yellow,

Para aplicar los cambios ejecutamos, al igual que antes:

update-grub

Esta información ha sido extraída de este excelente artículo, por lo que si queréis profundizar más en este tema, os remito directamente a él. De hecho, en el caso de cambio de fondo de escritorio, yo he seleccionado el método que más cómo me ha resultado, pero en el artículo se proponen varios más.

 

(*) Aunque aquí nos referimos a la imagen como «fondo», ésta se refiere a la grub splash image, que es la imagen que aparece cuando se muestra GRUB en pantalla tras arrancar o reiniciar el PC.

Sincroniza tu música en todos tus equipos

Actualmente están muy de moda servicios para reproducir música online (como Spotify o Grooveshark, por ejemplo), lo que se conoce como streaming de audio. Esto permite escuchar música en todos tus dispositivos sin tener que llevar físicamente la música copiada en ellos.

Si eres usuario de estos servicios y estás cómodo con ellos, este artículo no es para tí. De hecho, este artículo está dirigido a aquéllos quienes, como yo, aún prefieren llevar sus canciones (mp3, ogg…) en su dispositivo y reproducir la música que les gusta sin anuncios, a cualquier hora y sin la necesidad de una conexión permanente a Internet (con la suficiente calidad, además, para que no haya cortes).

El problema de este sistema que planteo, es que tienes que copiar toda tu música a todos los dispositivos que uses (portátiles, PCs, netbooks…). Realmente, no es necesario copiar absolutamente toda la música, pero si tienes espacio en los discos, ¿por qué no?

Una vez que has efectuado la copia ya está superado este primer obstáculo pero, si consigues unas canciones nuevas que quieres añadir a tu biblioteca, ¿cómo actualizas la música en todos los equipos de forma fácil y sin que queden inconsistencias? Cuando digo inconsistencias me refiero a que un dispositivo tenga menos canciones que otro porque no las hemos copiado todas, y es que si son 4 canciones no hay problema, pero si son 321 canciones distribuidas en distintos discos y que deben ir a distintas carpetas… la cosa se complica.

Para evitar estos problemas, yo uso el siguiente sistema. Tengo un disco externo donde está toda la música. Podríamos decir que es la copia maestra, la principal. Desde ese disco externo hago una primera copia a cada dispositivo donde quiero llevarla, es decir, lo voy conectando a cada equipo y traspasándole toda la música.

Cuando hay nuevas canciones/discos los añado, en su lugar correspondiente, dentro del disco duro externo (que hemos dicho que es la copia principal, que siempre contiene la versión más actualizada de la biblioteca). Una vez hecho esto, conecto dicho disco externo a cada dispositivo y, mediante rsync, se actualizan todos los nuevos ficheros.

También, si repasando nuestra biblioteca de música detectamos que hay algún disco que no nos gusta, canciones que queremos borrar, mover de sitio, etc., lo hacemos en el disco externo. De esta forma, cuando hagamos de nuevo un rsync con cualquier PC/portátil/…, este último tendrá sincronizada toda la música (incluyendo todos estos últimos cambios que hemos hecho).

Para facilitar las cosas, uso siempre la misma ruta en todos los dispositivos, de forma que el comando rsync a ejecutar es el mismo en todos ellos:

rsync -arvtl --no-whole-file --delete RUTA_EN_DISCO_EXTERNO  RUTA_EN_NUESTRO_PC

Las opciones que uso son éstas:

-r: recursivo

-l: copia los enlaces simbólicos como enlaces simbólicos (no los archivos a los que apuntan)

-t: conserva los tiempos de modificación de los archivos

-v: verbose

-z: comprime los datos de los ficheros durante la transferencia de un equipo al otro

–no-whole-file: no copia los archivos enteros, sólo las modificaciones

–delete: borra los archivos en el destino si se han borrado en el origen

Como la ruta donde está la música es exactamente la misma en todos mis dispositivos, puedo crear un script (*) que me vale para todos. Para ello -oye-, básicamente, metéis el comando anterior en un script, le dáis permisos de ejecución y lo copiáis en /usr/local/bin (por ejemplo).

Cada vez que vayáis a actualizar la colección con algún CD nuevo, etc., lo hacéis en el disco duro externo. Luego, simplemente ejecutáis el script tras conectarlo en cada PC, portátil, etc..

De esta forma, siempre tendréis vuestra música sincronizada en todos los dispositivos, es decir, tendréis los mismos archivos y directorios en todos vuestros equipos.

Por útlimo, si guardáis también dentro de vuestra colección de música un directorio con las listas de reproducción (.m3u normalmente), también las tendréis actualizadas. Si además usáis las mismas combinaciones de teclas en todos los equipos, podréis escuchar los discos de la misma forma en cada equipo. En mi caso particular, cuando pulso por ejemplo la combinación de teclas Windows+Alt+F4 suena un recopilatorio que comienza con Jump, de Van Halen. Tras la sincronización inicial, podré escuchar dicha lista de reproducción en cada equipo.

 

(*) Esto del script tiene aún más sentido cuando usáis Dropbox (o servicio similar). Yo tengo todos mis scripts en Dropbox y, nada más instalar un equipo, sincronizo Dropbox y enlazo simbólicamente todos los scripts en /usr/local/bin. De esta forma, cada vez que modifico un script, se modifica para todos los equipos.