My openSuse 13.1 is lately not showing me a login screen, but simply stops at the Chameleon. Pressing F2 produces several pages of status updates, ending in
OK ] Reached target Multi-User System
OK ] Reached target Graphical Interface
Looks fine, but no login screen.
Swtiching to tty5, and logging in as root, then running startx gives me a KDE session running as root, but again with no login screen, and leaving the KDE session drops me back at the commandline, with no X server running.
I’m by no means an expert on X configuration but I have not found any errors in /valr/log/Xorg.0.log
I have tried uninstalling the proprietary FGLRX driver (suspected Kernel update problems at first), but whether or not I use FGLRX does not change the main problem – the state described above is independent of whether I’m running fglrx or not.
Booting in recovery mode, or using an earlier Kernel version, produces exactly the same behaviour.
The only thing I’ve found so far is this line in the boot messages:
DEPEND] Dependency failed for LSB: X Display Manager
… could this be some indicator? X seems to work when asked nicely, but I don’t know what LSB is. There’s a package called LSB, which was not installed. Installing it did not fix anything.
Any comments welcome. In the short term, it’d be enough if I could just run KDE as regular user using some workaround – the machine needs to be updated anyway but I must get some work done first.
Some service that is required by the Display Manager (login screen) failed to start, so the Display Manager won’t start either.
I suppose running “systemctl restart display-manager” (as root) should work and give you a login screen, rught?
The likely candidate is the remote-fs.service, i.e. what mounts remote file systems that are specified in the /etc/fstab.
To fix it, remove the offending network share from /etc/fstab or add “nofail” to the mount options.
2: I did not expect failed network mounts to prevent the display manager from running. Why would that be a thing? I’m fairly certain that it did not use to be like that. I’ve got a lot of mounted network drives, and every time IT reconfigures anything, they fail – but I have run this machine for a few years without getting stuck this way.
3: I simply commented two of the shares out this time – I suppose I’d have to simply add “nofail” to the fstab mount attributes?
Well, you are not the first one who had this problem on 13.1…
2: I did not expect failed network mounts to prevent the display manager from running. Why would that be a thing?
Because /etc/init.d/xdm specifies that it requires $remote_fs.
AFAIK it does so because /usr/ may be mounted via NFS.
It was quite common for services in earlier openSUSE releases to have such a dependency.
I’m fairly certain that it did not use to be like that.
There hasn’t been a change to xdm/the displaymanager service.
But IIRC there was a systemd upgrade some time ago (systemd was updated in 13.1 to the same version that 13.2 has), that may have changed the exact behavior.
That was about two years ago I think though.
I’ve got a lot of mounted network drives, and every time IT reconfigures anything, they fail – but I have run this machine for a few years without getting stuck this way.
3: I simply commented two of the shares out this time – I suppose I’d have to simply add “nofail” to the fstab mount attributes?
Yes, “nofail” means that the system should ignore it if the mount fails.
Or use other means to mount them.
I cannot really help you with that, but autofs is probably the best way.