from:"frederit mogollon"

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

2015-10-09 Thread Frederit Mogollon

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

2015-10-09 Thread Frederit Mogollon

>> 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

2015-09-29 Thread Frederit Mogollon

-- 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 Thread Frederit Mogollon

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

2015-09-28 Thread Frederit Mogollon

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

2015-07-11 Thread Frederit Mogollon

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

2015-06-19 Thread Frederit Mogollon

 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

2015-06-14 Thread Frederit Mogollon

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

2015-06-13 Thread Frederit Mogollon

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-13 Thread Frederit Mogollon

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

2015-06-13 Thread Frederit Mogollon

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

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).

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.

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.

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:

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

2015-05-09 Thread Frederit Mogollon

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

2015-05-08 Thread Frederit Mogollon

.

 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

2015-05-08 Thread Frederit Mogollon


 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-07 Thread Frederit Mogollon

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

2015-05-05 Thread Frederit Mogollon

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

2015-05-05 Thread Frederit Mogollon

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

2015-04-27 Thread Frederit Mogollon

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