I occasionally want to login via a console rather than via the GUI (ie. Alt-N from the GUI, login to a command prompt, do some work, then startx to start KDE).
Everything is fine in KDE when I do this apart from the network connection. KNetworkManager will not connect to my wireless (or even list the network) when I login via the console. But with a GUI login of the same user, everything is fine. I’m using KDE3.
There are some errors in /var/log/messages, which may be a clue:
I am trying to reconstruct what you are doing. openSUSE 10.3 and KDE 3.5 here. These are my observations.
I tried ALT-N in the GUI. Nothing happened!
I tried ALT-N from the kdm login screen. Nothing happened.
I looked in the System menu of the kdm login screen. It has: ‘Console login Cntrl-N’. It this what you mean?
I used it and the console was shown. A CNTRL-ALT-F7 did not show the kdm login screen so I suppose that X it is killed, but I do not know in which runlevel we are now.
As you say you use startx, I suppose you log in as root. I did. I used startx. I then reached a GUI loged as ROOT. THIS SHOULD NEVER BEEN DONE! I killed this asap with CNTRL-ALT-BS. Back in the console CLI I used
To get my kdm login screen again.
End of test.
I am not sure I did exactly what you do, but this would not be my method. When I would feel need to use the console CLI (as user or as root) I would use CNTRL-ALT-F1 (from the KDE GUI or from the kdm login) to go there.
After finishing there I would use CNTRL-ALT-F7 to go back too the GUI screen.
When running in the console CLI and need arises to have the whole X shut down I would (as root) use
to switch the GUI of and
to go back to normal.
As the above observations contain nothing about your networkmanager problem, you may be disapointed with my reaction. But I think that it is possible that the fact that killing your kdm might be done going to runlevel 3. Your startx would not restore runlevel 5 then. As a consquence knetworkmanager may not want to start the network (a lot of may be’s here).
Maybe my method of working may fit your needs and also solve your problem.
I think they’ve changed the method of getting from the GUI login to a console from CTRL-N (10.3) to Alt-N (11.1), but yes, this is what I’m trying to do. The GUI login re-appears (sometimes…?) after a short delay when you logout, yes. Strictly, I don’t think this is changing the runlevel.
I would (typically) login as myself from the console, not root. It lets me run things with minimal other processes running, for example.
So the X session I’m subsequently trying to start with startx should be the normal one for my user. I was expecting everything to run as normal - but networking doesn’t.
I should have mentioned I’m on SUSE 11.1, and KDE 3.5, sorry.
The GUI login re-appears (sometimes…?) after a short delay when you logout, yes
As i did not do it to often, my idea that it does/does not re-appear using root/norml user may be a wrong interpratation on my side.
And I agree that no runlevel change is involved.
Talking about your knetworkmanager problem. I do not know what the usage of the system is. But I found out that many people use knetworkmanager (which connects to the network when a user logs in) instead of the normal/traditional method of using the startup scripts (using ifup) on reaching runlevel 3. The knetworkmanager method is for laptops that travel around and use wifi connections found on the spot. The traditional method is much better for servers, desktops ad laptops that are only using the same network all the time. You willl then have your network also when the GUI is not running.
You guys and girls are missing something: if you let the Networkmanager do the networking, the connection is made after logging in to the desktop. So, if you login to the desktop, wait for the connection to be established by the networkmanager, you can hit Ctrl-Alt-F1 to enter the console, and you will have networking.
If you want the networking started at boot, you’d have to configure networking with if-up. This way you can have any networking started at boot, being available at the login-screen.
But, if you’re on a laptop, that you’re willing to connect elsewhere, you should use the Networkmanager.
TIP: ever considered using yakuake? It’s a full featured terminal app, that even keeps running when plasma crashes…so you can restart plasma, by just hitting F12 (or the key defined to open yakuake) and typing: plasma. I’ve been using it since it’s first beta’s. And, since it runs on the desktop, networkconnections are available.
I can see what I’m doing is a little unusual. Perhaps using ifup/down is the way to go - I’ve used this in the past, but as the machine is a laptop I thought it would be more useful to have the flexibility of connecting “on the road” easily.
I appreciate that I can CTRL-ALT-F1 after the desktop has established the network to get to a console, but for certain tasks I want the machine as quiet (and RAM as empty) as possible, so the runlevel3-like feature of a console login via ALT-N is very useful. Switching to a console from the GUI has the whole of X and KDE running in the background still.
I’ll have a look at cnetworkmanager, thanks.
Am I wrong to think that this “should work” though? I wonder what’s different about starting KDE via kdm compared to via startx, as far as NetworkManager is concerned?
nick battle wrote:
> Akoellh;1962453 Wrote:
>> It should, but I just tested it and it doesn’t, no interfaces are
>> available in knetworkmanager although NWM, dbus and hal are running.
> Thanks very much for confirming this isn’t just me!
> Do you think it’s worth raising a bug, or is it too obscure to really
> matter? Very low priority perhaps?
There is a bug already posted - #486267.
In fact, we think we have the reason that some systems fail, and others work the
way they should.
Please check your system for the presence of a directory named
nick battle wrote:
> lwfinger;1962486 Wrote:
>> Please check your system for the presence of a directory named
> Hi Larry. Unfortunately that directory doesn’t exist. I just have two
> sub-directories in /var/run/dbus/at_console:
> drwxr-xr-x 2 root root 4096 2009-03-14 11:07 linux
> drwxr-xr-x 2 root root 4096 2009-03-24 17:17 nick
> The linux sub-directory is empty (created at install by the look of the
> date); nick has a sub-directory called Session1, but that is also
Does deleting the linux directory help? It should not be there.
I have very simmilar thing but does not depend on console login…
My knetworkmanager does not work all the time… shows available networks but when i click on one of them “nothing” happens, I’ve tried cnetworkmanager and it complains about not being able to connect to networkmanager because another process is “using it”. quote form console:
cnetworkmanager 0.8 - Command Line Interface for NetworkManager
Could not provide settings service, another applet is running (pid 4095)
this pid 4095 happens to be kded4 process. if i kill and restart kded4 and then restart knetworkmanger or cnetworkmanager everything works ok… it must be some bug in kded4… or settings or something… i don’t know how/where to dig to find out more…
The d-bus configuration of networkmanager is so that the user must be considered to be “at console” to be able to use it. The misunderstanding is that “at console” means in fact “sitting in front the computer” and this is something which is set by the graphical login but not by a login at the “console”. This is handle by the ConsoleKit package.
Just add the following line to your /etc/pam.d/login file :
session optional pam_ck_connector.so
after that when login at the console you will be considered to be “at console” by dbus, then if you startx and launch knetwormanager it will work.