El sistema funciona, pero no accede al monitor. ¿nVidia en linux?

Como ya había indicado en una entrada anterior, mi sistema presentaba un error bastante extraño; arrancaba, pero después de que se activara el protector de pantalla no se podía acceder al monitor. Funcionaba, por que respondía a las teclas mágicas (al reves que antes de actualizar la BIOS, que ni eso podía hacer). La única solución era acceder a un escritorio no gráficos adicional (Ctrl+Alt+F1 a F7), y luego volver al F2, que es el gráfico.
Este problema ya se ha indicado en Fedora en equipos con tarjetas nVidia, y una de las soluciones indicadas era desactivar el protector de pantalla (como siempre, no vamos apuntando las páginas web donde lo vemos). Así ha sido. He anulado el protector

y todo va como la seda. Por fin hemos logrado un funcionamiento adecuado sin sorpresas. Eso sí, al dejar el ordenador, aplico Super + L. La seguridad es importante.

Nautilus. Problemas... ¿con vlc?

Desde hace un tiempo —largo, no me acuerdo cuando empezó— estoy teniendo problemas con nautilus. El sistema —Fedora 25, pero también con 24 y 23...— se inicia, llamo a nautilus, trabajo en lo que sea y, tarde o temprano, nautilus se bloquea y hay que recurrir al teminal y matarlo

killall nautilus

Debido a ello normalmente llamo a nautilus desde el terminal, para leer los errores y comprender que pasa. En general los errores son del tipo

Stream with high frequencies VQ coding
libpng warning: iCCP: known incorrect sRGB profile

que asocio a un plugin de conversión de imágenes,

[00007f5f38d31c08] core decoder error: failed to create audio output
[000055be0e896ee8] pulse audio output error: digital pass-through stream connection failure: No soportado
[000055be0e896ee8] core audio output error: module not functional
[00007f5f38d57de8] core decoder error: failed to create audio output

que asumo que es algún sonido con codec no soportado,

pero cuando se bloquea todo los errores suelen ser

VLC media player 3.0.0-git Vetinari (revision 2.2.0-git-10582-g9eb9eb0bd2)
[00005596eb6311c8] core libvlc: Ejecutar vlc con la interfaz predeterminada. Use «cvlc» para usar vlc sin interfaz.
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory
QObject::~QObject: Timers cannot be stopped from another thread

que deberíamos asociar a VLC. El problema está en que muchos bloqueos se hacen sin que haya llamado a VLC o a cualquier vídeo.

Lo llevo con resignación. Una pequeña cruz de cada día

Kernel Linux 4.10

Se ha liberado el kernel 4.10. Para comentarios más técnicos existen páginas especializadas, pero en lo que importa a un simple usuario como yo destaco la mejora de la gestión de escritura a disco. Cuando Linux escribe al disco e intentas arrancar alguna aplicación, todos los procesos se bloquean hasta que el proceso de escritura se acaba, y como prueba de la relatividad del tiempo, a mi siempre me parecen horas. Como señala D'Oh! aquí estos problemas ocurren porque las escrituras intensas llenan las colas de la capa de bloques, y otras peticiones de E/S tienen que esperar mucho para ser atendidas. Teóricamente la versión 4.10 añade un mecanismo que controlará las escrituras y el bloqueo por la copia. Así que, Fedora, ¡ya estás tardando para actualizar el kernel! —ahora mismo tenemos instalada la versión 4.9.10—.

A ver si es verdad la rapidez en las actualizaciones en Fedora.

Actualización a Firefox 50. Bloqueo del navegador por el mensaje de error de la extensión dragdropupload

Eso mismo; por cierto, un error repetido en el tiempo y especialmente molesto. En la última actualización de Fedora Firefox se actualizó a la versión 50 (y otras muchas cosas). Al lanzar el nuevo navegador apareció un mensaje de error que lo bloqueaba continuamente haciendo imposible su uso. No he guardado instantáneas, pero era un mensaje de un Java Script similar a

"...dragdropupload TypeError: can't access dead object..."

La única solución fue, tras tratar de cerrar el mensaje muchas veces, aceptar la posibilidad de eliminar todos las extensiones. Al arrancar empezará a cargar de nuevo todas las extensiones, ya que se sincroniza entre todas las máquinas, y hay que estar rápido de reflejos para eliminar la extensión en cuestión. De paso eliminé algunas que tenía desde hace tiempo y que ya no utilizo.

Las ventajas has sido claras; en primer lugar Firefox arranca antes (se ve que tenía demasiadas extensiones) y además sincronizan los cambios a las otras máquinas, con lo que al día siguiente ya estaban aplicadas en mi despacho, como se puede ver en la siguiente captura de pantalla.

Menos mal, por que estos 15 minutos de Chrome me habían generado un dolor de cabeza...

Aparcamiento. Cuando el S.O. se bloquea y resulta ser...

...Windows XP. ¿Acaso lo dudaban? Pues sí. Hoy, con toda la prisa imaginable, ya que el aparcamiento era el del Hospital, de repente perdemos 10 minutos en el aparcamiento. Cuando la gente que estaba delante sacó los coches marcha atrás, apreté el botón de comunicación con los encargados y entonces la pantalla en negro se convirtió en un minimonitor en el que arrancaba el sistema... Era ¡Windows XP! en inglés. Y luego se extrañan de que se atasque

http://www.dbwallpapers.com/44701/windows-xp-bliss-high-res-wallpaper.html/windows-xp-bliss-high-res-wallpaper

Últimas semanas. Fedora 18

En los últimos días no he traído nada nuevo en el blog por que he estado bastante ocupado instalando el sistema en mi ordenador principal. La historia ha sido más o menos así:
1. El 27 de enero instalaba en el ordenador principal Fedora 18

mediante FedUp.Las primeras impresiones las podéis leer aquí. Podría destacar especialmente los cambios que trae gnome 3.6 en Nautilus y los problemas iniciales con el repositorio de Dropbox. La actualización por FedUp hace que el inicio no muestre el panel gráfico que se ve al instalar de limpio, pero lo que llevó a una instalación nueva fue un bloqueo aleatorio del sistema gráfico, que me impedía refrescar la pantalla y podía ver en terminales que los programas gráficos estaban funcionando pero no podía acceder a ellos.
2. El 16 de febrero instalé de forma limpia Fedora 18. Seguía teniendo bastantes problemas, así que tuve que activar las teclas mágicas, cuya localización ha variado en Fedora 18. Se generaron nuevos problemas:
- Anaconda no pide nombre identificativo para el ordenador (o yo me salto algún botón sin darme cuenta), con lo cual aparece identificado como new-host (problema general que es fácil de solucionar, aunque lo descubrí después)
- Ciertos programas, pero especialmente aMule, se apagaban sin previo aviso, lo que me obligó a generar un script para reiniciarlo.
- Se generaba una cascada de dependencias entre programas, de tal manera que al llamar a un fichero de LibreOffice desde Nautilus, el fichero solo se abría al cerrar Nautilus. Para poder hacer funcionar otros, tenía que matar el terminal y finalmente era casi imposible trabajar con el sistema gráfico. En general solo me afecta en el movimiento de ficheros, ya que últimamente trabajo fundamentalmente en terminal. Aun así, en ocasiones el sistema gráfico estaba completamente bloqueado y tenía que trabajar en las pantallas de texto (de Ctrl+Alt 2 hasta 7) y, de hecho, tenía activa siempre la 2 para poder matar procesos gráficos que bloqueaban a otros mediante la identificación por top y uso intensivo de kill.
3. Como daba la sensación de que parecía haber una "herencia" de unas instalaciones a las siguientes, y pensando que el formateo del disco de sistema no era tal formateo, por que es un disco sólido, y aprovechando de que es bastante antiguo, lo cambié por un INTEL 520 de 60GB, que sale en un precio razonable, e instalé de nuevo Fedora de limpio. Me generó de nuevo un ordenador new-host, pero lo cambié con la orden

hostnamectl set-hostname --static

que descubrí aquí, ya que ahora el nombre está en  /etc/hostname y no en /etc/sysconfig/network.

Estado actual. Debido al cambio de disco, el sistema es mucho más rápido (se nota muchísimo); sin embargo, después de haberlo usado sin problemas varias horas, volvieron a aparecer dependencias de unos programas sobre otros. En general el proceso responsable parece ser nautilus, y una vez que un programa se niega a abrirse, hasta que se cierra nautilus nada parece funcionar. Como falta poco para el nuevo openSUSE 12.3, estoy pensando seriamente probarlo, incluido KDE. Si no me convence, lo que si tenemos en cuenta lo poco que me gusta KDE es casi seguro, me pasaré al que nunca falla, Debian Stable. Ya tengo preparado el 6.0.7 que salió el sabado, 23.Me va a costar, ya que he estado muy contento en Fedora. Las actualizaciones son muy rápidas y, hasta ahora, no he tenido problemas de estabilidad o seguridad. Además, tengo 5 ordenadores funcionando con Fedora 18 y solo el principal genera problemas (será por que es al que más le pido).

Reinicio automático de amule [ACTUALIZADO]

Bien; voy a empezar por la "historia del arte" de esta entrada. Como indiqué en la entrada anterior, he instalado de forma limpia Fedora 18 en mi ordenador principal. La actualización dejó varios rastros indeseables. En primer lugar, Fedora arrancaba en una pantalla de formato antigua. Segundo, de forma aleatoria no era capaz de refrescar el sistema gráfico aunque los programas seguían funcionando si los controlaba en una pantalla de texto con top. El arranque es ahora con una pantalla más gráfica y visualmente atractiva, pero lo segundo sigue pasando. Por ahora parece que lo he solucionado evitando el bloqueo de pantalla. Mi primo, técnico informático, me ha dicho que él ya había visto casos similares en gráficos HD3000 integrados en procesadores Intel, que eran incapaces de refrescar el sistema gráfico tras el bloqueo. También me ha indicado que eso se producía en escritorios gnome, y no en KDE, así que los que lo deseen, pueden evitarlo pasando su Fedora a KDE en la instalación.
Esta instalación ha generado otro problema. En el proceso configuré mal mi usuario, y en vez de solucionarlo adecuadamente, decidí borrar el usuario y sustituirlo por otro, sin darme cuenta de que así borraba el directorio completo de ese usuario. En resumen, 1,2TB perdidos. Lo importante es recuperable, ya que tengo la copia de seguridad que hice justo antes de la instalación, pero los ficheros ed2k que estaba en descarga, más directorios completos a los que les faltaba algún capítulo o el directorio que tengo compartido se han perdido completamente. Algunos ficheros no son recuperables, ya que eran versiones especiales que ya no conservo (ficheros de versiones originales que he remontado con sonido en español; ficheros que he recodificado pero que se mantenían para la gente que está interesada etc...). Otros, sin embargo, son recuperables bajándolos de nuevo. Bien, desde hace tiempo amule se cierra aleatoriamente, sin que supiera a que es debido. Los envíos a bugzilla no creo que surjan efecto, ya que amule no es un paquete mantenido por Fedora (como dice bugzilla cuando le envías el informe). Cuando le he inyectado 466 hash para intentar recuperar lo perdido, el programa ha decidido cerranse no de forma aleatoria, si no premeditada, y cada 10 minutos. Sin embargo, he encontrado la solución. En esta entrada de los foros de Fedora he leído esta respuesta que ha solucionado el problema. He copiado el texto en un script,

lo he nombrado reinicio.amule; le he dado permiso de ejecución (# chmod +x reinicio.amule) y ya llamo directamente a amule con él

$ . reinicio.amule

Como no encuentra amule, ya lo llama directamente

Cuando se genera una corrupción en amule, la detecta

y al cerrarse amule

lo llama de nuevo y ya está otra vez activo

He borrado los  ficheros por protección de datos, ya que se ve el nick de los ripeadores. Bromas aparte, he estado probando unas 10 horas y se ha cortado varias veces, recuperándose inmediatamente  alcanzando picos e subida de 3MB/s de forma bastante rápida. Un gran script, aunque personalmente, por desconocimiento no sea interpretarlo. Aun así, cubre mis necesidades. Solo me falta generar un ejecutable en aplicaciones y conectarlo a los favoritos. Muchas gracias a stevea, el nick del programador que ha generado las 6 líneas de código bash que nos ha sacado de este aprieto. La otra opción que tenía e mene era usar la versión amule-nogui, que no precisa sistema gráfico, por si la culpa, como casi siempre se debe a la máscara gráfica.

Actualización:
Y para que se vea que funciona, tras varias horas de funcionamiento desatendido, los informes de errores mostrados por ABRT fue este (y lo que no se ve).

Todos estos fallos suponen cuelgues continuados de amule con la recuperación inmediata gracias al script.
Por cierto, ya he generado un acceso directo y lo he puesto en favoritos, ya que ahora llamo a emule a través del script.

Fedora 18. Bloqueo gráfico y Backslide

He tenido un problema de bloqueo del sistema gráfico, además, tres veces seguidas. Al dejar de actuar sobre el ordenador y tratar de desbloquear la pantalla de bloqueo, queda el fondo sin ninguna posibilidad gráfica de interaccionar. Sin embargo, al llamar a un sistema de texto (Ctrl+Alt+ F2 o F3...) y activar top se puede ver que el sistema continúa en funcionamiento. No he encontrado la forma de llegar a la forma gráfica de nuevo. Puedo llamar a Ctrl+Alt+F1, pero solo sale un escritorio vacío sin acceso a las aplicaciones activas en algún otro sitio virtual. En general siempre he recuperado mediante las teclas mágicas (AltGr+Imp Pant+REISUO). Teniendo en cuenta el retraso que en ocasiones había observado en los momentos de cambio de fondo generado por la extensión Backslide, decidí desactivarla. Una vez desactivada, no se me ha vuelto a bloquear el iema gráfico. Lo lamento, por que me gustaba el cambio de fondo, pero es preferible evitar un bloqueo aleatorio que ver un cambio de fondo, por bonito que sea. El sistema registra varios fallos también de kernel, de los que he informado en bugzilla. No son de extrañar, por que estamos usando un kernel beta

Como se puede ver, el kernel es 3.7.4-204.fc18.x86_64; el 7 es impar, teóricamente una versión beta (impares=beta). Sin embargo, no puedo arrancar con la versión 3.6.11-xxx por que no me reconoce todas las resoluciones de la pantalla

CDLive y solo probar; o quizás algo más

He tenido una experiencia sorprendente y no esperada. Después de usar un ordenador antiguo cuyo disco duro presentaba un sector erróneo no recolocado, decidí darle un repaso a ese disco. Apliqué, para probar, ya que no la había aplicado hasta ahora, esta orden (tomada de aquí):

# badblocks -s -v -n -f /dev/sda1

Por desgracia dejé el ordenador aplicándola y no avisé a nadie, así que el usuario habitual, al llegar, y ver que el ordenador no le respondía, lo reseteó directamente. Esto generó que después no arrancara, seguramente por que se cortó el sistema cuando estaba recolocando algunos ficheros de arranque (sda1 era la partición raíz, con otra para home y otra de intercambio). Lo curioso es que al intentar recuperar el sistema, simplemente instalando de nuevo Ubuntu 10.04.4, y aprovechar el home que había quedado intacto, todo se quedaba bloqueado en el momento de escoger la zona horaria. Se intentó con diferentes copias de esa ISO, luego de otras ISOs, por si la primera tenía algún error y hasta con otras ISOs de distintas versiones, todos los intentos bloqueados en algún momento.
Después de pensar y pensar, en el arranque del CDLive utilizamos gparted, descubriendo que la swap del disco duro estaba montada. Solo se pudo instalar y recuperar el ordenador cuando se eliminó esta partición (y de paso sda1, dejando solo sin tocar la correspondiente a home), ya que los CDLive accedían a ella y la montaban, por lo cual supongo que la usaban, ya que la RAM disponible en ese ordenador era solo de 1GB. En resumen, los CDLive hacen algo más que probar las distribuciones, y sí tocan el disco duro, por que acceden a la partición swap.

Disco duro bloqueado: segunda parte

Como decía en la entrada anterior sobre discos duros bloqueados, disponía de un segundo disco duro en el mismo estado, con 1 TB reducido a 33MB. Es un disco idéntico al anterior, misma marca, modelo y hasta lote. Para realizar la restauración del tamaño original se siguieron los mismos pasos que la otra vez:
1. Detección de su estado, después de un arranque defectuoso en una placa GigaByte. A través de palimpsest detectamos que realmente solo se reconocen 33MB.

2. Arranque con Ultimate Boot CD, repitiendo con un Aspire One, con el disco conectado a través de la misma caja externa USB, y Ultimate Boot CD en el mismo lápiz Kingston. El disco solo se puede poner en la unidad USB de la derecha, posición más retrasada de las dos, ya que en caso contrario no es detectado por MHDD (tal como se ve en la foto).

3. Una vez detectado el dispositivo, se ve la protección por password y se intenta romper (passwords genéricas de Western Digital indicadas en la otra entrada), y aunque parece que en cada segundo intento parece valer (no pone fail), eso no es cierto y el dispositivo sigue protegido y no es posible hacer aplicar ningún comando de recuperacion (HPA=cut o NHPA=uncut)

4. Se realiza la misma acción en un ordenador sobremesa nuevo, que permite también arranque desde USB (el mismo lápiz USB con Ultimate Boot CD). Se desconecta todos los discos duros de la máquina y se coloca el disco bloqueado en S-ATA 1. MHDD detecta a la primera, sin necesidad de escanear, el dispositivo, al contrario que en el intento a través de una conexión por USB:

5. Al acceder a él, no aparece marca de protección alguna ni la de password (PWD con fondo rojo en la línea superior). Aplico directamente NHPA (uncut) y funciona.

6. Para asegurarnos, lo pasamos por el palimsest. Perfecto.

Conclusiones:

- El desbloqueo de la HPA debe realizarse en una conexión S-ATA y no USB. De esta manera no aparece la protección.
Podemos encontrar dos dudas:

- ¿Es preciso hacerlo en un ordenador moderno? Probablemente no, ya que podemos generar un Ultimate Boot CD en un CD, como su propio nombre indica. Sin embargo sigo pensando que existe la posibilidad de que la protección no se muestre por algunas características modernas del ordenador. La protección existe y en muchos blogs se da por supuesto que no es fácil romperla. Deberíamos terner un tercer disco similar y aplicar directamente el uso del S-ATA 1 de un sobremesa directamente para estar seguros de cual ha sido el paso definitivo.

- ¿Sería posible que en la conexión USB hubieramos roto la protección mediante alguna de las palabras genéricas, y que debido a esa misma conexión USB no pudieramos aplicar NHPA, a pesar de haber roto la protección? Aun tengo esta duda, pero no creo, ya que lo repetí muchas veces. Al principio aplique todas las palabras juntas, hasta que no aparecía "fail", pero luego lo hice una a una y reiniciaba, y en todas aparecía el mensaje "fail".

Por si son interesantes las características del ordenador donde se solucionaron los dos bloqueos, aquí va el hardware tras un
lshw -short
Dos consideraciones.
Una. Sí, como usuario normal, ya que así sale más corta y comparando no se pierde información.
Dos, lshw no se instala con Fedora; tuve que instalarlo para esto (su -, y luego yum install lshw)

Disco duro bloqueado

Otra entrada sobre hardware, pero esta vez hardware informático de verdad. Antes de vacaciones me entregaron un disco duro, para ser exactos un Western Digital Caviar Green de 1 TB y 64 MB de buffer, modelo WD10EARX-00N0YB0, que al conectarlo a un ordenador mostraba solamente 33MB, según el software con que lo manejamos (palimpsest). La intención era descubrir si era posible recuperar el tamaño original.

Tanto este como otro disco idéntico "sufrieron" esta llamemos alteración tras intentar utilizarlos como disco de sistema en un ordenador con una placa ASUS. Lo digo por que al documentarme en la red para manejar este "poltergeist" informático encontré en muchos sitios que es un caso documentado de determinadas placas Gigabyte, que reconocen un tamaño erróneo en determinados discos por un error en la BIOS (33MB para discos de 1 TB, 500 MB para los de 1,5TB y 1TB para los de 2; véase aquí). ¿Cómo es esto posible? Quizá lo comprendamos mejor si leemos qué es realmente la HPA (Host -a veces Hidden- Protected Area) de los discos duros.
Segundo, extraño que sean 33MB, ya que si hemos realizado alguna acción inconveniente que provoca el bloqueo del disco duro, lo normal es que muestre 64MB, que es el buffer. A pesar de ello, seguí investigando que posibilidades teníamos, y en alguna página señalan la posibilidad de recurrir a programas escritos para acceder y manipular a bajo nivel los discos duros. Fundamentalmente recomiendan el uso de MHDD y con él aplicar la orden de uncut (o NHPA) a la propia HPA para que recupere su tamaño original ("return to factory size").
Yo, que no tengo diskettes en mis ordenadores, y que no me gusta quemar CDs, instalé una ISO de Ultimate Boot CD a través de UNetbootin en un Flash USB Kingston DataTraveler ELITE de 1GB (el más caro que me he comprado jamás; en sus momentos, el mejor lápiz USB que había visto; ahora se me ha quedado algo pequeño y solo sirve para estas cosas. Pongo la foto solo para fardar de él).

Tras arrancar desde Ultimate Boot CD, en este caso en un Aspire One, con el disco conectado a través de una caja externa USB,

simplemente seguimos estos pasos:
- vamos a HDD
- seguidamente Diagnostics
- MHDD
y en el ejecutamos uncut (o NHPA)

Sin embargo, después de ver muchas páginas, fundamentalmente ésta, y haber llegado hasta ahí y ejecutado esa orden, quedaron bastante claras varias cosas:
1. Los discos están protegidos por una palabra clave
2. Dicha palabra puede ser extraída, aunque muchos señalan que puede ser ilegal (ver aquí "HPA can also be used to store data that is deemed illegal and is thus of interest to government and police computer forensics teams" y en otros lugares; leer con atención aquí desde la primera página a la última).

En resumen, en esta página que recomiendo se explica como se aplican unos scripts en MHDD para extraer en hexadecimal el contenido de la HPA y que parte contiene la palabra de protección de 32 bytes. Si no se dispone de la palabra no se puede aplicar la orden "uncut" y da un error.

Además, teníamos otras dos posibilidades. aplicar programas de desbloqueo, como HDAT2 o hdparm (ver aquí) o utilizar palabras maestras que podrían funcionar (tomadas de aquí). Como no tenía muchas ganas de traducir un hexadecimal y extraer una palabra, estuve aplicando estas cuatro para discos WD.


WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW
WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCWD
&'()*.WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCWD
h2oinsyde

pero parecía que no funcionaban. Un poco cansado lo dejé así. A la vuelta de las vacaciones, hoy por la tarde, al terminar de trabajar, he colocado el disco en una entrada SATA de un ordenador y arrancado con el mismo lápiz, y al ir a MHDD aplique directamente tanto NHPA (uncut) primero como HPA (cut, señalando el extremo final de 2TB, que el programa señalaba como 1,953,625,168) después y en ese momento me di cuenta de que el disco no tenía protección; además, no se encontraba la palabra PWD en la parte de arriba del programa. El disco había quedado desbloqueado.
Esto nos presenta algunos problemas. No sabemos qué es lo que ha funcionado; puede que haya quedado desprotegido el otro día con alguna de esas 4 palabras (en teoría hay un límite de 5, y luego hay que reiniciar el ordenador). Otra posibilidad es que la conexión por SATA haya permitido ejecutar la orden "cut" (HPA). Otro problema es que no he grabado imágenes decentes de cada acción. Por suerte tenemos otro disco y esta vez intentaré hacerlo de forma seriada, paso a paso y foto a foto. Como todos sabemos, lo mejor es siempre cazar el segundo león, y no empezar por el primero.

PD. Sigo sin tener clara la ilegalidad de esta acción. Si uno compra un disco, y por un bug de una BIOS hay que comprar otro ¿quien es el dueño del disco? Pongo un ejemplo. Te compras un coche de 24000€. Como arrancas en frío dando acelerones el sistema eléctrico se bloquea, y como tiene una palabra clave que es ilegal aplicar, te tienes que comprar otro. La gente no protesta por que cuestan 100€, pero si no fuera así...

Errores en memoria RAM: memtest

La verdad es que llevaba unos meses -aproximadamente desde mayo- bastante fastidiado, ya que el ordenador principal, el que tiene una copia maestra de todo, se bloquea cuando quiere. En esta última semana he tenido dos copias masivas de ficheros con pérdida total del material al colgarse el ordenador en medio de la copia y no guardar el índice en el disco externo. Como estaba cansado de tanta tontería decidí hacer dos cosas; una, pasarme definitivamente a Fedora, que me gusta mucho; dos, antes de poner Fedora, hacer un memtest sobre la RAM del ordenador, ya que es la única explicación lógica de que Linux me haga pantallazos como si fuera Windows. Siempre he tenido un cierto miedo a los fallos de RAM, por que suelen aparecer aleatoriamente y son difíciles de detectar; o eso pensaba yo. Por alguna razón los técnicos informáticos (todos seguidores acerrimos de Windows) se reían de mi diciendo que nunca encontraría el error. Sin embargo, memtest86 v.4.20 había detectado el error a los pocos segundos

Como se ve detecta un error en el MB 1095 de la memoria RAM. Sin embargo, dejé que continuara hasta el final.

A pesar de los 192 errores registrados esta última foto, los errores totales, todos en el MB 1095 y todos con el mismo error (Err-Bits 00000020) llegaron a más de 220. Por suposición extraje el banco A1 de los 4 de 2GB DDR2 del ordenador y volví a pasar el test. Esta vez no apareció ningún error. Por suerte, la RAM la había cambiado hace relativamente poco tiempo (4 bancos de 1GB por 4 de 2GB), por lo que estaba en garantía. Espero que haya reparado el ordenador, por que la otra solución sería cambiarlo y ahora mismo no quiero. Además, escribo esta entrada desde ese mismo ordenador y Fedora 16. Ya solo me queda el ordenador más antiguo con Ubuntu (un 10.04.3). Un día de estos lo cambiaré también. Es más, a pesar de ser bastante antiguo y con poca RAM, voy a intentar Fedora 16, por que funciona de forma muy fluida, más "ágil", desde mi punto de vista, que Ubuntu 11.10 (¿Será culpa de un tal Unity?)..
Para esta solución he aplicado el memtest que viene en el DVD 64bits de Fedora 16, con el que luego he instalado el nuevo sistema. Simplemente como conclusión, gracias memtest.