Atrapado por el hardware antiguo

Llegó su final mucho antes de lo que deseaba, y eso que ya tiene su década de servicio. Hablo de una unidad de cinta HP C1533A que está comenzando a dar fallos en la lectura de las cintas, y ha llegado incluso a partir una. Bueno, esto es una deducción mía muy provisional, pero he llegado a ella tras observar que aunque los datos de copias anteriores se han grabado bien, los extraños ruidos que se escuchaban han sido siempre los mismos, incluyendo hace dos días cuando he tenido que sacar la cinta con los dedos.

Respecto al bus [[WP SCSI]] el hardware que monta la máquina es el siguiente:

• Controladora Advansys ABP940U / ABP960U
• Disco Maxtor STM 325082 de 232 Gb.
• Unidad de cinta HP C1533A DDS-2 DAT.

Y para empeorar las cosas en el disco está montado el sistema raíz en una partición, el área de intercambio (swap) en otra y la tercera forma parte de un volumen LVM.

Las opciones que se me presentan, dado que la unidad de cinta está más que descatalogada, son las siguientes:

1. Intentar encontrar reemplazo en tiendas de segunda mano.
2. Sustituirla por una unidad nueva.

La primera opción es la que más problemas resuelve, siempre que sea posible encontrarla, puesto que puedo:

• Conservar la inversión en cintas DAT
• Inscribir la unidad de cinta en el sistema de copias sin alterar la definición de las mismas.

La segunda opción es más complicada puesto que las nuevas unidades funcionan con estándares DDS superiores, lo que suele significar que mientras es posible en algunos casos leer los formatos antiguos, generalmente no se puede escribir sobre ellas. Y sí, tengo acceso a la información, pero debo restructurar el sistema de salvaguarda.

De momento estoy intentando encontrar reemplazo, veremos más tarde en qué queda.

Unknown media type in type

De cuando en cuando, en las actualizaciones en Debian Sid aparece este mensaje en grupo, y con diferentes valores:

Unknown media type in type 'print/driver'

Unknown media type in type 'print/folder'

Unknown media type in type 'print/jobs'

...

Tras una pequeña búsqueda he encontrado un informe en el error 469833 del paquete shared-mime-info, y alguna mención más en foros sueltos.

No, no es un error grave, como bien se dice en los enlaces anteriores, pero como no me ha terminado de gustar he investigado un poco más, y he encontrado la causa en los fuentes de shared-mime-info.

Resulta que el programa update-mime-database emplea una lista de directorios contra los que verifica los archivos MIME encontrados, y que le sirve para descartar. Esta lista, en la versión 0.23 del paquete, contiene los siguientes valores:

• text
• application
• image
• audio
• inode
• video
• message
• model
• multipart
• x-epoc

Aún estoy pendiente de averiguar qué paquetes instalan entradas en esta base de datos.

Enlaces

• Tipos MIME según IANA.

Acer Aspire 9500 sin teclado

Un conocido cercano me contó que tenía un problema verdaderamente extraño con su ordenador. Es un portátil, un Acer Aspire 9500, grande y pesado, que presentaba un comportamiento exasperante: el teclado dejaba de funcionar en cuanto entraba en Windows XP.

Tenía acceso al BIOS con él, por lo que no parecía un problema hardware, y se las podía apañar con un teclado externo, vía USB. Habían intentado varias veces reinstalar desde el principio el sistema operativo, incluso formateando el disco a bajo nivel, pero nada de nada; el teclado desaparecía en cuanto WinXP mostraba su pantalla de arranque.

Como coincidimos todas las mañanas en el bar y es buen chico, le dije que me pasase la máquina y que le echaría un vistazo, seguro de que no habían reinstalado tanto como decía, y que bastaría con echarle un vistazo desde GNU/Linux para arreglar el asunto. Pues no, tampoco, en cuanto arrancaba una Knoppix el teclado volvía a desaparecer.

Angel y yo estuvimos haciendo pruebas y él dió con la solución: desactivar el ACPI en el arranque usando el parámetro acpi=off.

En WinXP la cosa pintaba mal, primero por mi inexperiencia con los entresijos del arranque en dicho entorno, y segundo porque no conseguía encontrar en la red ningún parámetro mágico con el que desactivar dicho ACPI. Y sí, si existe un método utilizando el disco de instalación, pero al no tener a mano un teclado USB no me parecía práctico.

Tras pensar un buen rato en ello a Angel se le ocurrió que el código del ACPI podía estar corrupto (dado que ese PC ha funcionado con normalidad anteriormente), y que la solución para ello podría ser:

1. Entrar en el BIOS y cargar los valores de fábrica, los más seguros. Lo hicimos y nada, seguía igual. El BIOS, todo hay que decirlo, es de esos escuetos que apenas de dejan tocar nada, como mucho el órden de arranque en las unidades.
2. Reinstalar el firmware del ordenador. Esta operación es bastante más complicada y la describo abajo.
3. Restaurar la máquina al estado de fábrica, empleando los programas que para ello residen en una partición oculta del sistema. Una operación sencilla de realizar (empleando Alt+F10 con Windows funcionando) y que deja el sistema como nuevo.

... Y no da buenos resultados porque el portátil se niega a funcionar si no es con un teclado externo.

En este punto, y visto que no encuentro más información en la red sobre ello, voy a recomendar al propietario que lo lleve a un servicio técnico puesto que no hay manera de modificarlo.

Investigando más me he encontrado con un problema mucho más habitual de lo que uno pudiera pensar: DSDT corrupto ó incorrecto. Al parecer, dentro de ACPI existen varias tablas que proporcionan información al sistema y que pueden venir de fábrica con valores erróneos, ó sufrir algún tipo de corrupción de datos a posteriori. He visto en muchos sitios cómo alterar esas tablas, pero nada sobre qué cambiar en ellas, al menos nada que yo pueda entender.

Actualización: 7 de Marzo de 2008

He recopilado algo más de información sobre lo que le pasó a la máquina. Por lo visto la desaparición del teclado y el ratón fueron consecutivas; primero dejó de funcionar el teclado, mientras se usaba, y luego el ratón. ¿ Un virus ? Pues tal vez ...

Voy a intentar aplicar una solución mediante el uso del disco de instalación de WinXP que tal vez arregle algo de verdad.

Reinstalando el firmware

Son varios pasos, cada uno de ellos con sus correspondientes humillaciones y problemas, por este orden:

1. Descargar la última versión del firmware de la máquina del archivo oficial y descomprimirla.
2. Arrancar la máquina con una knoppix y el ACPI desactivado.
3. Dado que tenemos la red configurada para aceptar nuevas máquinas en cualquier momento (DHCP vamos), conectar el portátil a la red, montar el disco C: y transferir vía rsync todos los archivos del flasheador de Acer.
4. Reiniciar la máquina en --msdos--, aunque para ello tengamos antes que:
   1. Descargar si no se tiene ya una versión en CD de freedos.
   2. Copiarla a CD.
   3. Arrancar el ordenador con ella.
5. Acceder a la unidad C:
6. Cambiar a la carpeta donde tengamos los archivos para actualizar y ejecutar el flasheador, en este caso FLASH.BAT. Visto y no visto el programa efectúa su trabajo, indica que no hay error y reinicia.

Enlaces varios

Información que he ido reuniendo y que puede darme pistas para posteriores encuentros con estos problemas basura:

• Cómo arreglar problemas ACPI en Gentoo
• Proyecto ACPI en Linux
• Silenciando ventiladores en un HP Compaq para Windows XP

Cuatro años ya ...

... que acaba de cumplir Laura, mi meloncilla, no sé por qué, pero quiero recordarlo aquí con una pequeña selección de fotos. No son las mejores, porque en casa estoy temporalmente sin acceso a la red, y aquí en el trabajo no tengo más que una fracción de ellas; mejoraré la selección en cuanto pueda.

Ecoembes y linux

Ahora tenemos ya la declaración de envases anterior, y pretendo incorporarla a nuestra base de datos de alguna manera para poder manipularla mejor.

El archivo fuente es de tipo .mdb y en GNU/Linux se puede manipular hasta cierto punto con el paquete mdbtools que incluye un puñado de útiles.

Lo primero es obtener la estructura SQL para incorporarla a nuestro servidor:

$ mdb-schema -S ECO13148.mdb postgres > ecoembes.sql

Lo anterior extrae la estructura de tablas, limpia los nombres de los identificadores (aunque no del todo) y crea un archivo fuente SQL compatible con --postgres--.

Dicho fuente incluye un par de detalles molestos: la inclusión de sentencias de borrado de tablais y ciertos nombres de columnas completamente numéricos:

DROP TABLE Cliente;
CREATE TABLE Cliente
(
        901                     Bool,
        902                     Bool,
        903                     Bool,
        904                     Bool,
        Direccion               Char (100),
        CodEmpresa              Char (5),
        Nombre                  Char (50),

Para subsanarlo empleamos Perl de esta forma:

$ mdb-schema -S ECO13148.mdb postgres | \
    perl -p -e 's{^DROP.*$}{}xms;' -e 's{(\s+)(90\d)}{$1N_$2}xms' \
    > ecoembes.sql

De tal manera que lo anterior queda así

CREATE TABLE Cliente
(
        N_901                   Bool,
        N_902                   Bool,
        N_903                   Bool,
        N_904                   Bool,
        Direccion                       Char (100),
        CodEmpresa                      Char (5),

y ya tenemos un archivo SQL con el que crear una base de datos en --postgres--.

Después necesitamos cargar los datos, para lo cual usamos el programa mdb-export que inicialmente produce archivos en formato --csv--, pero que también puede crear sentencias SQL que insertan datos en las tablas.

Como mdb-export trabaja con una tabla a la vez podemos automatizar el proceso con un poco de bash:

$ for tabla in `mdb-tables -1 data/ECO13148.mdb` 
> do
> mdb-export -q"'" -R";\n" -I data/ECO13148.mdb $tabla >> carga.sql
> done

El parámetro -R le indica que añada el valor como delimitador de filas, y en mis pruebas he comprobado que mejor así, porque las instruciones SQL terminan con un punto y coma y las líneas en sí con un salto de línea.

Por su parte el parámetro -q indica qué usar para delimitar campos de tipo texto, que en el caso de --postgres-- deberán ser comillas simples.

Antes de pasar el archivo a --postgres-- debemos cambiar los nombres de las columnas que antes eran únicamente números; como ya sabemos que la tabla es la que contiene los datos del cliente, y no hay más código por ahora que los referencie, le aplicamos un filtro vía Perl de esta manera:

$ perl -p -e 's{(90\d)}{N_$1}gmxs if /^INSERT.*\sCliente\s/' < carga.sql > datos-ecoembes.sql

Los procesos anteriores, con algunos retoques, los he automatizado mediante un programa para obtener el esquema, y otro para volcar los datos. Ambos generan fuentes SQL que luego es cuestión de enviar al servidor.

La historia es triste y parece que bien conocida. Se desinstala algún paquete de un Windows XP y puede suceder que la máquina no vuelva a conectar nunca más.

El ordenador de un familiar, tras un corte inesperado de luz, no puede conectar con Internet. Tiene un router D-LINK DSL 524T, que mostraba el led de estado parpadeante, y WinXP informando de que la conectividad era nula ó incompleta en la tarjeta de red. Como veía que el sistema estaba funcionando sin pantallazos ni mensajes raros creí tontamente que el problema era del router, y tal vez tenía parte de razón, porque me lo llevé, le reinicié a los valores de fábrica ya que no respondía a conexiones HTTP ni DHCP, sólo al Telnet, le actualicé el firmware y le puse en marcha, menos la conexión ADSL, ya que no tenía acceso a la línea.

Pues bien, lo llevo de vuelta y como si quieres arroz Catalina, no había manera por ninguna de las dos tarjetas de red que el equipo tenía conectado. De vuelta a casa con el router y la caja, consulto con expertos en la materia (mi cuñado) y me indica que reinstale el protocolo TCP/IP, ó que intente la vuelta a un punto anterior. Lo primero sin efecto alguno (netsh int ip reset resetlog.txt y reiniciar) y lo segundo es lo que me pone sobre aviso; el usuario ha desinstalado la suite de Nokia y no me ha dicho nada, así que vuelvo al punto anterior a ese paso y reinicio.

Y sí, ahora es cuando veo el mensaje que da título a esta entrada, algo que el usuario tampoco me dice hasta que le pregunto directamente (para variar). Una búsqueda en la red me proporciona dos enlaces:

• En el estupendo BandaAncha.st alguien se queja de lo mismo y otro lo soluciona.
• El fabricante del sistema operativo tiene instrucciones detalladas.

Al final todo se ha reducido a emplear la orden netsh winsock reset y a reiniciar inmediatamente después.

Desde hace un tiempo estoy usando la extensión para Firefox/Iceweasel llamada foxmarks, que me permite conservar sincronizados mis marcadores en varias máquinas, siempre que nos las use al mismo tiempo, obviamente.

Hace poco anunciaron la versión 2.0 y funcionaba tan mal que tuve que reinstalar una versión 1, porque si lo que fallaba era la sincronización en un programa que sólo sirve para sincronizar ...

Una vez que lo hice me decidí por utilizar mi propio servidor WebDAV como depósito central, y me he encontrado con varios problemas absurdos, entre ellos el que desde hace unos días no funcionaba en absoluto, aunque yo creía que sí.

Me explico: una vez arrancado el proceso de sincronización, Foxmarks lee el archivo foxmarks.xml del servidor sin problemas (recibía generalmente un código 304 que indica que no hay cambios); luego envía los marcadores locales al servidor y cuando termina no aparece un error como tal, sino más bien un letrero informativo sobre que hay una precondición fallida.

Revisando los registros del servidor me encuentro un buen número de errores 412 devueltos, y entonces caigo en la cuenta de que la operación de escritura no había terminado bien, y se estaban produciendo errores fatales.

Buscando en el wiki de los autores encuentro la explicación, y una solución aparentemente no muy sana, pero que funciona. El fallo parece residir en el módulo mod_dav de Apache, registrado como error, y las soluciones propuestas son dos, y ambas tienen que ver con desactivar el mecanismo de protección contra sobreescritura que foxmarks incluye.

1. Incluir en la configuración del navegador la siguiente estrofa (vía about:config):

   user_pref("foxmarks.disableIfMatchOnPut", true);
   

2. Anular en el servidor la generación de etiquetas de respuesta HTTP con la directiva FileETag:

   FileETag None
   

   en la sección correspondiente.

De un tiempo a esta parte venían apareciendo unos resultados extraños con el complemento img de IkiWiki. En lugar de funcionar como antes se mostraba el siguiente mensaje:

[[img redimensionado fallido: Exception 410: no images defined `Resize']]

Y me tenía completamente descolocado porque me estaba fijando en el dato final Resize y el extraño código de error Exception 410, en lugar de en el mensaje intermedio no images defined.

Buscando en la red no encontré más referencias que las de mis páginas ya indexadas por los buscadores, donde la condición se repetía. Al final se ha resuelto tras comprobar minuciosamente que la página de la imagen que quiero incluir como miniatura, existe previamente definida.

Estaba cometiendo errores tan tontos como pasarle lo siguiente al complemento img

/images/hardware/dlink-dsl-g604t.jpg

mientras que la imágen real es

/images/hardware/dlink-dsl-g640t.jpg

En fin, para la próxima ya sabré que cuando algo así aparezca es que, me ponga como me ponga, la página no existe.

CUPS es un sistema estupendo para imprimir ... cuando no hay problemas. En caso de haberlos se suele convertir en bastante molesto y complejo para resolverlos, y eso que los autores han hecho muchísimos avances desde las primeras versiones. Hay cosas, sin embargo, que siguen siendo complicadas, y determinar a qué se debe el fallo es una de ellas.

En CUPS existe una norma respecto a qué hacer cuando una impresora presenta un fallo considerado grave, y para ello hay varias opciones:

• stop-printer: detiene la cola de impresión (éste parece ser el valor predeterminado).
• retry-job: reintenta enviar el trabajo cuando las condiciones de error desaparezcan.
• abort-job: cancela el trabajo de impresión.

Estos valores se especifican utilizando la directiva ErrorPolicy dentro de una definición de impresora, en el archivo /etc/cups/printers.conf, del que muestro una parte convenientemente arreglada:

<Printer hp3300>
    Info HP LaserJet 3330
    DeviceURI socket://hp3300.cruzada1.int:9100
    State Idle
    StateTime 1185963034
    Accepting Yes
    Shared Yes
    JobSheets none none
    QuotaPeriod 0
    PageLimit 0
    KLimit 0
    OpPolicy default
    ErrorPolicy retry-job
</Printer>

Para las siguientes impresoras podemos establecer el valor en el archivo de configuración /etc/cups/cupsd.conf incluyendo

DefaultPolicy policy-name

Enlaces

• fixing cups printer problem, donde se describe la política de errores de CUPS predefinida y una forma de alterarla. No es demasiado profundo, pero sirve como referencia.
• La entrada de Juliet Kemp que me ha puesto sobre la pista.

Para variar las cosas dejan de funcionar cuando más se las necesita. Esta mañana he intentando imprimir dos documentos PDF con mucha urgencia, porque me hacían falta para reparar daños en uno de los coches. El primero es un parte de la compañía de seguros, bastante grande, y el segundo un recibo del banco confirmando la puesta al día del pago de la póliza.

Nada. No había forma de que la impresora, una HP PhotoSmart 7760, marchase en absoluto. Los documentos se quedaban atascados en la cola y el servidor no mostraba error alguno con ella. Bueno, no lo mostraba en los sitios normales, porque sí que había una referencia al backend ptal en cierto archivo de registro perdido. Decía que fallaba con un código 143 pero nada más.

Lo más extraño es que es una instalación que no me ha dado problemas y suelo imprimir en ella con cierta regularidad; ayer, sin ir más lejos, imprimí una carátula para un DVD sin fijarme apenas en lo que hacía. Hoy, después de trastear mucho me entero que para que esta impresora funcione se puede usar el paquete hpoj ó el paquete hplip, con preferencia por éste último dado el modelo, pero no los dos al mismo tiempo. Pues bien, siempre he tenido los dos paquetes instalados (vete a saber por qué) y no he tenido problemas con ello para imprimir hasta hoy.

Desde luego supongo que los pasos que seguí fueron:

• Instalar el paquete hpoj.
• Leer la documentación y ver que recomiendaba hplip para este modelo en concreto.
• Instalar hplip, no desinstalar hpoj, y crear la impresora en cupsys.
• Usar la impresora normalmente durante unos meses.
• Alguna actualización de algún tipo hace que se reinicie el servicio de impresión ó algo similar (tengo que revisar los registros en /var/log/dpkg.log) y entonces deja de funcionar.
• Dado que un hecho de este tipo suele acaparar la atención inmediata del administrador, yo en mi caso, investigo y elimino el paquete hpoj, con lo que todo vuelve a funcionar como antes.

Actualización 9 de Octubre de 2007

El problema no es tener los dos paquetes instalados en la misma máquina, eso puede funcionar sin problemas; el problema aparece cuando los dos paquetes están utilizando la misma impresora. Y ahí si que hay conflictos.