Hi, I would like to know the best way to disable any desktop environments and default to running a more server like env. The systems already has KDE on it but I am moving it to the basement and no longer need a GUI, please advise the best way. I know going to runlevel 3 will work, but I think that when you do a clean install and select command line only instead of a DE the result will still boot to run level 5 but just has no GUI.
Running 13.1 BTW
No, when you install a text only system, it will boot by default into runlevel 3. Obvious, because everything that should be started to get runlevel 5 is not installed and it will generate a lot of problems when the system would try to go to runlevel 5.
And you can of course switch your boot configuration so that it will start into runlevel 3 by default. Only thing is that I am a bit retared here. I could tell you prefectly how to do that in a sysvinit system, but not in a systemd environment.
I assume that YaST > System > Bootloader and then clicking BootLLoader Options and then adding something to the Optional Kernel Command LIne Parametr field would do it. Try adding a 3 there.
When that works, do the same with the Failsafe field below it, but not before the standard one is OK.
On 2014-05-19 21:16, miked63017 wrote:
>
> Hi, I would like to know the best way to disable any desktop
> environments and default to running a more server like env. The systems
> already has KDE on it but I am moving it to the basement and no longer
> need a GUI, please advise the best way. I know going to runlevel 3 will
> work, but I think that when you do a clean install and select command
> line only instead of a DE the result will still boot to run level 5 but
> just has no GUI.
If you boot to run level 3, there is no GUI started, as simple as that.
You don’t need doing else.
Look at the directory “/etc/systemd/system”, there is a symlink named
“default.target”. It normally points to
“/usr/lib/systemd/system/runlevel5.target” or to
“/usr/lib/systemd/system/graphical.target”.
You now know what do now to change to boot on text mode 
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
That is the better sustemd explanation I was looking for.
Yes, either runlevel3.target, which is a link itself to multi-user.target. And that what the OP wants IMHO.
Even better:
To find out what target is set as default:
systemctl get-default
To change the default target to text mode:
systemctl set-default multi-user.target
Or just use YaST->System->Services Manager. (this has a text mode interface as well)
On 2014-05-20 12:46, hcvv wrote:
> That is the better sustemd explanation I was looking for.
> Yes, either runlevel3.target, which is a link itself to
> multi-user.target. And that what the OP wants IMHO.
He, there is a new command somewhere, which I forgot the name, that does
the switch fast and easy. Maybe someone remembers.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
On 2014-05-20 12:56, wolfi323 wrote:
> Even better:
> To find out what target is set as default:
>
> Code:
> --------------------
> systemctl get-default
> --------------------
>
>
> To change the default target to text mode:
>
> Code:
> --------------------
> systemctl set-default multi-user.target
> --------------------
THAT one! That’s the command I was talking about but could not remember.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
And I was fiddlinng around in YaST > System > Bootl;oader, where I should have advised YaST > System > System services (runlevel).
Thanks wolfi323 for all the different ways to do the same.
No.
That old module only allows to set the runlevel when /etc/inittab exists (it was designed for sysvinit, not systemd). But this file does not exist any more since 12.3, because systemd doesn’t use it anyway.
You have to use the new (in 13.1) YaST->System->Services Manager, as I wrote.
If you upgraded your system to 13.1, you might have to install it manually though. The package is called “yast2-services-manager”.
The name may have changed a bit, but I assume that it will be clear what item to click when you are there.
In any case, many people will see other languages, thus a general “pointing to” will do the trick IMHO.
No, it’s not just that the name has “changed a bit”. It’s a completely new module with a completely different name.
And the old one is still available (especially if you did an upgrade to 13.1), so pointing to “YaST > System > System services (runlevel)” is completely wrong as well.
Again, “YaST > System > System services (runlevel)” DOES NOT ALLOW YOU TO CHANGE THE RUNLEVEL on 12.3 and 13.1. (unless you create /etc/inittab manually or copy it from an earlier version)
I have “Servicesbeheerder” and that is the only one that comes near both of the names you cite. For the YaST GUI users they are not modules, that is something that is hidden from such a user. They are just features to click.
That’s the new one, “Services Manager” in english.
The one that you mentioned (“System services (runlevel)”), is called “Systeemservices (Runlevel)” in dutch.
Here’s a screenshot:
http://wstaw.org/m/2014/05/20/yast.png
Do you still think that it’s ok to point to “System services (runlevel)”? 
For the YaST GUI users they are not modules, that is something that is hidden from such a user. They are just features to click.
Ok, but still they show the name next to the icon, and the name is actually the only way to distinguish them.
And as I said, there are two different “features to click”. One that works and one that does not work. You pointed to the one that does not work.
I think it is a bug when you have those two.
I do not have them. Why should I have a defunct entry?
I did not say you should have it, but it is still available in 13.1. So you (or anybody) might still have it.
If you upgrade to 13.1 it would not get uninstalled automatically AFAIK.
And it’s not a “defunct entry”. It’s the old sysvinit runlevel module, that doesn’t fully work any more with systemd (on 12.2/12.3 already).
You can still enable/disable/start/stop services. And with an /etc/inittab, also setting the default runlevel works.
But again, for systemd a completely new module has been written (Services Manager) which is first available in 13.1 and is designed especially for systemd of course.
But why is it a bug?
Those are two independent modules. If I install both, I should have both.
Anyway, my main point is, that “System Services (Runlevel)” (which you came up with) is the wrong one, you have to use “Services Manager”.
On 2014-05-20 15:36, wolfi323 wrote:
> And it’s not a “defunct entry”. It’s the old sysvinit runlevel module,
> that doesn’t fully work any more with systemd (on 12.2/12.3 already).
> You can still enable/disable/start/stop services. And with an
> /etc/inittab, also setting the default runlevel works.
>
> But again, for systemd a completely new module has been written
> (Services Manager) which is first available in 13.1 and is designed
> especially for systemd of course.
We have both modules because a) the old module still works, somehow, and
b) the new module is not complete yet. It is new, and the yast devs
probably thought best to leave both modules, so that if you need
something it should be in one or the other module.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
I do not have both items and I did nothing special to get rid of the old one.
If you installed 13.1 fresh, the old “System Services (Runlevel)” module WILL NOT get installed by default.
Only the new “Services Manager”.
Which means that
the yast devs
probably thought best to leave both modules, so that if you need
something it should be in one or the other module.
is futile, because then both modules would be installed with a 13.1
Why?
There’s a difference between not installing a module by default and removing/dropping a module.
And there are a lot more modules that are included in the distribution but not installed by default.
Maybe one wanted to still use sysvinit? In that case the new module would not work at all obviously, you would need the old one.
But maybe they just forgot.
Well, if you think it’s a bug, file a report.
But that would be futile actually: the module cannot be removed for 13.1 any more anyway as that is released already, and it doesn’t exist any more in Factory.