Archivo de la etiqueta: debian

LibreOffice hace crash cuando hago copia-pega

Es un bug realmente enojoso, porque habitualmente todo el mundo hace copia-pega de gráficos, tablas, literalmente de todo cuando hace diapositivas con Impress. No hay mensajes de error de ningún tipo, LibreOffice simplemente se cierra y pierdes todos los cambios que no hayas hecho en disco. Si arrancas el programa desde consola (precisamente para ver cualquier hipotético error), verás que no hay información ninguna. Haces un copy o un paste y el programa se cierra sin mensaje de error ninguno, aunque si tienes forma de capturar códigos de error verás que se cierra con código 139, es decir un SEGFAULT en toda regla.

Este fallo me aparece en Debian 8.6 Jessie, pero por lo que he visto por ahí es bastante ubicuo y aparece en todo tipo de sistemas, en múltiples versiones de LibreOffice, tanto en Linux como en Windows, y no he visto ningún lugar donde se aporte solución. Te dicen que elimines con fichero «~/.config/openoffice/4/user» y que vuelvas a intentarlo. Y efectivamente, durante unos minutos parece que funciona, pero luego vuelven a aparecer los crash.

Es un bug conocido con múltiples quejas pero no he visto workaround alguno, así que la solución que te propongo es de cosecha propia. :-)

La pista me la dio cuando observé que hacía crash sistemáticamente al copiar objetos relativamente complicados pero me permitía copiar objetos muy simples (un poco de texto, por ejemplo). ¿Qué es eso?. ¿Se queda sin memoria?.

Vale, vete a Herramientas -> Opciones -> LibreOffice -> Memoria.

Ahí verás varias opciones que se refieren a cuantos recursos pilla LibreOffice del sistema. Y parece todo como bastante escaso. Recorta pasos de deshacer y amplía la memoria caché. Yo puse esto:

  • Deshacer
    • Número de pasos: 20
  • Caché de Imágenes
    • Usar para LibreOffice: 100 Mb
    • Memoria por objeto: 20 Mb
    • Eliminar de la memoria después de: 00:10 hh:mm
  • Caché para los objetos insertados
    • Número de objetos: 20

Oye, y a la primera. En cuanto puse esos parámetros, LibreOffice empezó a funcionar bien y hacer sin problemas los copia-pega. Ya te diré como va la cosa si surgen novedades.

 

Chrome da continuos mensajes del tipo «Shockwave Flash has crashed» en Debian Wheezy 7

Me volví loco intentando una solución a través de chrome://plugins, que es la solución que aparece en todas partes. Pero, oye, que nada.

Al final, lo que me lo solucionó sin problemas fue lo que se propone en un foro italiano. Si, está en italiano, pero los comandos se entienden a la perfección, y el problema no tanto pero prestando un poco de atención y con ayuda de Google ya está. El fallo está en el plugin Pepper Flash, que viene incorporado en el Chrome. Resulta que a partir de la versión 37.0.2062.120 de Chrome, el plugin Pepper Flash necesita las librería glibc 2.14 para funcionar. Sin embargo la versión estable de Debian Wheezy proporciona glibc 2.13. Oh, si, Chrome se actualizará sin quejarse de ninguna dependencia, pero el plugin Pepper Flash no parará de lloriquear y de romperse una y otra vez. Puedes comprobar la versión de tu navegador Chrome en el menú, «Información de Google Chrome», si te pasa a ti.

¿Hay alguna solución?. Bueno, nuestro amigo italiano tomberry propone descargar una versión anterior de Pepper Flash y sobreescribir la que viene con el Chrome. Es muy fácil, nos da los comandos listos para ejecutar (eso si, hazte root).

Para amd64 (es decir, la versión 64 bit de Debian):

cd /opt/google/chrome/PepperFlash && sudo wget http://goo.gl/4dJvJE -O libpepflashplayer.so && exit

Para i386 (es decir, la versión 32 bit de Debian):

cd /opt/google/chrome/PepperFlash && sudo wget http://goo.gl/4awX8D -O libpepflashplayer.so && exit

Ignoro qué ocurre en otras versiones de Linux tal que Ubuntu, pero es muy posible que sus librerías glibc estén más actualizadas y no les falle el Pepper Flash. ¡Eh, no te quejes, es el precio que pagas por usar la versión estable de Debian!.

Después de ejecutar el comando no te olvides de que tienes que cerrar todas las ventanas de Chrome y luego volverlo abrir. Hombre, si eres muy paranoico, puedes copiar antes el fichero /opt/google/chrome/PepperFlash/libpepflashplayer.so en un lugar seguro por si ocurre un accidente nuclear o tu ordenador es devorado por un agujero negro. A mi me funcionó como la seda, qué quieres que te diga.

¡¡Eh, un momento!!

Bueno, sí. Estás instalando una versión anterior de libpepflashplayer.so que está colgada en un Dropbox de no-se-quién. Y con privilegios de root. ¿No te fías?. Paranoia cosa fina, ¿eh?.

Vaaale, vale. Vete al directorio /var/cache/apt/archives. Ahí deberías tener todos los paquetes legales de google-chrome que has ido actualizando desde el principio de los tiempos. El sistema los deja ahí almacenados cuando los descarga de los repositorios. Elige una versión anterior a la 37.0.2062.120, descomprímela, pilla el fichero libpepflashplayer.so y copialo a /opt/google/chrome/PepperFlash. Para descomprimir el paquete puedes usar los comandos siguientes (sustituye el número de versión por uno que tengas):

cp /var/cache/apt/archives/google-chrome-stable-35.0.1916.153-1_amd64.deb ~
cd ~
ar x google-chrome-stable_35.0.1916.153-1_amd64.deb
tar --lzma --extract --verbose --file data.tar.lzma
sudo cp opt/google/chrome/PepperFlash/libpepflashplayer.so /usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so

Y ya está, estás instalando un Peeper Flash que procede directamente de los repositorios. ¿Más tranquilo así?. Yo no lo he hecho, preferí vivir peligrosamente, pero debería funcionar.

Instalar Spotify en Linux Debian Wheezy 7.x

Si lo has intentado, sabrás ya que no se puede por culpa de unas dependencias anticuadas (libssl0.9.8). Con todo, aún se puede instalar Spotify en una versión un poco más antigua. Pero no necesito explicártelo porque ya lo hace muy bien Javier Lleó. A mi me funcionó sin problemas. Las gracias, a él.

Fallos en una unidad USB después de hibernar/suspender mi ordenador

Si usas hibernar / suspender en tu ordenador y tienes unidades USB montadas habitualmente, es posible que cuando vuelva a despertar no reconozca las unidades USB y te de algún tipo de error.

La forma más rápida de evitar problemas es desmontar todas las unidades USB justo antes de hibernar y volver a montarlas después de despertar. Podemos automatizarlo todo para que ocurra sin tener que hacer nada, solo hay que añadir un script en el directorio /etc/pm/sleep.d/ (suponiendo que usas un sistema Debian o Ubuntu). Observa el script, es muy sencillo, y cámbialo según tus necesidades. Recuerda que, como cualquier script, debe tener permisos de ejecución.

#!/bin/sh
case "$1" in
       hibernate|suspend)
             umount /media/LinBkp1
             umount /media/LinBkp2
             ;;
       thaw|resume)
             mount /media/LinBkp1
             mount /media/LinBkp2
             ;;
       *)
             exit 0
             ;;
esac

Debian no reconoce mi Kindle Touch

Si, si lo reconoce. Incluso podrás montarlo con el comando mount manualmente después de enchufar el kindle al ordenador por USB. Pero no será reconocido automáticamente ni será detectado por Calibre aunque lo hagas.

Para que haga todo eso necesitas instalar las mtp tools (apt-get install mtp-tools mptfs libmtp8). Y con eso ya está. Ahora debería reconocerlo de forma automática tanto Debian como Calibre en cuanto lo conectes por USB.

El teclado hace cosas muy raras en TightVNC

Pongamos que tienes un ordenador con Linux que usa habitualmente otro miembro de tu familia. Pero pongamos que quieres poder logarte de vez en cuando en esa máquina de forma remota, desde otro ordenador de tu intranet, y sin tener que darle un codazo a tu familiar, al grito de «Quita, que siempre lo tienes tu…«.

Obviamente, ya te habrás dado cuenta de que estoy hablando de mi santa. Es muy duro administrar un sistema si nunca consigues ponerte tu al teclado… :-D

Bien, si. Has mencionado SSH y tienes razón. Listo, que eres un listo.

No, yo me refería a un login gráfico.

Bueno, hay mil formas. Yo la que uso ahora mismo es VNC, concretamente vnc4server. Si usas Ubuntu, o cualquier otra variante de Linux basada en Debian, puedes configurar un script de inicio en la máquina que va a hacer de servidor. Pero no voy a desgañitarme en contártelo, porque ese trabajo ya lo ha hecho a la perfección nuestro amigo Andrew Berry. Así que vas, y te lo lees.

Luego vas a la máquina que va a hacer de cliente, instalas el paquete xtightvncviewer, y ejecutas un «vncviewer ip_del_servidor:1» para logarte. Y ya está.

Bueno, no. Puede que no esté. Yo lo hice y me encontré con que todo funcionaba de maravilla, a no ser que usara el teclado. Cuando tecleabas algo (por ejemplo una contraseña, o un comando, da igual) el resultado de lo que tecleas no tiene nada que ver con las teclas que apretabas. Y de forma bastante absurda, además. Al pulsar «q» aparece «c». Al pulsar «5» es como si pulsaras «retroceso». Cuando digo «cosas raras» quiero decir «cosas raras».

Afortunadamente, otro amigo que se llama Bassu Khan ha encontrado el origen del problema y la solución.

El problema surge solo si el servidor carga Gnome como escritorio. No ocurre con otros gestores de ventanas. Y la solución que propone Bassu Khan es editar el fichero $HOME/.vnc/xstartup (en el ordenador que hace de servidor) y, al final, justo antes de la linea que pone «/etc/X11/Xsession» añadir otra línea que ponga «export XKL_XMODMAP_DISABLE=1». Y ya está. Reinicia TightVNC en el servidor y vuelve a logarte con el cliente.

Yo apliqué esta solución y oye, como la seda.

No, no me des las gracias. Dáselas a ellos.

Tras actualizar unas librerías, no oigo sonidos de sistema en KDE

Ya está. Ya lo has roto. ;-)

Lo digo en serio, ¿eh?. :-D

A ver, te cuento lo que me pasó a mi. Resulta que me bajé dos programas de base de datos, Knoda y Rekall. Ambos hay que compilarlos, pero tienen unas dependencias bastante puñeteras. Total, que «actualicé» unas cuantas librerías y paquetes (sobre todo del grupo KDE y de la sección «devel»).

Bien, Knoda y Rekall se compilaron, sí. Pero a partir de ahí empezaron a surgir problemas, todos ellos relacionados con el sonido. Los síntomas principales eran estos, todos ellos bastante sorprendentes:

  1. KDE arranca sin el habitual sonido «KDE_Startup.wav».
  2. No se oye absolutamente ningún sonido del sistema (ventanitas al abrirse, ventanitas al cerrarse).
  3. Sin embargo, puedo abrir ir al «menú K» y abrir cualquier programa de audio (noatun, kaboodle…) y escuchar cualquier mp3 y ogg de mi colección sin ningún problema. También puedo ejecutar noatun y kaboodle en ventana de comandos; y funcionan, pero sacan un curioso mensaje de error que dice «mcop warning: user defined signal handler found for SIG_PIPE, overriding».
  4. Curiosamente, ya no puedo arrancar noatun ni kaboodle pulsando los iconos del escritorio. Sale un mensajito que dice que KDEinit no pudo ejecutar «noatun», por ejemplo. Pero si, con el botón derecho del ratón, abro las propiedades del icono, puedo poner como ejecutable «/usr/bin/noatun» en vez de «noatun». Entonces, sí arranca. Pero siguen apareciendo los mensajitos de error «KDEinit no pudo ejecutar «noatun».
  5. Si abro Konqueror y me voy a los directorios donde guardo los mp3 y ogg, ocurre lo mismo. Si pulso en un ogg me salta la misma ventanita de error, solo que dos veces seguidas. Puedo modificar los patrones de MIME para que incluya la ruta «/usr/bin/kaboodle» en vez de «kaboodle» con lo que sí arranca. Pero siguen apareciendo los dos mensajitos de error, uno detrás de otro.
  6. Abro el Centro de Control de KDE y reviso toda la configuración del audio. Está correcta, exactamente igual que estaba la última vez que la modifiqué. Pero, curiosamente, cuando pulso los botones de prueba para escuchar los sonidos asignados a cada evento, no se oye nada.
  7. Abro una ventana de comandos xterm y tecleo un comando «killall artsd». Ejecuto «artsd» en la misma ventana de comandos, con lo que me salen en pantalla todos los mensajes de log. Los log de artsd indican que todo está funcionando bien.
  8. Abro otra ventana de comandos distinta para no interferir con los logs de la primera. En ese otro shell ejecuto un glorioso «artscat /usr/share/sounds/KDE_Startup.wav». El sonido se oye perfectamente y la primera ventana de comandos vomita un log en el que identifica claramente el sonido que estoy escuchando. Lo mismo ocurre cuando ejecuto un «play /usr/share…».
  9. Abro, cierro, maximizo, minimizo y restauro unas cuantas ventanas del escritorio. Los logs de artsd ni se inmutan… es como si no hubiera hecho nada. ¡La leche, artsd funciona perfectamente, el culpable es el KDE, que no consigue comunicarse con el demonio de sonido!.
  10. Salgo de KDE y de todo X Window (o sea me cambio de telinit, vaya, que todo hay que decirlo), me voy a una consola (no un terminal X, sino una verdadera consola). En mi home ejecuto un «rm -Rf .mcop* .DCOP*». Me vuelvo root y ejecuto un «rm -Rf /tmp/*». Rearranco X Windows y que si quiés arroz, Catalina. Que no, que seguimos sin sonidos del sistema.
  11. A la desesperada, creo un usuario llamado «tralarí» y con contraseña «chinpón», para que le instale el escritorio KDE por defecto. Lo mismo mismito. El error es mucho más profundo que eso. No es un fallo de configuración, sino un error del propio KDE, concretamente de lo-que-sea que se encargue de comnunicarle los eventos al demonio de sonido (artsd). La única conclusión lógica es que me lo he cepillado con las últimas «actualizaciones». Que lo he roto, vamos. Después de hecha la prueba, borro el usuario «tralarí», por supuesto. ;-)

¿Y la solución?

Pues deshacer el camino andado es la leche. Porque vete tu a saber cual es la librería dañada, y hay que desinstalar cosas, reactualizar paquetes pero a la inversa (con las versionas antiguas, no las nuevas…). Mi madre, también podría recurrir a las copias de seguridad, pero no me hace ninguna gracia meterme en ese berenjenal por los eventos de sonido, que mira tú lo que me importan. Tiene más importancia lo de Konqueror, no por mi, que me la refanfinfla… pero a mi santa esposa no le gusta la informática, a ella lo que le va es que haciendo «click» se oiga la canción y punto. Pobrecita, y yo haciendo trastadas :-D.

Ya. ¿Y la solución?

Pues la «huida hacia delante», claro. Es un buen momento para actualizar TODO el KDE. Qué demonios, es buen momento para actualizar TODO Woody. Al fin y al cabo, KDE es el escritorio por defecto de María. Y el mio también, que hace tiempo que no toco Window Maker. Además, hace mucho que ha salido ya la versión 3.2

Hala, venga. Nos vamos a /etc/apt/sources.list y cambiamos la línea que dice:

deb http://download.at.kde.org/pub/kde/stable/3.1/Debian stable main

por esta otra:

deb http://download.at.kde.org/pub/kde/stable/3.2/Debian stable main

Y luego los consabidos:

[15:05:21/0][root@claudia:~]# apt-get update ;; apt-get upgrade

Eso sí. Hay librerías rotas (era esperable, ¿verdad?). Así que el upgrade es tormentoso y advierte que hay muchos librerías que han sido «keep back» (dejadas atrás). Algunas de esas librerías se refieren al sistema de sonido de KDE (eeeeh, ¿lo has visto?… te pillé). No pasa nada, cuando «apt-get upgrade» se detiene, hago un «apt-get install» manual contra uno de esos paquetes dejados «keep back». Si esto falla por alguna otra dependencia, hago un «dpkg –remove paquete» contra ella y vuelvo a intentarlo. Después, reintento el «apt-get upgrade» y continúo así una y otra vez, hasta dejar todos los paquetes disponibles a cero.

La pregunta que te estás haciendo ahora es… ¿Solucionó esto el problema?.

Sí. Por completo. X-D

Al arrancar KDE 3.2 sale un mensaje «Could not start KDEinit»

Al logarme para entrar en mi nuevo KDE 3.2 sale un estúpido mensaje que dice «Could not start KDEinit. Check your installation». Y la barra de progreso de KDE se detiene hasta que pulso «Okay». Luego, KDE arranca normalmente y funciona muy bien (y es precioso, además ;-) pero cuando deslogo, aparece un mensaje de crash diciendo que KNotify se ha ido al carajo. Afortunadamente, solo dura unos segundos y luego desaparece sola y se desloga normalmente.

Sorprendente, ¿verdad?. Mensajes de error haciendo referencia a no-se-qué porque lo cierto es que KDE 3.2 funciona a la perfección. :-?

Bien, la verdad es que esto se debe a un bug gordo, gordísimo, en el script /usr/bin/startkde. Es tan gordo y evidente que se merece solo un capón y unas risas, porque es como un matemático que después de una larga fórmula de integrales, escribe en la pizarra 2+2=5.

Vale, pues edita con cualquier editor de textos el archivo /usr/bin/startkde. Alrededor de la línea 164, donde pone:

LD_BIND_NOW=true kdeinit +kcminit +knotify
if test $? -ne 0; then
	# Startup error
	echo 'startkde: Could not start kdeinit. Check your installation.'  1>&2
	xmessage -geometry 500x100 "Could not start kdeinit. Check your installation."
fi

Debe poner (fijaos en las dos primeras líneas):

LD_BIND_NOW=true 
kdeinit +kcminit +knotify
if test $? -ne 0; then
	# Startup error
	echo 'startkde: Could not start kdeinit. Check your installation.'  1>&2
	xmessage -geometry 500x100 "Could not start kdeinit. Check your installation."
fi

¿Habeis visto?. Se les olvidó un <Enter> X-D

Pues ya está. Cambiando eso, el bug está resuelto.

Eliminar el puñetero autologin de Knoppix en disco duro

Comprobarás que el Knoppix del disco duro sigue funcionando como la versión en CD, es decir, que te sigue metiendo en el usuario knoppix sin password ni nada.

Pero una vez instalado en el disco duro, tal vez quieras entrar con un login decente, con usuarios de verdad. Fale. Crear usuarios de verdad es muy fácil, así que ni te lo cuento. Pero comprobarás que sigues entrando automáticamente como usuario «knoppix», y que en cuanto deslogas knoppix va y te resetea la máquina. Irritante, diría yo.

Edita el fichero /etc/inittab y comenta la última linea, de tal forma que donde pone:

x5:5:wait:/etc/init.d/xsession start

debe poner:

#x5:5:wait:/etc/init.d/xsession start

También debes cambiar las lineas como:

1:12345:respawn:/bin/bash -login >/dev/tty1 2>&1 </dev/tty1
2:2345:respawn:/bin/bash -login >/dev/tty2 2>&1 </dev/tty2
3:2345:respawn:/bin/bash -login >/dev/tty3 2>&1 </dev/tty3
4:2345:respawn:/bin/bash -login >/dev/tty4 2>&1 </dev/tty4

por estas otras:

1:2345:respawn:/sbin/getty 38400 tty1
2:2345:respawn:/sbin/getty 38400 tty2
3:2345:respawn:/sbin/getty 38400 tty3
4:2345:respawn:/sbin/getty 38400 tty4

Vale. Ahora has anulado el arranque gráfico. Es decir, cada vez que arranques entrarás en modo consola. Pero tal vez te interese hacer el login mediante kdm, o xdm, ¿no?.

Al contrario que Debian Woody, la Knoppix arranca en modo telinit 5, así que tienes que meterte en /etc/rc5.d y hacer un link, en modo root, mediante el comando:

[root@claudia rc5.d]# ln -s ../init.d/kdm S30kdm

Y ya está. Ya de paso, puedes empezar a crear links como un loco para arrancar automáticamente todos los demonios que quieras en cada arranque. Probablemente querrás, por ejemplo, un:

[root@claudia rc5.d]# ln -s ../init.d/inetd S20inetd

…si es que tienes algún tipo de conexión de red y deseas ofrecer algún servicio.

Configuración «rápida» de un genuino MS-DOS con DosEmu

Si procedes de la «vieja escuela», como yo, seguramente has empezado con un ordenador 8086 o 80286 (¿te acuerdas?) con MS-DOS. Puede que tengas multitud de antiguos programas y datos procedentes de ese sistema. Casi todos ellos pueden ser convertidos, de algún modo, a un formato manejable con Linux. Pero quizás prefieras usar los documentos tal y como fueron creados. Y al fin y al cabo, MS-DOS tenía también su encanto, ¿no?. :-)

Puedes usar VMWare, pero es un programa comercial y cuesta dinero. Otra opción gratuita y de similar calidad sería VirtualBox. Cualquiera de las dos podría servirte pues son magníficos emuladores. Pero quizás quieras probar DosEmu, que es mucho más ligero y rápido de arrancar.

Lo primero de todo es instalar DosEmu, claro. Así que haz un apt-get o un emerge, o lo que sea.

Bien. Pero ahora hay que configurarlo, ¿qué te creías?. Y puede llegar a ser bastante complicado. Aquí te voy a poner la configuración que yo usaba en Debian y como ponerla en marcha. Si quieres usar otra diferente, tendrás que usar google.

Vale, lo primero es prescindir de FreeDOS. Lo siento, se que es políticamente incorrecto y que es software libre y todas esas cosas, pero FreeDOS es malo. Si no quieres pagar por un DOS, úsalo. Pero el DOS de Microsoft es mucho mejor.

Yo aún conservo mi antiguo MS-DOS 6.22, así que…

[lacofi@claudia lacofi]$ su
password:
[root@claudia lacofi]# cd /var/lib/dosemu
[root@claudia lacofi]# mkdir msdos622
[root@claudia lacofi]# chown lacofi.personal msdos622
[root@claudia lacofi]# chmod ug+rwx msdos622
[root@claudia lacofi]# mkdir prgdos
[root@claudia lacofi]# chown lacofi.personal prgdos
[root@claudia lacofi]# chmod ug+rwx prgdos

Vale. El directorio «msdos622» se comportará como unidad «C:» y contendrá el sistema operativo. Todos sus subdirectorios serán directorios de «C:» en cuanto arranquemos DosEmu. El directorio «prgdos» se comportará como unidad «D:» y contendrá todos los programas y datos. Ambos directorios pertenecen al usuario lacofi y grupo personal. Los dos usuarios de mi ordenador (maría y yo) pertenecemos a ese grupo, con lo que los dos tendríamos permiso para leer y escribir en ambas unidades de DosEmu (C: y D:).

Ahora necesito mi viejo disquette de arranque de DOS. Ojo, aquí necesito las copias de seguridad, es decir con todos los ficheros copiados directamente desde el disco duro, no la versión sin instalar. Si solo dispones de la versión «virgen» de MS-DOS, tendrás que arreglartelas para instalarla en alguna partición, y luego copiar todos los archivos a disquette. Cuando digo todos, digo TODOS, incluidos los ocultos (IO.SYS y MSDOS.SYS).

Bueno, si quieres que sea sincero, también se puede instalar directamente en DosEmu, claro, pero es más complicado y no voy a detallarlo aquí ahora. Quizás otro día. ;-)

Muy bien, pues ahora metemos el disquette de arranque en la disquetera:

[root@claudia dosemu]# exit
[lacofi@claudia lacofi]$ cd /var/lib/dosemu/msdos622
[lacofi@claudia msdos622]$ mcopy a:io.sys .
[lacofi@claudia msdos622]$ mcopy a:msdos.sys .
[lacofi@claudia msdos622]$ mcopy a:command.com .
[lacofi@claudia msdos622]$ mcopy a:autoexec.bat .
[lacofi@claudia msdos622]$ mcopy a:config.sys .
[lacofi@claudia msdos622]$ mkdir utils
[lacofi@claudia msdos622]$ mkdir dos
[lacofi@claudia msdos622]$ cd dos
[lacofi@claudia dos]$ mcopy a:dos\* .

Ahora vamos metiendo todos los disquettes de nuestro MS-DOS y copiandolo todo al directorio /var/lib/dosemu/msdos622/dos. El directorio /var/lib/dosemu/msdos622/utils, de momento, quedará vacío. A continuación:

[lacofi@claudia dos]$ cd ..
[lacofi@claudia msdos622]$ chown -R lacofi.personal *
[lacofi@claudia msdos622]$ chmod -R ug+rw *
[lacofi@claudia msdos622]$ chmod ug+x dos
[lacofi@claudia msdos622]$ chmod ug+x utils

Observad que me he salido de root en cuanto he dejado de necesitarlo. Nunca useis root para nada más que lo imprescindible. Os ahorrará muchos disgustos.

Observad también que he usado las «mtools» para acceder a la disquetera bajo linux. Si no las teneis instaladas, podeis usar mount y copiar los ficheros con cp. Da igual cómo, la cuestión es copiarlo todo al directorio /var/lib/dosemu/msdos622 y reconstruir ahí toda la estructura de subdirectorios.

Ya hemos creado la infraestructura. Ahora tenemos que configurar DosEmu. Primero editamos /etc/dosemu/dosemu.users y añadimos una línea que ponga: «all nosuidroot c_all». Esto permite que sea ejecutado por otros usuarios sin necesitar privilegios de root.

Ahora editamos el fichero /etc/dosemu/dosemu.conf y ponemos los valores adecuados. Es un fichero muy largo, pero no todo nos interesa. Está bien comentado, así que a continuación pongo solo los cambios más relevantes:

$_cpu = «80586» #emulará un procesador pentium
$_xms = (5120) #usará 5Mb de memoria expandida XMS
$_ems = (5120) #usará 5Mb de memoria extendida EMS
$_dpmi = (4096) #usará 4Mb de memoria protegida DPMI
$_dosmem = (640) #memoria convencional de 640Kb
$_term_char_set = «latin1» #hablas castellano, ¿verdad? ;-)
$_layout = «es-latin1» #¿verdad? :-D
$_X_font = «vga» #fuente VGA, la mejor y la que asume
#pero leete este truco
$_video = «vga» #imita una VGA para los gráficos
$_chipset = «S3» #si tu tarjeta es, realmente, una S3
#mira mas opciones en fichero original
$_hdimage = «msdos622 prgdos» #ahí está la madre del cordero.
#si son subdirs de /var/lib/dosemu
#el primero será unidad C:
#y el segundo unidad D:
#Si ficheros, serán unidades virtuales
# (esa es otra historia)
#Y si son dispositivos (/dev/hda1)
#es un DOS real en otra partición
$_sound = (on) #¿Sonido?
$_sb_base = (0x220) #Pues hala, parámetros SoundBlaster:
$_sb_irq = (5)
$_sb_dma = (1)
$_sb_dsp = «/dev/dsp» #Dispositivo linux para el sonido.
$_sb_mixer = «/dev/mixer» #Dispositivo mezclador.

Y te dirás que con esto ya puede ir. ¿O no?.

Pues no. Ahora tienes que arrancar tu nuevo emulador de DOS con los comandos «dos» o «dosemu» si estás en consola, o bien «xdos» o «xdosemu» si estás en xwindow. Observarás que las cosas, ahí, empiezan a fallar un poco. DOS arranca, pero sale una retahila de errores. Y es que ahora tienes que configurar los ficheros «autoexec.bat» y «config.sys»:

C:\> edit config.sys

Por ejemplo, para la configuración propuesta serviría un config.sys tal que así:

device=c:\utils\ems.sys
buffers=30
files=60
dos=high,umb
lastdrive=z
devicehigh=c:\dos\ansi.sys
devicehigh=c:\utils\cdrom.sys /d:mscd0001
country=034,437,c:\dos\country.sys

Observa que cargamos un driver «c:\utils\cdrom.sys» de un directorio que no contiene nada… Bien, ese driver no está incluido en MS-DOS. Es un driver para una conocida marca de CD, que es compatible con la emulación que hace DosEmu. Tendrás que descargarte ese driver de algún sitio (consulta las FAQ de DosEmu) y ponerlo en el directorio «c:\utils» (o lo que es lo mismo, /var/lib/dosemu/msdos622/utils, que es como lo vería Linux).

Vaaale, vaaaale. Es un driver de libre distribución, así que no busques maaaaas. Aquí lo tienes. En cuanto a esa misteriosa referencia a c:\utils\ems.sys, que tampoco existe, no seas impaciente. Llegaremos a eso enseguida. De momento, tu mételo tal cual.

Ahora es el turno de «autoexec.bat». Por ejemplo:

@echo off
echo --------------------------
echo ¡Bienvenido a  dosemu 1.0!
echo  ¡Esto es DOS bajo Linux!
echo --------------------------
set path=.;C:\;C:\dos;c:\utils;D:\PRG;D:\BAT
lh mscdex.exe /d:mscd0001 /l:e

¿Que queda?. Solo una cosa… ¿cómo salir de DosEmu?. No con «exit». Tendrías que salir a lo bruto, matando el programa. Pero hay una solución mejor, claro. Instalaste FreeDOS, ¿recuerdas?.

Bueno, pues vete al directorio «/usr/lib/freedos/dosemu» y verás un montón de comandos propios de FreeDOS pero especialmente diseñados para DosEmu. Cópialos todos a «/var/lib/dosemu/msdos622/utils» (¿ves por qué te recomendaba crearlo?). Entre todos esos comandos, verás uno que se llama «exitemu». Ejecútalo en tu sesión DosEmu y ésta se cerrará limpiamente. También entre esos comandos está el fichero ems.sys al que hacíamos referencia antes.

Ahí lo tienes funcionando. :-)