Re: no keyboard in xorg after the change of runlevel
Thanks, Sven. That was the problem. udev wasn't restarted after the change of runlevel back. I wanted to change the runlevel to single-user because I wanted to remount my filesystems on top of lvm read-only for a short time and create lvm snapshots with consistent filesystems. So I need to stop some daemons and processes to be able to remount the filesystems read-only. I'm going to stop only those services I need. On 06/18/2011 11:33 PM, Sven Joachim wrote: On 2011-06-18 22:25 +0200, Lukas Baxa wrote: I discovered a problem with Xorg recently. When I change the runlevel to single-user mode (i.e. to 1) and then back to multi-user mode (i.e. to 2) and start the X server again, my keyboard doesn't work anymore under X. The same happens if I boot directly into runlevel 1 and then change it to 2. Don't do that. One of the problems of the Debian boot system is that it starts too many services in runlevel S. When you switch too runlevel 1, they get killed and will not be restarted in runlevel 2. This includes udev, among others¹. I suppose that the problem is that the evdev module (generic input driver module) gets unloaded at the end for some reason. The X server relies on udev for detecting input devices, and if udev is not running this will not work. Have anybody met similar problem before? Or can anybody give me a clue how to solve this problem? I'm asking before filing a new bug under the xserver-xorg-input-evdev package. Sadly, the most sensible thing after entering runlevel 1 is to reboot. Otherwise you have to restart udev, dhclient, wpasupplicant and what not by hand which is cumbersome and error-prone. Sven ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444980 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dff3fe6.5000...@seznam.cz
no keyboard in xorg after the change of runlevel
Hello, I discovered a problem with Xorg recently. When I change the runlevel to single-user mode (i.e. to 1) and then back to multi-user mode (i.e. to 2) and start the X server again, my keyboard doesn't work anymore under X. The same happens if I boot directly into runlevel 1 and then change it to 2. I compared the Xorg logs that were generated with and without the problem, i.e. after the runlevel change and without the runlevel change (the log produced after the direct boot to runlevel 2). The log with the .old suffix is the problematic one generated after the runlevel change. The result was following: # diff Xorg.0.log Xorg.0.log.old 16c16 (==) Log file: /var/log/Xorg.0.log, Time: Sat Jun 18 19:34:22 2011 --- (==) Log file: /var/log/Xorg.0.log, Time: Sat Jun 18 19:32:14 2011 693,718c693,707 (II) config/udev: Adding input device Mouseemu virtual keyboard (/dev/input/ev ent14) (**) Mouseemu virtual keyboard: Applying InputClass evdev keyboard catchall (**) Mouseemu virtual keyboard: always reports core events (**) Mouseemu virtual keyboard: Device: /dev/input/event14 (II) Mouseemu virtual keyboard: Found keys (II) Mouseemu virtual keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device Mouseemu virtual keyboard (type: K EYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout us,cz (**) Option xkb_options grp:shift_toggle (II) config/udev: Adding input device Mouseemu virtual mouse (/dev/input/event 15) (**) Mouseemu virtual mouse: Applying InputClass evdev pointer catchall (**) Mouseemu virtual mouse: always reports core events (**) Mouseemu virtual mouse: Device: /dev/input/event15 (II) Mouseemu virtual mouse: Found 3 mouse buttons (II) Mouseemu virtual mouse: Found scroll wheel(s) (II) Mouseemu virtual mouse: Found relative axes (II) Mouseemu virtual mouse: Found x and y relative axes (II) Mouseemu virtual mouse: Configuring as mouse (**) Mouseemu virtual mouse: YAxisMapping: buttons 4 and 5 (**) Mouseemu virtual mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device Mouseemu virtual mouse (type: MOUSE) (II) Mouseemu virtual mouse: initialized for relative axes. (II) config/udev: Adding input device Mouseemu virtual mouse (/dev/input/mouse2) (II) No input driver/identifier specified (ignoring) --- (II) Power Button: Close (II) UnloadModule: evdev (II) Video Bus: Close (II) UnloadModule: evdev (II) Sleep Button: Close (II) UnloadModule: evdev (II) HP Webcam [2 MP Fixed]: Close (II) UnloadModule: evdev (II) CHICONY USB Keyboard: Close (II) UnloadModule: evdev (II) AT Translated Set 2 keyboard: Close (II) UnloadModule: evdev (II) UnloadModule: synaptics (II) Macintosh mouse button emulation: Close (II) UnloadModule: evdev I don't know why the Mouseemu virtual keyboard isn't detected in the problematic log, but it shouldn't be the cause of the problem (maybe another consequence). I use the Mouseemu daemon to emulate the right and middle button clicks by key presses because my touchpad doesn't work as it should and it works fine. It's also properly stopped/started after the runlevel change. I suppose that the problem is that the evdev module (generic input driver module) gets unloaded at the end for some reason. Have anybody met similar problem before? Or can anybody give me a clue how to solve this problem? I'm asking before filing a new bug under the xserver-xorg-input-evdev package. Lukas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dfd09b5.4080...@seznam.cz
Re: minimum number of days between password change
Wolodja Wentland wrote: On Thu, Nov 04, 2010 at 10:55 +, Camaleón wrote: On Wed, 03 Nov 2010 20:40:15 +0100, Lukas Baxa wrote: Camaleón wrote: I would like to file a new bug report, but I'm not sure against which package. I'm considering either passwd or libpam-modules. passwd (as Wolodja suggested) should not allow the user to change his password if /etc/shadow states so. Anyway, I would not worry about the correctness of the package against you are to report the bug as devels will change it if they estimate it convenient. Exactly. Given that we do not know what causes this bug, we have no way to assign it to the correct package. I would therefore file a bug against the package that ships the program that exhibits the buggy behaviour. OK, good to know that the developers can change the package :-) Thanks. I've changed my meaning and I'm going to file the bug against the package passwd. Kind Regards The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd30066.1020...@seznam.cz
Re: minimum number of days between password change
Camaleón wrote: On Mon, 01 Nov 2010 21:35:20 +, Wolodja Wentland wrote: On Mon, Nov 01, 2010 at 12:49 -0500, Ron Johnson wrote: However, I'm able to change my password when logged in as guest as many times I want the same day If someone learns my password on day 2, they have full access to my account for 74 days, or I must beg for SysAdmin help? Minimum number of days isn't a very bright idea. I completely agree¹, but this policy should still be enforced or it has to be made clear that this setting is deprecated and no longer enforced. +1 for the enforcement. --- chage manpage --- -m, --mindays MIN_DAYS (...) … which is clearly not working in the way it is described. I have not reproduced this bug myself, but it is exactly that and should therefore be reported - not by posting to d-d - but rather by executing reportbug passwd. I've tried in a lenny box and faced the same behaviour than the OP. Maybe the new policy is to be applied _a day after_ the change or it should be enforced _as soon as_ changed? Is a passwd error (not reading/applying /etc/shadow mandate) or a chage one? :-? Greetings, Even if the discussion to this topic shows that the mindays option of chage might not be very useful in most cases, it doesn't work as it should. I would like to file a new bug report, but I'm not sure against which package. I'm considering either passwd or libpam-modules. I think that I should choose the libpam-modules package, because my passwd command uses PAM and is configured as follows: cat /etc/pam.d/passwd @include common-password cat /etc/pam.d/common-password password required pam_cracklib.so retry=3 difok=3 minlen=12 lcredit=0 ocredit=2 minclass=3 password required pam_unix.so use_authtok md5 remember=6 I suppose that the pam_unix.so library/module should check the aging information in /etc/shadow before changing the password in this file. Am I right? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd1ba9f.2030...@seznam.cz
minimum number of days between password change
Hi, I created an account guest to test password aging. The aging info of this account is following: chage -l guest Last password change: Nov 01, 2010 Password expires: Jan 30, 2011 Password inactive : never Account expires : never Minimum number of days between password change : 76 Maximum number of days between password change : 90 Number of days of warning before password expires : 14 However, I'm able to change my password when logged in as guest as many times I want the same day, even if minimum number of days between password change is set to a non-zero value. Does anybody know where the problem can be? I'm using an up-to-date debian lenny (5.0.6 nowadays) and I'm using PAM. The file /etc/pam.d/passwd looks as follows: cd /etc/pam.d cat passwd @include common-password cat common-password password required pam_cracklib.so retry=3 difok=3 minlen=12 lcredit=0 ocredit=2 minclass=3 password required pam_unix.so use_authtok md5 remember=6 The pam_cracklib module works fine and I suposse that password aging info should be checked by pam_unix. However, it doesn't work properly when using passwd from the command line. On the other hand, the maximum number of days between password change works fine and if the user guest logs in after the timeout expires, guest is forced to change his password before login. Can anybody give me a clue where the problem can be? Thanks, Lukas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cceeaba.3090...@seznam.cz
