Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
Este hilo se está haciendo muy largo. Para no extenderme más, hago un resumen del problema y lo solucionado hasta ahora (por favor, leer hasta el final): Sistema: Debian Wheezy + IceWM + SpaceFM + SLiM Ordenador: CPU 1,7 GHz + 512 RAM + HD 13 GB Instalación: NetInstall + paquetes oficiales + paquetes propietarios + scripts propios y de terceros. Propósito: General, investigación científica. Comentarios de interés para esta consulta y breve historial de la instalación: 1). Se creó 1 cuenta de usuario normal (tesistas) para varias personas. 2). Recién instalado, se configuró el sistema para apagado/reinicio/cierre de sesión sin privilegios de superusuario: 2.1). Como root, creé un grupo llamado salir. 2.2). El usuario fue asignado al grupo salir. 2.3). Los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt se cambiaron al grupo salir. 2.4). Asigné permisos de lectura, escritura y ejecución para propietario, grupo y otros a los comandos del punto anterior. 2.5). Creé enlaces simbólicos de /sbin/shutdown, /sbin/reboot y /sbin/halt hasta el directorio /usr/local/bin. 2.6). Se editaron varias líneas del archivo /etc/sudoers de la siguiente forma: Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" User_AliasUSERS = tesistas Cmnd_AliasSHUTDOWN = /usr/local/bin/shutdown, /usr/local/bin/halt, /usr/local/bin/reboot USERSALL = NOPASSWD: SHUTDOWN USERSALL = NOPASSWD: /sbin/poweroff %sudo ALL = (ALL:ALL) ALL 3). Desde el repositorio Wheezy-backports se requirió instalar p11-kit-modules:i386 y pepperfalashplayer-nonfree. 4). Casi un año de instalado y todo funcionaba bien. Luego, varios meses atrás, hice "aptitude full-upgrade" con los repositorios Wheezy-backports habilitados. 5). Hace unos 4-5 días hice "aptitude upgrade" instalándose la actualización para Wheezy 7.9. El problema: Al usar el ordenador, hace un par de días, noté que al intentar apagarlo o reiniciarlo entraba de nuevo en sesión. Al intentarlo desde la terminal de usuario me denegaba el acceso por falta de permisos. Igual resultado al intentarlo como superusuario. Revisando me percaté de que tampoco tenía acceso a las tareas cron del usuario, sin privilegios de root, cuando antes lo podía hacer sin problemas. Solución parcial: El problema con cron se solucionó al hacer "dpkg-reconfigure cron". Situación actual: Aún no he podido solucionar lo de los permisos para apagado/reinicio. Al comprobar los permisos de los ejecutables /sbin/shutdown y /sbin/halt veo que el propietario y el grupo de ambos, tesistas y fuse, respectivamente, no tienen permisos de ejecución. A continuación pego el resultado: --- root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown lrwxrwxrwx 1 root staff 14 abr 27 00:48 /usr/local/bin/shutdown -> /sbin/shutdown root@Tesistas:/home/tesistas# ls -l /sbin/shutdown -rw-r- 1 tesistas fuse 22192 abr 27 00:48 /sbin/shutdown root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot lrwxrwxrwx 1 root staff 12 abr 27 00:49 /usr/local/bin/reboot -> /sbin/reboot root@Tesistas:/home/tesistas# ls -l /sbin/reboot lrwxrwxrwx 1 root root 4 jul 17 2013 /sbin/reboot -> halt root@Tesistas:/home/tesistas# ls -l /sbin/halt -rw-r- 1 tesistas fuse 13848 abr 27 00:49 /sbin/halt root@Tesistas:/home/tesistas# ls -l /sbin/poweroff lrwxrwxrwx 1 root root 4 jul 17 2013 /sbin/poweroff -> halt -- Lo que llevo hecho: 1/ Cambié los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt al grupo salir: # chgrp salir /sbin/shutdown /sbin/reboot /sbin/halt 2/ Dí permisos de ejecución a los comandos /sbin/shutdown y /sbin/halt: # chmod u+s,o-rwx /sbin/shutdown /sbin/halt 3/ Revisé el estado de los permisos para estos comandos: - root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown lrwxrwxrwx 1 root staff 14 oct 10 21:21 /usr/local/bin/shutdown -> /sbin/shutdown root@Tesistas:/home/tesistas# ls -l /sbin/shutdown -rwSr- 1 tesistas salir 22192 abr 27 00:48 /sbin/shutdown root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot lrwxrwxrwx 1 root staff 12 oct 10 21:22 /usr/local/bin/reboot -> /sbin/reboot root@Tesistas:/home/tesistas# ls -l /sbin/reboot lrwxrwxrwx 1 root root 4 jul 17 2013 /sbin/reboot -> halt root@Tesistas:/home/tesistas# ls -l /sbin/halt -rwSr- 1 tesistas salir 13848 abr 27 00:49 /sbin/halt root@Tesistas:/home/tesistas# ls -l /sbin/poweroff lrwxrwxrwx 1 root root 4 jul 17 2013 /sbin/poweroff -> halt Veo varias cosas: - /sbin/reboot no cambió de grupo, pero sí lo hicieron /sbin/shutdown y /sbin/halt. - No estoy seguro si están bien los permisos de los enlaces simbólicos: lrwxrwxrwx 1 root staff. - Sigo sin poder apagar/reiniciar como usuario normal ni como superusuario. No tengo permisos. Con esto me doy cuenta que mis conocimientos sobre GNU/Linux aún son muy limitados. Sin embargo, el sentido común me dice que falta algo que permita apagar/reiniciar
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
2015-10-11 4:40 GMT-04:30, Manolo Díaz <diaz.man...@gmail.com>: > El domingo, 11 oct 2015 a las 06:10 UTC > Frederit Mogollon escribió: > > >> - Sigo sin poder apagar/reiniciar como usuario normal ni como >> superusuario. No tengo permisos. > > Efectivamente, no tienes permiso de ejecución para nadie en esos dos > ejecutables: tienes el bit setuid pero no permiso de ejecución para > root (indicado por la S mayúscula). Por otro lado, ¿para qué cambiar el > grupo si luego el grupo no tiene ningún permiso? > > ¿Has pensado en el enfoque de Ramses, dejar los permisos originales y > utilizar sudo? > > -- > Manolo Díaz > > Hola Ramses, Manolo I En el sudoers sigue todo como lo especifique desde un principio. Voy a probar con usar los permisos originales a ver que tal. Les cuento. Como dato, añado que he estado apagando la máquina dejando presionado el botón de encendido del case/cpu, ayer lo intenté desde una terminal root con el comando # init 0 y me envió a la consola tty1 con el mensaje siguiente Debian GNU t Tesistas tty1 Tesistas login : [8700.289287] EXT4-fs (sda1): remount. Opts: (null) INIT: no more process left in this runlevel y allí se quedó congelada. Igual tuve que apagarla por el botón del case. fdm
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización [SOLUCIONADO]
2015-10-11 11:31 GMT-04:30, Frederit Mogollon <frederitmogol...@gmail.com>: > Las configuraciones que había hecho para apagar/reiniciar sin > privilegios de superusuario solo las llevé a cabo luego de una buena > búsqueda en Google. Y todo salió bien. Y es una de las normas de la > lista, buscar primero antes de caer a preguntar sin más... eso lo he > aprendido desde que estoy usando Debian. > > Sin embargo, la duda que me embarga está planteada arriba, y no se me > quita de la mente que algo de la última actualización tuvo que ver... > no hay otra manera. En base a ello, estuve revisando en la Internet, y > hasta ayer no había hallado respuesta. > > Seguiré intentando. > > > > Bueno, gracias a todos los que me echaron la mano. Es genial contar > con una comunidad dispuesta a yudar. Espero más temprano que tarde, > poder contribuir a la lista, para retribuir toda la ayuda que me han > prestado en estos años. > > > Saludos > > fdm > Ahhh... casi lo olvido. Marco este tema como [SOLUCIONADO]
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
Para lo sugerido por Ramses y Manolo: Entre al modo recovery desde el GRUB2 y - Eliminé los enlaces simbólicos /usr/local/bin/shutdown, /usr/local/bin/halt y /usr/local/bin/reboot. - Luego cambié al grupo root los comandos /sbin/shutdown, /sbin/halt y /sbin/reboot. - Por último, cambié los permisos de los tres comandos anteriores a: # ls -l /sbin/shutdown -rwxr-xr-x 1 tesistas root 22192 abr 27 00:48 /sbin/shutdown # ls -l /sbin/halt -rwxr-xr-x 1 tesistas root 13848 abr 27 00:49 /sbin/halt # ls -l /sbin/reboot lrwxrwxrwx 1 root root 4 jul 17 2013 /sbin/reboot -> halt Con esto, al usar el comando # init 0 el sistema se apagó como debe ser. :) Ya en modo gráfico, todo funciona nuevamente. Ya puedo apagar/reiniciar usando sudo desde la terminal. Gracias por la ayuda. Lo que no me queda claro, es que si estuve trabajando por más de 1 año con las opciones que había configurado para apagar/reiniciar sin privilegios root: ¿por qué razón se alteraron los permisos de estos comandos??? Es un tema que aún debo investigar más... no me puedo quedar con esta duda que me está carcomiendo :) 2015-10-11 10:39 GMT-04:30, Camaleón <noela...@gmail.com>: > El Sun, 11 Oct 2015 01:40:00 -0430, Frederit Mogollon escribió: > >> >> 2). Recién instalado, se configuró el sistema para >> apagado/reinicio/cierre de sesión sin privilegios de superusuario: > > (...) > > Creo que aquí está el lío con el cambio de ruta, usuarios, grupos, > permisos. A mí "sudo" no me gusta, pero mira el Método 2 que usan > en esta guía. > > How to allow non-super users to shutdown computer in Linux > http://how-to.wikia.com/wiki/How_to_allow_non-super_users_to_shutdown_computer_in_Linux > Gracias por el link, lo revisaré...! >> >> Con esto me doy cuenta que mis conocimientos sobre GNU/Linux aún son muy >> limitados. Sin embargo, el sentido común me dice que falta algo que >> permita apagar/reiniciar el sistema. > > Bueno, por lo general (99%) siempre hay alguien que ha pasado por la > misma situación antes que tú, sólo hay que buscar en Google y ver > cómo lo resolvieron :-) > > Saludos, > > -- > Camaleón > > Las configuraciones que había hecho para apagar/reiniciar sin privilegios de superusuario solo las llevé a cabo luego de una buena búsqueda en Google. Y todo salió bien. Y es una de las normas de la lista, buscar primero antes de caer a preguntar sin más... eso lo he aprendido desde que estoy usando Debian. Sin embargo, la duda que me embarga está planteada arriba, y no se me quita de la mente que algo de la última actualización tuvo que ver... no hay otra manera. En base a ello, estuve revisando en la Internet, y hasta ayer no había hallado respuesta. Seguiré intentando. Bueno, gracias a todos los que me echaron la mano. Es genial contar con una comunidad dispuesta a yudar. Espero más temprano que tarde, poder contribuir a la lista, para retribuir toda la ayuda que me han prestado en estos años. Saludos fdm
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
>> -- >> $ crontab -l >> >> $ crontab/tesistas: fdopen: Permiso denegado >> > > Con toda probabilidad, no tienes estos permisos: > > ls -l /usr/bin/crontab > -rwxr-sr-x 1 root crontab 36008 jun 11 12:23 /usr/bin/crontab > > Reinstala el paquete: > > apt-get --reinstall install cron > Hola Santiago, gracias por responder. Pues, al ejecutar la orden sugerida, obtengo los mismos permisos: --- tesistas@Tesistas:~$ ls -l /usr/bin/crontab -rwxr-sr-x 1 root crontab 34760 jul 3 2012 /usr/bin/crontab --- Agradezco el intento. No se si leíste los mensajes anteriores, pero aparentemente no es cron el problema. Algo pasó que me alteró los permisos sobre cron, además de poder apagar/reiniciar como usuario normal, incluso con privilegios de superusuario. Pienso que fue algo relacionado con algún paquete de wheezy-backports instalado. Para agregar más datos, probé desde otro usuario creado anteriormente para ensayos, y obtengo la misma respuesta: -- sancho@Tesistas:~$ crontab -l $ crontab/sancho: fdopen: Permiso denegado Al probar reiniciar desde la consola, entrando en el modo recovery desde el Grub2, obtengo que ni root puede apagar/reiniciar: -- root@Tesistas:~# reboot bash: /sbin/reboot: Permission denied -- pero al revisar las tareas cron de mi usuario desde la consola, puedo verla asignada: - root@Tesistas:~# crontab -u tesistas -l 0 0 13 * * 4 /usr/bin/freshclam --quiet; /usr/bin/clamscan -ril /home/tesistas/Descargas -- Saludos fdm
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
2015-10-10 13:09 GMT-04:30, Santiago Vila <sanv...@unex.es>: > On Sat, Oct 10, 2015 at 09:44:40AM -0430, Frederit Mogollon wrote: > >> Agradezco el intento. No se si leíste los mensajes anteriores, pero >> aparentemente no es cron el problema. > > Al final sí era cron el problema. Las opciones eran básicamente dos: > > * Que la orden crontab no fuera set-gid crontab (la que yo pensaba que > al final no era). > > * Que el directorio /var/spool/cron/crontabs no fuera del grupo > crontab y escribible por el grupo. > > El permiso set-gid crontab permite a la orden crontab ejecutarse con > privilegios del grupo crontab aunque lo ejecute un usuario normal, > para así para poder escribir en /var/spool/cron/crontabs, por eso > el directorio es escribible por el grupo y pertenece al grupo crontab. > Santiago, esta parte del cuento, pude solucionarlo al ejecutar la reconfiguración automática de cron con la orden "dpkg-reconfigure cron", lo cual restauró la asignación del directorio /var/spool/cron/crontabs al grupo crontab. > Me vas a decir que "es muy fácil decirlo" pero una vez que entiendes > cómo funcionan las cosas lo único que hace falta es ir revisando cada > eslabón de la cadena. > Tienes toda la razón. Como todos, cada vez voy aprendiendo más sobre el entorno GNU/Linux, y en especial de Debian. > Me leí los mensajes anteriores, sí, pero no entendí qué tienen que ver > los backports con todo esto. En general los backports no estropean > cosas. > Cuando escribí que cron no era el problema, me refería a que de buenas a primera pasó algo que alteró la asignación de permisos, tanto a cron como a los comandos /sbin/halt y /sbin/shutdown, tal como los había configurado luego de instalar el sistema hace tiempo atrás. Estoy consciente de que recientemente, no toqué nada de eso. Una posibilidad en la que había pensado, es que alguien más tuvo acceso al sistema y alteró los permisos. Sin embargo, esto es poco probable, porque en el sitio donde estoy soy el único que trato con Debian. Los demás son fieles seguidores de los sistemas operativos de Redmont y para nada se meten con otra cosa que no sea usar el navegador web, el paquete ofimático, el lector de pdf, el visor de imágenes y reproductor multimedia. Dado que esta máquina es viejita, con solo unos 10 GB de disco duro y 512 MB de ram, fue Debian GNU/Linux la que la puso a volar. Y casi a regañadientes, puesto que no hay más ordenadores disponibles, han aprendido a usar el sistema para lo que necesitan. Entonces, el único hecho al que puedo asociar las alteraciones registradas en los permisos, es la actualización automática de paquetes a wheezy-backports, considerando que tenía el repositorio habilitado en el fichero /etc/sources.list. Saludos fdm
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
2015-10-10 10:41 GMT-04:30, Camaleón <noela...@gmail.com>: > El Sat, 10 Oct 2015 10:18:07 -0430, Frederit Mogollon escribió: > >>> >> tesistas@Tesistas:~$ ls -la /var/spool/cron/ >> >> total 20 >> drwxr-xr-x 5 root root 4096 abr 17 16:01 . >> drwxr-xr-x 4 root root 4096 jul 18 14:52 .. >> drwxrwx--T 2 root root 4096 abr 17 16:03 atjobs >> drwxrwx--T 2 root root 4096 oct 3 2014 atspool >> drwx-wx--T 2 root root 4096 jul 10 01:00 crontabs > > > Aquí hay algo raro, mira: > > root@stt008:~# ls -l /var/spool/cron/ > total 0 > drwxrwx--T 2 daemon daemon 72 jun 1 2013 atjobs > drwxrwx--T 2 daemon daemon 48 jun 9 2012 atspool > drwx-wx--T 2 root crontab 48 jul 3 2012 crontabs > > El grupo del directorio "crontabs" es root en tu caso y "crontab" en el > mío (el comando lo he ejecutado desde Wheezy pero en mi testing de > pruebas los propietarios se mantienen como en Wheezy). > > >> Aunque lo extraño es que antes podía hacerlo sin sudo. Además, creo que >> el enfoque no es tanto sobre cron/crontab, sino en ¿por qué carrizo se >> vieron afectados los permisos si no los toqueteé? y ¿por qué no me deja >> apagar/reiniciar el equipo, devolviéndome al inicio de sesión, aún como >> superusuario? > > Obviamente algo ha pasado con los permisos pero no sé qué puede haberlo > generado salvo un cambio manual. Puedes intentar reconfigurar el paquete > con "dpkg-reconfigure cron" a ver si es capaz de arreglarlo > automáticamente. > Si, la reconfiguración automática del paquete cron surtió efecto! :) El grupo del directorio crontabs es nuevamente crontab, y ya puedo ver las tareas cron de mi usuario sin privilegios de root, que es lo normal: --- root@Tesistas:/home/tesistas# dpkg-reconfigure cron [ ok ] Stopping periodic command scheduler: cron. [ ok ] Starting periodic command scheduler: cron. root@Tesistas:/home/tesistas# ls -l /var/spool/cron/ total 12 drwxrwx--T 2 root root4096 abr 17 16:03 atjobs drwxrwx--T 2 root root4096 oct 3 2014 atspool drwx-wx--T 2 root crontab 4096 jul 10 01:00 crontabs root@Tesistas:/home/tesistas# ls -l /var/spool/cron/crontabs/ total 4 -rw--- 1 tesistas crontab 1630 jul 10 01:00 tesistas tesistas@Tesistas:~$ crontab -l 0 0 13 * * 4 /usr/bin/freshclam --quiet; /usr/bin/clamscan -ril /home/tesistas/Descargas tesistas@Tesistas:~$ crontab -e No modification made - Muchas gracias por tu ayuda. Me sirvió de mucho. Saludos fdm
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
2015-10-10 10:54 GMT-04:30, Manolo Díaz <diaz.man...@gmail.com>: > El viernes, 9 oct 2015 a las 11:38 UTC > Frederit Mogollon escribió: > >> >> # shutdown -h now >> bash: /usr/local/bin/shutdown: Permiso denegado >> - >> >> # poweroff >> bash: /sbin/poweroff: Permiso denegado >> --- >> --- >> # reboot >> bash: /usr/local/bin/reboot: Permiso denegado >> > > ¿El sistema de ficheros está bien? ¿Has comprobado los permisos de > alguno de esos ejecutables que te lo deniegan? > > -- Hola Manolo, gracias por responder. No lo había hecho. Al comprobar los permisos de los ejecutables /sbin/shutdown y /sbin/halt veo que el propietario y el grupo de ambos, tesistas y fuse, respectivamente, no tienen permisos de ejecución. Aquí creo es importante destacar, que hace año y medio cuando instalé este sistema, configuré que el ordenador se apagara/reiniciara desde el usuario normal, sin privilegios de root, dado que el equipo iba a ser consultado por muchas personas, dejando un solo usuario. Para esto, como root, creé un grupo llamado salir, al que asigné al usuario. Luego, cambié al grupo salir los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt, y les cambié los permisos a lectura, escritura y ejecución para todo mundo. Seguidamente, creé enlaces simbólicos al path del usuario, es decir, al directorio /usr/local/bin. A continuación pego el resultado: --- root@Tesistas:/home/tesistas# ls -l /usr/local/bin/shutdown lrwxrwxrwx 1 root staff 14 abr 27 00:48 /usr/local/bin/shutdown -> /sbin/shutdown root@Tesistas:/home/tesistas# ls -l /sbin/shutdown -rw-r- 1 tesistas fuse 22192 abr 27 00:48 /sbin/shutdown root@Tesistas:/home/tesistas# ls -l /usr/local/bin/reboot lrwxrwxrwx 1 root staff 12 abr 27 00:49 /usr/local/bin/reboot -> /sbin/reboot root@Tesistas:/home/tesistas# ls -l /sbin/reboot lrwxrwxrwx 1 root root 4 jul 17 2013 /sbin/reboot -> halt root@Tesistas:/home/tesistas# ls -l /sbin/halt -rw-r- 1 tesistas fuse 13848 abr 27 00:49 /sbin/halt root@Tesistas:/home/tesistas# ls -l /sbin/poweroff lrwxrwxrwx 1 root root 4 jul 17 2013 /sbin/poweroff -> halt --- Me pregunto: ¿Qué pudo haber ocasionado que los comandos /sbin/shutdown y /sbin/halt perdiesen sus permisos de ejecución, cuando ya se los había configurado y funcionaba bien? Aquí especulo sobre la posibilidad de que la actualización de algún paquete desde wheezy a wheeezy-bacports, relacionado con la asignación de permisos, sea la causante de la restauración de permisos sobre los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt, a como queda acabado de instalar el sistema operativo. Bueno, para intentar solucionar esto, podría volver a asignar permisos de lectura, escritura y ejecución a los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt para el propietario tesistas y el grupo fuse. Puedo intentar con la opción de "dpkg-reconfigure sysvinit" para reconfigurar el paquete que proporciona a los comandos antes mencionados (si funcionó con cron, puede que funcione con esto). Saludos fdm
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
>> root@Tesistas:/home/tesistas# ls -la /var/spool/cron/crontabs/ >> total 12 drwx-wx--T 2 root root4096 jul 10 01:00 . >> drwxr-xr-x 5 root root4096 abr 17 16:01 .. >> -rw--- 1 tesistas crontab 1630 jul 10 01:00 tesistas > > Parece correcto. Sube un nivel más para ver si los permisos/propietarios > siguen bien: > > ls -la /var/spool/cron/ > -- tesistas@Tesistas:~$ ls -la /var/spool/cron/ total 20 drwxr-xr-x 5 root root 4096 abr 17 16:01 . drwxr-xr-x 4 root root 4096 jul 18 14:52 .. drwxrwx--T 2 root root 4096 abr 17 16:03 atjobs drwxrwx--T 2 root root 4096 oct 3 2014 atspool drwx-wx--T 2 root root 4096 jul 10 01:00 crontabs - > Y revisa también lo que comentan en esta página, más que nada porque el > mensaje que recibe el usuario parece el mismo que recibes tú: > > crontab listing or editing results in fopen: permission denied > http://serverfault.com/questions/619296/crontab-listing-or-editing- > results-in-fopen-permission-denied > Revisé el link que dejaste, y efectivamente puedo editar el crontab de mi usuario accediendo como superusuario, sin modificar permisos: - tesistas@Tesistas:~$ sudo crontab -u tesistas -e 0 0 13 * * 4 /usr/bin/freshclam --quiet; /usr/bin/clamscan -ril /home/tesistas/Descargas - Aunque lo extraño es que antes podía hacerlo sin sudo. Además, creo que el enfoque no es tanto sobre cron/crontab, sino en ¿por qué carrizo se vieron afectados los permisos si no los toqueteé? y ¿por qué no me deja apagar/reiniciar el equipo, devolviéndome al inicio de sesión, aún como superusuario? >> Aquí si es falta mía en agregar que para apagar el ordenador desde el >> usuario normal sin privilegios de root (es un ordenador con un solo >> usuario -tesistas-, pero utilizado por varias personas desde la misma >> cuenta de usuario), había creado links simbólicos de los comandos >> /sbin/shutdown, /sbin/reboot y /sbin/halt al path del usuario tesistas. >> Esto en nada representa un factor que contribuya al problema en debate, >> puesto que lo había implementado ya desde hace más de año y medio, y >> funcionaba de maravilla. > > Pero no es normal que no te permita apagar el equipo y que te devuelva l > inicio de sesión, porque entiendo que has ejecutado el "shutdown -h now" > como súperusaurio ¿no? En caso contrario, prueba como root. > Si, lo he intentado como root > Bueno, es pronto para saber qué es lo que ha pasado, de momento hay > algunos comandos que no funcionan como deberían pero de ahí a echar la > culpa a los backports va un mundo :-) > > Los paquetes de los backports llevan la coletilla "-bpo" y aquí la > mayoría (en realidad, todos menos el kernel) no la tienen, es decir, que > no parece que el problema venga de esos paquetes. > Si lees mi mensaje anterior en el hilo (de fecha 10 de octubre de 2015, 2:28 a. m), te darás cuenta por qué lo digo. Saludos fdm
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
> > Al listar los paquetes instalados desde backports, obtengo que son en > total 120: > --- > root@Tesistas:/home/tesistas# for p in $(dpkg -l | grep '^ii' | cut -d > ' ' -f 3); do apt-cache showpkg $p | head -3 | grep -v '^Versions' | > sed -e 's/Package: //;' | paste - - ; done | grep backports | wc -l > 120 > -- > > y son: > > > -- > root@Tesistas:/home/tesistas# for p in $(dpkg -l | grep '^ii' | cut -d > ' ' -f 3); do apt-cache showpkg $p | head -3 | grep -v '^Versions' | > sed -e 's/Package: //;' | paste - - ; done | grep backports | awk -F > '\t' '{print $1}' > autopoint > bind9-host > consolekit > cryptsetup-bin > desktop-file-utils > dmidecode > dnsutils > file > geoip-database > gettext > gettext-base > git > git-man > gstreamer1.0-libav > init-system-helpers > initramfs-tools > iproute > iproute2 > irqbalance > liba52-0.7.4 > libasprintf0c2 > libavutil53 > libbind9-90 > libbsd0 > libck-connector0 > libcryptsetup4 > libdns100 > libdvdnav4 > libdvdread4 > libestr0 > libevdev2 > libgeoip1 > libgettextpo0 > libgnutls-deb0-28 > libgpg-error0 > libgstreamer-plugins-base1.0-0 > libgstreamer1.0-0 > libgudev-1.0-0 > libhogweed2 > libisc95 > libisccc90 > libisccfg90 > libjson-c2 > libjson0 > libldap-2.4-2 > libldb1 > liblogging-stdlog0 > liblwres90 > libmagic1 > libnettle4 > libnl-3-200 > libnl-genl-3-200 > libntdb1 > libopus0 > liborc-0.4-0 > libp11-kit0 > libpam-ck-connector > libpoppler-glib8 > libpoppler46 > libpulse0 > libqt4-dbus > libqt4-network > libqt4-opengl > libqt4-sql > libqt4-sql-sqlite > libqt4-svg > libqt4-xml > libqtcore4 > libqtdbus4 > libqtgui4 > libsmbclient > libsystemd-login0 > libtag1-vanilla > libtag1c2a > libtalloc2 > libtasn1-6 > libtdb1 > libtevent0 > libudev1 > libusb-1.0-0 > libwbclient0 > libxapian22 > libxcb-glx0 > libxcb-randr0 > libxcb-render0 > libxcb-shape0 > libxcb-shm0 > libxcb-xv0 > libxcb1 > libxnvctrl0 > linux-image-3.16.0-0.bpo.4-686-pae > linux-image-686-pae > linux-libc-dev > memtest86+ > openssh-client > p11-kit-modules > pepperflashplugin-nonfree > poppler-utils > python-debian > python-libtorrent > python-six > python-talloc > python-twisted-bin > python-twisted-core > python-twisted-web > qdbus > rsyslog > samba-libs > shared-mime-info > slim > smartmontools > spacefm > spacefm-common > tar > udev > udevil > vim-common > vim-tiny > whois > xserver-xorg-input-synaptics > -- > Como actualización en el intento de solucionar el embrollo en que estoy metido (sin reinstalar -es lo que estoy intentando no hacer-), comento lo que he hecho hasta ahora: 1. Inhabilité el repositorio de wheezy-backports: -- root@Tesistas:/home/tesistas# cat /etc/apt/sources.list # deb cdrom:[Debian GNU/Linux 7.8.0 _Wheezy_ - Official i386 NETINST Binary-1 20150110-13:31]/ wheezy main deb http://cdn.debian.net/debian/ wheezy main contrib non-free deb-src http://cdn.debian.net/debian/ wheezy main contrib non-free deb http://security.debian.org/ wheezy/updates main contrib non-free deb-src http://security.debian.org/ wheezy/updates main contrib non-free # wheezy-updates, previously known as 'volatile' deb http://cdn.debian.net/debian/ wheezy-updates main contrib non-free deb-src http://cdn.debian.net/debian/ wheezy-updates main #deb http://http.debian.net/debian wheezy-backports main contrib -- 2. Actualicé la lista de paquetes en el caché de apt root@Tesistas:/home/tesistas# aptitude update -- 3. Creé el archivo /etc/apt/preferences para configurar apt a que instalara versiones de paquetes desde el repositorio de wheezy: root@Tesistas:/home/tesistas# cat /etc/apt/preferences Package: * Pin: release n=wheezy Pin-Priority: 1001 - 4. Intenté desactualizar los paquetes instalados, pero no se ejecutó la acción: - root@Tesistas:/home/tesistas# aptitude safe-upgrade No se instalará, actualizará o eliminará ningún paquete. 0
Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
Buenas compañeros de la lista. En esta ocasión les comentaré sobre un problema inicial con cron/crontab, pero que ahora creo se trata de actualización. Es un poco largo, así que por partes. ## Primero, el contexto: Les escribo desde un sistema Debian Wheezy 7.9 + IceWM + SpaceFM + SLiM, instalado en una PC de escritorio, con 512 MB de RAM y 10 GB de HD IDE. Los kernels instalados son: linux-image-3.16.0-0.bpo.4-686-pae linux-image-3.2.0-4-686-pae La lista de repositorios es: --- root@Tesistas:/home/tesistas# cat /etc/apt/sources.list # deb cdrom:[Debian GNU/Linux 7.8.0 _Wheezy_ - Official i386 NETINST Binary-1 20150110-13:31]/ wheezy main deb http://cdn.debian.net/debian/ wheezy main contrib non-free deb-src http://cdn.debian.net/debian/ wheezy main contrib non-free deb http://security.debian.org/ wheezy/updates main contrib non-free deb-src http://security.debian.org/ wheezy/updates main contrib non-free # wheezy-updates, previously known as 'volatile' deb http://cdn.debian.net/debian/ wheezy-updates main contrib non-free deb-src http://cdn.debian.net/debian/ wheezy-updates main deb http://http.debian.net/debian wheezy-backports main contrib #deb http://www.deb-multimedia.org wheezy main non-free #deb-src http://cdn.debian.net/debian/ wheezy main --- ## Ahora, el problema e intentos de solucionarlo. Desde la versión Debian 7.8 había asignado el escaneado automático del sistema con clamav, mediante crontab desde el usuario normal. Aclaro, que funcionaba perfecto. En el lapso de los últimos 15 días, actualicé un par de veces el sistema, con las líneas: --- $ sudo aptitude update $ sudo aptitude upgrade - siendo la última actualización entre ayer y hoy. Al intentar modificar la tarea de ejecución de clamav desde crontab, con las órdenes -- $ crontab -l $ crontab -e obtuve la siguiente respuesta: -- $ crontab/tesistas: fdopen: Permiso denegado - cuando antes se listaba la única tarea asignada en el crontab del usuario tesistas. Se que aún existe tal asignación puesto que el clamscan se ejecutó a la hora que lo tenía programado inicialmente. Luego de leer los manuales de cron/crontab, me percaté que en el directorio /var/spool/cron/crontabs/ se halla un archivo con el nombre del usuario (tesistas), y que contiene la tarea asignada al crontab. Supuse que tras un cambio mayor en una de las actualizaciones, se alteró alguna configuración que conllevó a la pérdida de permisos por parte del usuario normal. Al intentar reasignar al usuario al grupo crontab, con la línea: --- $ usermod -aG crontab tesistas -- obtuve la misma respuesta de permiso denegado. Eventualmente, descubrí que al intentar apagar o reiniciar el ordenador, era redirigido a la pantalla de inicio de SLiM, solicitando el login y password, como normalmente ocurre al cerrar sesión. Al intentarlo desde terminal de usuario y de root, obtuve respuestas similares: # shutdown -h now bash: /usr/local/bin/shutdown: Permiso denegado - # poweroff bash: /sbin/poweroff: Permiso denegado --- --- # reboot bash: /usr/local/bin/reboot: Permiso denegado En este punto pensé que el problema radicaba en la última actualización del kernel desde backports, por lo que opté por el reinicio forzado desde el hardware, e ingresé mediante el kernel linux-image-3.2.0-4-686-pae. Al realizar pruebas tanto con crontab como con el apagado, similares a las anteriores, obtuve las mismas respuestas de "permiso denegado", lo que obviamente descarta el kernel como fuente de problema. A continuación pego el contenido de dos archivos log relevantes: --- # cat /var/log/aptitude Aptitude 0.6.8.2: informe de registro vie, oct 9 2015 02:29:56 -0430 IMPORTANTE: este registro sólo muestra las acciones que se pretenden realizar. Puede que no se completen algunas acciones por fallos de dpkg. Se instalarán 4 paquetes y se eliminarán 0. Se
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
>> deb http://http.debian.net/debian wheezy-backports main contrib > > Yo le tengo mucho respeto a los backports porque a menudo instalan/ > actualizan paquetes que no siempre esperas, generalmente bibliotecas y > generalmente también por dependencias, lo cual es esperable pero no > siempre deseable. > > Mi política con los paquetes/repositorios de los backports es dejarlos > desactivados y usarlos sólo de manera premeditada, es decir, si quiero > instalar un paquete lo hago manualmente con "apt-get -t wheezy-backports > install [paquete]" y así me evito disgustos. > Hola Camaleón. Gracias por responder. Si, siempre había usado esa estrategia, pero esta vez me fui de impulso, y como que no es buena idea actualizar todo a backports de una. >> -- >> $ crontab/tesistas: fdopen: Permiso denegado >> - > > (...) > > Comprueba los permisos/propietarios del directorio de tareas de tu > usuario: > > ls -la /var/spool/cron/crontabs/ > Al intentar leer los permisos obtengo esto: - tesistas@Tesistas:~$ ls -la /var/spool/cron/crontabs/ ls: no se puede abrir el directorio /var/spool/cron/crontabs/: Permiso denegado - Al hacerlo como root, resulta lo siguiente: -- root@Tesistas:/home/tesistas# ls -la /var/spool/cron/crontabs/ total 12 drwx-wx--T 2 root root4096 jul 10 01:00 . drwxr-xr-x 5 root root4096 abr 17 16:01 .. -rw--- 1 tesistas crontab 1630 jul 10 01:00 tesistas --- > No veo la forma en que un escaneo de clamav altere los permisos de los > archivos, creo que no lo hace al menos de manera predeterminada y en caso > de cambiarlos sin haberle dicho expresamente que lo haga se trataría de > un bug muy serio. Lo que sí podría hacer es mover archivos a una > cuarentena pero como digo, hasta donde sé hay que configurarlo para que > eso suceda. > o.O Oh no no... tal vez fui yo, que no me supe explicar bien: Clamav en ningún momento alteró los permisos de archivos. Solamente hice la referencia para denotar contextualmente que la ejecución de tareas asignadas a cron desde crontab del usuario tesistas (usuario normal), funcionaba perfectamente, y que de esto me cercioré al observar que el antivirus se ejecutaba al tiempo programado, aún cuando no mostraba el crontab del usuario. > > Eso de añadir tu usuario al grupo crontab no debería ser necesario :-? Si, lo sé..., antes funcionaba y no había sido necesario añadirlo, pero intenté esa opción para ver si con ello el usuario tesistas obtenía de nuevo permisos en su otrora crontab de usuario. >> >> # shutdown -h now >> bash: /usr/local/bin/shutdown: Permiso denegado >> >> > > (...) > > ¿Y esa ruta? :-? > > root@stt008:~# whereis shutdown > shutdown: /sbin/shutdown /usr/share/man/man8/shutdown.8.gz > Aquí si es falta mía en agregar que para apagar el ordenador desde el usuario normal sin privilegios de root (es un ordenador con un solo usuario -tesistas-, pero utilizado por varias personas desde la misma cuenta de usuario), había creado links simbólicos de los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt al path del usuario tesistas. Esto en nada representa un factor que contribuya al problema en debate, puesto que lo había implementado ya desde hace más de año y medio, y funcionaba de maravilla. > > El kernel no suele hacer esas maldades de tocar los permisos, cuando te > toca las narices usa otros "métodos". > Si, descarté su participación en este rompecabezas... > Yo estoy con la misma versión pero no he tenido ese problema (eso sí, no > tengo el repo de backports habilitado y uso el kernel predeterminado) > > sm01@stt008:~$ lsb_release -a > No LSB modules are available. > Distributor ID: Debian > Description: Debian GNU/Linux 7.9 (wheezy) > Release: 7.9 > Codename: wheezy > Tocará hacer una desactualización de la mayoría de paquetes instalados/actualizados desde backports... :/ > Desde luego parece un problema de permisos, vete revisando los registros > (/var/log/syslog) por si vieras algo raro y comprueba a ver cuántos > paquetes de los backports tienes instalados. > Sinceramente no veo los logs a menudo, pero al revisar el syslog, hay algo que me llama la atención y no sé si es normal, me refiero a la descripción "ordered data mode. Opts: (null)" en las siguientes líneas del log:
[SOLUCIONADO] Configuración fstab luego de separar directorios de sistema en distintas particiones
-- Forwarded message -- From: Frederit Mogollon <frederitmogol...@gmail.com> Date: Mon, 28 Sep 2015 02:19:59 -0430 Subject: Configuración fstab luego de separar directorios de sistema en distintas particiones To: debian-user-spanish <debian-user-spanish@lists.debian.org> Buenas compañeros listeros. Tiempo sin pasar por aquí. Esta vez, solicito su ayuda con respecto al fichero fstab. Es un poco largo, así que trataré de darme a entender. Primero el contexto. Les escribo desde un sistema Debian Wheezy + IceWM + SpaceFM + SLiM. Inicialmente fue instalado en una PC de escritorio viejito, con 512 MB de RAM y 10 GB de HD IDE. Este último estaba particionado de la siguiente forma: 1 partición primaria 4,8 GB para / 1 partición extendida 1 partición lógica 0,5 GB para swap 1 partición lógica 4,7 GB para /home y su respectivo fichero /etc/fstab: --- # # / was on /dev/sda1 during installation UUID=7437b2c5-67cd-4c93-9e62-503ae6725b01 / ext4 errors=remount-ro 0 1 # /home was on /dev/sda6 during installation UUID=231fedce-f93b-46f0-a60b-5ac147b5a465 /home ext4defaults 0 2 # swap was on /dev/sda5 during installation UUID=f844c8a0-2201-4b05-a925-de36ab021f28 noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sr1/media/cdrom1 udf,iso9660 user,noauto 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0 --- Todo funcionaba bien. Pero, obviamente lo menos malo que cabría esperar sucedió, el disco se llenó. Monté como esclavo otro disco duro IDE de 3 GB que conseguí en otra máquina viejita ya no usada. Para no reinstalar el sistema, decidí transferir los directorios /opt, /var, /tmp y la swap a este disco duro "nuevo", dejando un par de GBs disponibles para / y /home en el disco duro "viejo". Siguiendo varios minitutoriales que hallé en la Internet, seguí los siguientes pasos: 1) Usando una distribución Puppy Linux corriendo desde la RAM, particioné el disco duro de 3 GB, de la siguiente forma: /dev/sdb1 0,5 GB /dev/sdb2 1 GB /dev/sdb3 1 GB /dev/sdb4 0,5 GB 2) El contenido de los directorios antes mencionados en /dev/sda1, fueron copiados hasta las nuevas particiones, de la siguiente forma: /opt > /dev/sdb1 /var > /dev/sdb2 /tmp > /dev/sdb3 y swap en /dev/sda5 > /dev/sdb4 3) Los directorios en cuestión en /dev/sda1, fueron renombrados para conservarlos (por si acaso..!), y movidos a una unidad usb externa. /opt > /opt-old /var > /var-old /tmp > /tmp-old 4) Se crearon nuevos directorios /opt, /var, /tmp vacíos en /dev/sda1. 5) Se modificó el fichero /etc/fstab, para indicarle al sistema donde buscar en el inicio, de la siguiente forma: --- # # # / was on /dev/sda1 during installation UUID=7437b2c5-67cd-4c93-9e62-503ae6725b01 /ext4 errors=remount-ro0 1 # # /opt was on /dev/sdb1 during secondary hard disk installation UUID=4c02b4db-c7c8-4efc-a04f-e48e2bbba6f6 /optext4 defaults0 2 # # /var was on /dev/sdb2 during secondary hard disk installation UUID=ce476a9b-047b-474b-bf04-320f2f7d292e /varext4 defaults0 2 # # /tmp was on /dev/sdb3 during secondary hard disk installation UUID=663a04f9-e8d0-49ee-96d0-2f9f4627865c /tmp ext4 defaults0 2 # # /home was on /dev/sda6 during installation UUID=231fedce-f93b-46f0-a60b-5ac147b5a465 /home ext4 defaults0 2 # # swap was /dev/sdb4 during secondary hard disk installation /dev/sdb4 noneswap sw0 0 # /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sr1/media/cdrom1 udf,iso9660 user,noauto 0 0 # /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0 --- Se guardaron los cambios y se cerró el fichero. 6) Se reinició el sistema, cruzando los dedos. Todo bien. Ahora, el problema. Bien, todo andubo perfecto hasta que me cercioré que 2 aplicaciones (Opera-developer 32-bit y programas para MS-Windows instalados en PlayOnLinux), no se ejecutaban cabalmente al hacer clic desde el menú, cuando antes de las modificaciones lo hacían bien. Al intentar ejecutarlas desde una terminal de usuario, se obtienen los siguientes mensajes; --- tesistas@Tesistas:~$ opera-developer Failed to create random directory /tmp/pulse-S5Y2v7FilcE6: Permiso denegado Failed to symlink /home/tesistas/.pulse/918262357ad06d6
Re: Configuración fstab luego de separar directorios de sistema en distintas particiones
2015-09-28 6:27 GMT-04:30, Santiago Vila: > > El directorio /tmp debe ser escribible por todo el mundo y tener el > bit "sticky". Se corrige así, mientras está montado: > > chmod 1777 /tmp > > Eso es todo. - Gracias por responder. Sí, era eso. :) Fue la primera vez que hice esta operación, de usar /tmp en otra partición manualmente. Antes, cuando lo había hecho era con el instalador de Debian. Aprendí sobre el sticky bit. 2015-09-28 8:50 GMT-04:30, Camaleón : > Cuando hay discos duros de poca capacidad, yo prefiero seguir otra > estrategia en cuanto al particionados: > > 1/ Unirlos antes que separarlos, es decir, conectar los dos discos y > crean un volumen de 10+3=13 GiB (con LVM y sin RAID, si se trata de un > equipo casero). La ventaja de este esquema es que podrás añadir/quitar > discos de mayor capacidad en caso de que lo necesites sin tener que > volver a reinstalar/reparticionar todo de nuevo. > > 2/ Evitar el uso de particiones. Cuando hay poco espacio para repartir, > usar sólo 2 particiones: una para la raíz "/" y otra para la "swap", nada > más porque no es necesario. > - Gracias por responder. Gracias por el dato, lo tomaré en cuenta. :) - > Como bien apuntas, parece que tienes problemas con los permisos del > directorio /tmp, te pongo tal y como están los míos en Wheezy: > > sm01@stt008:~$ ls -la / | grep tmp > drwxrwxrwt 6 root root 504 sep 28 15:11 tmp > > Saludos, > > -- > Camaleón > > -- Si, efectivamente, era problemas de permisos sobre el directorio /tmp. Se aprecia en la letra "t"asignada en la línea que colocaste. Ahora, otra pregunta, tal vez tonta, pero de interés. He leído en varios sitios que no es buena práctica dar permisos de ejecución a todo en el directorio /tmp, puesto que en el mismo tiene acceso todo el mundo, imagino se refiere a los que tienen acceso físico al ordenador. Aquí el sticky bit, "permite evitar que un usuario pueda borrar ficheros/directorios de otro usuario dentro de ese directorio, ya que todos tienen permiso de escritura" (tomado desde http://rm-rf.es/permisos-especiales-setuid-setgid-sticky-bit/). Es una forma de proteger a todos de todos? fdm
Configuración fstab luego de separar directorios de sistema en distintas particiones
Buenas compañeros listeros. Tiempo sin pasar por aquí. Esta vez, solicito su ayuda con respecto al fichero fstab. Es un poco largo, así que trataré de darme a entender. Primero el contexto. Les escribo desde un sistema Debian Wheezy + IceWM + SpaceFM + SLiM. Inicialmente fue instalado en una PC de escritorio viejito, con 512 MB de RAM y 10 GB de HD IDE. Este último estaba particionado de la siguiente forma: 1 partición primaria 4,8 GB para / 1 partición extendida 1 partición lógica 0,5 GB para swap 1 partición lógica 4,7 GB para /home y su respectivo fichero /etc/fstab: --- # # / was on /dev/sda1 during installation UUID=7437b2c5-67cd-4c93-9e62-503ae6725b01 / ext4 errors=remount-ro 0 1 # /home was on /dev/sda6 during installation UUID=231fedce-f93b-46f0-a60b-5ac147b5a465 /home ext4defaults 0 2 # swap was on /dev/sda5 during installation UUID=f844c8a0-2201-4b05-a925-de36ab021f28 noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sr1/media/cdrom1 udf,iso9660 user,noauto 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0 --- Todo funcionaba bien. Pero, obviamente lo menos malo que cabría esperar sucedió, el disco se llenó. Monté como esclavo otro disco duro IDE de 3 GB que conseguí en otra máquina viejita ya no usada. Para no reinstalar el sistema, decidí transferir los directorios /opt, /var, /tmp y la swap a este disco duro "nuevo", dejando un par de GBs disponibles para / y /home en el disco duro "viejo". Siguiendo varios minitutoriales que hallé en la Internet, seguí los siguientes pasos: 1) Usando una distribución Puppy Linux corriendo desde la RAM, particioné el disco duro de 3 GB, de la siguiente forma: /dev/sdb1 0,5 GB /dev/sdb2 1 GB /dev/sdb3 1 GB /dev/sdb4 0,5 GB 2) El contenido de los directorios antes mencionados en /dev/sda1, fueron copiados hasta las nuevas particiones, de la siguiente forma: /opt > /dev/sdb1 /var > /dev/sdb2 /tmp > /dev/sdb3 y swap en /dev/sda5 > /dev/sdb4 3) Los directorios en cuestión en /dev/sda1, fueron renombrados para conservarlos (por si acaso..!), y movidos a una unidad usb externa. /opt > /opt-old /var > /var-old /tmp > /tmp-old 4) Se crearon nuevos directorios /opt, /var, /tmp vacíos en /dev/sda1. 5) Se modificó el fichero /etc/fstab, para indicarle al sistema donde buscar en el inicio, de la siguiente forma: --- # # # / was on /dev/sda1 during installation UUID=7437b2c5-67cd-4c93-9e62-503ae6725b01 /ext4 errors=remount-ro0 1 # # /opt was on /dev/sdb1 during secondary hard disk installation UUID=4c02b4db-c7c8-4efc-a04f-e48e2bbba6f6 /optext4 defaults0 2 # # /var was on /dev/sdb2 during secondary hard disk installation UUID=ce476a9b-047b-474b-bf04-320f2f7d292e /varext4 defaults0 2 # # /tmp was on /dev/sdb3 during secondary hard disk installation UUID=663a04f9-e8d0-49ee-96d0-2f9f4627865c /tmp ext4 defaults0 2 # # /home was on /dev/sda6 during installation UUID=231fedce-f93b-46f0-a60b-5ac147b5a465 /home ext4 defaults0 2 # # swap was /dev/sdb4 during secondary hard disk installation /dev/sdb4 noneswap sw0 0 # /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sr1/media/cdrom1 udf,iso9660 user,noauto 0 0 # /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0 --- Se guardaron los cambios y se cerró el fichero. 6) Se reinició el sistema, cruzando los dedos. Todo bien. Ahora, el problema. Bien, todo andubo perfecto hasta que me cercioré que 2 aplicaciones (Opera-developer 32-bit y programas para MS-Windows instalados en PlayOnLinux), no se ejecutaban cabalmente al hacer clic desde el menú, cuando antes de las modificaciones lo hacían bien. Al intentar ejecutarlas desde una terminal de usuario, se obtienen los siguientes mensajes; --- tesistas@Tesistas:~$ opera-developer Failed to create random directory /tmp/pulse-S5Y2v7FilcE6: Permiso denegado Failed to symlink /home/tesistas/.pulse/918262357ad06d602d3d474a55318f1f-runtime.tmp: Permiso denegado [0928/005850:ERROR:process_singleton_posix.cc(975)] Failed to create socket directory. [0928/005850:ERROR:opera_browser_main_parts.cc(682)] Failed to create a ProcessSingleton for your profile directory. This means that running multiple instances would start multiple browser processes rather
[OT]: Crear applet con udevil para barra de tareas en IceWM
Buenas compañeros listeros. En esta ocasión vengo con una consulta de algo que se me ocurrió. Primero, el ordenador sustrato: Procesador Pentium IV 1,7 GHz, 512 MB RAM, 10 GB HD, tarjeta gráfica GeForce2 MX/MX400 NV11. Debian Wheezy 7.8, IceWM _1.3.7, SpaceFM_0.9.3, Udevil_0.4.3-1, SLiM_1.3.4-2. El contexto: Dado que uso SpaceFM con udevil, que permite montar medios removibles (dispositivos USB, CD/DVD) sin permisos de root, pensé en la posibilidad de un dockapp/applet para la taskbar de IceWM (gestor de ventanas que uso), que permita desmontar fácilmente medios removibles montados con un simple clic de ratón. No sé si algo así, como lo pinto, existe ya; he buscado en la gran red y no he hallado algo directamente relacionado con lo planteo (claro, suponiendo que busqué bien...! ). Aclaro, que aunque llevo un buen tiempo usando Debian, y alguna que otra derivada, apenas estoy aprendiendo a programar en bash... que por cierto, un comentario de novato: Es genial crear algo... y que funcione...! :-) La pregunta/duda: Si es posible (creo que todo en GNU/Linux es posible...! ), ¿qué se necesitaría para crear, armar, escribir... un dockapp/applet como el que describí antes, basado en udevil y devmon, con ícono y todo para la taskbar, de forma que con un simple clic pueda desmontarse algún medio removible montado?.. muy a lo Xfce-mount-plugin. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcfc4sw3rnqkd7kow1dymee3qoax_46nk2afjqfinej...@mail.gmail.com
Re: [SOLUCIONADO] Problema con el LED NumLock y teclas modificadoras
No es conky, es ese comando. Busca otra instrucción para que conky te pinte el mapa de teclado actual en lugar de esa. Una consulta parece funcionar, prueba con: ${exec setxkbmap -query | grep layout | awk '{print $2}'} Saludos, -- Camaleón Lamento el retraso en responder. Ya había visto esa línea antes en un sitio de archlinux, y genera el mismo comportamiento erróneo. Está visto que la sola presencia de setxkbmap en conky provoca esto... Interesante me parece que aunque ya había configurado los ficheros del teclado y el de conky para funcionar perfecto sin setxkbmap, al hacer esta prueba en conky y cambiando la distribución de teclado ingresando la orden desde la terminal, el sistema dejaba de responder con el atajo de teclado, incluso haciendo clic directamente sobre la aplicación de bandeja fbxkb. Es como si el uso de setxkbmap alterara a quien escucha el keyboard. Bueno, al eliminar setxkbmap de conky, cerrar y reingresar a sesión, todo volvía a la normalidad. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcfha18+x9ebvlib_t8efkfauctbnbc4mmy3-owsw+l...@mail.gmail.com
Re: [SOLUCIONADO] Problema con el LED NumLock y teclas modificadoras
La cuestión es si esa línea (¿qué comando es, exactamente?) que invoca al comando setxkbmap la ha añadido automáticamente Conky o lo has hecho tú, manualmente. Si es lo primero, obviamente se trata de un bug que deberías informar a los desarrolladores de la aplicación (o en el BTS de Debian si has instalado el paquete desde los repos) pero si la has añadido tú pues entonces tienes que leer el manual para saber cómo y dónde ponerla, qué parámetros admite, etc. Por otra parte, Conky no hace más que ejecutar el comando que se ha dicho, igual que si lo ejecutas desde una terminal, así que más que un error suyo se trataría de un problema con el comando en sí mismo. Saludos, -- Camaleón Hola Camaleón. Gracias por la sugerencia. La línea es: ${exec setxkbmap -v 7 | grep layout | awk '{print $2}'} donde el comando exec es un parámetro de conky. Hice revisión del manual, sitio web, otras configuraciones postedas en foros y blogs, y probé con parámetros similares, como execi, execpi, texec y aunque muestran el layout actual, no muetran el layout siguiente al invocar el cambio. Para estos casos es exec. Aunque he visto reportes de bug relacionados con setxkbmap y cambios de layout, apenas vi uno o dos relacionados con conky y setxkbmap, en la búsquedas que hice. Además, encontré reiteradamente que el paquete xserver-xorg-input-kbd de la versión Wheezy, y equivalente en Ubuntu, está en metido en el lío. Haré el reporte para conky, y para setxkbmap para BTS de Debian. Muchas gracias por tus aportes. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCE_7QpUFYkbt+Gp7xF=hbrg24glq3xcphyzakwdaz4...@mail.gmail.com
Re: [SOLUCIONADO] Problema con el LED NumLock y teclas modificadoras
Lo lamento, en el segmento anterior accidentalmente y no sé cómo sucedió, pero sucedió, apreté el botón enviar. o.O Aquí va completo el mensaje: Bueno, logré solucionar localmente el problema, dejando el sistema como quería para una funcionalidad extrema. :-) A continuación, haré un resumen de lo que hice por si a alguien le sirve en un futuro. Ambiente gráfico - IceWM_1.3.7 Debian 7.8 Wheezy kernel linux-image-3.16.0-0.bpo.4-686-pae xorg_1:7.7+3~deb7u1 x11-xkb-utils_7.7~1 PCManFM_1.2.3 conky-all_1.9.0 Se usaron 2 distribuciones de teclado, español con tilde muerta (ES) e inglés internacional (US). El problema - Las teclas modificadoras apagaban el LED indicador NumLock. La tecla NumLock funcionaba perfectamente. Cuando se pulsaba, el LED encendía y se podía escribir números con el numpad. Cuando volvía a pulsar la tecla NumLock, el LED apagaba, y el numpad se comportaba como teclado de direccionamiento. Lo que determiné y la solución - Después de varios intentos fallidos, pero que permitieron descartar paquetes inicialmente sospechosos, se llegó a la conclusión de que la extensión de teclado de X (XKB) de xorg, setxkbmap y/o x11-xkb-utils, tienen bugs que: - No permiten usar el comando setxkbmap en cualquier parte del archivo de configuración de conky. La presencia de esta orden en el texto de conky, provocaba que se apagase el LED NumLock al presionar las teclas modificadoras. Ignoro si esto se deberá más bien a un bug en conky. No encontré nada específico en la búsqueda que hice en la Internet. - No permiten usar la opción grp:toogle o grp:_toogle en la configuración del teclado (fichero /etc/default/keyboard). Este es una causa recurrente de consulta en los foros de varias distribuciones GNU/Linux. Aquí el contenido definitivo del archivo de configuración keyboard tesistas@Tesistas:~$ cat /etc/default/keyboard --- # KEYBOARD CONFIGURATION FILE. # Consult the keyboard(5) manual page. XKBMODEL=pc105 XKBLAYOUT=es,us XKBVARIANT=deadtilde,intl XKBOPTIONS=grp:win_menu_switch,lv3:ralt_switch BACKSPACE=guess --- - No permiten usar la opción grp:switch o grp:_switch en el fichero anterior; solamente funciona si se crea un fichero de configuración 10-keyboard.conf en el directorio /etc/X11/xorg.conf.d). Esto lo tocan someramente en la wiki de Debian relativo a teclado, pero dan un enlace a un sitio con la solución. Aquí el contenido definitivo del archivo de configuración 10-keyboard.conf tesistas@Tesistas:~$ cat /etc/X11/xorg.conf.d/10-keyboard.conf -- Section InputClass Identifier system-keyboard MatchIsKeyboard on Option XkbLayout es,us Option XkbModel pc105 Option XkbVariant deadtilde,intl Option XkbOptions grp:win_menu_switch,lv3:ralt_switch EndSection - La opción grp:win_menu_switch en los ficheros de configuración anteriores, habilita que se usen las teclas Super_L para conmutar a la primera distribución de teclado (en éste caso ES), y la Super_R para conmutar a la otra distribución de teclado (en éste caso US). Se instaló el paquete fbxkb para ver el estado de la distribución del teclado desde la bandeja del sistema. Y con esto, el problema resuelto para mí, aunque sin bugs corregidos. Doy este hilo como cerrado y el tema solucionado. Resalto que durante todo el procedimiento anterior, se puso en evidencia problemas para usar la secuencia de teclas por default de icewm para mover las ventanas sobre el escritorio, así como que el LED de Scroll Lock no enciende. Pero esto será motivo de otros hilos. Agradezco las sugerencias de Ala de Dragón, Camaleón y Carlos Zuñiga, puesto que de sus comentarios salieron las ideas para dar con una solución. Aún con todos éstos problemillas, no me arrepiento de haber instalado icewm, su poquísimo consumo, su configurabilidad extrema, y la robustez y eficiencia de Debian Wheezy, permiten que una hardware con 512 MB vaya más que aceptable. Vaya gran saludo a todos los Debianitas. fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbchtpsgj5thgmbgu4mtbktzcb_fjjam3wr6edrdbkoa...@mail.gmail.com
Re:[SOLUCIONADO] Problema con el LED NumLock y teclas modificadoras
2015-06-11 2:50 GMT-04:30, Frederit Mogollon frederitmogol...@gmail.com: Buenas a todos los Debianitas/Debianeros... como les guste más el término. Les consulto sobre un pequeño problema que no he podido resolver con el LED de NumLock y las teclas modificadoras. Lo que sigue es un poco largo, y de una vez agradezco quien tenga el tiempo y la paciencia de leerlo. 1) Les comento el contexto: Utilizando un CD NetInstall Oficial de Debian 7.8, ensamblé (ignoro si puedo usar el término adecuadamente en este contexto) el ambiente gráfico del sistema operativo con el gestor de ventanas IceWM_1.3.7, el gestor de archivos PCManFM_1.2.3 y el gestor de inicio Slim, más las aplicaciones que consideré necesarias, siempre usando como norte bastante información desde varios sitios de la red, incluyendo éste (cuando termine la guía que estoy escribiendo, la dejaré por aquí, seguro que a alguien le servirá...). Es de resaltar que el sistema fue actualizado usando los repositorios Wheezy-Backports, por lo que trabaja con el kernel linux-image-3.16-bpo. También instalé el paquete numlockx-1.2-4, la versión en Wheezy, y se ejecuta en segundo plano desde el inicio por haberlo declarado en el archivo .xinitrc, en el home del usuario. 2) El problema: Al presionar la tecla numlock, el LED respectivo se enciende y puedo insertar caracteres numéricos haciendo uso del numpad. Cuando vuelvo a presionar numlock, el LED se apaga y ahora el numpad funciona como teclado de direccionamiento. Esto es lo que normalmente debe hacer. Bien. Pero al presionar las teclas modificadoras (Shift_izq; Ctrl_izq; Super_izq; Alt_izq; AltGr; Super_der; Ctrl_der; Shift_der), excepto la tecla Meta, el LED de numlock se apaga, aunque el numpad sigue en modo numérico. 3) Lo que he hecho hasta ahora: En una búsqueda inicial por la Internet, encontré varias posibilidades. Las que más parecían cercanas a la descripción y posible solución del problema, apuntaban hacia el paquete numlockx. ### Primer intento de solución # En estos sitios web: https://bugs.freedesktop.org/show_bug.cgi?id=16145 http://blog.ssokolow.com/archives/2013/04/18/how-to-invert-your-x11-numlock-led/ aparece como que es un bug de numlockx, y sugieren colocar la siguiente línea en el inicio (será en el gestor de entrada) -- numlockx off; xdotool key Num_Lock Vi alguna guía para hacerlo en lightdm pero no hallé para slim. Así, que primero quise probar que fuese en verdad numlockx el culpable, y lo desintalé, con lo que esperaría que el problema desapareciese. Pero no fue así, persistió. De lo expuesto en estos sitios web: https://wiki.debian.org/es/FrontPage?action=showredirect=P%C3%A1ginaInicial https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482592 entiendo que el problema es de la versión de numlockx en Wheezy, pero con el resultado del intento anterior, deduzco que numlockx no tiene que ver con el problema, aparentemente. ### Segundo intento de solución # En algún sitio, creo que un foro de Ubuntu, leí que se resolvía haciendo downgrade del paquete x11-xkb-utils_7.7~1 (presente en Wheezy). Algo parecido lo sugieren en este sitio: http://crunchbang.org/forums/viewtopic.php?id=12229 Así que, desde el modo recovery, desinstalé la versión de Wheezy, y con el mismo, los paquetes del servidor de ventanas X, como dependencias. Luego, instalé el paquete x11-xkb-utils_7.4+1_i386.deb, previamente descargado desde los repositorios de Squeeze y lo bloqueé para que no se actualizara, reinstalando luego los paquetes del servidor de ventanas X. Al hacer la prueba de presionar las teclas modificadoras, el LED de numlock se apagaba; así que el problema persistía. ### Tercer intento de solución # En éste punto (donde las esperanzas comenzaron a verse afectadas), pensaba que el problema podría deberse a un bug en alguno de los siguientes paquetes: kernel linux-image-3.16-bpo (Wheezy-backports) xorg_1:7.7+3(Wheezy) xserver-xorg_1:7.7+3(Wheezy) xserver-xorg-core_2:1.12.4-6(Wheezy) slim_1.3.4-2(Wheezy) Reinicié, entré con el kernel linux-image-3.2 (Wheezy), y el problema persistía. Deducí que el causante debería estar entre los paquetes restantes. Como a veces los gestores de inicio dan problemas por presencia/ausencia de alguna línea referente a permisos, probé a desinstalar slim, y al iniciar desde la consola tty1: El problema persistía. Busqué en las páginas de reporte de cambios y reporte de bugs para estos paquetes en las versiones de Wheezy y Jessie, y no encontré nada que se refiriera directamente a este problema. Inicie desde un CD Debian Live 7.1 con Xfce4.8, que está provisto de las mismas versiones de los paquetes antes referidos: kernel linux-image-3.2.0-4-686-pae lightdm 1.2.2-4 xorg_1
Re: Problema con el LED NumLock y teclas modificadoras
Bueno, aunque logré solucionar localmente el problema, dejando el sistema como quería por funcionalidad extrema. A continuación, haré un resumen de lo q -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCFUwShSm8fRY+stZmWrBCsHytOvF31rpk-d3_ApY=z...@mail.gmail.com
Re: Problema con el LED NumLock y teclas modificadoras
2015-06-11 23:56 GMT-04:30, Frederit Mogollon frederitmogol...@gmail.com: Funciona el LED correctamente en una consola TTY (sin entorno gráfico)? De ser así puede ser problema del manejador de ventanas (bug o configuración). Prueba ingresar con un nuevo usuario para descartar que sea configuración y con otro manejador para descartar que sea bug del IceWM. Hola Carlos. Gracias por responder. Probé desde las cónsolas TTY2 y 3, y el LED numlock NO se apaga al presionar las teclas modificadoras mencionadas antes. Esto indica la posibilidad de que sea problema de configuración de icewm en mi usuario, o un bug en el mismo. Instalé el entorno Xfce4, creé un nuevo usuario, configuré el archivo slim.conf, en cada caso, y los respectivos ficheros .xinitrc para cada usuario, probando entrar a los ambientes IceWM y Xfce. Los resultados fueron los siguientes: El LED de numlock se apagaba al presionar teclas modificadoras en el usuario ya existente, en ambos ambientes gráficos. Por el contrario, con el nuevo usuario, el LED se mantuvo siempre encendido al presionar las teclas modificadoras, tanto en icewm como en Xfce. De esto se concluye, que la causa de este comportamiento se halla en la configuración del gestor de ventanas icewm en el usuario primigenio. Algo activé o desactivé durante la configuración de icewm, que altera el comportamiento de las teclas modificadoras. Aunque existen utilidades (actualmente sin mantenimiento) para configurar icewm, decidí decantarme por el método tradicional y hacerlo a mano. Fue largo el proceso, pero lo disfruté; aprendí mucho. Gracias por las sugerencias. En consecuencia, procederé a determinar qué archivo es el contenedor de la causa, dejándolo como viene por default, uno a uno (afortunadamente son 7). Cuando lo halle, haré trabajo de chino buscando la línea o líneas que provocan esa conducta errática. Saludos fdm Al momento, hago una actualización en la búsqueda del culpable... :) Luego de descartar que fuera el gestor de ventanas icewm (algún parámetro activado/desactivado en sus archivos de configuración), llegué a la conclusión de que lo que fuera que causara este comportamiento extraño estaba dentro de la carpeta del usuario en /home. Comparando el contenido de archivos de carpeta personal entre los del usuario inicial y el recién creado, y haciendo pruebas, pude determinar que las teclas modificadoras apagaban el led numlock solamente cuando conky estaba activo. Esto lo corroboré, reproduciendo el comportamiento errático en el nuevo usuario con Xfce4 al ejecutar conky en su sesión. Aún más, pude determinar que se debe a una única línea en conky, la referente a mostrar la distribución actual del teclado: ${exec setxkbmap -v 7 | grep layout | awk '{print $2}'} La presencia del comando setxkbmap en esta línea provoca el apagado del LED numlock al pulsar las teclas Ctrl, Shift, Alt y Super. El por qué y cómo lo hace, aún no lo sé..! Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbch4t_w2afbqljuqob3numriziwkhcmvz1ba-jtpuho...@mail.gmail.com
Re: Problema con el LED NumLock y teclas modificadoras
2015-06-12 9:56 GMT-04:30, Frederit Mogollon frederitmogol...@gmail.com: No sé si habrás probado con una configuración más simple, sin variante ni dobles idiomas de entrada. Es decir: sm01@stt008:~$ cat /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL=pc105 XKBLAYOUT=es XKBVARIANT= XKBOPTIONS= BACKSPACE=guess La doble distribución de teclado la configuré debido a que el ordenador involucrado, del cual estoy escribiendo estas palabras, es usado por varias personas pero con un sólo usuario; pertenece a un laboratorio de investigación científica donde se amerita usar ambos lenguajes en distintos momentos para redactar y/o editar distintos documentos. Sin embargo, no recuerdo haber llevado a cabo esa prueba, y me parece interesante hacerlo para saber si de alguna manera es lo que que setxkbmap provoque la conducta anormal. Y sin ningún archivo /etc/X11/xorg.conf.d/10-keyboard.conf (yo no lo tengo). Debido que el usar la opción XKBOPTIONS del archivo /etc/default/keyboard no daba resultado para alternar entre las 2 distribuciones de teclado dispuestas, y siguiendo las indicaciones de los especificado en éstos links: https://wiki.debian.org/Keyboard https://forums.freebsd.org/threads/solved-setxkbmap-xinitrc.48412/#post-270733 consideré prudente crear el archivo de configuración /etc/X11/xorg.conf.d/10-keyboard.conf. Claro, en ese momento aún no usaba conky, y por lo tanto, no me había percatado del probable bug en setxkbmap para con el LED numlock. De todas formas, como escribí arriba, me parece interesante hacer la prueba. No tiene por qué hacer mención específica a Num_Lock, sino simplemente que alguna combinación genere un conflicto con el bloqueo numérico. Prueba a desactivar esos dos archivos de atajos del teclado (si puedes), reinicia la sesión y comprueba si se sigue generando el mismo problema. También lo probaré. Saludos fdm Segunda actualización en la búsqueda del culpable... :) Hice las pruebas secuencialmente, y lo que pude determinar es que: - ni eliminar el archivo 10-keyboard.conf del directorio /etc/X11/xorg.conf.d/; - ni comentar los atajos de teclado en el fichero keys referente a alternación de distribuciones de teclado; - ni modificar el archivo keyboard del directorio /etc/default, dejándolo declarado para un solo idioma (es) sin variantes ni opciones; acaba con el problema. Lo único que lo hace es comentar la línea referente a setxkbmap en conky. He leído varias páginas donde se refieren a un bug en la extensión XKB setxkbmap. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCHNihXM=iVj2=phjwonckdjwhywueta_0hyrikpahi...@mail.gmail.com
Re: Problema con el LED NumLock y teclas modificadoras
No sé si habrás probado con una configuración más simple, sin variante ni dobles idiomas de entrada. Es decir: sm01@stt008:~$ cat /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL=pc105 XKBLAYOUT=es XKBVARIANT= XKBOPTIONS= BACKSPACE=guess La doble distribución de teclado la configuré debido a que el ordenador involucrado, del cual estoy escribiendo estas palabras, es usado por varias personas pero con un sólo usuario; pertenece a un laboratorio de investigación científica donde se amerita usar ambos lenguajes en distintos momentos para redactar y/o editar distintos documentos. Sin embargo, no recuerdo haber llevado a cabo esa prueba, y me parece interesante hacerlo para saber si de alguna manera es lo que que setxkbmap provoque la conducta anormal. Y sin ningún archivo /etc/X11/xorg.conf.d/10-keyboard.conf (yo no lo tengo). Debido que el usar la opción XKBOPTIONS del archivo /etc/default/keyboard no daba resultado para alternar entre las 2 distribuciones de teclado dispuestas, y siguiendo las indicaciones de los especificado en éstos links: https://wiki.debian.org/Keyboard https://forums.freebsd.org/threads/solved-setxkbmap-xinitrc.48412/#post-270733 consideré prudente crear el archivo de configuración /etc/X11/xorg.conf.d/10-keyboard.conf. Claro, en ese momento aún no usaba conky, y por lo tanto, no me había percatado del probable bug en setxkbmap para con el LED numlock. De todas formas, como escribí arriba, me parece interesante hacer la prueba. No tiene por qué hacer mención específica a Num_Lock, sino simplemente que alguna combinación genere un conflicto con el bloqueo numérico. Prueba a desactivar esos dos archivos de atajos del teclado (si puedes), reinicia la sesión y comprueba si se sigue generando el mismo problema. También lo probaré. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcgv7mkssa8qxdqtmnh6wrgu3uocjonhbbn8lazenjh...@mail.gmail.com
Re: Problema con el LED NumLock y teclas modificadoras
Sí, es posible que en lugar de ser el entorno gráfico sea una aplicación concreta la que monopolice las teclas rápidas y te genere el conflicto. Eso lo podrás comprobar también si desde XCFE con Conky en ejecución puedes replicar el problema. Ya lo hice, ayer mismo que otro listero, Carlos Zuñiga, sugirió la idea del nuevo usuario y otro gestor de ventanas. Tanto en IceWM como en Xfce4, y en usuario recién creado, el problema aparece cuando se ejecuta conky con el comando setxkbmap declarado en alguna línea. Aparentemente es un bug en la extensión XKB de xorg; lo he visto en páginas relacionadas a Ubuntu, FreeDesktop.org, y creo que Fedora. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcfewqwnrf0zcnb2sfwfxay2xvgnt6csxxw8dpbxcev...@mail.gmail.com
Re: Problema con el LED NumLock y teclas modificadoras
Se agradece de verdad el nivel de detalle del problema. Por aquí se ven pocos correos así :-) Hola Camaleón. Gracias por responder. Bueno, poco a poco uno aprende que entre más detalles expongas al realizar una consulta, es más probable que recibas respuestas que ayuden, en menor tiempo. Lo que me hace pensar que el causante del encendido del LED del bloque numérico es el entorno gráfico o en tu caso, el gestor de ventanas. Por el comportamiento que indicas, me hace pensar que las combinaciones de teclas están interactuando o activando el NumLock, por lo que lo primero que haría sería probar a configurar un mapa de teclado junto con una variante distinto del que tengas (en Wheezy la configuración del teclado se hacía desde el archivo /etc/default/keyboard). El sistema está configurado para alternar entre 2 distribuciones de teclado, el español (es) y el inglés (us). A continuación, muestro el contenido de los archivos de configuración del teclado: $ cat /etc/default/keyboard - # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL=pc105 XKBLAYOUT=es,us XKBVARIANT=deadtilde,altgr-intl XKBOPTIONS= BACKSPACE=guess - y $ cat /etc/X11/xorg.conf.d/10-keyboard.conf - Section InputClass Identifier system-keyboard MatchIsKeyboard on Option XkbLayout es,us Option XkbModel pc105 Option XkbVariant deadtilde,altgr-intl Option XkbOptions EndSection - Además, en el archivo de configuración keys, para los shortcuts de icewm, se hallan las secuencias de teclas para alternar entre las distribuciones de teclado es y us. -- key Shift+Caps_Lock setxkbmap es key Shift+Tab setxkbmap us También es posible que alguna aplicación o configuración general del gestor de ventanas esté canibalizando el funcionamiento de las teclas modificadoras, por lo que sería otra cosa a mirar. En el siguiente link, le(s) muestro la secuencia de teclas asociadas con funciones activas (líneas no comentadas) en el archivo de configuración preferences, para el control de icewm: http://pastebin.com/0WeZjFiS En este otro link, le(s) muestro la secuencia de teclas asociadas con la ejecución de aplicaciones en el archivo de configuración keys, para lanzar programas rápidamente: http://pastebin.com/jmi9kaZz Como podrán corroborar en los enlaces anteriores, no hay ninguna secuencia de teclas que llame a numlock. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcfs_e9eyawm3l-7kxlufa6egj23jb0b_j875hurt+n...@mail.gmail.com
Re: Problema con el LED NumLock y teclas modificadoras
Funciona el LED correctamente en una consola TTY (sin entorno gráfico)? De ser así puede ser problema del manejador de ventanas (bug o configuración). Prueba ingresar con un nuevo usuario para descartar que sea configuración y con otro manejador para descartar que sea bug del IceWM. Hola Carlos. Gracias por responder. Probé desde las cónsolas TTY2 y 3, y el LED numlock NO se apaga al presionar las teclas modificadoras mencionadas antes. Esto indica la posibilidad de que sea problema de configuración de icewm en mi usuario, o un bug en el mismo. Instalé el entorno Xfce4, creé un nuevo usuario, configuré el archivo slim.conf, en cada caso, y los respectivos ficheros .xinitrc para cada usuario, probando entrar a los ambientes IceWM y Xfce. Los resultados fueron los siguientes: El LED de numlock se apagaba al presionar teclas modificadoras en el usuario ya existente, en ambos ambientes gráficos. Por el contrario, con el nuevo usuario, el LED se mantuvo siempre encendido al presionar las teclas modificadoras, tanto en icewm como en Xfce. De esto se concluye, que la causa de este comportamiento se halla en la configuración del gestor de ventanas icewm en el usuario primigenio. Algo activé o desactivé durante la configuración de icewm, que altera el comportamiento de las teclas modificadoras. Aunque existen utilidades (actualmente sin mantenimiento) para configurar icewm, decidí decantarme por el método tradicional y hacerlo a mano. Fue largo el proceso, pero lo disfruté; aprendí mucho. Gracias por las sugerencias. En consecuencia, procederé a determinar qué archivo es el contenedor de la causa, dejándolo como viene por default, uno a uno (afortunadamente son 7). Cuando lo halle, haré trabajo de chino buscando la línea o líneas que provocan esa conducta errática. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbchyud-stt+qbin_gpyx2-+g+dcupmfnzb3dbdwpbgd...@mail.gmail.com
Re: Configuracion teclado BLOQ NUM
Debe existir alguna manera de que al arrancar la maquina esta opcion quede activada por default. He leido algo al respecto y es instalar otra aplicacion sudo apt-get install numlockx Y editar el archivo de configuracion, pero... ¿en Debian se puede activar sin tener que instalar otra aplicacion? ¿Alguno de ustedes podra orientarme? Hola Debianeromx. Yo también uso icewm. Si no quieres instalar otro paquete, te podría servir revisar el siguiente enlace: http://usuariodebian.blogspot.com/2007/08/activar-numlock-o-bloqnum-al-arranque.html Inicialmente usaba xdm, pero me decanté por slim por ser más configurable sin dejar de ser ligero. Incluso tiene una opción en su archivo de configuración para activar numlock al entrar en sesión. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcejq-h3giwid7rgozq0bdxbawyi6prgas0tbykg7wt...@mail.gmail.com
Problema con el LED NumLock y teclas modificadoras
Buenas a todos los Debianitas/Debianeros... como les guste más el término. Les consulto sobre un pequeño problema que no he podido resolver con el LED de NumLock y las teclas modificadoras. Lo que sigue es un poco largo, y de una vez agradezco quien tenga el tiempo y la paciencia de leerlo. 1) Les comento el contexto: Utilizando un CD NetInstall Oficial de Debian 7.8, ensamblé (ignoro si puedo usar el término adecuadamente en este contexto) el ambiente gráfico del sistema operativo con el gestor de ventanas IceWM_1.3.7, el gestor de archivos PCManFM_1.2.3 y el gestor de inicio Slim, más las aplicaciones que consideré necesarias, siempre usando como norte bastante información desde varios sitios de la red, incluyendo éste (cuando termine la guía que estoy escribiendo, la dejaré por aquí, seguro que a alguien le servirá...). Es de resaltar que el sistema fue actualizado usando los repositorios Wheezy-Backports, por lo que trabaja con el kernel linux-image-3.16-bpo. También instalé el paquete numlockx-1.2-4, la versión en Wheezy, y se ejecuta en segundo plano desde el inicio por haberlo declarado en el archivo .xinitrc, en el home del usuario. 2) El problema: Al presionar la tecla numlock, el LED respectivo se enciende y puedo insertar caracteres numéricos haciendo uso del numpad. Cuando vuelvo a presionar numlock, el LED se apaga y ahora el numpad funciona como teclado de direccionamiento. Esto es lo que normalmente debe hacer. Bien. Pero al presionar las teclas modificadoras (Shift_izq; Ctrl_izq; Super_izq; Alt_izq; AltGr; Super_der; Ctrl_der; Shift_der), excepto la tecla Meta, el LED de numlock se apaga, aunque el numpad sigue en modo numérico. 3) Lo que he hecho hasta ahora: En una búsqueda inicial por la Internet, encontré varias posibilidades. Las que más parecían cercanas a la descripción y posible solución del problema, apuntaban hacia el paquete numlockx. ### Primer intento de solución # En estos sitios web: https://bugs.freedesktop.org/show_bug.cgi?id=16145 http://blog.ssokolow.com/archives/2013/04/18/how-to-invert-your-x11-numlock-led/ aparece como que es un bug de numlockx, y sugieren colocar la siguiente línea en el inicio (será en el gestor de entrada) -- numlockx off; xdotool key Num_Lock Vi alguna guía para hacerlo en lightdm pero no hallé para slim. Así, que primero quise probar que fuese en verdad numlockx el culpable, y lo desintalé, con lo que esperaría que el problema desapareciese. Pero no fue así, persistió. De lo expuesto en estos sitios web: https://wiki.debian.org/es/FrontPage?action=showredirect=P%C3%A1ginaInicial https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482592 entiendo que el problema es de la versión de numlockx en Wheezy, pero con el resultado del intento anterior, deduzco que numlockx no tiene que ver con el problema, aparentemente. ### Segundo intento de solución # En algún sitio, creo que un foro de Ubuntu, leí que se resolvía haciendo downgrade del paquete x11-xkb-utils_7.7~1 (presente en Wheezy). Algo parecido lo sugieren en este sitio: http://crunchbang.org/forums/viewtopic.php?id=12229 Así que, desde el modo recovery, desinstalé la versión de Wheezy, y con el mismo, los paquetes del servidor de ventanas X, como dependencias. Luego, instalé el paquete x11-xkb-utils_7.4+1_i386.deb, previamente descargado desde los repositorios de Squeeze y lo bloqueé para que no se actualizara, reinstalando luego los paquetes del servidor de ventanas X. Al hacer la prueba de presionar las teclas modificadoras, el LED de numlock se apagaba; así que el problema persistía. ### Tercer intento de solución # En éste punto (donde las esperanzas comenzaron a verse afectadas), pensaba que el problema podría deberse a un bug en alguno de los siguientes paquetes: kernel linux-image-3.16-bpo (Wheezy-backports) xorg_1:7.7+3(Wheezy) xserver-xorg_1:7.7+3(Wheezy) xserver-xorg-core_2:1.12.4-6(Wheezy) slim_1.3.4-2(Wheezy) Reinicié, entré con el kernel linux-image-3.2 (Wheezy), y el problema persistía. Deducí que el causante debería estar entre los paquetes restantes. Como a veces los gestores de inicio dan problemas por presencia/ausencia de alguna línea referente a permisos, probé a desinstalar slim, y al iniciar desde la consola tty1: El problema persistía. Busqué en las páginas de reporte de cambios y reporte de bugs para estos paquetes en las versiones de Wheezy y Jessie, y no encontré nada que se refiriera directamente a este problema. Inicie desde un CD Debian Live 7.1 con Xfce4.8, que está provisto de las mismas versiones de los paquetes antes referidos: kernel linux-image-3.2.0-4-686-pae lightdm 1.2.2-4 xorg_1:7.7+3 xserver-xorg_1:7.7+3 xserver-xorg-core_2:1.12.4-6 y para sorpresa, aquí no se presenta el fulano problema con el LED numlock y las teclas modificadoras,
Re: Problema con el LED NumLock y teclas modificadoras
Pues fijate que la live usa un kernel generico. A mi los kernel de backports me han traido mas de un dolor de cabeza, prueva a instalar la version del kernel que trae la live, desinstalando y purgando los paketes instalados referidos a numlokcs. xdotool necesitara que instales el paquete xdotool... sino no le veo sentido a esas lineas Gracias por responder Ala de Dragón. La línea del xdotool se que implica la instalación del paquete del mismo nombre; me cercioré de que no estaba instalado al leer esa posible solución. Pero como el motivo de consulta en ese sitio no era exactamente lo que ocurre aquí, decidí probar primero desinstalando numlockx_1.2-4. Lo que sugieres, lo tomaré en cuenta y luego comento. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbchjkfr8663njopgx84mbqwij01eszq4ousmuo+91i4...@mail.gmail.com
Re: ACPI y smsc47m1
Tal vez no utilicé los términos correctos... a ver si me explico mejor... Al reiniciar, y antes de que se inicie el ambiente gráfico, se cargan los módulos de kernel y drivers necesarios para hacer funcionar los dispositivos conectados. Es aquí, donde es posible leer rápidamente en una línea, algo referente a: Error inserting smsc47m1... Device or resource busy A esto es lo que me refiero. Ah, es importante enviar siempre los registros completos, no a medias ;-) Sí, tienes toda la razón... Intentaré corregir desde ya eso,... ! --- lm-sensors si funciona, puesto que tengo conky-all instalado y corriendo monitoreanso cada 5 s, y al llamar en terminal la salida de sensors, obtengo: (...) Entonces, si lm-sensors y los valores que te da son correctos, ¿para qué necesitas ese módulo (smsc47m1)? No lo cargues. Creo que también tendrás razón en eso... El módulo smsc47m1 está relacionado con el control de ventiladores en el sistema... y dado que: 1) Tengo 5 ventiladores conectados a la placa base: - 2 fan (cpu y ram) con tres cables, es decir, son controlados; - 2 fan (case frontal y case posterior) con 2 cables, ligados a conectores de 3 pines, es decir no están siendo controlados; - 1 fan (gpu) con 2 cables, adaptado por mí después de haber leído el manual de la placa; 2) La salida del comando sensors me indica que hay 2 ventiladores conectados pero uno de ellos tiene valor de cero, entonces, suspuse que cargar ese módulo permitiría al sistema controlar el on/off de otro fan (del case), y por lo tanto mantener el adecuado flujo de aire en el sistema... en una máquina viejita, es bueno. --- No, no... la información es clara: usar el sistema antiguo es peligroso porque se pueden alterar parámetros del kernel que pueden afectar a los componentes del ordenador, te mucho cuidado con eso :-/ (...) OJO. No, no lo ignores, si activas el sistema de funcionamiento antiguo (acpi_enforce_resources=lax) puedes tener problemas. Reconsidéralo. Será mejor dejar ese módulo sin cargar, y que los ventiladores para el case estén todo el tiempo encendidos! El interior del case todo el tiempo fresco...!Así no modifico el grub, no altero los parámetros del kernel y no corro el riesgo de fastidiar el hardware terminaría siendo algo así como el remedio peor que la enfermedad... :) --- 1) Atendiendo a una sugerencia anterior sobre usar el kernel 3.16 desde los backports para probar si se resolvía este fulano conflicto de ACPI, (...) No creo que sea buena idea instalar una versión determinada del kernel sólo por eso, creo que la seguridad es más importante que lm-sensors ;-) La actualización del kernel era solo para probar si se corregía eso, igual podría desinstalarlo y quedarme con el kernel 3.2 El resto de la actualización era para instalar el paquete p11-kit-modules:i386 que proveía la librería p11-kit-trust.so, necesaria para el adecuado funcionamiento de wine. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCHJNoSjbj=V�fBY6OmYEE6TgM4sp=lhobwkgo3ad...@mail.gmail.com
Re: ACPI y smsc47m1
. Pues si todo funciona correctamente, el módulo se carga y los sensores funcionan, quizá no tengas de qué preocuparte. Lo digo porque encontré un bug de Debian con un asunto similar y esa fue la respuesta de uno de los mantenedores del kernel: ACPI Conflict (Hardware in risk) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602128 P.S. No te olvides de eliminar la línea que añadiste en la configuración de GRUB (acpi_enforce_resources=lax). Saludos, -- Camaleón Hola de nuevo. Leí el enlace sobre el bug ACPI Conflict. Eliminé la línea acpi_enforce_resources=lax del archivo /etc/default/grub, dejándolo como al principio. Actualice el grub, y al reiniciar, en la información sobre la carga del sistema, volvió a aparecer el mensaje de Error, por no poder cargar el módulo smsc47m1, como estábamos al principio. Será que deberé dejar el grub modificado (con la línea acpi_enforce_resources=lax)? También probaré instalando el kernel 3.16 como lo sugirieron antes! Cualquier idea es bienvenida. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcfb0kymnnex51ms0r1fts1qzf_vlbbg+_lmwn6zyow...@mail.gmail.com
Re: ACPI y smsc47m1
Eliminé la línea acpi_enforce_resources=lax del archivo /etc/default/grub, dejándolo como al principio. Actualice el grub, y al reiniciar, en la información sobre la carga del sistema, volvió a aparecer el mensaje de Error, por no poder cargar el módulo smsc47m1, como estábamos al principio. ¿A qué mensaje de error te refieres exactamente? ¿Funciona lm-sensors? Tal vez no utilicé los términos correctos... a ver si me explico mejor... Al reiniciar, y antes de que se inicie el ambiente gráfico, se cargan los módulos de kernel y drivers necesarios para hacer funcionar los dispositivos conectados. Es aquí, donde es posible leer rápidamente en una línea, algo referente a: Error inserting smsc47m1... Device or resource busy A esto es lo que me refiero. lm-sensors si funciona, puesto que tengo conky-all instalado y corriendo monitoreanso cada 5 s, y al llamar en terminal la salida de sensors, obtengo: tesistas@Tesistas:~$ sensors adm1025-i2c-0-2d Adapter: SMBus I801 adapter at efa0 in0: +2.49 V (min = +0.00 V, max = +3.32 V) Vcore:+1.71 V (min = +0.00 V, max = +2.99 V) +3.3V:+3.25 V (min = +2.97 V, max = +3.63 V) +5V: +5.16 V (min = +4.50 V, max = +5.50 V) VCC: +3.32 V (min = +2.97 V, max = +3.63 V) CPU Temp: +42.0°C (low = +0.0°C, high = +127.0°C) M/B Temp: +37.0°C (low = +0.0°C, high = +127.0°C) cpu0_vid:+1.750 V adm1031-i2c-0-2c Adapter: SMBus I801 adapter at efa0 fan1: 0 RPM (min = 330 RPM, div = 8) fan2:4218 RPM (min = 330 RPM, div = 8) M/B Temp: +37.5°C (low = +0.0°C, high = +80.0°C) (crit = +81.0°C) temp2:+35.1°C (low = +0.0°C, high = +80.0°C) (crit = +81.0°C) temp3:+41.2°C (low = +0.0°C, high = +80.0°C) (crit = +81.0°C) --- Para verificar: root@Tesistas:/home/tesistas# /etc/init.d/kmod stop Volví a hacer root@Tesistas:/home/tesistas# sensors-detect y root@Tesistas:/home/tesistas# /etc/init.d/kmod start [info] Loading kernel module loop. [info] Loading kernel module sg. [info] Loading kernel module adm1025. [info] Loading kernel module adm1031. [info] Loading kernel module smsc47m1. ERROR: could not insert 'smsc47m1': Device or resource busy [info] Loading kernel module adm1025. [info] Loading kernel module adm1031. [info] Loading kernel module smsc47m1. ERROR: could not insert 'smsc47m1': Device or resource busy --- Será que deberé dejar el grub modificado (con la línea acpi_enforce_resources=lax)? Según la documentación de lm-sensors (ver más abajo) podría ser peligroso. En el enlace anterior que sugeriste, estaba indicada esa documentación y la leí, pero en ella se refiere a cuando se detiene sensors... y este no es el caso. - Piensas si no te convendría mejor usar otro monitor de sensores o intentar cargar otro módulo en lm-sensors genérico. Sobre usar otro módulo genérico, la verdad no sé nada de ello. Tendría que investigar más. 1) Atendiendo a una sugerencia anterior sobre usar el kernel 3.16 desde los backports para probar si se resolvía este fulano conflicto de ACPI, y 2) aprovechando que estoy instalando playonlinux-wine, y anteriormente este último no se podía usar por falta de instalar dlls, y esto por problemas de dependencias en Debian con el paquete p11-kit-modules:i386, decidí actualizar todo a wheezy-backports. Hice esto: $ sudo aptitude update $ sudo aptitude upgrade $ sudo aptitude -t wheezy-backports safe-upgrade $ sudo aptitude upgrade $ sudo aptitude safe-upgrade $ sudo aptitude full-upgrade Reinicié el sistema. Luego: $ sudo aptitude purge $(deborphan --gues-all) $ sudo aptitude autoremove $ sudo aptitude autoclean Arrancando ya con el kernel 3.16.0-0.bpo.4-686-pae, pude leer la misma línea al cargar módulos: Error inserting smsc47m1... Device or resource busy Al hacer: $ dmesg | tail [ 17.879580] FS-Cache: Loaded [ 17.951326] FS-Cache: Netfs 'nfs' registered for caching [ 18.091008] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 24.489728] lp0: using parport0 (interrupt-driven). [ 53.137423] fuse init (API version 7.23) [ 1508.874684] perf interrupt took too long (2514 2500), lowering kernel.perf_event_max_sample_rate to 5 [ 3488.201220] perf interrupt took too long (5027 5000), lowering kernel.perf_event_max_sample_rate to 25000 [ 3814.805633] smsc47m1: Found SMSC LPC47M10x/LPC47M112/LPC47M13x [ 3814.805661] ACPI Warning: SystemIO range 0x0804-0x0804 conflicts with
Re: ACPI y smsc47m1
2015-05-06 9:36 GMT-04:30, Camaleón noela...@gmail.com: El Tue, 05 May 2015 16:18:42 -0430, Frederit Mogollon escribió: (...) Al hacer un dmesg | tail decía algo de un aparente conflicto con ACPI y smsc47m1, pero no lo guardé; torpeza mía... Al hacer un dmesg | grep smsc47m1 obtuve lo siguiente: tesistas@Tesistas:~$ dmesg | grep smsc47m1 [ 12.893666] smsc47m1: Found SMSC LPC47M10x/LPC47M112/LPC47M13x [ 12.893694] ACPI: resource smsc47m1 [io 0x0804] conflicts with ACPI region RNTR [io 0x800-0x80a] (...) Siguiendo lo sugerido en los sitios antes mencionados, edité el fichero /etc/default/grub modificando la línea: GRUB_CMDLINE_LINUX_DEFAULT=quiet por GRUB_CMDLINE_LINUX_DEFAULT=acpi_enforce_resources=lax quiet (...) Tras editar ese archivo te faltó ejecutar un update-grub de lo contrario no te guardará los cambios. Saludos, -- Camaleón Hola Camaleón. Gracias por responder. Si, pequeño pelón el mío, faltarme por actualizar el grub, aún cuando lo leí en los sitios revisados... jejej :( Bueno, lo hice y al reiniciar, puedo leer que el módulo smsc47m1 ha sido cargado, en la información que aparece en el momento de cargar el sistema. Bien Sin embargo, al volver hacer dmesg, me devuelve el mismo mensaje que antes: tesistas@Tesistas:~$ dmesg | grep smsc47m1 [ 13.031035] smsc47m1: Found SMSC LPC47M10x/LPC47M112/LPC47M13x [ 13.031062] ACPI: resource smsc47m1 [io 0x0804] conflicts with ACPI region RNTR [io 0x800-0x80a] Eso del conflicto, es lo que me llama la atención... -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcejzwgb5uadpjh5domrhytxgcuq-7k77q_ofdsy7vl...@mail.gmail.com
Re: ACPI y smsc47m1
Hola, gracias por responder. a pesar que entiendo poco y nada... y siendo que vos mismo encontraste la informacion de que este problema se arrastra de una version ya antigua del kernel linux... yo acabo de solucionar problemas de consumo desmedido de cpu y alguna cosita mas en wheezy actualizando al kernel 3.16 que se encuentra en los wheezy-backports... En el poco tiempo, unos 5 años, tratando con Debian GNU/Linux y 2 años antes con Ubuntu, he aprendido a buscar primero y preguntar después, además de ser una de las normas de la lista, lo que ha permitido adquirir paulatinamente conocimientos que no son de mi principal campo de acción. Por lo que dices, suena interesante bajar el kernel 3.16 para hacer la prueba. Antes leeré e intentaré comprender las notas de liberación de ese kernel, para ver si hay algo respecto a acpi y/o smsc47m1. Algo me da que pensar que sos de aquellos que no quieren saber nada con los backports, pero dada la situacion podes probar y obviamente, sin desinstalar el kernel 3.2.. Acepto que me guste la estabilidad, robustez y eficiencia, además que Jessie me dió dolores de cabeza en esta máquina tratando de instalarlo, algo relacionado con systemd. Ya no recuerdo. Lo que si creo recordar, sin estar totalmente seguro, es que había un aviso similar en el inicio sobre el módulo smsc47m1. Pero, también tengo wheezy-backports enlistado en el fichero sources.list. :) -doy por sentado que ya sabes como hacerlo...- Lo hice hace tiempo, cuando estaba entrando en el mundo de GNU y Linux, con la distro de la empresa surafricana. Con un repaso al libro del administrador, la wiki de Debian, el foro de esDebian y por supuesto, de esta prodigiosa lista, que siempre anda sacando de apuros a más de uno, lo lograré. Y luego les cuento. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbch0rnt6as9enzb9+mxpmfh7isnm4acqvkzfc_qje82...@mail.gmail.com
ACPI y smsc47m1
Buenas tardes listeros. En esta ocasión solo paso a comentar sobre algo relacionado con la PC desde la que trabajo. Hardware: M/B Intel D850GB con dos ventiladores que mantienen circulando aire en el case. CPU Intel Pentium IV 1.7 GHz con un ventilador. GPU GeForce MX/MX 400 NV11 con un ventilador. RAM 512 MB con un ventilador. HD 10 GB con 3 particiones: / (4.5 GB), Swap (~500 MB) y /home (4.4 GB). Software principal: S.O. Debian GNU/Linux Wheezy 7.8 con kernel 3.2.0-4-686-pae y con x11-xkb-utils 7.7~1. IceWM 1.3.7 con numlockx 1.2-4. PCManFM 1.2.3. Conky-all 1.9.0-2 La cuestión es que tenía con el sistema trabajando bien (aún terminando de configurar IceWM). Notaba que al encender la PC, una de las líneas de la información en pantalla al inicio, decía algo así como que no se había cargado el módulo smsc47m1 porque no se encontraba dispositivo... Al consultar sobre ese módulo, leí que está relacionado con el control de ventilador para el enfriamiento del hardware. Al ver la información aportada por conky indicaba que la CPU estaba a 41ºC y la M/B a 35ºC. Bueno, pensaba vagamente entonces, uno de las siguientes pasos de optimización de mi sistema será desinstalar o deshabilitar ese módulo para que no aparezca más ese aviso... Cosa que tenía pendiente de hacer. Pero hoy, al reiniciar el ordenador luego de terminar de editar un fichero de configuración de icewm, noté que el applet de volumen en la barra de tareas había desaparecido, que había una ventana pequeña en la esquina superior izquierda de la pantalla que no hallé forma de saber que era (ni mirando el htop), además de que el teclado no funcionaba. Al hacer un dmesg | tail decía algo de un aparente conflicto con ACPI y smsc47m1, pero no lo guardé; torpeza mía... Al hacer un dmesg | grep smsc47m1 obtuve lo siguiente: tesistas@Tesistas:~$ dmesg | grep smsc47m1 [ 12.893666] smsc47m1: Found SMSC LPC47M10x/LPC47M112/LPC47M13x [ 12.893694] ACPI: resource smsc47m1 [io 0x0804] conflicts with ACPI region RNTR [io 0x800-0x80a] Hice la respectiva búsqueda en la gran red y al parecer es una suerte de bug no oficial desde el kernel 2.6.31 en el que hay problemas con los sensores, según lo encontrado en los siguientes enlaces (entre otro par que no anoté): https://bugs.launchpad.net/ubuntu/+source/lm-sensors/+bug/478762 https://bbs.archlinux.org/viewtopic.php?id=83452 https://wiki.archlinux.org/index.php/Lm_sensors_(Español) Siguiendo lo sugerido en los sitios antes mencionados, edité el fichero /etc/default/grub modificando la línea: GRUB_CMDLINE_LINUX_DEFAULT=quiet por GRUB_CMDLINE_LINUX_DEFAULT=acpi_enforce_resources=lax quiet reinicié el equipo, y aunque al entrar ya estaba todo de vuelta a la normalidad en la interfaz gráfica, al hacer de nuevo un dmesg obtuve lo mismo que antes: tesistas@Tesistas:~$ dmesg | grep smsc47m1 [ 15.655807] smsc47m1: Found SMSC LPC47M10x/LPC47M112/LPC47M13x [ 15.655835] ACPI: resource smsc47m1 [io 0x0804] conflicts with ACPI region RNTR [io 0x800-0x80a] Para complementar la información arriba expuesta, les pego aquí las salidas de varias órdenes que le dí a la terminal: tesistas@Tesistas:~$ sudo acpi --everything [sudo] password for tesistas: No support for device type: power_supply No support for device type: power_supply Cooling 0: Processor 0 of 0 tesistas@Tesistas:~$ lsmod | grep -i -e thermal -e wmi mxm_wmi12467 1 nouveau wmi13051 2 mxm_wmi,nouveau thermal_sys17752 2 processor,video - tesistas@Tesistas:~$ lsmod | grep fan NO DEVUELVE NADA tesistas@Tesistas:~$ sensors adm1025-i2c-0-2d Adapter: SMBus I801 adapter at efa0 in0: +2.49 V (min = +0.00 V, max = +3.32 V) Vcore:+1.72 V (min = +0.00 V, max = +2.99 V) +3.3V:+3.25 V (min = +2.97 V, max = +3.63 V) +5V: +5.18 V (min = +4.50 V, max = +5.50 V) VCC: +3.32 V (min = +2.97 V, max = +3.63 V) CPU Temp: +42.0°C (low = +0.0°C, high = +127.0°C) M/B Temp: +37.0°C (low = +0.0°C, high = +127.0°C) cpu0_vid:+1.750 V adm1031-i2c-0-2c Adapter: SMBus I801 adapter at efa0 fan1: 0 RPM (min = 330 RPM, div = 8) fan2:4218 RPM (min = 330 RPM, div = 8) M/B Temp: +37.0°C (low = +0.0°C, high = +80.0°C) (crit = +81.0°C) temp2:+34.8°C (low = +0.0°C, high = +80.0°C) (crit = +81.0°C) temp3:+41.4°C (low = +0.0°C, high = +80.0°C) (crit = +81.0°C) -- tesistas@Tesistas:~$ cat /proc/ioports | grep ACPI 0400-0403 : ACPI PM1a_EVT_BLK 0404-0405 : ACPI PM1b_CNT_BLK
Re: [Solucionado] Script bash se cierra al intentar ejecutarse
Fíjate que en la primera entrada de menú (gxmessage-memfree) pides al terminal que ejecute un script, por lo que este permanece hasta que tú lo cierras. En el segundo sin embargo ejecutas sh que, a su vez, ejecuta el script bash memfree.sh. Cuando este termina se cierra. ¿Por qué no lo haces de manera similar al primero si quieres que el terminal permanezca abierto? Saludos. -- Manolo Díaz -- Hola Manolo. Gracias por responder. Efectivamente, tome tu sugerencia y modifique el script de gxmessage-memfree. Otra modificación no directamente relacionada con el tema, es que coloque los scripts en /usr/local/bin, donde deben ir, según he leído en manuales de Debian. El resultado es el siguiente: 1. Entrada del menú menu Mantenimiento folder { progMemfree: Liberar memoria cache y swap /usr/local/share/icons/hicolor/32x32/apps/memfree.xpm /bin/sh -c /usr/local/bin/gxmessage-memfree } 2. Script gxmessage-memfree #!/bin/bash gxmessage -center -geometry 280x200 -title Memfree -buttons Ok:1,Exit:2 -default Exit -font Sans bold 12 -wrap Cuidado: Usar sólo si la cantidad de memoria SWAP USADA es menor a la RAM USABLE. Si lo es, presione Ok. Si no lo es, presione Exit. case $? in 1) xterm -e sudo /usr/local/bin/memfree.sh;; 2) ;; esac 3. Script memfree.sh #!/bin/bash echo “Limpiando la caché~ “; sync ; echo 2 /proc/sys/vm/drop_caches echo “Limpiando Swap~ “; swapoff -a swapon -a Al hacer clic sobre la entrada del menú para memfree, aparece el mensaje que da la opción al usuario de provocar la liberación de memoria cache y swap si la cantidad de swap usada es menor a la cantidad de RAM libre. Cuando terminé de hacer las modificaciones, se me ocurrió que seria una mejora que el mismo sistema detectara si se cumple esa condición, y entonces ejecutar el script memfree. Pero apenas estoy leyendo haber como se lograría eso. Pero con el asunto original, ya esta resuelto, así que doy esto por solucionado. - (...) Bien, ahora el problema: Al hacer clic en la entrada del menú, aparece el mensaje en el escritorio, pero al dar clic en el botón Ok, aparece una ventana de xterm y se cierra al segundo, sin que se ejecute el script memfree. (...) ¿Seguro que no se ejecuta el script? Lo normal es que se ejecute y se cierre la terminal que has iniciado. Podrías forzar a que se mantenga la terminal con nohup o si usas xterm, con el parámetro -hold pero entonces tendrás que cerrarla manualmente. Saludos, -- Camaleón --- Hola Camaleón. Pienso que no se ejecutaba porque no veía cambio en la cantidad de memoria cache, lo que si ocurría al ejecutarlo desde un emulador de terminal. En un inicio, esa era la idea de hallar un parámetro para mantener abierta la terminal pero que luego se cerrara automáticamente. Sin embargo, seguí la sugerencia de ofrecida antes y pude resolverlo. Muchas gracias por acudir a la ayuda también. Saludos Frederit -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcfyw06hkaud8k8m6xqhvuqjamr0ms0gj7ofh643yfc...@mail.gmail.com
Script bash se cierra al intentar ejecutarse
Buenas tardes listeros... Primero el contexto para esta consulta: Ando en un sistema Debian 7 Wheezy + IceWM, con 512 MB de RAM, 476 MB de swap y un HD de 10 GB, con la home en una partición separada. Aun lo estoy terminando de configurar... :) y se que estoy rompiendo la regla de que la swap debe ser el doble de la RAM. Antes de todo, aviso que no se nada de programación, pero estoy intentando aprender modificando scripts existentes y observando el resultado de su ejecución. Tengo 2 scripts llamados por mi como gxmessage-memfree y memfree, pero inicialmente tomados desde https://debianfacil.wordpress.com/2010/03/19/gxmessage/ y http://geekland.eu/limpiar-nuestro-sistema/, respectivamente. Ambos tienen permisos de ejecución y sus contenidos, modificados por mi persona, son: gxmessage-memfree #!/bin/bash gxmessage -center -geometry 280x200 -title Memfree -buttons Ok:1,Exit:2 -default Exit -font Sans bold 12 -wrap Cuidado: Usar sólo si la cantidad de memoria SWAP USADA es menor a la RAM USABLE. Si lo es, presione Ok. Si no lo es, presione Exit. case $? in 1) x-terminal-emulator -T \memfree\ -e sh -c \su-to-root -c '/usr/bin/memfree.sh'\;; 2) ;; esac memfree.sh #!/bin/bash echo “Limpiando la caché~ “; sync ; echo 2 /proc/sys/vm/drop_caches echo “Limpiando Swap~ “; swapoff -a swapon -a Estoy asignando una entrada en el menú de aplicaciones de IceWM al script gxmessage-memfree, de forma que al dar clic sobre la misma, le de la opción al usuario de ejecutar el script memfree, solamente si la cantidad de swap usada es menor a la cantidad de RAM libre. La entrada en el menú esta escrita así: menu Mantenimiento folder { progMemfree: Liberar memoria cache y swap /usr/share/pixmaps/memfree.xpm /bin/sh -c /home/tesistas/Descargas/scripts/gxmessage-memfree } donde obviamente mi usuario es tesistas. Bien, ahora el problema: Al hacer clic en la entrada del menú, aparece el mensaje en el escritorio, pero al dar clic en el botón Ok, aparece una ventana de xterm y se cierra al segundo, sin que se ejecute el script memfree. Aunque sigo leyendo sobre bash y sh, aun no llego a comprender porque no se ejecuta el segundo script, cuando usando directamente desde menú, el script memfree si lo hace. Imagino que sera algo sencillo de resolver y tontería mía que no logro verlo. Así que acudo a vuestra sapiencia y paciencia para que me ayuden a dar con la solución. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcexonediigyrgchb0ftuy85pnj0gaizmexuk9zqn0o...@mail.gmail.com
Script bash se cierra al intentar ejecutarse
Buenas tardes listeros... Primero el contexto para esta consulta: Ando en un sistema Debian 7 Wheezy + IceWM, con 512 MB de RAM, 476 MB de swap y un HD de 10 GB, con la home en una partición separada. Aun lo estoy terminando de configurar... :) y se que estoy rompiendo la regla de que la swap debe ser el doble de la RAM. Antes de todo, aviso que no se nada de programación, pero estoy intentando aprender modificando scripts existentes y observando el resultado de su ejecución. Tengo 2 scripts llamados por mi como gxmessage-memfree y memfree, pero inicialmente tomados desde https://debianfacil.wordpress.com/2010/03/19/gxmessage/ y http://geekland.eu/limpiar-nuestro-sistema/, respectivamente. Ambos tienen permisos de ejecución y sus contenidos, modificados por mi persona, son: gxmessage-memfree #!/bin/bash gxmessage -center -geometry 280x200 -title Memfree -buttons Ok:1,Exit:2 -default Exit -font Sans bold 12 -wrap Cuidado: Usar sólo si la cantidad de memoria SWAP USADA es menor a la RAM USABLE. Si lo es, presione Ok. Si no lo es, presione Exit. case $? in 1) x-terminal-emulator -T \memfree\ -e sh -c \su-to-root -c '/usr/bin/memfree.sh'\;; 2) ;; esac memfree.sh #!/bin/bash echo “Limpiando la caché~ “; sync ; echo 2 /proc/sys/vm/drop_caches echo “Limpiando Swap~ “; swapoff -a swapon -a Estoy asignando una entrada en el menú de aplicaciones de IceWM al script gxmessage-memfree, de forma que al dar clic sobre la misma, le de la opción al usuario de ejecutar el script memfree, solamente si la cantidad de swap usada es menor a la cantidad de RAM libre. La entrada en el menú esta escrita así: menu Mantenimiento folder { progMemfree: Liberar memoria cache y swap /usr/share/pixmaps/memfree.xpm /bin/sh -c /home/tesistas/Descargas/scripts/gxmessage-memfree } donde obviamente mi usuario es tesistas. Bien, ahora el problema: Al hacer clic en la entrada del menú, aparece el mensaje en el escritorio, pero al dar clic en el botón Ok, aparece una ventana de xterm y se cierra al segundo, sin que se ejecute el script memfree. Aunque sigo leyendo sobre bash y sh, aun no llego a comprender porque no se ejecuta el segundo script, cuando usando directamente desde menú, el script memfree si lo hace. Imagino que sera algo sencillo de resolver y tontería mía que no logro verlo. Así que acudo a vuestra sapiencia y paciencia para que me ayuden a dar con la solución. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbch1rokotfdkkk9f5ov7gsghu0+ntkjpa6odojhn82h...@mail.gmail.com
Re: [Solucionado] PCmanFM no automonta dispositivos en Debian Wheezy + IceWM
2015-04-24 0:02 GMT-04:30, Frederit Mogollon frederitmogol...@gmail.com: 2015-04-23 17:44 GMT-04:30, Jose Maldonado josemal...@gmail.com: On 23/04/15 17:42, Frederit Mogollon wrote: Buenas tardes usuarios debianitas... Reciban un cordial saludo. En esta ocasión solicito vuestra ayuda. Estoy en una máquina con CPU Pentium IV 1,7 GHz caché 256 kB; GPU NV11 GeForce MX/MX 400; RAM 512 MB; HD IDE 10 GB. Una joya pues...! :) Como necesitaba más recursos (ram y cpu) disponibles, pero con un sistema operativo que brindase estabilidad, robustez, rapidez y eficiencia en el hardware antes descrito, eliminé el Debian con Xfce4 que tenía, y emprendí la tarea de hacer una instalación mínima con Debian GNU/Linux 7.8 desde CD netinstall + IceWM como gestor de ventanas + PCManFM como gestor de archivos + Slim como gestor de entrada. Bien voy por el camino, porque el consumo basal de ram es de ~51 MB, frente a los ~100 MB de Xfce. El problema radica en que el gestor de archivos PCManFM no monta memorias usb como usuario normal: al insertarla aparece el aviso Error: Not Authorized (por lo que no aparece en /media), pero sí lo hace como superusuario. Paralelamente, monta y desmonta CD/DVD recién insertado en el usuario normal, pero no permite expulsarlo: al dar clic sobre el ícono del dispositivo en el panel lateral del gestor, aparece el mismo aviso Error: Not Authorized. Como root, sí permite expulsarlo desde la interfaz gráfica. Luego de par de días buscando en Google, apliqué varias posibles soluciones: 1) Desinstalé la versión estable pcmanfm_0.9.10-3 e instalé la versión desde wheezy-backports, debido a que leí en un foro que era un bug presente en el gestor. 2) Modifiqué el archivo /usr/share/polkit-1/actions/org.freedesktop.udisks.policy según lo indicado en los siguientes foros: http://ubuntuforums.org/archive/index.php/t-1435044.html http://forums.bodhilinux.com/index.php?/topic/2214-authentication-is-required-solved/ 3) Modifiqué líneas en los archivos /home/mi_usuario/.xinitrc y /etc/slim.conf según lo indicado en éste y otros foros que no apunté la dirección: https://bbs.archlinux.org/viewtopic.php?id=100635 ~/.xinitrc -- http://pastebin.com/6gqjfHXa /etc/slim.conf -- http://pastebin.com/7B44Lqnb 4) Creé el grupo storage y agregué a mi_usuario a dicho grupo, según lo indicado en estos foros: http://blog.desdelinux.net/como-montar-dispositivos-usb-y-el-cdrom-en-pcman-con-nuestro-usuario/ http://foros.archlinux-es.org/viewtopic.php?f=4t=6078 Tengo instalado las siguientes versiones de paquetes que creo están de alguna forma involucrados: pcmanfm 1.2.3-1~bpo70+1 gvfs-fuse 1.12.3-4 libfm-data 1.2.3-1~bpo70+1 libfm-gtk-data 1.2.3-1~bpo70+1 libfm-modules 1.2.3-1~bpo70+1 libfm-gtk4 1.2.3-1~bpo70+1 gvfs-backends 1.12.3-4 policykit-1-gnome 0.105-2 lxde-icon-theme 0.5.0-1 gnome-icon-theme 3.4.0-2 pmount 0.9.23-2 hal 0.5.14-8 fuse 2.9.0-2+deb7u1 fuse-utils 2.9.0-2+deb7u1 usbutils 1:005-3 usb-modeswitch 1.2.3+repack0-1 El resultado de la orden dmesg | tail luego de insertar el pen drive se encuentra aquí http://pastebin.com/RzFhAdZm Aquí está el contenido del fichero /etc/fstab - http://pastebin.com/smeD6dwb aunque no lo creo necesario, puesto que si se espera automontaje, no debería haber entradas para estos dispositivos hotplug, en este archivo. Creo que hay algún detalle que he pasado por alto, pero no lo veo. Así que recurro a Uds. para que me ayuden a ver luz... fdm Se te ha ocurrido habilitar Consolekit y Dbus-launch para SLIM. Slim es bien conocido por que no inicia estos servicios de forma automatica durante el login y resultan ser necesarios para poder usar el automontaje usando Polkit y UDisks, que son los que vienen por defecto en Debian. Revisa por acá como configurar Consolekit y activar la opción para que Slim pueda activar este servicio correctamente. https://wiki.archlinux.org/index.php/ConsoleKit#ck-launch-session -- Dios en su Cielo, todo bien en la Tierra - Compañero Jose Maldonado, gracias por la ayuda proporcionada. Ya el gestor de archivos pcmanfm automonta dispositivos usb y cd-rom al no más insertarlos. En cierta forma era eso, puesto que sí había habilitado el uso de consolekit, solo que tenía mal configurado el fichero /etc/slim.conf, con la orden inadecuada ck-launch-session en la línea: login_cmd exec dbus-launch /bin/bash -login ~/.xinitrc %session corrigiéndolo con la información dispuesta en el enlace que me sugeriste, que dice exactamente: Display managers like KDM, GDM, LXDM and SLiM start ConsoleKit automatically with each X session. Note: Do not nest ConsoleKit sessions by calling one from another, or you will break ConsoleKit. In particular, since SLiM reads ~/.xinitrc, you should make sure not to run ck-launch-session there. Por lo tanto, el fichero ~/.xinitrc, se mantiene
Re: [Solucionado] PCmanFM no automonta dispositivos en Debian Wheezy + IceWM
2015-04-23 17:42 GMT-04:30, Frederit Mogollon frederitmogol...@gmail.com: Buenas tardes usuarios debianitas... Reciban un cordial saludo. En esta ocasión solicito vuestra ayuda. Estoy en una máquina con CPU Pentium IV 1,7 GHz caché 256 kB; GPU NV11 GeForce MX/MX 400; RAM 512 MB; HD IDE 10 GB. Una joya pues...! :) Como necesitaba más recursos (ram y cpu) disponibles, pero con un sistema operativo que brindase estabilidad, robustez, rapidez y eficiencia en el hardware antes descrito, eliminé el Debian con Xfce4 que tenía, y emprendí la tarea de hacer una instalación mínima con Debian GNU/Linux 7.8 desde CD netinstall + IceWM como gestor de ventanas + PCManFM como gestor de archivos + Slim como gestor de entrada. Bien voy por el camino, porque el consumo basal de ram es de ~51 MB, frente a los ~100 MB de Xfce. El problema radica en que el gestor de archivos PCManFM no monta memorias usb como usuario normal: al insertarla aparece el aviso Error: Not Authorized (por lo que no aparece en /media), pero sí lo hace como superusuario. Paralelamente, monta y desmonta CD/DVD recién insertado en el usuario normal, pero no permite expulsarlo: al dar clic sobre el ícono del dispositivo en el panel lateral del gestor, aparece el mismo aviso Error: Not Authorized. Como root, sí permite expulsarlo desde la interfaz gráfica. Luego de par de días buscando en Google, apliqué varias posibles soluciones: 1) Desinstalé la versión estable pcmanfm_0.9.10-3 e instalé la versión desde wheezy-backports, debido a que leí en un foro que era un bug presente en el gestor. 2) Modifiqué el archivo /usr/share/polkit-1/actions/org.freedesktop.udisks.policy según lo indicado en los siguientes foros: http://ubuntuforums.org/archive/index.php/t-1435044.html http://forums.bodhilinux.com/index.php?/topic/2214-authentication-is-required-solved/ 3) Modifiqué líneas en los archivos /home/mi_usuario/.xinitrc y /etc/slim.conf según lo indicado en éste y otros foros que no apunté la dirección: https://bbs.archlinux.org/viewtopic.php?id=100635 ~/.xinitrc -- http://pastebin.com/6gqjfHXa /etc/slim.conf -- http://pastebin.com/7B44Lqnb 4) Creé el grupo storage y agregué a mi_usuario a dicho grupo, según lo indicado en estos foros: http://blog.desdelinux.net/como-montar-dispositivos-usb-y-el-cdrom-en-pcman-con-nuestro-usuario/ http://foros.archlinux-es.org/viewtopic.php?f=4t=6078 Tengo instalado las siguientes versiones de paquetes que creo están de alguna forma involucrados: pcmanfm 1.2.3-1~bpo70+1 gvfs-fuse 1.12.3-4 libfm-data 1.2.3-1~bpo70+1 libfm-gtk-data 1.2.3-1~bpo70+1 libfm-modules 1.2.3-1~bpo70+1 libfm-gtk4 1.2.3-1~bpo70+1 gvfs-backends 1.12.3-4 policykit-1-gnome 0.105-2 lxde-icon-theme 0.5.0-1 gnome-icon-theme 3.4.0-2 pmount 0.9.23-2 hal 0.5.14-8 fuse 2.9.0-2+deb7u1 fuse-utils 2.9.0-2+deb7u1 usbutils 1:005-3 usb-modeswitch 1.2.3+repack0-1 El resultado de la orden dmesg | tail luego de insertar el pen drive se encuentra aquí http://pastebin.com/RzFhAdZm Aquí está el contenido del fichero /etc/fstab - http://pastebin.com/smeD6dwb aunque no lo creo necesario, puesto que si se espera automontaje, no debería haber entradas para estos dispositivos hotplug, en este archivo. Creo que hay algún detalle que he pasado por alto, pero no lo veo. Así que recurro a Uds. para que me ayuden a ver luz... fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCEcxDp7xMsUZJ+4ZJkXqxMGMimiqKs_2Qi0s=7ze9w...@mail.gmail.com
PCmanFM no automonta dispositivos en Debian Wheezy + IceWM
Buenas tardes usuarios debianitas... Reciban un cordial saludo. En esta ocasión solicito vuestra ayuda. Estoy en una máquina con CPU Pentium IV 1,7 GHz caché 256 kB; GPU NV11 GeForce MX/MX 400; RAM 512 MB; HD IDE 10 GB. Una joya pues...! :) Como necesitaba más recursos (ram y cpu) disponibles, pero con un sistema operativo que brindase estabilidad, robustez, rapidez y eficiencia en el hardware antes descrito, eliminé el Debian con Xfce4 que tenía, y emprendí la tarea de hacer una instalación mínima con Debian GNU/Linux 7.8 desde CD netinstall + IceWM como gestor de ventanas + PCManFM como gestor de archivos + Slim como gestor de entrada. Bien voy por el camino, porque el consumo basal de ram es de ~51 MB, frente a los ~100 MB de Xfce. El problema radica en que el gestor de archivos PCManFM no monta memorias usb como usuario normal: al insertarla aparece el aviso Error: Not Authorized (por lo que no aparece en /media), pero sí lo hace como superusuario. Paralelamente, monta y desmonta CD/DVD recién insertado en el usuario normal, pero no permite expulsarlo: al dar clic sobre el ícono del dispositivo en el panel lateral del gestor, aparece el mismo aviso Error: Not Authorized. Como root, sí permite expulsarlo desde la interfaz gráfica. Luego de par de días buscando en Google, apliqué varias posibles soluciones: 1) Desinstalé la versión estable pcmanfm_0.9.10-3 e instalé la versión desde wheezy-backports, debido a que leí en un foro que era un bug presente en el gestor. 2) Modifiqué el archivo /usr/share/polkit-1/actions/org.freedesktop.udisks.policy según lo indicado en los siguientes foros: http://ubuntuforums.org/archive/index.php/t-1435044.html http://forums.bodhilinux.com/index.php?/topic/2214-authentication-is-required-solved/ 3) Modifiqué líneas en los archivos /home/mi_usuario/.xinitrc y /etc/slim.conf según lo indicado en éste y otros foros que no apunté la dirección: https://bbs.archlinux.org/viewtopic.php?id=100635 ~/.xinitrc -- http://pastebin.com/6gqjfHXa /etc/slim.conf -- http://pastebin.com/7B44Lqnb 4) Creé el grupo storage y agregué a mi_usuario a dicho grupo, según lo indicado en estos foros: http://blog.desdelinux.net/como-montar-dispositivos-usb-y-el-cdrom-en-pcman-con-nuestro-usuario/ http://foros.archlinux-es.org/viewtopic.php?f=4t=6078 Tengo instalado las siguientes versiones de paquetes que creo están de alguna forma involucrados: pcmanfm 1.2.3-1~bpo70+1 gvfs-fuse 1.12.3-4 libfm-data 1.2.3-1~bpo70+1 libfm-gtk-data 1.2.3-1~bpo70+1 libfm-modules 1.2.3-1~bpo70+1 libfm-gtk4 1.2.3-1~bpo70+1 gvfs-backends 1.12.3-4 policykit-1-gnome 0.105-2 lxde-icon-theme 0.5.0-1 gnome-icon-theme 3.4.0-2 pmount 0.9.23-2 hal 0.5.14-8 fuse 2.9.0-2+deb7u1 fuse-utils 2.9.0-2+deb7u1 usbutils 1:005-3 usb-modeswitch 1.2.3+repack0-1 El resultado de la orden dmesg | tail luego de insertar el pen drive se encuentra aquí http://pastebin.com/RzFhAdZm Aquí está el contenido del fichero /etc/fstab - http://pastebin.com/smeD6dwb aunque no lo creo necesario, puesto que si se espera automontaje, no debería haber entradas para estos dispositivos hotplug, en este archivo. Creo que hay algún detalle que he pasado por alto, pero no lo veo. Así que recurro a Uds. para que me ayuden a ver luz... fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcepxgrsvw0ond6zhen9sosjt+tlre9gpggonzf007v...@mail.gmail.com
Re: PCmanFM no automonta dispositivos en Debian Wheezy + IceWM
2015-04-23 17:44 GMT-04:30, Jose Maldonado josemal...@gmail.com: On 23/04/15 17:42, Frederit Mogollon wrote: Buenas tardes usuarios debianitas... Reciban un cordial saludo. En esta ocasión solicito vuestra ayuda. Estoy en una máquina con CPU Pentium IV 1,7 GHz caché 256 kB; GPU NV11 GeForce MX/MX 400; RAM 512 MB; HD IDE 10 GB. Una joya pues...! :) Como necesitaba más recursos (ram y cpu) disponibles, pero con un sistema operativo que brindase estabilidad, robustez, rapidez y eficiencia en el hardware antes descrito, eliminé el Debian con Xfce4 que tenía, y emprendí la tarea de hacer una instalación mínima con Debian GNU/Linux 7.8 desde CD netinstall + IceWM como gestor de ventanas + PCManFM como gestor de archivos + Slim como gestor de entrada. Bien voy por el camino, porque el consumo basal de ram es de ~51 MB, frente a los ~100 MB de Xfce. El problema radica en que el gestor de archivos PCManFM no monta memorias usb como usuario normal: al insertarla aparece el aviso Error: Not Authorized (por lo que no aparece en /media), pero sí lo hace como superusuario. Paralelamente, monta y desmonta CD/DVD recién insertado en el usuario normal, pero no permite expulsarlo: al dar clic sobre el ícono del dispositivo en el panel lateral del gestor, aparece el mismo aviso Error: Not Authorized. Como root, sí permite expulsarlo desde la interfaz gráfica. Luego de par de días buscando en Google, apliqué varias posibles soluciones: 1) Desinstalé la versión estable pcmanfm_0.9.10-3 e instalé la versión desde wheezy-backports, debido a que leí en un foro que era un bug presente en el gestor. 2) Modifiqué el archivo /usr/share/polkit-1/actions/org.freedesktop.udisks.policy según lo indicado en los siguientes foros: http://ubuntuforums.org/archive/index.php/t-1435044.html http://forums.bodhilinux.com/index.php?/topic/2214-authentication-is-required-solved/ 3) Modifiqué líneas en los archivos /home/mi_usuario/.xinitrc y /etc/slim.conf según lo indicado en éste y otros foros que no apunté la dirección: https://bbs.archlinux.org/viewtopic.php?id=100635 ~/.xinitrc -- http://pastebin.com/6gqjfHXa /etc/slim.conf -- http://pastebin.com/7B44Lqnb 4) Creé el grupo storage y agregué a mi_usuario a dicho grupo, según lo indicado en estos foros: http://blog.desdelinux.net/como-montar-dispositivos-usb-y-el-cdrom-en-pcman-con-nuestro-usuario/ http://foros.archlinux-es.org/viewtopic.php?f=4t=6078 Tengo instalado las siguientes versiones de paquetes que creo están de alguna forma involucrados: pcmanfm 1.2.3-1~bpo70+1 gvfs-fuse 1.12.3-4 libfm-data 1.2.3-1~bpo70+1 libfm-gtk-data 1.2.3-1~bpo70+1 libfm-modules 1.2.3-1~bpo70+1 libfm-gtk4 1.2.3-1~bpo70+1 gvfs-backends 1.12.3-4 policykit-1-gnome 0.105-2 lxde-icon-theme 0.5.0-1 gnome-icon-theme 3.4.0-2 pmount 0.9.23-2 hal 0.5.14-8 fuse 2.9.0-2+deb7u1 fuse-utils 2.9.0-2+deb7u1 usbutils 1:005-3 usb-modeswitch 1.2.3+repack0-1 El resultado de la orden dmesg | tail luego de insertar el pen drive se encuentra aquí http://pastebin.com/RzFhAdZm Aquí está el contenido del fichero /etc/fstab - http://pastebin.com/smeD6dwb aunque no lo creo necesario, puesto que si se espera automontaje, no debería haber entradas para estos dispositivos hotplug, en este archivo. Creo que hay algún detalle que he pasado por alto, pero no lo veo. Así que recurro a Uds. para que me ayuden a ver luz... fdm Se te ha ocurrido habilitar Consolekit y Dbus-launch para SLIM. Slim es bien conocido por que no inicia estos servicios de forma automatica durante el login y resultan ser necesarios para poder usar el automontaje usando Polkit y UDisks, que son los que vienen por defecto en Debian. Revisa por acá como configurar Consolekit y activar la opción para que Slim pueda activar este servicio correctamente. https://wiki.archlinux.org/index.php/ConsoleKit#ck-launch-session -- Dios en su Cielo, todo bien en la Tierra - Compañero Jose Maldonado, gracias por la ayuda proporcionada. Ya el gestor de archivos pcmanfm automonta dispositivos usb y cd-rom al no más insertarlos. En cierta forma era eso, puesto que sí había habilitado el uso de consolekit, solo que tenía mal configurado el fichero /etc/slim.conf, con la orden inadecuada ck-launch-session en la línea: login_cmd exec dbus-launch /bin/bash -login ~/.xinitrc %session corrigiéndolo con la información dispuesta en el enlace que me sugeriste, que dice exactamente: Display managers like KDM, GDM, LXDM and SLiM start ConsoleKit automatically with each X session. Note: Do not nest ConsoleKit sessions by calling one from another, or you will break ConsoleKit. In particular, since SLiM reads ~/.xinitrc, you should make sure not to run ck-launch-session there. Por lo tanto, el fichero ~/.xinitrc, se mantiene sin cambios: exec ck-launch-session dbus-launch /usr/bin/icewm-session Ya veo que tenía
Re: Versión minima de Debian
2015-03-19 19:09 GMT-04:30, Carlos Zuniga carlos@gmail.com: On Thu, Mar 19, 2015 at 10:02 AM, Camaleón noela...@gmail.com wrote: El Thu, 19 Mar 2015 11:41:43 -0300, mramirez escribió: Hola! Ve si te sirve: http://www.damnsmalllinux.org/index_es.html No, no me vale. ¿Desde cuando Damn Small Linux es Debian? ;-) No es propiamente Debian, pero esta basado en Knoppix que a su vez esta basado en Debian ;) http://www.debian.org/misc/children-distros#damnsmall -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caabycjmfhkafhaate4tbzyo_4orb2n7yfhmzevhtgy+v5d...@mail.gmail.com Un buen titmpo sin escribir en esta lista, aunque siempre la estoy leyendo. Compañero Eduardo Gil, como dicen los compañeros listeros es más una práctica/aprendizaje de instalación mínima (sistema base + utilidades estándar del sistema + servidor de ventanas X + ambiente gráfico + aplicaciones seleccionadas). Pero depende mucho de la capacidad en términos de hardware presentes en esas máquinas algo viejas, como les dices, y del tiempo disponible para hacerlo con calma y no enredarse en el proceso. Sin embargo, busca distribuciones basadas en Debian, con gestores de ventanas instalados por defecto como ambiente gráfico, tipo AntiX, que corre bien con 256-512 MB de RAM y unos 3 GB de disco duro. Yo estoy/estaba terminando una guía para instalar Debian 7 con IceWM, hasta que me cercioré que AntiX ya viene con todo lo que me proponía a hacer, y hasta mejor configurado, pulido, y completo. Posee un conjunto de diferentes opciones de entornos gráficos ligeros (incluso más ligeros que LXDE) para usar al vuelo. Frederit Mogollon Saludos -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbch9d2argt6onv8kgzrnwdrja_0qsyu7zzlw+cvnm5y...@mail.gmail.com
Re: Problemas en Debian Wheezy con conky
Te pongo al tanto que desde que hice la prueba 3, inicié el conky manualmente, dejé desactivado la ejecución del script de inicio en el autostart (en verdad había olvidado volverlo a activar... ooops...:) ) y no toqué más nada. Pues se resolvió el asunto, ya no se inician conkys duplicados. Sin embargo, como también me interesa saber cuál era la causa real del problema, llevaré a cabo las otras pruebas que sugieres. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Esto es interesante. Haz dos pruebas sencillas y manda el resultado que obtienes con cada una de ellas: Antes de nada, asegúrate de que la opción de guardar la sesión en XFCE está desactivada. Prueba 1 Desactiva la ejecución de Conky (como has hecho en tu prueba 3) para que al iniciar el sistema no se inicie y una vez dentro de la sesión, inicia el servicio manualmente. Cuando termines la jornada, antes de apagar el equipo comprueba cuántas instancias padre tienes de Conky (pstree | grep -i conky). - - - - - - - tesistas@pedroPC-Tesistas:~$ pstree | grep -i conky |-conky---8*[{conky}] Se ejecuta una sola instancia de conky. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Prueba 2 Deja que Conky inicie como siempre desde el autostart para que genere dos instancias padre y cuando inicies la sesión, mata una de ellas (kill -9 PID_instancia1_padre). Sigue trabajando normalmente y cuando termines la jornada, antes de apagar el equipo comprueba cuántas instancias padre tienes de Conky (pstree | grep -i conky). - - - - - - - Al iniciar automáticamente: tesistas@pedroPC-Tesistas:~$ pstree -pan | grep -i conky |-conky,2872 -c /home/tesistas/.conky/conkyrc | |-{conky},2873 | |-{conky},2874 | |-{conky},2875 | |-{conky},2876 | |-{conky},2877 | |-{conky},2878 | |-{conky},2879 | `-{conky},2886 |-conky,2905 -c /home/tesistas/.conky/conkyrc | |-{conky},2906 | |-{conky},2907 | |-{conky},2908 | |-{conky},2909 | |-{conky},2910 | |-{conky},2911 | |-{conky},2912 | `-{conky},2913 | `-grep,4898 -i conky Inmediatamente después de matar una instancia padre: tesistas@pedroPC-Tesistas:~$ kill -9 2905 tesistas@pedroPC-Tesistas:~$ pstree | grep -i conky |-conky---8*[{conky}] tesistas@pedroPC-Tesistas:~$ pstree -pan | grep -i conky |-conky,2872 -c /home/tesistas/.conky/conkyrc | |-{conky},2873 | |-{conky},2874 | |-{conky},2875 | |-{conky},2876 | |-{conky},2877 | |-{conky},2878 | |-{conky},2879 | `-{conky},2886 | `-grep,6150 -i conky Después de un buen rato: tesistas@pedroPC-Tesistas:~$ pstree | grep -i conky |-conky---8*[{conky}] Se mantiene una sola instancia de conky ejecutándose. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Prueba tercera) Y también prueba con un archivo de configuración de Conky vacío, sin ninguna configuración que hayas podido incluir para personalizarlo. - - - - - - - El resultado de dejar un 'conkyrc' completamente vacío es: tesistas@pedroPC-Tesistas:~$ pstree | grep -i conky tesistas@pedroPC-Tesistas:~$ ninguna instancia de conky ejecutándose. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Prueba cuarta) Probando únicamente con la información hallada en el link que pusiste https://wiki.archlinux.org/index.php/conky#Autostart_with_Xfce4: - - - - - - - In .conkyrc file: background yes own_window yes own_window_type override double_buffer yes El resultado es: tesistas@pedroPC-Tesistas:~$ pstree | grep -i conky tesistas@pedroPC-Tesistas:~$ - - - (Prueba quinta) Luego, probando un añadido de mi parte: In .conkyrc file: background yes own_window yes own_window_type override double_buffer yes # Update interval in seconds update_interval 1.0 #position alignment top_right gap_x 0 gap_y 0 # Draw shades? draw_shades no # Draw outlines? draw_outline no # Draw borders around text draw_borders no # Draw borders around graph draw_graph_borders yes own_window_argb_visual yes own_window_argb_value 255 own_window_colour 00 TEXT # Fecha - Nombre del día | Día | Mes | Año ### ${color1}${goto 65}${font LiberationsansNarrow-Bold:Bold:size=14}${time %A} ${goto 160}${time %e} ${goto 220}${time %B} ${alignr}${time %Y} Uso de CPU ### Uso de CPU ${color5}${if_match ${cpu} 75}${color4}${if_match ${cpu} 90}${color6}${else}${color5}${endif}${endif}${cpubar 5,70}${offset 50} ${goto 220}${if_match ${cpu} 75}${color4}${if_match ${cpu} 90}${color6}${else}${color5}${endif}${endif}${cpu}% ${offset 0}${goto 260}$freq_g GHz El resultado es una sola instancia padre con un único proceso hijo ejecutándose: tesistas@pedroPC-Tesistas:~$ pstree | grep -i conky |-conky---{conky} tesistas@pedroPC-Tesistas:~$ pstree -pan | grep -i conky |-conky,2889 -c /home/tesistas/.conky/conkyrc | `-{conky},2890 | | `-grep,2981 -i conky - - -
[SOLUCIONADO parcialmente]Re: Problemas en Debian Wheezy con conky
Un resumen de todo este proceso de consultas, pruebas y errores, para quien esté en la misma situación y le resulte útil: Problema que motivó la consulta inicialmente: Autoinicio de instancias duplicadas de conky. Entorno: Debian Wheezy + Xfce 4.8 instalación mínima. Paquetes relacionados con el asunto: conky-all_1.9.0-2. xfce4-session_4.8.3-3 Archivo de configuración personalizado 'conkyrc' ubicado en $HOME. Script de inicio para ejecutar automáticamente conky con un retardo de 20 s posterior al inicio del sistema. Variables de configuración ensayadas en las pruebas, modificando una a la vez: 1. Marcado/desmarcado de la casilla 'Guardar sesión automáticamente al salir' en 'Configuración' 'Sesión e Inicio' pestaña 'General'. 2. Marcado/desmarcado de la casilla 'Preguntar al salir' en 'Configuración' 'Sesión e Inicio' pestaña 'General'. 3. Marcado/desmarcado de la casilla que habilita la ejecución del script de inicio de conky en el 'autoarranque de aplicaciones' en 'Configuración' 'Sesión e Inicio'. 4. Borrado de sesiones guardadas por 'xfce4-session' con la línea de comando: rm -r ~/.cache/sessions/*. 5. Estructura del contenido del fichero '.xinitrc' ubicado en $HOME ck-launch-session dbus-launch startxfce4 o ck-launch-session dbus-launch xfce4-session. La única forma en la que fue posible configurar conky para que se iniciara normal y automáticamente con el sistema, fue la siguiente: 1.- Usar el fichero '.xinitrc' con la línea ck-launch-session dbus-launch startxfce4. 2.- Desmarcar 'Guardar sesión automáticamente al salir'. 3.- Marcar 'Preguntar al salir'. 4.- Deshabilitar la ejecución del script de inicio de conky en el autostart. 5.- Borrar las sesiones anteriormente guardadas de xfce4. 6.- Matar cualquier proceso de conky que estubiese corriendo con la línea de comando killall conky. 7.- Usar el applet 'botones de acción' en el panel de Xfce4, y en el 'diálogo de cierre de sesion', marcar la casilla 'Guardar sesión para futuros inicios de sesión'. 8.- Reiniciar, y se verifica que no se ejecuta conky. 9.- Seguido, se inicia manualmente conky a través de la ejecución del script de inicio. 10.- Reiniciar y se verifica se constata que se está ejecutando una sola instancia de conky. En los próximos reinicios del sistema, conky se ejecutará automáticamente de forma normal, es decir, sin duplicados. OBSERVACIONES: * Si se cierra la sesión de xfce4, al volver a ingresar ya conky no se ejecutará. * Si se desmarca la casilla 'Guardar sesión para futuros inicios de sesión' en el 'diálogo de cierre de sesion', al salir de la sesión y volver a ingresar conky se estará ejecutando, pero si repite la salida y entrada de sesión, ya no se ejecutará. Todo esto me lleva a estar convencido que el problema lo presenta el paquete xfce4-session_4.8.3-3. Hay muchos sitios en la Internet donde sale a relucir problemas iguales o similares y casi todos apuntaban a xfce4-session. Considero éste tópico solucionado, a menos en parte... espero que haya alguna actualización que lo solvente completamente. Estoy agradecido con los listeros que se molestaron en acudir en mi ayuda, especialmente a Camaleón, sus sugerencias fueron claves para llegar a éste resultado. Ah, estoy maravillado con los manuales y ayudas al usuario que encontré en la mayoría de foros y blogs de la comunidad Archilinux sobre conky y xfce4, muchas veces más completa que en los propios sitios oficiales de las aplicaciones. Saludos Frederit Mogollón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCE3e+6e1uRvHhBKSdT1RMvwA4MLxFDM+Zj4_Ks=hlv...@mail.gmail.com
Re: Problemas en Debian Wheezy con conky
(...) Ejecuta pstree | grep -i conky para comprobar que no se trate de algún proceso hijo que se haya generado de la instancia principal en cuyo caso podría ser comprensible. - - - - - - - - - tesistas@pedroPC-Tesistas:~$ pstree | grep -i conky |-2*[conky---8*[{conky}]] Consultando la página de manual de pstree en el emulador de terminal, usé los parámetros -p para obtener el PID de cada proceso y -a para obtener argumentos de las lineas de comandos tesistas@pedroPC-Tesistas:~$ pstree -pa | grep -i conky |-conky,2873 -c /home/tesistas/.conky/conkyrc | |-{conky},2874 | |-{conky},2875 | |-{conky},2876 | |-{conky},2877 | |-{conky},2878 | |-{conky},2879 | |-{conky},2880 | `-{conky},2888 |-conky,2905 -c /home/tesistas/.conky/conkyrc | |-{conky},2906 | |-{conky},2907 | |-{conky},2908 | |-{conky},2909 | |-{conky},2910 | |-{conky},2911 | |-{conky},2912 | `-{conky},2913 | | |-grep,7337 -i conky - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Otra cosa que puede probar es decirle a Conky que no se inicie nada más iniciar la sesión para ver qué es lo que pasa, si se inicia igualmente la instancia fantasma o no se inicia ninguna. - - - - - - - - - Buena sugerencia. Hice 3 pruebas: 1. Desactivé la ejecución del script de inicio en el autostart, sin borrar sesiones de xfce4 ni cerrar los procesos de conky que estaban corriendo. El resultado fue que se iniciaron los duplicados de conky después de arrancar el sistema. 2. Desactivé la ejecución del script de inicio en el autostart, y borré las sesiones de xfce4 pero sin cerrar los procesos de conky que estaban corriendo. El resultado fue que al reiniciar el sistema, se ejecutaron los duplicados de conky. 3. Desactivé la ejecución del script de inicio en el autostart, borré las sesiones de xfce4 y cerré los procesos de conky que estaban corriendo. El resultado fue que al reiniciar el sistema, no había conky corriendo. Creo que puedo afirmar que se confirma un aparente bug en xfce4-session en el entorno Xfce 4.8. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ¿Y cómo se inicia Conky? ¿A través de un demonio/servicio o se carga desde el autostart de entorno gráfico? - - - - - - - - - En el autostart del entorno gráfico se halla la línea de comando /home/tesistas/.conky_start para que ejecute el script conky_start, y 20 s después de arrancar el sistema, se ejecute la línea de comando conky -c /home/tesistas/.conky/conkyrc es decir, inicie conky con el archivo de configuración 'conkyrc' creado para el usuario 'tesistas'. Sin embargo, dado el problema de duplicados, cree 2 lanzadores en el panel de xfce4, uno para terminar todo proceso de conky con la línea de comando killall conky y el otro lanzador para iniciarlo con la línea /home/tesistas/.conky_start. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - De nada hombre, y mira que nunca he usado esos monitores del sistema porque no les veo la gracia O:-) - - - - - - - - - Entiendo tu punto de vista. Lo uso porque la única computadora que hay, y por tanto, empleada diariamente por varios usuarios de un laboratorio científico universitario, tiene 512 MB de ram y poco espacio en discos duros, y el conky con la configuración actual consume menos que los plugins de xfce4, pudiendo obervar y correlacionar en todo momento algún episodio de lentitud de respuesta en la máquina con los consumos de cpu, ram, red, espacio libre en discos y unidades usb montadas, así como tener a simple vista atajos de teclado para los novatos. Dada la limitación de hardware para correr aplicaciones pesadas en el Windows Xp instalado, aprovecho la oportunidad para contribuir a romper el casi paradigma de único sistema operativo que existe en el mundo, por parte de mis compañeros de trabajo, y de poco a poco están aprendiendo a utilizar un sistema más potente (GNU/Linux) y múltiples aplicaciones open-source, en esencia a trabajar con Debian. Saludos Frederit Mogollón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbchznvb8b8tyrs1imfmy3ejp3rqmzo0u_t-i7rdmqcs...@mail.gmail.com
Re: Problemas en Debian Wheezy con conky
Parece que se trata de un problema conocido o al mneos bastante común en XFCE, mira a ver si los pasos que comentan en este foro (#4) te sirven: multiple conky process with xfce session startup https://bbs.archlinux.org/viewtopic.php?pid=992748#p992748 Saludos, -- Camaleón Gracias Camaleón, seguí los pasos indicados en el enlace anterior, y que a los que presentaron problema similar les resultó: 1. Entrar en sesión, e ir a Sesión e inicio. 2. En la pestaña general desmarcar guardar automáticamente y marcar preguntar al salir. 3. En la pestaña autoarranque de aplicaciones desmarcar todo. 4. Abrir el administrador de tareas y cerrar todos los procesos que involucren a conky (en mi caso solo el inicial y el duplicado). 5. Salir de sesión, pero antes marcar guardar sesión. 6. Entrar en sesión e inmediatamente salir de sesión otra vez, desmarcando antes guardar sesión. 7. Entrar en sesión, ir a Sesión e inicio y en la pestaña autoarranque de aplicaciones marcar todo. 8. Verificar que en la pestaña general esté desmarcado guardar automáticamente. 9. Cerrar sesión, volver a entrar y ya debería todo trabajar bien. Sin embargo, al reiniciar borrándo las sesiones guardadas (como lo sugieren en el mismo enlace), o sin borrarlas, se inicia el duplicado. Incluso usando el applet de botones de acción para reiniciar/apagar y no el botón para salir de sesión del menú de aplicaciones... Ya es más que obvio que el problema es aparentemente un bug en el paquete xfce4-session versión 4.8.3-3, que sigue en alguna parte guardando una sesión donde está cativo el conky. Aunque en cada inicio puedo matar todos los procesos de conky y volver a arrancarlo desde un par de lanzadores desde el panel, es molesto hacerlo cada vez. Creo que una solución sería intentar compilar las aplicaciones del escritorio Xfce 4.10 en Debian Wheezy... claro sería mi primera compilación de software... :) Aún así Camaleón, te agradezco todos los aportes, me has ayudado un mundo. aunque no solucionado, he podido encontrar la causa probable del problema, y eso ya es mucho. Saludos Frederit Mogollón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcep06o67s7tgbtjedvdzhwmvuen5jgqtmuhfw-yn1r...@mail.gmail.com
Re: Problemas en Debian Wheezy con conky
Me disculpo por la demora, este fin de semana estuve alejado de la computadora protagonista... :) Gracias por la ayuda y los aportes Camaleon y Juan José lópez, hallé algo interesante, abajo bien descrito. Camaleón, seguí tu sugerencia: 1. Creé un nuevo usuario llamado pruebas. 2. Como estaba con configuración prederterminada, copié el script de inicio conky_start y su archivo de configuración conkyrc, desde la carpeta del usuario anterior, y lo asigné a autoinicio. 3. Como no se ejecutaba el conky al arrancar el sistema, revise sus permisos, y estaban asisgandos a root, así que añadí el nuevo usuario pruebas al grupo sudoers, y cambié el propietario del script en cuestión y del conkyrc al nuevo usuario pruebas. 4. Reinicié y voila... apareció el conky, perfecto una sola vez. Juan José seguí tus sugerencias con una modificación: 1. Las sesiones de Xfce se guardan en $HOME/.cache/sessions/ 2. Siguiendo pautas halladas en búsquedas previas en la web, ya había probado el borrar las sesiones y guardar para futuros inicios de sesión. 3. Pero esta vez, probé borrando las sesiones de Xfce del nuevo usuario pruebas, creado a sugerencia de Camaleón, y al reiniciar volvió a iniciar el conky duplicado. Es extraño, no comprendo bien que ocurre, puesto que había leído en distintos foros, blogs, etc., que al borrar sesiones y reiniciar (sin sesiones guardadas) se resolvía este tipo de problema con conky pero aquí ocurre al revés: conky se inicia duplicado al borrar las sesiones... y no hay en otro lado archivo .desktop alguno que lance conky. o.O haber, por favor, si pueden explicarme esto... yo sigo pensando que puede estar ocurriendo... Frederit Mogollón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcgm3o3tcvkstlsythlctfcrpfsjlkhrdugmuxhf1gd...@mail.gmail.com
Re: Problemas en Debian Wheezy con conky
Gracias Camaleón, en alguno de los link que colocaste hacían referencia a otro en el que ocurría algo similar, y era porque se estaban usando muchas fuentes distintas en la sección TEXTO del conkyrc. Así que opté por ser tajante y usé una sola fuente para todo, variando en algunos casos el tamaño de la misma, y funcionó, ya no se cierra. :) Ahora otro problemilla con el bendito conky... Al iniciar el sistema, conky se ejecuta por duplicado (uso una sola instancia), es decir, mismo nombre y ruta, pero diferente PID. Siguiendo los mismos links que amablemente Camaleón puso en la respuesta anterior, y corroborando lo que ya había leído en búsquedas previas en la www, borro las sesiones y reinicio guardando sesión (uso Debian Wheezy con Xfce 4.8). Pero sigue iniciando conky duplicado...!!o.O Usé un script anti fork de conky indicado por éste sitio: http://hackingthesystem4fun.blogspot.com/2012/05/script-inicio-de-conky-mejorado-para.html y aún así el sistema arranca con el conky duplicado. No sé mucho de programación, y no hallo solución en la internet, no sé si es que no sé buscar. Que opinan los listeros...? fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCGWctTo1X2LM2YSyUR1cOdY_ZtwpdXeQg7BwDD=ezz...@mail.gmail.com
Problemas en Debian Wheezy con conky
Buenos días lista. Reciban un gran saludo. Hace tiempo que no paso por aquí, pero siempre estoy revisando los resultados de la lista sobre diferentes aspectos que aparecen en una búsqueda relacionada en Google. Espero no violar las normas de la lista al redactar un mensaje para la lista, por el html digo, dado que estoy en la vista clásica de Gmail, y no encuentro (o recuerdo) como desactivarlo. Esta vez quiero (y/o necesito) hacerles una consulta: Estoy medio loco (casi no desperado... :=) dado que quiero saber y resolver los aparentes problemas que presenta la roca de Debian Wheezy que uso, dado que tengo Conky-all versión 1.9.0-2 instalado, hermoso, corriendo pero tiempo variable después se cierra. Reviso el archivo .xsession-errors en mi carpeta de usuario (tesistas) y aparece lo siguiente: http://www.pastebin.ca/2850446 He hecho la respectiva búsqueda previa en el buscador antes mencionado varias veces y en varios idiomas (gracias por la herramienta web-trasnlate), incluso en las listas Debian y no obtengo resultados, que por lo menos me diesen idea que está ocurriendo. Les presento también el contenido del Xorg.0.log: http://www.pastebin.ca/2850448 y el contenido de un dmesg que hice en el emulador de terminal: http://www.pastebin.ca/2850452 Por si hace falta, les dejo también el contenido del archivo de configuración de conky: http://www.pastebin.ca/2850455 Para salvar dudas, dentro del conkyrc que les pongo se encuentra un script Apt-Upd.sh para actualizaciones del sistema, que dice algo así: #!/bin/bash #muestra el número de paquetes a actualizar n=$(aptitude search ~U | wc -l) echo $n Disponibles El conky se ejecuta desde las aplicaciones al inicio, con el comando: /home/tesistas/.conky_start que hace referencia al script conky_start oculta en la carpeta de mi usuario: #!/bin/bash sleep 20 /usr/bin/conky -c ~/.conky/conkyrc Por último, pero no menos importante, trabajo sobre una máquina con las siguientes características: procesador Pentium4M 1.7 GHz RAM 512 MB Ethernet Unidad quemadora Unidad lectora 2 discos duros: uno con MS-WinXP (dev/sda1) donde esta instalado el burg y otro con Debian Wheezy kernel 3.2.0-4-686-pae con burg y plymouth, instalación mínima con escritorio Xfce 4.8 (instalado con paquetes individuales, sin metapaquetes). Ojalá toda esta información sirva de algo. De ustedes quedo en espera, y agradecido de antemano. fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABZkBCGV+qa1mMpFm97=huhgej+schjotjko5hirfehavhp...@mail.gmail.com
Re: Error al instalar o desintalar algún paquete [SOLUCIONADO]
Vuelve a instalar los paquetes de testing y deja únicamente ruby-locale con una versión anterior a la que te generó el problema e intenta de nuevo. Si te sigue apareciendo el mismo mensaje, convendría que informaras del fallo. Saludos, -- Camaleón Hola Camaleón. Hice lo que has sugerido. Apunté el sources.list solo a testing, desinstalé los paquetes de stable, e instalé la versión ruby-locale 2.1. Y voilá...!, ya puedo instalar y remover paquetes. Gracias por los aportes de todos los listeros que participaron, en especial vuestra ayuda. Ahora espero no sea necesario abrir otro hilo, pero hay algo extraño, el sistema no monta automáticamente dispositivos usb, ni monta las particiones donde esta Windows XP, como lo hacía antes de todo este problema. Ni siquiera CD introducidos en la lectora. Revisé el archivo fstab y no aparecía indicación alguna del medio usb, así que posterior al respectivo googleo, lo modifiqué añadiendo la línea respectiva, quedando: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass # / was on /dev/sdb1 during installation UUID=79c631c7-1e4c-4836-a32f-40b608c65291 / ext4 errors=remount-ro 0 1 # /home was on /dev/sdb2 during installation UUID=89610581-a629-4da8-8127-c0a8ac56e3a7 /home ext4 defaults0 2 # swap was on /dev/sdc2 during installation UUID=27c00b51-4e56-4cc6-9466-392244cfd7cd noneswapsw 0 0 # /media/cdrom0 was on /dev/sr0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 # /media/usb was on /dev/sdd1 /dev/sdd1 /media/usb vfat rw,user,auto0 0 Aparentemente, todo está bien. Está instalado los paquetes usb_storage y thunar-volman. Pero no monta nada. Pienso que el upgrade, actualizó algún paquete que tiene problemas, tal vez el kernel 3.10-2-686-pae. Sigo investigando al respecto. fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcha-1sku9sbcydccl6-2emyo_aoqhaqaqgsjnqakqm...@mail.gmail.com
Error al instalar o desintalar algún paquete
Buenos días amigos de la lista. Tiempo sin pasar por aquí. En esta ocasión es para solicitar información, o mejor orientación, respecto a un pequeño gran problema. Primero el contexto: Les escribo desde un sistema Debian Jessie con XFCE, y todo de maravilla, en una máquina Intel Pentium 4 con 512 MB de RAM. Tenía como 5 meses sin acceder a Internet, y al tener conexión, actualicé el sistema con aptitude update y posteriormente con aptitude safe-upgrade. Ya no recuerdo si fue después de realizar update o el upgrade, pero lo cierto es que (ahora viene el problema), al intentar instalar o desinstalar algún paquete desde la terminal, me sale el siguiente mensaje: /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- debian_version (LoadError) from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/sbin/apt-listbugs:269:in `require' from /usr/sbin/apt-listbugs:269 E: El subproceso /usr/sbin/apt-listbugs apt || exit 10 devolvió un código de error (10) E: Failure running script /usr/sbin/apt-listbugs apt || exit 10 Un paquete no se pudo instalar. Intentado recuperarse: y ahí se queda! Busque en san Google, y una de las entradas me remitió a un mensaje de la lista de usuarios de Debian en inglés donde a alguien (o algunos) ya les había pasado esto en Wheezy con ruby1.8, así que pienso que es un problema con el sistema base de Debian, pero no tengo mayor conocimiento del tema para asegurar algo o poder solucionarlo, por ello estoy aquí. Cualquier información será bien recibida. fdm
Re: Error al instalar o desintalar algún paquete
Parece una regresión de un error similar al de este bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733140 Prueba a volver a instalar la versión anterior del paquete ruby-locale como sugerían. Saludos, -- Camaleón Amigo, revisé el enlace que me enviaste, pero como no podía instalar ni remover nada, seguí los pasos descritos para solucionar un problema similar en http://forums.debian.net/viewtopic.php?f=10t=110438 en donde deshabilitaban apt-listbugs (comentando todas las líneas del archivo /etc/apt/apt.conf.d/10apt-listbugs). Luego, de hacer apt-get upgrade y verificar que seguía el problema, me decidí a añadir el repositorio de stable al sources.list, logré desinstalar el paquete ruby-locale2.1 de testing (se desintalaron también ruby-gettext y apt-listbugs), e instalar el paquete ruby-locale2.0.5, ruby-gettext y apt-listbugs de stable. Se arreglaron dependencias rotas con apt-get -f install, y por último descomenté las líneas del archivo /etc/apt/apt.conf.d/10apt-listbugs, como estaba al principio. Entonces, ya contento por haber resuelto por fin el problema, al intentar instalar o desinstalar algún paquete en terminal, aparece el mensaje: /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- debian_version (LoadError) from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/sbin/apt-listbugs:269:in `require' from /usr/sbin/apt-listbugs:269 E: El subproceso /usr/sbin/apt-listbugs apt || exit 10 devolvió un código de error (10) E: Failure running script /usr/sbin/apt-listbugs apt || exit 10 Juan Carlos Betancourt amigo utiliza primero el siguiente comando dpkg -l | grep el nombre del paquete para que verifiques si esta instalado y debes quitarlo que eso lo puedes hacer con apt-get remove nombre del paquete a eliminar y asi depues prueba instalar y veras que podras pues a veces quedan dependencias las cuales quedan regas y por eso no se puede instalar o desintalar. Otra forma puede ser con apt-get -f install esto termina de instalar los paquetes que esten regados con sus dependencias prueba las dos y di cual resolviste saludos Como escribí arriba, logré desintslar ruby-locale de testing e instalar la versión de stable, y resolver dependencias con apt-get -f install, pero sigue apareciendo un error similar. Jorge Iglesias No es que no haya querido hacerlo, a finales del año pasado hubo una tormenta eléctrica que mandó al otro mundo a dos servidores principales que daban cobertura de red a varias máquinas de la universidad, entre ellas esta. Por esa razón no podía actualizar nada hasta ahora que se resolvió con un router usado mientras se compra un servidor nuevo. fdm Estoy pensando que paso seguir. Igual cualquier ayuda es bienvenida* -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cabzkbcglxwac65f2qo0hgcsn4jue6wb8_bqbqb3563zcpgo...@mail.gmail.com
Re: error al actualizar debian 7 con jre
Hola Ricardo. Según lo que entendí de las notas de publicación que lí ayer en la noche, la actualización se debe realizar desde un sistema squeeze puro, es decir no deben haber instalados paquetes de otros proveedores (repositorios) diferentes a los de squeeze, por lo que además de comentar los repos de backports (no estoy seguro si los de scribus también, imagino que sí), se deben eliminar los paquetes instalados desde ellos. Luego, se actualiza el sistema squeeze, para que no hayan tareas pendientes y apuntas los repos a wheezy o stable, y haces actualización parcial con la orden apt-get update y luego total con la orden apt-get dist-upgrade Es importante leer las notas de publicación. Incluso los amigos de Debian insisten en usar apt-get y no aptitude para la actualización. Saludos Frederit 2013/5/7 Ricardo Mendoza pgsql...@gmail.com En un primer momento crei que era gnome por los cambio de gnome 3, y segui el consejo de las notas de actualizacion que sugeriste, y en este momento el sistema operativo esta inutilizado se queda cargando un modulo de virtualbox, Habia olvidalo lo traumatico que es actualizar de una version a otra, de hecho ahora que recuerdo nunca he podido actualizar de una version a otra sin sufrir percances y he tenido que volver a instalar todo el sistema operativo, mis repositorios estan bien, apuntan a stable,salvo por unos repositorios para scribus que desabilite por error de llaves al hacer un update.Y es cierto la actualizacion la realice alegremente sin considerar muchas cosas y confiando en apt. Asi que esto lo escribo desde un Lubuntu en otro disco, y me dispongo a copia /home. - #Repositorio Debian deb http://ftp.us.debian.org/debian/ stable main contrib non-free deb-src http://ftp.us.debian.org/debian/ stable main contrib non-free ## Actualizaciones de seguridad deb http://security.debian.org/ stable/updates main contrib non-free deb-src http://security.debian.org/ stable/updates main contrib non-free ##Squeeze-Backports deb http://backports.debian.org/debian-backports squeeze-backports main #Repositorios para Scribus #deb http://debian.scribus.net/debian/ stable main #deb http://debian.tagancha.org/debian/ stable main El día 6 de mayo de 2013 15:06, Camaleón noela...@gmail.com escribió: El Mon, 06 May 2013 14:26:46 -0500, Ricardo Mendoza escribió: Saludos al intentar instalar debian 7 desde debian 6.0.6 obtengo este error: apt-get update apt-get dist-upgrade 1254 actualizados, 960 se instalarán, 116 para eliminar y 0 no actualizados. Se necesita descargar 0 B/2694 MB de archivos. Se utilizarán 2087 MB de espacio de disco adicional después de esta operación. ¿Desea continuar [S/n]? S E: Couldn't configure pre-depend jre for libreoffice-wiki-publisher, probably a dependency cycle. - Debo desintalar gnome?.para tener una actulizacion exitosa. ¿Qué te hace pensar que se trata de GNOME? :-? El paquete con problemas parece ser libreoffice-wiki-publisher o jre en todo caso. De todas formas, veo que la mayoría de los que actualizáis de una versión a otra lo hacéis muy alegremente, sin tener en cuenta los repositorios que tenéis activados ni nada... no sé, es normal que haya problemas y/o conflictos con algunos paquetes. Revisa las notas de publicación, y más concretamente las secciones 4.5.1 y 4.5.4: http://www.debian.org/releases/wheezy/amd64/release-notes/ch-upgrading.es.html#trouble Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/km92fm$ds9$2...@ger.gmane.org -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cad1pindmdh-t7s3isawi+1_rjovky7mnsl_mkdihgmtea0f...@mail.gmail.com
Re: error al actualizar debian 7 con jre
Disculpa Ricardo, en el comentario anterior, acerca de hacer la actualización parcial, es con la orden apt-get upgrade Saludos Frederit 2013/5/7 Frederit Mogollon frederitmogol...@gmail.com Hola Ricardo. Según lo que entendí de las notas de publicación que lí ayer en la noche, la actualización se debe realizar desde un sistema squeeze puro, es decir no deben haber instalados paquetes de otros proveedores (repositorios) diferentes a los de squeeze, por lo que además de comentar los repos de backports (no estoy seguro si los de scribus también, imagino que sí), se deben eliminar los paquetes instalados desde ellos. Luego, se actualiza el sistema squeeze, para que no hayan tareas pendientes y apuntas los repos a wheezy o stable, y haces actualización parcial con la orden apt-get update y luego total con la orden apt-get dist-upgrade Es importante leer las notas de publicación. Incluso los amigos de Debian insisten en usar apt-get y no aptitude para la actualización. Saludos Frederit 2013/5/7 Ricardo Mendoza pgsql...@gmail.com En un primer momento crei que era gnome por los cambio de gnome 3, y segui el consejo de las notas de actualizacion que sugeriste, y en este momento el sistema operativo esta inutilizado se queda cargando un modulo de virtualbox, Habia olvidalo lo traumatico que es actualizar de una version a otra, de hecho ahora que recuerdo nunca he podido actualizar de una version a otra sin sufrir percances y he tenido que volver a instalar todo el sistema operativo, mis repositorios estan bien, apuntan a stable,salvo por unos repositorios para scribus que desabilite por error de llaves al hacer un update.Y es cierto la actualizacion la realice alegremente sin considerar muchas cosas y confiando en apt. Asi que esto lo escribo desde un Lubuntu en otro disco, y me dispongo a copia /home. - #Repositorio Debian deb http://ftp.us.debian.org/debian/ stable main contrib non-free deb-src http://ftp.us.debian.org/debian/ stable main contrib non-free ## Actualizaciones de seguridad deb http://security.debian.org/ stable/updates main contrib non-free deb-src http://security.debian.org/ stable/updates main contrib non-free ##Squeeze-Backports deb http://backports.debian.org/debian-backports squeeze-backports main #Repositorios para Scribus #deb http://debian.scribus.net/debian/ stable main #deb http://debian.tagancha.org/debian/ stable main El día 6 de mayo de 2013 15:06, Camaleón noela...@gmail.com escribió: El Mon, 06 May 2013 14:26:46 -0500, Ricardo Mendoza escribió: Saludos al intentar instalar debian 7 desde debian 6.0.6 obtengo este error: apt-get update apt-get dist-upgrade 1254 actualizados, 960 se instalarán, 116 para eliminar y 0 no actualizados. Se necesita descargar 0 B/2694 MB de archivos. Se utilizarán 2087 MB de espacio de disco adicional después de esta operación. ¿Desea continuar [S/n]? S E: Couldn't configure pre-depend jre for libreoffice-wiki-publisher, probably a dependency cycle. - Debo desintalar gnome?.para tener una actulizacion exitosa. ¿Qué te hace pensar que se trata de GNOME? :-? El paquete con problemas parece ser libreoffice-wiki-publisher o jre en todo caso. De todas formas, veo que la mayoría de los que actualizáis de una versión a otra lo hacéis muy alegremente, sin tener en cuenta los repositorios que tenéis activados ni nada... no sé, es normal que haya problemas y/o conflictos con algunos paquetes. Revisa las notas de publicación, y más concretamente las secciones 4.5.1 y 4.5.4: http://www.debian.org/releases/wheezy/amd64/release-notes/ch-upgrading.es.html#trouble Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/km92fm$ds9$2...@ger.gmane.org -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cad1pindmdh-t7s3isawi+1_rjovky7mnsl_mkdihgmtea0f...@mail.gmail.com
Re: Como asociar archivos con programas en GNU/Linux
Buen día, tiempo sin estar por éstos lares. saludos a todos los debianitas. Amigo Marcos, debido a mi ignorancia al respecto, me puede indicar dónde añado la línea xdg-mime default evince.desktop application/pdf para asociar los .pdf con evince en chrome (-ium) ??? Gracias por adelantado 2013/4/17 Camaleón noela...@gmail.com El Wed, 17 Apr 2013 14:41:49 -0300, Pablo Jiménez escribió: On Wed, Apr 17, 2013 at 04:25:43PM +, Camaleón wrote: (...) No es sólo Chromium. Midori también se vale de xdg-utils de Freedesktop en lo que se refiere a MIME. Lo normal (¿ideal?) sería que el navegador usara la aplicación predeterminada del sistema pero que permita cambiarlo de manera independiente. xdg-mime lo cambia para cada usuario, pero no cuenta con el nivel de detalle que le permita asignar la aplicación X al formato Y en el programa Z. Claro, por eso digo que esa opción no siempre resulta conveniente. Un mismo usuario puede querer abrir el mismo documento desde distintas aplicaciones según le convenga (por ejemplo, usar un lector PDF rápido y con menos bugs para el navegador y usar el acrobat reader cuando lo abre desde un archivo local). Vamos, que Chrome y Midori pinchan en ese aspecto :-) Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kkmnlc$aff$6...@ger.gmane.org
Re: Como asociar archivos con programas en GNU/Linux
Hecho. Muchas gracias Santiago. Frederit 2013/4/18 Santiago José López Borrazás sjlop...@gmail.com El 18/04/13 17:06, Frederit Mogollon escribió: (...) xdg-mime default evince.desktop application/pdf Ya te han dado tal cual, si tienes el paquete evince instalado pones ese comando directamente en la consola de tu usuario. -- Saludos de Santiago José López Borrazás. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51704d92.1010...@sjlopezb.yahoo.es
Re: Mi entorno gráfico favorito es ______ por ...
2012/12/18 Miguel Matos unefistano...@gmail.com Saludos a la lista. Ahora que el Windows 7 (¡ZAPE!, aunque menos ¡SUSTO! que WIN8) se ha... pues... :'-( ... ido... me toca quedarme con Debian, así que intentaré explotarlo lo mejor posible, por ello recurirré a ustedes más seguido. Puedes usar GNU/Linux Debian aunque sigas usando Windows, y no usarlo sólo porque la versión 7 del sistema privativo tiene sus días de soporte contado. Mi siguiente duda es esta: ya que se viene Whezzy, un muy querido juguete de Toy Story (BTW, la tercera parte la pasarán el jueves 20, ¡DOS VECES!, por si se la perdieron), se viene un cambio de entorno gráfico y otros cambios extras. Pero quisiera seguir usando Squeeze un año más, así que mi duda es esta: ¿cuál es su entorno gráfico favorito, y por qué? Pueden escribirlo (sin top-posting, porfa, del anti-HTML se encargan ustedes), siguiendo la línea del título de este mensaje. Evaluaré sus respuestas por una semana, y luego haré el cambio a mi PC. ¿Me siguen? Uso Debian desde hace unos 5 años, y en todas las máquinas (portátiles y desktops con más de 1,5 GHz de procesador y de 512 MB a 1 GB de ram) que lo he probado, generalmente partiendo de una netinstall nunca me ha fallado. Los problemas encontrados han sido provocados por jurungar como root los archivos del sistema sin saber y/o por mi falta de experiencia para resolverlos. Por curiosear he probado los entornos de escritorio gnome3, gnome2-fallback, xfce, lxde, kde, enlighment, intentando configurarlos a mi gusto, y aunque algunos son muy rápidos y otros muy vistosos, el único que siempre me llena tanto en configurabilidad como en elegancia, ha sido gnome2.32. Espero éstos comentarios te sirvan de algo para que puedas escoger el que más se adapte a tus necesidades y gustos. Saludos desde Venezuela. Frederit -- Buen uso de las listas (como se ven en Debian): http://wiki.debian.org/es/NormasLista Ayuda para hacer preguntas inteligentes: http://is.gd/NJIwRz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/calevjmsnzzo4vgtnbtnc0ewqdccui1vhc5iu5pinbaussq...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabzkbcgy5jdg+anvxpmurf_upokb19p_p8yhaubdcf5caem...@mail.gmail.com
Fwd: instalacion de debian
Hola Andrés. Yo tengo instalado Debian Squeeze en una laptop Síragon con procesador Intel celeron 1,6 GHz, 512 MB RAM, tarjeta gráfica VIA, y tarjeta inalámbrica realtek con chip rtl8187L. La instalación la hice hace casi 1 año, desde una imagen netinstall vía usb. Es importante que primero hagas un particionado previo del disco duro. Esto lo puedes hacer conectando el disco duro mediante cable usb a otro computador, o utlizando un livecd de alguna distro GNU/Linux que use paquetes .deb (tipo Ubuntu) mediante la aplicación GParted. Luego arrancas desde el usb o el CD/DVD de Debian. Se recomienda, sobre todo si la instalación es desde una netinstall, conectar a internet vía cable de red. lee la documentación de Debian, para saber si el kernel ya soporta ese controlador. Si es así sólo tienes que cargar el módulo. Por ejemplo, mi controlador era soportado por el kernel 2.6.32 (que uso actualmente), así que luego de instalar el sistema sólo le indique al sistema vía terminal como root, con el comando modprobe rtl8187 para cargar el módulo respectivo. Luego sólo queda actualizar la lista de repositorios, instalar las aplicaciones necesarias/deseadas y a disfrutar. El sistema es exquisitamente hermoso y estable. Vale recordar que en ese momento Camaleón, entre otras personas no menos importantes, me ayudaron bastante y me dieron luces. Espero con éstas palabras puedas instalar el Debian. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabzkbch37l7rv9-24ffmdooo8fjknc2q9pix5qnfcoblsop...@mail.gmail.com
Re: sigo sin poder instalr impresora en Debian 6
Hola Luis. Inicialmente verifica que estén instalados los siguientes paquetes: cups-bsd cups-driver-gutenprint foomatic-db-engine system-config-printer gvfs-backends gvfs-bin modem-manager usb-modemswitch Esto lo puedes hacer escribiendo en una terminal de root, la línea (sin las comillas): aptitude search nombre_del_paquete. El que no esté instalado, lo instalas en la misma terminal con la línea: aptitude install nombre_del_paquete. Todo ésto, también lo puesdes hacer de forma gráfica des Synaptic, buscando entre los paquetes instalados y no instalados. Ahora sí, sigue los pasos expuestos en el siguiente link, pero ubicando tu modelo de impresora: http://usuariodebian.blogspot.com/2009/01/multifuncin-hp-psc1610.html Con ésto es muy probable que resuelvas el problema. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABZkBCHwZLTFgPYyutteQbh=k6pdklzos8-7gfq2-ypjzag...@mail.gmail.com
Squeeze desde netinstall
Hola Jawifi. Yo estoy con un Debian Squeeze instalado desde netinstall, desde hace unos 5 meses, y todo va perfecto. Lo monté en un portátil con procesador intel celeron 1,6 GHz, 512 MB de ram y disco duro de 120 GB. Usé como gestor de archivos nautilus y gnome como entorno de escritorio. Probé inicialmente con lxde y xfce y están bien, pero quería un entorno más prsonalizable puesto que me gusta monitorear constantemente el sistema, y con gnome puedo hacerlo permanentemente desde los paneles, además de colocar lanzadores de aplicaciones para tenerlas al toque. Con las especificaciones de la máquina que quieres usar lxde te va a volar, xfce te gustará, y gnome también te serviría. Si puedes instala desde el netinstall vía usb, sólo el sistema base y sin entorno gráfico (hay buenas guías en la red), y luego instala el entorno de escritorio y el gestor de sesion como te dijeron anteriormente. Cualquier cosa avisa y te ayudamos si podemos. Saludos fdm -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabzkbch0ual-jndfe3qafwfaf6axja0hd1dc2ao0vwfuvea...@mail.gmail.com
Re: Problema configuracion monitor y touchpad post-instalacion Squeeze
Buenas noches. Un saludos a todos. Les cuento que al no poder resolver el problema de la configuración no óptima del monitor, reinstalé el sistema desde netinstall vía usb, con gnome mínimo, aplicaciones seleccionadas y configurada para impresión, escaneo, multimedia, navegación, y todo va de maravillas. Ninguna de las opciones que me sugirieron hacer funcionaron. No sé que ocurrió en la primera instalación que causó ésta desconfiguración de la resolución de monitor, y touchpad, pero el sistema no aceptó ninguna opción para repararlo. Así que, como último recurso, reinstalé y todo fino. Lo único que si me parece extraño son 2 observaciones: - En la instalación anterior (la dañada), me di cuenta que al detener las X con el comando /etc/init.d/gdm3 stop, la pantalla se tornaba oscura y el sistema aparentemente se congelaba. Es decir, no aparecía una cónsola o terminal tty para entrar en modo texto. Así que tuve que crear el archivo xorg.conf.new desde una terminal tty entrando desde el modo de recuperación en le grub2. - En la anterior instalación (dañada) y la instalación actual (perfecta, fluida y desde la que estoy redactando éstas líneas), he apreciado que al reiniciar el sistema, ya sea desde el modo gráfico o con el comando /etc/init.d/gdm3 restart, la pantalla se torna de algún color (verde o rojizo o marrón) o muestra manchas blancas o grises pequeñas moviéndose rápidamente de un lado a otro, antes de apagarse, para luego reiniciar normal. Imagino que ésto puede ser debido a algo que no está bien configurado en el paquete instalado xserver-xorg-video-openchrome para la tarjeta gráfica VIA CN700/P4M800. Supongo que ésto puede explicar el por qué aparece el valor de 0 Hz como tasa de refresco en la ruta MenuSistemaPreferenciasMonitores, aunque la resolución es óptima y está fija a 1280x768 píxeles (el panel LCD de la portátil es una Chunghwa WXGA e 14 modelo CLAA140WA01A). Bueno, muy agradecido con todos por l gran ayuda. Aprendí mucho sobre la configuración de las X. Esto último compensa el que haya tenido que reinstalar el sistema a lo windows. :-) Saludos Frederit -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabzkbceovhf1dotgd8vozgkds2jav-h1gnqt4t70dsv7vvd...@mail.gmail.com
Re: Problema configuracion monitor y touchpad post-instalacion Squeeze
Gracias por responder. A César: Intenté bajar las X con el comando /etc/init.d/gdm3 stop y la pantalla se torna oscura con manchas pequeñas pasando muy rápido de un lado a otro todo el tiempo, y lo único que me deja hacer es reiniciar el sistema con Ctrl+Alt+Supr. Opté por entrar en el modo recuperación que aparece en la lista de grub2, y cuando ingreso el password de root, entonces hago Xorg -configure, con lo que genera el archivo xorg.conf.new en el directorio /root/xorg.conf.new. De ahí lo copié al directorio /etc/X11/xorg.conf.new, reinicié el sistema y todo sigue igual. A Camaleón: Inicialmente usé xrandr, siguiendo instrucciones del link que pones y no hay cambios. Con lo del touchpad, creo que escribí un poco confuso, lo tenía configurado para poder activar botones, lanzar aplicaciones, etc., haciendo doble-click en el touchpad y bien, pero ésto ya no pasa desde que se desconfiguró la resolución de pantalla. Actualicé el sistema y todo sigue igual. No hay cambio. Con respecto a usar pastebin, lo intenté pero el administardor de red no permite usarlo (está bloqueado). Yo uso la red de un instituto de investigación científica (y en el cual también resido), en el que estoy haciendo postgrado en Venezuela y estoy limitado a no poder usar ciertas páginas, según el anuncio de la gerencia de administración de red, que es por razones institucionales. Así que me temo que seguiré colocando el texto completo aquí en el correo. A continuación les cuento lo que hice, luego de investigar un buen rato en internet y muestro el contenido de xorg.conf.new: Este es el contenido del archivo xorg.conf.new recien creado: Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDevice Mouse0 CorePointer InputDevice Keyboard0 CoreKeyboard EndSection Section Files ModulePath /usr/lib/xorg/modules FontPath /usr/share/fonts/X11/misc FontPath /usr/share/fonts/X11/cyrillic FontPath /usr/share/fonts/X11/100dpi/:unscaled FontPath /usr/share/fonts/X11/75dpi/:unscaled FontPath /usr/share/fonts/X11/Type1 FontPath /usr/share/fonts/X11/100dpi FontPath /usr/share/fonts/X11/75dpi FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType FontPath built-ins EndSection Section Module Load dbe Load glx Load dri Load dri2 Load extmod Load record EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option ZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelName Monitor Model EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option ShadowFB # [bool] #Option DefaultRefresh # [bool] #Option ModeSetClearScreen # [bool] Identifier Card0 Driver vesa VendorName VIA Technologies, Inc. BoardName CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro] BusID PCI:1:0:0 EndSection Section Screen Identifier Screen0 Device Card0 Monitor Monitor0 SubSection Display Viewport 0 0 Depth 1 EndSubSection SubSection Display Viewport 0 0 Depth 4 EndSubSection SubSection Display Viewport 0 0 Depth 8 EndSubSection SubSection Display Viewport 0 0 Depth 15 EndSubSection SubSection Display Viewport 0 0 Depth 16 EndSubSection SubSection Display Viewport 0 0 Depth 24 EndSubSection EndSection Luego desde terminal ordene lspci y obtuve lo siguiente: root@lapfmogollo:/home/fdmogollon# lspci 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge 00:0e.0 CardBus bridge: ENE Technology Inc CB-712/4 Cardbus Controller (rev 10) 00:0e.1 FLASH memory: ENE Technology Inc ENE PCI Memory Stick Card Reader Controller (rev 01) 00:0e.2 SD Host controller: ENE Technology Inc ENE PCI Secure Digital Card Reader Controller (rev 01) 00:0e.4 FLASH memory: ENE Technology Inc SD/MMC Card Reader Controller (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA
Problema configuracion monitor y touchpad post-instalacion Squeeze
Buenas amigos... Les saludo nuevamente. Aunque se que hay mucha info en la red, les pregunto para orientarme, puesto que no hallo como comenzar. Les cuento a continuación las características de la máquina que uso y mi problema: HARDWARE: Portátil Síragon Canaima NB3050 Procesador Intel Celeron M 430 1,73 GHz RAM 512 MB Tarjeta gráfica VIA CN700/P4M800 Pantalla LCD WXGA 1280x768 Teclado AT Chicony Español SynPS/2 synaptics touchpad SOFTWARE: Debian Squeeze Kernel Linux 2.6.32-5-686 instalado desde netinstall vía USB El Xorg se instaló con paquetes xserver-xorg-video-openchrome y xserver-xorg-input-all Nombre de máquina: lapfmogollo Nombre de usuario: fdmogollon El PROBLEMA: Luego de culminar la instalación del sistema base, entorno gnome mínimo, aplicaciones seleccionadas y configurar resolución de monitor y touchpad, el sistema funcionó perfectamente. Lo apagué. Al iniciar (al día siguiente), la resolución del monitor es de 1600x1200 e intento cambiarla en menusistemapreferenciasmonitores, pero no hay cambio. Además, puedo mover el puntero con el touchpad pero no responde adecuadamente al usar el botón izquierdo bajo el mismo aunque en menusistemapreferenciasratontouchpad aparece como bien configurado. Intenté arreglar reinstalando los paquetes xserver-xorg-video-openchrome y xserver-xorg-input-all, e instalando los paquetes xserver-xorg-video-vesa y xserver-xorg-video-fbdev, que no lo estaban, y nada. El problema descrito sigue sin resolverse. PISTAS (resultado de usar varios comandos desde terminal): root@lapfmogollo:/home/fdmogollon# Xorg -configure Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. Please consult the The X.Org Foundation support at http://wiki.x.org for help. root@lapfmogollo:/home/fdmogollon# sudo dpkg-reconfigure -phigh xserver-xorg Esto aparentemente no tiene mayor efecto... root@lapfmogollo:/home/fdmogollon# xrandr xrandr: Failed to get size of gamma for output default Screen 0: minimum 640 x 480, current 1680 x 1200, maximum 1680 x 1200 default connected 1680x1200+0+0 0mm x 0mm 1600x1200 0.0 1680x1050 0.0 1400x1050 0.0 1280x1024 0.0 1280x8000.0 1280x7680.0 1024x7680.0 800x60061.0 640x48060.0 1680x1200 0.0* root@lapfmogollo:/home/fdmogollon# nano /var/log/Xorg.0.log X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-amd64 i686 Debian Current Operating System: Linux lapfmogollo 2.6.32-5-686 #1 SMP Mon Mar 26 05:2$ Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=1997fd32-f$ Build Date: 30 October 2011 08:56:49PM xorg-server 2:1.7.7-14 (Julien Cristau jcris...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Apr 22 02:03:46 2012 (==) Using system config directory /usr/share/X11/xorg.conf.d (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/75dpi/ does not exist. Entry deleted from font path. (WW) The directory /usr/share/fonts/X11/75dpi does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevi$ (II) Loader magic: 0x81ecce0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (++) using VT number 7 (--) PCI:*(0:1:0:0) 1106:3344:1558:5406 VIA Technologies, Inc. CN700/P4M800 $ (II) Open ACPI successful (/var/run/acpid.socket) (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module
Re: Problema compilando driver rtl8187L en Debian Squeeze desde NetInstall
Hola Camaleón, gracias por comentar, aprendí de lo que respondiste. Si sólo debo activar el módulo rtl8187 del kernel 2.6.32-5-686, pero antes desinstalar el kernel 3.2. Hice una mezcolanza extraña por no leer entre líneas el mensaje de la terminal. Gracias. 2012/4/8 Camaleón noela...@gmail.com El Sat, 07 Apr 2012 19:34:34 -0430, frederit mogollon escribió: Buenas noches. Un saludo. Soy nuvo en ésta lista. Hola :-) Explico mi problema: Tengo un portátil Síragon Canaima NB3050, con procesador Intel Celeron M430 1,7 GHz, 512 MB de RAM, un HD de 120 GB, tarjeta gráfica VIA CN700/P4M800, tarjeta ethernet VIA VT6102 y tarjeta Wi-Fi AW-GU700 con chipset Realtek RTL8187L. Previa revisión bibliográfica extensa, hice una instalación mínima de Debian Squeeze con NetInstall desde una unidad USB usando conexión LAN. Instalé lo necesario para tener un sistema Debian funcional, con kernel 2.6.32-5-686, con entorno Gnome mínimo y la aplicación wicd como gestor de redes. Todo bien, excepto que al intentar compilar e instalar el driver rtl8187L_linux_26.1040.0820.2010.release.tar.gz (previamente descargado desde el sitio web oficial de Realtek), me lanza un error y no puedo proseguir. Antes de nada... ¿por qué has compilado el driver? ¿has comprobado si el kernel que incluye squeeze tiene soporte para tu adaptador wifi? Según la página de la wiki de Debian debería está soportado por el módulo rtl8187: http://wiki.debian.org/rtl818x#supported-rtl8187 Aclaro que mi usuario es fdmogollon, entro desde una terminal de root y el archivo comprimido del driver lo tengo en la carpeta Descargas. A continuación coloco lo que me arroja la terminal durante el proceso: root@lapfmogollo:/home/fdmogollon# cd Descargasroot@lapfmogollo:/home/fdmogollon/Descargas# tar -zxvf rtl8187L_linux_26.1040.0820.2010.release.tar.gz rtl8187L_linux_26.1040.0820.2010.release/ (...) root@lapfmogollo :/home/fdmogollon/Descargas/rtl8187L_linux_26.1040.0820.2010.release# ./configure bash: ./configure: No existe el fichero o el directorio Y tiene razón, no existe ese archivo en la ruta dada. Hasta aquí veo que no encuentra el archivo, y pensé que era porque el código fuente del driver está dentro de la subcarpeta rtl8187, así que voy hasta ese directorio y lo intento de nuevo y obtengo lo siguiente: root@lapfmogollo :/home/fdmogollon/Descargas/rtl8187L_linux_26.1040.0820.2010.release/rtl8187# ./configure bash: ./configure: No existe el fichero o el directorio Y sigue teniendo razón, no hay ningún archivo .configure. ¿Has leído el archivo readme para ver cómo se compila y qué requisitos te pide? Por si me estoy saltando algo, reviso el contenido de un archivo ReadMe que se encuentra dentro de la carpeta descomprimida rtl8187L_linux_26.1040.0820.2010.release y que dice: (...) Eso es :-) Bueno, te indica que lo puedes compilar de dos formas, pero básicamente tienes que ejecutar make, make install, reiniciar el equipo y configurar la red (si lo que quieres es compilarlo). Haciendo lo que entiendo del texto, ordeno Makefile ya dentro de la subcarpeta rtl8187 y obtengo ésto: ¿De dónde sacas el Makefile? :-??? root@lapfmogollo :/home/fdmogollon/Descargas/rtl8187L_linux_26.1040.0820.2010.release/rtl8187# Makefile bash: Makefile: no se encontró la orden Cierto porque ese comando no existe. Entonces, ordeno make y obtengo ésto: Por fin :-) root@lapfmogollo :/home/fdmogollon/Descargas/rtl8187L_linux_26.1040.0820.2010.release/rtl8187# make make -C /lib/modules/3.2.0-0.bpo.2-686-pae/build M=/home/fdmogollon/Descargas/rtl8187L_linux_26.1040.0820.2010.release/rtl8187 CC=gcc modules make: *** /lib/modules/3.2.0-0.bpo.2-686-pae/build: No existe el fichero o el directorio. Alto. make: *** [modules] Error 2 Un momento... ese kernel no es que lleva squeeze sino que es de los backports. Menudo jaleo tienes. Aquí pensé que era necesario el kernel 3.2.0-0.bpo.2-686-pae, y lo instalé desde los repositorios squeeze-backports, entonces lo intento de nuevo y obtengo lo mismo: (...) No, no... eso no es así, no te está diciendo eso. Además, no instales un kernel tan a la ligera a no ser que lo necesites por algo concreto. En fin, te recomiendo que dejes la compilación a un lado y que pruebes a configurar tu adaptador con el módulo que incluye el kernel, salvo que tengas algún problema concreto y no te funcione, en cuyo caso la compilación sería la siguiente alternativa. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jls5hv$f2u$3...@dough.gmane.org
Re: Problema compilando driver rtl8187L en Debian Squeeze desde NetInstall
Si el adaptador ya funciona. Ordené cargar automáticamente el módulo con modprobe rtl8187, reinicié y listo. Gracias por tu ayuda 2012/4/9 Camaleón noela...@gmail.com El Mon, 09 Apr 2012 01:40:48 -0430, frederit mogollon escribió: No hagas top-posting y no uses el formato html, que se leen muy mal los correos. Hola Camaleón, gracias por comentar, aprendí de lo que respondiste. Si sólo debo activar el módulo rtl8187 del kernel 2.6.32-5-686, pero antes desinstalar el kernel 3.2. Hice una mezcolanza extraña por no leer entre líneas el mensaje de la terminal. Bueno, tener un kernel más moderno nunca está de más, es decir, que no es necesario que lo desinstales, te puede servir en el momento menos pensando. A todo esto ¿ya te funciona el adaptador wifi? Gracias. De nada :-) Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jlumhm$ss9$3...@dough.gmane.org -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabzkbchkmeb3ixeaubp5bmezqs1+jitwixm-vfhu5ue+pxy...@mail.gmail.com
Problema compilando driver rtl8187L en Debian Squeeze desde NetInstall
Buenas noches. Un saludo. Soy nuvo en ésta lista. Explico mi problema: Tengo un portátil Síragon Canaima NB3050, con procesador Intel Celeron M430 1,7 GHz, 512 MB de RAM, un HD de 120 GB, tarjeta gráfica VIA CN700/P4M800, tarjeta ethernet VIA VT6102 y tarjeta Wi-Fi AW-GU700 con chipset Realtek RTL8187L. Previa revisión bibliográfica extensa, hice una instalación mínima de Debian Squeeze con NetInstall desde una unidad USB usando conexión LAN. Instalé lo necesario para tener un sistema Debian funcional, con kernel 2.6.32-5-686, con entorno Gnome mínimo y la aplicación wicd como gestor de redes. Todo bien, excepto que al intentar compilar e instalar el driver rtl8187L_linux_26.1040.0820.2010.release.tar.gz (previamente descargado desde el sitio web oficial de Realtek), me lanza un error y no puedo proseguir. Aclaro que mi usuario es fdmogollon, entro desde una terminal de root y el archivo comprimido del driver lo tengo en la carpeta Descargas. A continuación coloco lo que me arroja la terminal durante el proceso: root@lapfmogollo:/home/fdmogollon# cd Descargasroot@lapfmogollo:/home/fdmogollon/Descargas# tar -zxvf rtl8187L_linux_26.1040.0820.2010.release.tar.gz rtl8187L_linux_26.1040.0820.2010.release/ rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ rtl8187L_linux_26.1040.0820.2010.release/ieee80211/scatterwalk.h rtl8187L_linux_26.1040.0820.2010.release/ieee80211/rtl_crypto.h rtl8187L_linux_26.1040.0820.2010.release/ieee80211/cipher.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/compress.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_wx.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/kmap_types.h rtl8187L_linux_26.1040.0820.2010.release/ieee80211/Makefile rtl8187L_linux_26.1040.0820.2010.release/ieee80211/digest.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_crypt_tkip.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_crypt_wep.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_softmac.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211.h rtl8187L_linux_26.1040.0820.2010.release/ieee80211/scatterwalk.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/license rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_module.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_crypt.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_crypt.h rtl8187L_linux_26.1040.0820.2010.release/ieee80211/tags rtl8187L_linux_26.1040.0820.2010.release/ieee80211/readme rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_softmac_wx.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/api.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_crypt_ccmp.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/michael_mic.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/internal.h rtl8187L_linux_26.1040.0820.2010.release/ieee80211/proc.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/aes.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/arc4.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_tx.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/ieee80211_rx.c rtl8187L_linux_26.1040.0820.2010.release/ieee80211/autoload.c rtl8187L_linux_26.1040.0820.2010.release/Makefile rtl8187L_linux_26.1040.0820.2010.release/wlan0down rtl8187L_linux_26.1040.0820.2010.release/RadioPower.sh rtl8187L_linux_26.1040.0820.2010.release/ReadMe rtl8187L_linux_26.1040.0820.2010.release/wlan0up rtl8187L_linux_26.1040.0820.2010.release/rtl8187/ rtl8187L_linux_26.1040.0820.2010.release/rtl8187/changes rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_dm.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8187.h rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_wx.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/install rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_pm.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/Makefile rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_dm.h rtl8187L_linux_26.1040.0820.2010.release/rtl8187/license rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_hw.h rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8187_core.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8187_led.h rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_93cx6.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/readme rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_rtl8225.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_wx.h rtl8187L_linux_26.1040.0820.2010.release/rtl8187/copying rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_rtl8225z2.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/authors rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8187_led.c rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_pm.h rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_93cx6.h rtl8187L_linux_26.1040.0820.2010.release/rtl8187/r8180_rtl8225.h rtl8187L_linux_26.1040.0820.2010.release/release_note rtl8187L_linux_26.1040.0820.2010.release/wlan0dhcp