Cannot toggle between ChromeOS and Wheezy/KDE

[RogerLevy]

I can get KDE to start by doing CTRL-ALT-=> logging in as chronos and sudo startkde, but when I go back to ChromeOS with CTRL-ALT-SHIFT-<=, and try to return to KDE with CTRL-ALT-SHIFT->=, the system appears to freeze and the mouse cursor goes away. I can get ChromeOS functioning again by hitting CTRL-ALT-SHIFT-<=.

I am on a Toshiba Chromebook 2 CB30.

[DennisLfromGA]

It's not recommended to enter your chroot via the 'Developer Console' on vt2. You should log into your google account, the one on the login screen when ChromeOS starts, and then enter the shell from there using Ctrl+Alt+t or the 'Crosh Window' extension.

Without first logging in, there's no active ChromeOS window session or gui to switch back to so you get stuck.

Take a look at this discussion for a few more details - https://github.com/dnschneid/crouton/issues/556#issuecomment-31305330

[RogerLevy]

Thank you for the quick answer, but this is already what I'm doing. CTRL-ALT-T, "shell", "sudo startkde"

Toggling back to ChromeOS works, but then I cannot really toggle back to KDE again - the mouse cursor just disappears.

[DennisLfromGA]

Sorry, maybe I misunderstood you.

I can get KDE to start by doing CTRL-ALT-=> logging in as chronos and sudo startkde

That always puts me in the Developer Console, I didn't see any mention of you logging in to your Google account.

---

Both ChromeOS and crouton change often so maybe you're just in need of an update, see Common-issues-and-reporting.

[RogerLevy]

I log in after the computer boots. I get the warning message, hit CTRL-D, then after a moment I get the login screen. After I am logged in then I hit CTRL-ALT-T to bring up crosh. Is that what you mean?

[DennisLfromGA]

Yup, that's exactly what I was trying to say. That should be the correct environment to launch a crouton chroot so the switching shortcuts 'Ctrl+Alt+Shift+Back' and 'Ctrl+Alt+Shift+Forward' should work. If not, then maybe an update is in order.

[RogerLevy]

I can toggle back to ChromeOS but nothing has changed, still can't return to KDE.

[RogerLevy]

Any followup on this?

[tonyxue]

Maybe download the latest crouton and uodate your chroot. I used to have this problem with the older version but not anymore and I have not done any particular to it.

If still not working, what's your console output when you try to switch back to chroot?

[lx1d]

If you want to go back into KDE from ChromeOS try CTRL-ALT-=> then at the black screen press CTRL-ALT-REFRESH (refresh is the button to the right of => ).

[DovW]

I have same problem as OP - but I was able to narrow down - "the system appears to freeze and the mouse cursor goes away" - to a problem of switching the display and NOT a problem of switching the active session.

By using X11vnc I discovered that although after pressing CTRL-ALT-SHIFT-=> Wheezy does not come back to the local display - and the display stays at the frozen Chrome OS - nevertheless after CTRL-ALT-SHIFT-=> the session has switched to Wheezy which is controlled by the Chrome OS system's keyboard and mouse - only the Chrome OS system's display has not switched.

Here is what I did to diagnose the problem -

1) I started the DE from outside the chroot (in my case my initial experiments were with lxde and then later I repeated them after I migrated my chroot to openbox under #! having edited my lxsession config files so that ob was started from sudo startlxde outside the chroot) within a logged-in session of Chrome OS and the session switched to Wheezy.

2) I then set up X11vnc on Wheezy (installed x11vnc and then from command line ran x11vnc -safer -localhost -nopw -once -display :0) - which I connected to from a remote PC that was right next to my Chrome OS system with a RealVNC client using SSH port-forwarding from a command line in a terminal (ssh -L 5901:localhost:5900 chronos@ChromeOS-IP-Address on the remote PC and pointed RealVNC on the remote PC to localhost:5901).

3) Using CTRL-ALT-<= I switched back to Chrome OS - and as soon as the session switched back Wheezy became totally unresponsive in the VNC client on the remote PC and even though the mouse arrow moved the display showed Wheezy frozen at its last state before switching back to Chrome OS. I do not know whether this is expected - what is very significant is the next step.

4) From Chrome OS I then tried to return to Wheezy with CTRL-ALT-SHIFT-=> (pressing CTRL-ALT-REFRESH after changes nothing) - and like the OP the Chrome OS screen froze and the mouse disappeared - HOWEVER - immediately, as soon as I had pressed CTRL-ALT-SHIFT-=> Wheezy came back to life in the remote PC's VNC client and it was fully controlled by the local Chrome OS system's mouse and keyboard and using the remote PC's VNC client as a monitor I was able to fully use Wheezy from the local Chrome OS system's mouse and keyboard.

CONCLUSION - CTRL-ALT-SHIFT-=> succeeds in switching the session from Chrome OS back to Wheezy - HOWEVER there is a problem with switching the display to the active display and NOT a problem of switching the active session - which did switch to Wheezy.

[DovW]

I have to add that although technically I am using a non-standard configuration - I have crouton installed in Chromium OS 8 GB USB flash booting on a Dell Optiplex PC - the identical symptoms that I share with the OP who is running on a Chromebook lead me to believe that this issue which has been reported many times is not unique to my setup and from what I have seen it seems this is a new opportunity to further narrow down the issue

[DovW]

Specifically if anyone can guide me to how to debug this further since I have BOTH Chrome OS's ssh server which I can log into remotely AND I have a second ssh server running in Wheezy on a higher port to which I can log into remotely throughout the process of switching from Chrome OS and back I should be able to isolate the issue with enough help (seems to me that two ssh sessions to chrome os's ssh server should be enough since in one session the shell can remain in chrome os as chronos user while in the other sudo enter-chroot gives a user shell into the chroot OS)

[DovW]

FYI due to this DISPLAY toggle problem I personally have been using the following WORKAROUND using the Chrome OS App RealVNC to connect to the desktop running headless in the chroot without switching between VTs. Here is how I am now doing it on #! (when I was using standard lxde and wheezy tightvncserver worked out of the box - but not after the switch to #!):

1) From within Chrome OS use crosh CTRL+ALT+t (or VT2) to sudo enter-chroot

2) Use xvfb to create a virtual X session on what the chroot sees as DISPLAY :2 and then run the DE to DISPLAY :2

3) Run X11vnc to DISPLAY :2 which then prints that VNC is on DISPLAY :0 at port 5900.

4) From Chrome OS's RealVNC app connect to localhost:5900

[DennisLfromGA]

I'd like to try this but I'm not familiar with xvfb or it's use or X11vnc either. I wonder if you could give me some more pointers on how this is setup please?

Thanx, -DennisL

On Fri, Nov 14, 2014 at 1:38 AM, DovW notifications@github.com wrote:

FYI due to this DISPLAY toggle problem I personally have been using the following WORKAROUND using the Chrome OS App RealVNC to connect to the desktop running headless in the chroot without switching between VTs. Here is how I did it.

1) From within Chrome OS use crosh CTRL+ALT+t to sudo enter-chroot

2) Use xvfb to create a virtual X session on what the chroot sees as DISPLAY :2 and then run the DE to DISPLAY :2

3) Run X11vnc to DISPLAY :2 which then prints that VNC is on DISPLAY :0 at port 5900.

4) From Chrome OS's RealVNC app connect to localhost:5900

— Reply to this email directly or view it on GitHub https://github.com/dnschneid/crouton/issues/1164#issuecomment-63016492.

DennyL@GMail

[DovW]

Dennis, Have you tried tightvncserver? (I only ran into trouble with that once I migrated from vanilla Wheezy to Crunchbang)

After entering your chroot (sudo enter-chroot):

~ sudo apt-get install tightvncserver

~ tightvncserver :2

You should then be able to connect using port forwarding from a remote PC :

From command line on remote PC:

~ ssh -L 5901:localhost:5900 chronos@ChromeOS-IP-Address

(with x11vnc display :2 in the chroot was display :0 locally - I don't recall how it worked in tightvncserver it's possible that in tightvncserver it is different and you may need to use display :2 and not display:0 remotely and so instead of the above - if it does not work use:

~ ssh -L 5901:localhost:5902 chronos@ChromeOS-IP-Address )

Then on remote PC connect RealVNC to localhost:5901

to end tightvnc session within chroot use:

~ tightvncserver -kill :2

[DennisLfromGA]

@DovW, Yes, I've used tightvncserver, in fact, I played around with a 'crouton-vnc' branch (see https://github.com/dnschneid/crouton/issues/147#issuecomment-19417706 ) that @dnschneid made a while ago.

I was interested in your approach using xvfb & X11vnc.

Thanx, -DennisL

[DovW]

Dennis, As it happens I first tried crouton-vnc but the script is out of date and would not build.

As for xvfb here's what worked for me:

~ sudo apt-get install x11vnc xvfb

start xvfb X-session and run WM inside it: ~ Xvfb :2 -screen 0 800x600x16& DISPLAY=:2 /usr/bin/lxsession& (replace 800x600x16 with desired resolution and /usr/bin/lxsession with your WM startup script)

start x11vnc server: ~ x11vnc -safer -localhost -once -nopw -display :2 (x11vnc starts showing that it is running on display :0 on port 5900)

From command line on remote PC: ~ ssh -L 5901:localhost:5900 chronos@ChromeOS-IP-Address

Then on remote PC connect RealVNC to localhost:5901

[DennisLfromGA]

@DovW, Thanx I'll give it a try.

[DovW]

@lx1d's solution exactly as written actually does work for me - I did not realize that the key in what he wrote was that he left out the Shift key - reading older threads on this I saw that on some systems the Shift should be left out to toggle back and forth - so to switch back to the chroot Ctl+Alt+=> goes to VT2 terminal and then either hitting Refresh with Ctl+Alt still pressed or doing a new Ctl+Alt+Refresh goes to the chroot.

Seems like issue ought to be Closed

[sfc-gh-eraigosa]

Same issue using trusty, ctrl+alt+refresh doesn't seem to allow switching back. I was working on enabling VT_x when this started occurring, not really sure if its related, but these were the instructions. Any other suggestion on how to solve this would be great. For now, only way to get mouse back on chromeos is to logout of the ubuntu session so that it closes down in the terminal. They keyboard remains responsive, it's just the mouse that seems to remain locked up on chromeos but not the ubuntu session. Switching back to the ubuntu session brings the mouse back on ubuntu only.

[divx118]

@DovW Proper way of switching which should be supported on all DE and supported releases is Ctr-Shift-Alt <=/=> (F1/F2) Only using Ctr-Alt => or Ctr-Alt Refresh are workarounds. So if Ctr-Shift-Alt <=/=> (F1/F2) is not working it is a bug.

[codyjroberts]

I am also having this issue. Regular shortcuts seem to be broken all of a sudden. ctrl-alt f2 then f3 will get me to ubuntu, but I used to be able to use ctrl-alt-shift f2.

[divx118]

It seems to me this is related to using the fbdev driver in X on your chroot. I had this issue with kali which uses the fdev driver by default. I also tried my trusty chroot which normally is using the intel driver and forced it to use the fbdev driver. Same issue. Session switches, so mouse cursor disappears, but display stays in chromeos. A workaround is first changing to vt 2 and then to the vt where your chroot is running. Let's see if we can find the cause why the display won't switch when using fbdev ...

[codyjroberts]

Just to be clear, my mouse does not disappear when using Ctr-Shift-Alt <=/=> (F1/F2). There are no signs of switching sessions.

[divx118]

@bloomyminded Try to update your chroot by downloading a new version of crouton and update. See https://github.com/dnschneid/crouton/wiki/Common-issues-and-reporting for the correct procedure. Since your mouse cursor doesn't disappear you don't have this bug.

[codyjroberts]

@divx118

Thank you, simple fix. The dev channel update must have broke it. All is working fine now.

[sfc-gh-eraigosa]

@bloomyminded that indeed did fix me too.

[dnschneid]

@divx118 does it help if you add a chvt 2 inside of croutoncycle somewhere (such as before any other calls to chvt)?

[divx118]

Yes, I tested that and it works. Adding it just before the other chvt.

On Sun, Dec 21, 2014 at 11:48 PM, David Schneider notifications@github.com wrote:

@divx118 https://github.com/divx118 does it help if you add a chvt 2 inside of croutoncycle somewhere (such as before any other calls to chvt)?

— Reply to this email directly or view it on GitHub https://github.com/dnschneid/crouton/issues/1164#issuecomment-67788486.

[dnschneid]

Fix released; please update the chroot and try again.