Using opensuse 13.1. Anyone else have this issue?
Hi
Not here, anything of note in the gdm logs in /var/log/gdm?
On Tue, 19 Nov 2013 21:46:02 +0000, ryanbach wrote:
> Using opensuse 13.1. Anyone else have this issue?
Can you define “broke” more precisely?
It also would be useful to know what media you installed from, if you did
an in-place upgrade or a fresh install - that would help us diagnose the
issue you’re seeing.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Yes, I’m having a problem too.
Installed 13.1 64 bit from DVD ISO via USB. Fresh install, disk formatted. KDE with volume and encrypted, separate home partition.
Install went fine. Rebooted. Lack of graphical prompt for bootloader password (see http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/491969-plymouth-not-showing-graphical-luks-password-screen.html) combined with some mei_me warnings (see https://bugs.archlinux.org/task/36288) caused me confusion, but after I entered password and hit return it proceeded OK. Loaded last part of install into YaST went OK. Then used KDE for setup & additional package installation. Then rebooted voluntarily, it loaded to login screen (I believe this is gdm) as normal. However, once I enter correct password on login screen, login boxes close but then system sticks on black background with the green lizard on the side, and KDE does not load, even if left for several minutes. No disk activity noticed. System has not crashed, can switch via Ctrl+Alt+F1 and do console login as normal. However startx command just hangs as well, even if done as root. Have now rebooted a few times, happens each time.
I don’t have the file /var/log/gdm. I had a look in /var/log/messages and there is “systemd” “Failed to open private bus connection: Failed to connect to socket /run/user/1000/dbus/user_bus_socket: No such file or directory” Nothing else looks like an error.
So effectively only have console login to 13.1 system (am posting this on another machine).
Hi
Unfortunately KDE doesn’t use gdm, it uses kdm. Can you please start a new thread with you issue. Once that’s done I will remove this wayward post 
On Wed 20 Nov 2013 09:16:01 PM CST, ryanbach wrote:
Posting 0.log:
‘pastebin - Miscellany - post number 2477585’
(http://pastebin.ca/2477585)
Hi
So was this an update? Seems your running the fglrx driver (which isn’t
working)?
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLED 11 SP3 (x86_64) GNOME 2.28.0 Kernel 3.0.93-0.8-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Seems that ryanbach upgraded without re-installing fglrx. I always use the “generic” install of the driver, which requires uninstall and re-install after each “major” kernel upgrade. If not done, I get similar symptoms. The system tries to load fglrx, but it fails. Much more information is needed, such as details of the install or upgrade, and a much better description of the symptoms.
rjwilmsi may have a different problem. It appears that your graphics settings or driver may be to blame. Have you tried booting into failsafe mode? Did you change the graphics settings during your first and only KDE session? What additional packages did you add? What happens if you use the command “kdm” rather than startx once logged in at the console?
First, lets verify what display manager you are using. If it was a fresh install, it’s difficult to believe that gdm was set as display manager if you installed KDE as a window manager. I’m assuming that you don’t have a console type of editor since the ones that I use are not installed by default. Type “sudo zypper install pico” after you log in at the console, and give the root password. Once installed, run “pico /etc/sysconfig/displaymanager”.
At about line 15, you will see “displaymanager=”. It will most likely show either kdm or kdm4. If it really does show gdm, then it should be changed to kdm if you plan to keep using KDE. CTL + X is used to close the editor. If you made changes, it will prompt you to save them. Just hit “y” to save it and hit “enter” to save it as the original file name.
Run “hwinfo --framebuffer” to verify what your graphics are capable of. Please note some of the modes for the higher resolutions.
To verify what your default graphics setting is, you can run “pico /etc/sysconfig/bootloader”. At about line 46, you will find “default_vga=”. If the default vga setting is not among the possibilities shown from the previous command, then it should be changed.
If working from the console is uncomfortable for you, you can always run “yast2” at the command prompt. That will open yast with a keyboard only type of graphical display.
I think rjwilmsi failed to click on a user name (or to type in a user name) on the “kdm” login screen. So he is entering a password, but the system does not know for which user the password is being entered.
I rebooted and tried to log in without a user name and only my password. I got a very clear login failure message and the login boxes remained on the kdm screen. I only tried it once, though. If I remember correctly, you have three tries to login before the system locks you out, although I’m not positive about that. Possibly he had the problem after 3 tries?
I’ve been using SuSE and openSUSE since 8.3 and I don’t remember ever having “X” hang when the window manager tries to start, as he describes. kwin has always either crashed and taken me back to the login screen, or “X” crashes completely and leaves me with a flashing cursor on a blank screen.
Well, I was incorrect about being locked out after 3 tries. I entered password without user name 6 times and was always given another chance to log in. I then did a correct login on the 7th try and got into the system.
Thanks for the replies. I think my issue was this in the end: my test laptop (ThinkPad X61T) had Intel AMT enabled in the BIOS. I don’t use this feature but it was enabled by the previous owner I suppose. Having this enabled meant that during boot warnings/errors relating to mei_me (a kernel feature/module relating to AMT I believe) were written out every few seconds, Googled it and found various threads about it. This probably happened on 12.3 as well, but I didn’t notice. Only reason I noticed was that with encrypted disk turned on, and no GUI password prompt due to plymouth problems (see other threads here), the password prompt came up but mei_me lines continued to be written. It was still possible to enter the encryption password, but confusing. So I disabled AMT. Then the system wouldn’t get past the login screen, tried all sorts of combinations, failsafe and startx/startkde and switching runlevels.
I reinstalled 13.1 with AMT disabled from the start and now the system is fine.
So my conclusion is that disabling AMT on an installed system doesn’t work. Perhaps you have to blacklist/disable a kernel module if you’re going to do it. Having reinstalled successfully it doesn’t matter.
The X61T is my test system so I’ll be proceeding to upgrade my travel laptop this weekend.
Thanks
Good that you figured that out. I have never heard of Intel AMT and had to look it up. I’ll have to remember that for future reference. Good luck with the main laptop.
The problem with Plymouth is being should be addressed before long. It is broken by design. There is a problem with getting the password box to work correctly when an encrypted root volume is used. They intentionally left it out of the initrd until that problem is fixed.