When I try to login on a VT, the system outputs '"System' (including the double-quote ") after entering the username and again after entering the password. Login succeeds anyhow. Autologin via KDM is entirely broken: I get an Ok-Box ~'Login of <user>\n"System' (roughly, telling from memory) and after clicking the Ok button, I get another Ok-Box with authentication failed. I can then enter the username and password, but login is again not granted. Syslog logs no failed auth attempt. Reproducible: Always Portage 2.2.0_alpha141 (default/linux/amd64/10.0/desktop/kde, gcc-4.7.2, glibc-2.15-r3, 3.6.2-gentoo x86_64) ================================================================= System uname: Linux-3.6.2-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5000+-with-gentoo-2.2 Timestamp of tree: Thu, 18 Oct 2012 16:45:01 +0000 distcc 3.2rc1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/cmake: 2.8.9-r1 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.10.5 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.6, 1.12.4 sys-devel/binutils: 2.22.90 sys-devel/gcc: 4.7.2 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo systemd ambro-cross local enlightenment kde sunrise g-ctan ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-pipe -O2 -march=athlon64-sse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0 /usr/share/themes/oxygen-gtk/gtk-3.0 /var/lib/neatx/home" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-pipe -O2 -march=athlon64-sse3" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--depclean-lib-check n --with-bdeps y --keep-going" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildsyspkg compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://distfiles.gentoo.org" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/var/cache/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/gentoo" PORTDIR_OVERLAY="/var/cache/portage/layman/systemd /var/cache/portage/layman/ambro-cross /var/cache/portage/local /var/cache/portage/overlays/enlightenment /var/cache/portage/overlays/kde /var/cache/portage/overlays/sunrise /var/lib/g-ctan" […] Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 326988 [details] rc.log
Same here: http://forums.gentoo.org/viewtopic-p-7167140.html#7167140 Att
Upgrading from openrc-0.11 to openrc-0.11.1 don't solve the problem, but downgrading to openrc-0.10.5 yes. ---
I confirm this bug. When I open konsole/yakuake I see… nothing, no prompt. After downgrading to openrc-0.10.5 I can login again.
(In reply to comment #4) > I confirm this bug. When I open konsole/yakuake I see… nothing, no prompt. > After downgrading to openrc-0.10.5 I can login again. I do not even get that far - I cannot login into KDE at all. I think the issue you are seeing might be another openrc-0.11 bug #438932.
I have similar problems with openrc-0.11 : My /home is a NFS-share. openrc-0.11 does not mount /home. I use NFSv4-Protocol for that. Result is: I can not log in as user. My second system is completly based on NFS (diskless, gPXE, tftp,...). The Kernel-Mount of / works (NFSv3), but openrc-0.11 does not mount my /home and other NFS-shares. Downgrading to openrc-0.10.5 solved the problem on booth systems. I have no idea how to debug the problem with openrc-0.11...
(In reply to comment #6) > I have similar problems with openrc-0.11 : > My /home is a NFS-share. openrc-0.11 does not mount /home. I use > NFSv4-Protocol for that. Result is: I can not log in as user. Since version 0.11 OpenRC does not longer mount NFS shares in the netmount init script. Instead you need to enable the nfsmount init script from the nfs-utils package. (See bug #427996 for the reasoning.)
Please follow the instructions in bug #438932#C24. with regard to the nfs systems not booting, you must add nfsmount to your runlevels. Let me know if that fixes your issues.
Such important changes in behaviour of openrc should be announced. Perhaps "eselect news" is a good place. A version bump from version 0.10.5 to 0.11 should not make a gentoo system unusable! If you do not stop this kind of chaos programming, I will write my own init script! ;-) Greetings
I have the same problem here, and following bug #438932#C24 did not solve it. i.e. I have : - openrc-0.11.1 - udev-init-scripts-17-r1 and I have done rc-update add udev sysinit rc-update add udev-mount sysinit
(In reply to comment #9) > A version bump from version 0.10.5 to 0.11 should not make a gentoo system > unusable! > If you do not stop this kind of chaos programming, I will write my own init > script! ;-) Since the situation annoys me, too, for quite a while, and "stop it" is not just that easy, I created bug #439136 as a proposal for OpenRC beta testing. If it is accepted, we could need some volunteers...
What I think might be most interesting is who outputs '"System' and why. (In any case this message should be fixed to be complete, so future issues can be debugged more easily.) Can the login process be straced? (strace -i -ff -o /tmp/login <...> ?) Maybe we can figure out this way which PAM module (I expect it to be a PAM module) is responsible and why.
(In reply to comment #9) > Such important changes in behaviour of openrc should be announced. > Perhaps "eselect news" is a good place. > > A version bump from version 0.10.5 to 0.11 should not make a gentoo system > unusable! > > If you do not stop this kind of chaos programming, I will write my own init > script! ;-) @Mario: Dennis is correct. This kind of approach isn't going to help anything. I also suggest you go over to bug #439136 and provide input on how we can improve things.
Someone just pointede something out to me about systemd's tmpfiles on #openrc. Do you have a file called /run/nologin on your box?
Do you have systemd installed?
Dennis, I need you to test with openrc-9999 asap if you are comfortable doing that. If not, I need you to apply the patch in commit 74b655. I need to know if that fixes your issue.
I verified with Dennis that commit 74c6b5 fixes this issue. This will be released in openrc-0.11.2 and carried to 0.12.
*** Bug 439024 has been marked as a duplicate of this bug. ***