When I login from console, I get a bunch of errors from modprobe that /dev/this and /dev/that is missing. This error flow is several pages long. I tracked down the modules which it is trying to load to /etc/security/console.perms. Most of the devices listed there doesn't exist, which causes devfs to complain when pam tries to access them and change the permissions... I guess I could get rid of this by just redirecting the errors from console to /var/log, but it doesn't look right... I'll put this down as a minor bug, feel free to drop it if you feel it's working as expected... Reproducible: Always Steps to Reproduce: 1.Login Actual Results: ~50 lines of modprobe complaining that devices that pam access doesn't exist. Expected Results: Not complained. :) emerge info: Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.2.5-r2,2.3.2-r1) ================================================================= System uname: 2.4.20-gentoo-r5 i686 Pentium III (Coppermine) GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline tetex tcltk java guile ruby X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gtk qt motif mozilla aalib directfb fbcon svga -kde -gnome -arts -opengl -alsa sse dvd" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache fixpackages" wolverine:fredde:~>emerge search ^pam$ ^devfsd$ Searching... [ Results for search key : ^pam$ ] [ Applications found : 1 ] * sys-libs/pam Latest version available: 0.75-r11 Latest version installed: 0.75-r11 Size of downloaded files: 977 kB Homepage: http://www.kernel.org/pub/linux/libs/pam/ Description: Pluggable Authentication Modules Searching... [ Results for search key : ^devfsd$ ] [ Applications found : 1 ] * sys-apps/devfsd Latest version available: 1.3.25-r3 Latest version installed: 1.3.25-r3 Size of downloaded files: 41 kB Homepage: http://www.atnf.csiro.au/~rgooch/linux/ Description: Daemon for the Linux Device Filesystem
svrmarty: this bug is a duplicate, and the issue was fixed -- I forget how exactly, though -- can you find?
Fredrik: did you changed your hdd and copied all data to a new disk, which is now your root ? maybe you forgot to create the /dev/* mknodes ?
donny, since Az is kinda temporarily offline/unavailable, can I throw this to you?
hmm. so you've uncommented the `pam_console_apply_devfsd.so' line in your devfsd.conf then huh? this is not a default configuration, and probably not a lot of people are running with it... actually i've never messed with it either, so am going in the dark here and i dont find any documentation on this module. good old pam eh! console.perms appears to be used by pam_console.so; i dunno at the moment how pam_console_apply_devfsd.so fits in with that. maybe this is related to kernel module loader, do you use that? sorry, not having much luck here.. sounds like a configuration issue somewhere....
I don't think I have messed with pam at all... It's one of those things that I just suppose should just work, and scream loudly when it doesn't... I don't think the problem is with PAM anyway, I think it's a devfs issue... When I played around with this bug trying to rule out things and generally track it down, I found that if I tried to access a file under the /dev tree, it would make modprobe complain... Kind of like this: ~> cd /dev ~> touch foo_bar modprobe: Can't locate module /dev/foo_bar I didn't get the message when I went /outside/ devfs and tried to access a file: ~> cd / ~> touch /dev/foo_bar (I think it was permission denied as an error message here, memory is vague) I though this was the 'standard' behavour with devfs and didn't bother to look into it more, and that pam somehow triggered this 'standard' behavour and the blame was with pam. It seems like I was wrong on that assumtion, and that it indeed is a devfs problem, as I didn't encounter this problem on my other gentoo install when I tried to touch a file inside devfs. I did turn on full devfs debug-messages, but they told me nothing, just that someone tried to access a device, so I didn't save any of those logs. There is a huge problem though, the laptop where I had this problem is dead. Dead as in "I'll just sit here and blink a LED and not even perform my PowerOnSelfTest". The Compaq support technician just scratched his head and a new laptop is on the way. I'll swap HDs and see if I can get gentoo to boot on the new laptop and look into the problem some more, like digging up log and configuration files, if you're interested that is. It's not a bug for me anymore, my other gentoo box is not suffering from this problem and I'll reinstall the new one anyway, so feel free to put a 'WORKSFORME' on it and I'll reopen it if it shows up again...
Ok thanks for the information. In /etc/devfsd.conf I have this line: # Uncomment this to let PAM manage devfs #REGISTER .* CFUNCTION /lib/security/pam_console_apply_devfsd.so pam_console_apply_single $devpath ^^^ that's all on one line. I note it seems commented out by default...
Alert gentlemen!! This bug has reared its ugly head again. Can I be of any assistance providing configuration files, etc, to help you work it out?? Like Frederik, I noticed that "touch xyz" results in a modprobe error and I think it's the "console.perms" file that causes PAM to try and access those device nodes. "man pam_console" has some useful information about this. I think that "pam_console" sounds like a bit of a hack, the fact that the console is up for grabs unless someone has logged in, somewhere... shouldn't access to the system be independent for independent logins on different ttys?? I would like to turn off this feature. But on the other hand, I have a few problems with permissions for the cdwriter and serial ports.. I don't know how to set things up so that certain users can use certain hardware devices. Is this the problem that "pam_console" is supposed to address?? At first glance I gathered that "pam_console" only applies to "root" users though. Correct??? cheers, Nick
Here is some further information about my previous report: 1. I also noticed the following line in "/etc/devfsd.conf": #REGISTER .# CFUNCTION /lib/security/pam_console_apply_devfsd.so pam_console_apply_single $devpath I've now tried rebooting with this line "commented in" and it doesn't seem to affect the problem at all. So I've commented it "out" again for the moment. 2. The problem doesn't occur if I login as "root". It only happens if I login as "nick". "nick" is not in the "wheel" group at the moment, so I assume that the "pam_console" program must be receiving the switch "allow_non_root_tty"?? Unfortunately I can't find this setting anywhere in etc, so maybe I better RTFM but can anyone tell me if I might be on the right track with this?? 3. To Donny: > maybe this is related to kernel module loader, do you use that? I compiled my own kernel for the system (in other respects its a standard stage 3 install) so maybe the problem is related to my kernel. I have CONFIG_KMOD=y although I'm not sure if this differs from the standard gentoo kernel. Anyone? 4. To Martin: > maybe you forgot to create the /dev/* mknodes ? I gathered this shouldn't be necessary when using devfsd? I thought devfsd was mandatory for running Gentoo at all? Please let me know if I need to "mknod".. If possible please can this bug be reopened? Unless an earlier solution is on file?? Thanks. It seems my BugZilla access doesn't allow me to change status. cheers, Nick
Well, I had this problem /again/ on my new install. I got rid of it by remembering to start metalog at startup. Then the problem disappeared. I can't even see it in the logs. I haven't tried to turn off metalog and see if the problem re-emerges, but I'll see when I get console access to it again...
