core/hybrid hanging on ctrl-alt-fx keys - can't get back to ui

[jamo]

Has anyone else had this problem with MDs or hybrid/cores. My core is running UI1 because I'm planning for it to sit in the closet when I'm done setting up and not bothering with NVidia on this machine if I can avoid it....

That said, all seems to run ok until I try to switch out of the UI-

Either to get to command line via ctrl-alt-f2 or whatever or if I start the KDE desktop. In either case, I don't seem able to get back to the Orbiter UI.

Actually, I think they're different issues:

If I go to KDE desktop, the machine seems to carry on running OK but I can't get back to the UI. I've tried:

• Clicking on the "Orbiter renderer" in the taskbar but nothing happens
• Logging out of KDE - but then I just get to the KDE login screen
• ctrl-alt-fx
• but then I end up with the problem below:
  

If I go from the UI to a tty, using ctrl-alt-fx key, I can't get back to the UI. As soon as I hit ctrl-alt-f7 I see the UI but it has some blurred stripes at the top and the machine appears to hang. At that point nothing but a hard power-off works... I think, though I haven't tested extensively yet, it even stops functioning as a router/dhcp server etc.

I will investigate further but has anyone had these issues?

[klanmce]

Not sure if you tried this, there suppose to be an desktop link, that relaunches the orbiter.

On my system, its on the top left hand corner.

[jamo]

Not sure if you tried this, there suppose to be an desktop link, that relaunches the orbiter.

On my system, its on the top left hand corner.

Thanks for the tip. I think I did and got the bouncing gear for a bit and then nothing. At first I was mighty nervous to click that link because it looked a lot like the original install link! I will check again when I get home, and perhaps have a look at the code it runs and see what it is supposed to do as well.

[jamo]

More on this-

Ctrl-alt-f2 to go to terminal, followed by ctrl-alt-f7 shows frozen ui with some interference lines across top and machine (core) is well hung 

From KDE-desktop, I tried the "Activate orbiter" application and the bouncing gear runs for a bit and then nothing changes. I had a little look at the script behind it and also tried running that from a kde terminal command line and also, nothing happens. Will search the forums a bit to see if anyone else has had this and maybe try to debug a little.

[jamo]

And more... so the shortcut is supposed to run

/usr/pluto/bin/ActivateOrbiterFromKDE.sh

Which it does for me but that, in itself, doesn't do anything on my system. So I guess I need to get to the bottom of that. I guess I can first try the manual way as outlined below....

No. but you can send a message to the media director device (for the core/hybrid, this is 1):

/usr/pluto/bin/MessageSend localhost 0 X 1 912 119 "0"

replace X with the PK_Device # of the Media director.

-Thom

and if that works then I know the problem is in the above script trying to figure out the right message and can debug from there.

[jamo]

Still have this issue with my core- Just had the motherboard replaced so I had a screen and keyboard attached to check all was hunky dory (and reset the motherboard SATA setting to AHCI) and I tried to ctrl-alt-f2 to get to command prompt (works) but then when I ctrl-alt-f7 to get back to on-screen orbiter, it appears hung. Can't ctrl-alt-f2 or anything.

See attachment for pic of hung orbiter. Mouse pointer doesn't move and there is sort of a stripe across the top of the screen.

How do I trouble-shoot this?

It is important to be able to get to the command prompt if things go dodgy on the graphical ui, surely? In fact, the way I came across this problem was when I tried playing a video and found I couldn't stop -ie no response to keyboard or mouse and no remote control onscreen.... so I hit ctrl-alt-f2 to see if that would give command prompt... it did but ctrl-alt-f7 took me back to video with the stripe across the top and, in fact, crashed the hybrid.

Ouch.

I'd welcome suggestions for troubleshooting/debugging.

My next step is to try to ssh in from another machine so I can look at logs, processes etc.

[jamo]

My next step is to try to ssh in from another machine so I can look at logs, processes etc.

Ok, did that and started the video playing. Checked the tail of Xorg.0.log and it basically had a series of

select returned 1
select returned 1
select returned 0
select returned 1

Presume that's normalish?

Then, ctrl-alt-f2 to get to command prompt. Checked Xorg.0.log:

select returned 0
select returned 1
select returned 1
select returned 1
select returned 0
GetModeLine - scrn: 0 clock: 0
GetModeLine - hdsp: 1024 hbeg: 0 hend: 0 httl: 0
              vdsp: 768 vbeg: 0 vend: 0 vttl: 0 flags: 0
GetModeLine - scrn: 0 clock: 0
GetModeLine - hdsp: 1024 hbeg: 0 hend: 0 httl: 0
              vdsp: 768 vbeg: 0 vend: 0 vttl: 0 flags: 0
GetModeLine - scrn: 0 clock: 0
GetModeLine - hdsp: 1024 hbeg: 0 hend: 0 httl: 0
              vdsp: 768 vbeg: 0 vend: 0 vttl: 0 flags: 0

---
Not sure what that means?

Then, pressed ctrl-alt-f7 to get back to X and the last bit of video screen showed, but frozen, my ssh session on remote machine stopped working and the core rebooted about 10s later.

Next step- try the same but directly from the on-screen orbiter without launching video first.

[DragonK]

Hey Jamo,


Just a thought... You mentioned that you replaced the Motherboard.... did you replace the ram to?

Karel

[jamo]

Next step- try the same but directly from the on-screen orbiter without launching video first.

Pretty much the same thing- only difference is that the tail of Xorg.0.log doesn't change from

select returned 1
select returned 1
select returned 0
select returned 1

when you hit ctrl-alt-f2.

When you hit ctrl-alt-f7, it shows the hung orbiter as attached before and machine seems hung - ssh session unresponsive.

So the conclusion is that ctrl-alt-f2, ctrl-alt-f7 hangs the machine. Perhaps I should search for something similar in kubuntu if it has not come up for others in LMCE.

[jamo]

Hey Jamo,


Just a thought... You mentioned that you replaced the Motherboard.... did you replace the ram to?

Karel

I didn't, but this is actually not a new problem (I don't think)- I think it has always existed but because my core is just that (not really a hybrid) I have never bothered because I don't really need to tinker on it... as long as it does its core stuff the video issues aren't important because it sits in the server closet. But I think I have similar things on my MDs and they may be related... one of the reasons I'm trying to get to the bottom of it now.

[jamo]

Well.... maybe it's an Xorg thing with my hardware -

http://www.linuxquestions.org/questions/debian-26/screen-freeze-when-back-from-ctrl-alt-f1-to-f7-413553/

Maybe I should try 10.04 while I'm still in the experimental phase.

[DragonK]

I've had fairly good succces with 1004.

[l3mce]

Well... I don't know why you would switch tty's on an MD in the first place... they are useless as you will not have a password to supply it. If you have forced a password on it, then it is broken... and this behavior is likely due to this.


Switching between desktop and orbiter is glitchy on the whole. I plan on fixing this in short order.

[jamo]

Well... I don't know why you would switch tty's on an MD in the first place... they are useless as you will not have a password to supply it. If you have forced a password on it, then it is broken... and this behavior is likely due to this.


Switching between desktop and orbiter is glitchy on the whole. I plan on fixing this in short order.

Good questions:

Why switch to a tty?
A number of reasons, primarily to get to the command line to do stuff like lspci, check the logs, run diskless_create etc etc? Sure, I wouldn't want to do it as part of my home-automation and media watching activities but when getting things set up and figuring out why stuff is/isn't working the command line is essential to me. Most often, I'd use it as a route to ssh onto the core (dcerouter). Mine sits in the server closet and has no screen or keyboard so if I want to go command line, I go via a media director.

How to log in?
If I recall (my system is semi broken at present as the mobo replacement changed the ethernet NIC and I'm having some issues there), I just log in with my username/password that I created during the install process. Then when I hit the command line I usually ssh to dcerouter. I haven't forced any passwords, anywhere, I promise. I will confirm that this is how I log in when it is up again. Are others not able to do this? Is it unusual? How does everyone else access dcerouter if it is a headless core?

Glitchy desktop/orbiter switching
Many thanks for addressing this. It will help me a lot. I generally don't go to the KDE desktop partly for this reason and partly because I think some of my MDs are quite low spec so they're fairly slow running it... which is why I prefer to hit the tty command line.

Thanks for the response l3mce, I appreciate all the input and if I'm fighting the system by all means let me know....

[EDIT]: Oh, I forgot, the reason I wanted to go to command line on the CORE was because I had my core at work plugged into a keyboard/mouse/screen because I was setting up the BIOS after the shop replaced the motherboard.... so I thought I'd fire up a video and see how it played. The video played but I had no way of stopping it. I couldn't bring  up the on-screen orbiter - no mouse or keyboard events seemed to be responsive and because it wasn't plugged into my network, I had no other orbiters to control it so in desparation I hit ctrl-alt-f2 to get to the tty and I thought maybe just switching back to the X-session would bring up the orbiter. Nope.

[DragonK]

How does everyone else access dcerouter if it is a headless core?

I use "putty" to ssh from my work laptop (MS Windows OS) into my core, when I'm at home and need todo updates and maintenance.

Karel