I have opensuse 13.2 with gdm display manager (kdm was installed, but was not used). After upgrade to 13.2 I wanted to switch to kdm. I made necessary changes to /etc/sysconfig/displaymanager and /etc/sysconfig/windowmanager files. After reboot kdm was displayed properly, as expected. But after second reboot I was brought back to gdm. I noticed the shutdown is required, not software reboot.
start with GDM
edit displaymanager (DISPLAYMANAGER=“kdm”) and windowmanager
shutdown / cold start
system started successfully with KDM
look at displaymanager => DISPLAYMANAGER=gdm
shutdown / cold start
system started successfully with GDM
The modification time of /etc/sysconfig/displaymanager shows that modification was made during system boot. Does anybody know what application modifies the configuration file and how to prevent them from unattended modification at boot time?
Apparmor is not installed. Yes, it looks like modification occurs during boot (but after X start) because system started with KDM successfully one time, and the modification time confirm that. I will check for any scripts…
On 2015-01-09 20:56, inok wrote:
>
> Hello!
>
> I have opensuse 13.2 with gdm display manager (kdm was installed, but
> was not used). After upgrade to 13.2 I wanted to switch to kdm.
The correct procedure should be:
log off graphical session
switch to text mode (ctrl-alt-f1)
close graphical mode (init 3)
edit /etc/sysconfig/displaymanager, using joe or vi, or mcedit if
installed.
restart graphical mode (init 5)
and you should have the new display manager running, without rebooting.
> The modification time of /etc/sysconfig/displaymanager shows that
> modification was made during system boot. Does anybody know what
> application modifies the configuration file and how to prevent them from
> unattended modification at boot time?
I don’t know what would do that change or why.
Maybe something inside gnome would want gdm running, but the change
would not be done at boot, and it would be very impolite to revert an
administrator choice.
Maybe some systemd configuration was not remade. Try the way I described
above.
The trick to prevent an unknown program from changing a particular file
is to block the action with apparmor, or make it report the action, as
wolfi323 mentioned. I can dig out the details from my notes if you want.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I think I found the problem. There was the following strings in the /etc/init.d/boot.local file:
if cat /proc/cmdline | grep -q kde; then sed -i -e "s:^DEFAULT_WM=.*:DEFAULT_WM=kde4:" /etc/sysconfig/windowmanager
sed -i -e "s:^DISPLAYMANAGER=.*:DISPLAYMANAGER=kdm4:" /etc/sysconfig/displaymanager
else
sed -i -e "s:^DEFAULT_WM=.*:DEFAULT_WM=gnome:" /etc/sysconfig/windowmanager
sed -i -e "s:^DISPLAYMANAGER=.*:DISPLAYMANAGER=gdm:" /etc/sysconfig/displaymanager
fi
When I commented them out, the problem disappeared. This is a quite strange code: why should /proc/cmdline contain kde substring?
/proc/cmdline would contain any option you add to the kernel command line.
This script would make it possible to specify the DISPLAYMANAGER and the DEFAULT_WM to be used via the kernel boot options, e.g. you could create different boot menu entries that boot to kdm with KDE as default and gdm with GNOME as default respectively. I.e. that script will set it to GNOME/gdm unless you specify “kde” at the kernel command line.
Btw, that DEFAULT_WM=kde4 is incorrect and won’t work. It should be DEFAULT_WM=kde-plasma since years…
The code itself I do not find strange. But it is strange that it is even there!
This is definitely not the case by default. The shipped boot.local looks like this:
#! /bin/sh
#
# Copyright (c) 2002 SuSE Linux AG Nuernberg, Germany. All rights reserved.
#
# Author: Werner Fink, 1996
# Burchard Steinbild, 1996
#
# /etc/init.d/boot.local
#
# script with local commands to be executed from init on system startup
#
# Here you should add things, that should happen directly after booting
# before we're going to the first run level.
#
I.e. it is practically empty.
But as it is a “config” file, it is not changed/replaced on updates/upgrades, and that wouldn’t be a good idea anyway.
Yes, to add /sbin and /usr/sbin to the path if wanted.
But boot.local never was created or changed by any YaST module AFAIK.
And this particular script doesn’t make sense as a general distribution-wide solution anyway, as it only takes gdm/GNOME and kdm4/KDE4 into account. I doubt that something like this ever was shipped in openSUSE. openSUSE always supported more than GNOME and KDE4…
On 2015-01-10 17:36, wolfi323 wrote:
>
> robin_listas;2688327 Wrote:
>> You can also run “rpm -qf /etc/init.d/boot.local”, The response should
>> be “file /etc/init.d/boot.local is not owned by any package”.
>>
> Actually it is owned by a package:
Not in my system. The sentence above is the actual result I get.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
That file is created by the postinstall script of the aaa_base package since 12.3 with the content I posted (if it doesn’t exist already, or doesn’t contain any actual commands). No idea what package created it on 12.2 or earlier (or whether it was created at all), it’s not done by aaa_base there.
I just looked and indeed, in 13.1 and 12.3 the aaa_base package doesn’t actually own the file. Could be seen as a packaging bug I suppose.
It is owned by aaa_base on 13.2 though, and the OP uses 13.2…