search

dnschneid / crouton

Chromium OS Universal Chroot Environment
https://goo.gl/fd3zc?si=1
BSD 3-Clause "New" or "Revised" License
8.57k stars 1.24k forks source link

xfce chroot sometimes becomes visually unresponsive on switch back #155

Closed konklone closed 9 years ago

konklone commented 11 years ago

It's difficult to predict whether it will happen or not ahead of time, but it's happened either sooner or later to every chroot I've begun. Running sudo startxfce4 works fine and brings me to a working xfce. Switching back to Chrome OS with Ctrl+Alt+Left Arrow works fine. Upon switching back to xfce (sometimes), most visual layers drop off entirely.

What's left is a blank dark grey title pane on top (default theme), a blank dark grey launcher rectangle on the bottom, and any windows I have open become a title bar (with text, the only text remaining on screen) and a white blank rectangle where the window used to be.

The only remedy I've found is to switch back to Chrome OS, end the chroot with Ctrl+C, and start it again.

I have a gist of the output of the startxfce4 script up until the crash, and the output of the script after I hit Ctrl+C.

However, nothing new is added to the output when the visual crash occurs. This is the same output I have when switching back and forth between a working xfce.

Any advice?

konklone commented 11 years ago

I've also added the output of the chroot after a Ctrl+C where I have not yet observed a crash (I started xfce, switched back, and Ctrl+C'ed).

dnschneid commented 11 years ago

Do you have compositing enabled in xfce?

konklone commented 11 years ago

It's the default chroot (this happens without me making any modifications to the settings), so I don't think so?

dnschneid commented 11 years ago

Yeah, not enabled then. By "visually unresponsive", do you mean you can't move the mouse, or drag windows around or anything?

konklone commented 11 years ago

I can move the mouse, but nothing responds to clicks - I can't drag windows, there are no longer any buttons to click. I didn't try setting up any global keyboard shortcuts to try, so I'm not sure if those would work.

On Sat, May 18, 2013 at 2:20 PM, David Schneider notifications@github.comwrote:

Yeah, not enabled then. By "visually unresponsive", do you mean you can't move the mouse, or drag windows around or anything?

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/155#issuecomment-18108183 .

twitter.com/konklone | sunlightfoundation.com | awesomefoundation.org

dnschneid commented 11 years ago

It's possible xscreensaver is locking the screen but not blanking it properly. Next time it happens, try going to Chromium OS and running pkill xscreensaver, then switch back and see if the system is usable.

konklone commented 11 years ago

No help. :/ Any instrumentation I can take from within crosh while xfce is running?

On Sat, May 18, 2013 at 3:11 PM, David Schneider notifications@github.comwrote:

It's possible xscreensaver is locking the screen but not blanking it properly. Next time it happens, try going to Chromium OS and running pkill xscreensaver, then switch back and see if the system is usable.

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/155#issuecomment-18108866 .

twitter.com/konklone | sunlightfoundation.com | awesomefoundation.org

sangto commented 11 years ago

i have exactly the same problem on chromebook pixel.

stephen-soltesz commented 11 years ago

I had this issue with default xfce install; I disabled xscreensaver in settings (on by default) and it did not happen again. This was on a Chromebook 550.

henningspruth commented 11 years ago

I'm experiencing the same issue on an Acer C7: the chroot GUI becomes unresponsive after a while. I tried disabling or killing xscreensaver processes, but this didn't fix the issue. This happened with both lxde and xfce4 on Ubuntu 12.04 using an encrypted chroot.

On my last attempt, I disabled the "Require password to wakeup from sleep" setting in ChromeOS, which may have fixed the issue for now.

tedm commented 11 years ago

on the ARM, with xfce / precise, xscreensaver can't be stopped with the application / power settings menu, and should indicate that a gnome screensaver must be stopped first.

You can temporarily stop it by killing it's pid, but it will restart at some point.

dnschneid commented 11 years ago

Are people still hitting this issue? xscreensaver will now default to "blank only", but only for new installs.

nadalle commented 11 years ago

This problem happens to me 100% of the time, every single time I switch to/from the chroot environment, on a Samsung Series 3. It happens with or without xscreensaver.

nadalle commented 11 years ago

Followup: It was doing this 100% of the time yesterday, and then started working for a while. After it locked up again, I looked at the processes involved and it seems that they're stuck in the STOP state:

30363 pts/4 S 0:00 | /bin/sh -e /usr/local/bin/croutonxinitrc-wrapper /etc/xdg/xfce4/xinitrc 30364 pts/4 T 0:00 | /bin/sh -e /usr/local/bin/croutonpowerd --daemon

... starting with croutonpowerd.

dnschneid commented 11 years ago

That's odd. You're not backgrounding the process in crosh with Ctrl-Z, are you?

nadalle commented 11 years ago

No, it's in the foreground. With it in the STOP state, I've also tried ^Z, fg, kill -CONT, etc. I believe it's also entered this state when started in the background.

I wonder if there's an issue with the crosh pty?

On Tue, Sep 10, 2013 at 10:24 AM, David Schneider notifications@github.com wrote:

That's odd. You're not backgrounding the process in crosh with Ctrl-Z, are you?

— Reply to this email directly or view it on GitHub.

nadalle commented 11 years ago

I decided to try my hypothesis that there was something fishy about the crosh pty, so I just tried running the chroot under screen. So far so good!

This problem has gone away mysteriously on me before, so I'm not sure yet if this workaround actually works or not.

Here's my workaround in case anyone else wants to try this. It basically amounts to "copy screen out of your chroot and get it running in ChromeOS." It's a little bit annoying.

  1. Go into your chroot and install screen. Then, do "ldd which screen" to find out its library dependencies.
  2. Copy all of them to ~/Downloads/screen/ as well as the screen binary itself.
  3. Go back to crosh and copy ~/Downloads/screen to /usr/local/screen.
  4. Make a symlink for your ld-linux.so.3 in that directory if you need to.
  5. cd /usr/local/screen and then sudo -s
  6. LD_LIBRARY_PATH=/usr/local/screen ./ld-linux.so.3 ./screen
  7. Now run your chroot from there. As a bonus, you can detach and close crosh now.
DennisLfromGA commented 11 years ago

@Nadalle - Just so you don't have to reinvent the wheel, here's a linkhttps://drive.google.com/folderview?id=0Byyp8R1NxgJlb1FBeFpnSGV4TVU&usp=drive_web#to some utilities, 'screen' included, compiled for Chrome OS and a forum threadhttps://groups.google.com/forum/#!topic/chromebook-central/UGD2ISPogAYwhere he talks about them.

On Fri, Sep 27, 2013 at 3:38 AM, nadalle notifications@github.com wrote:

I decided to try my hypothesis that there was something fishy about the crosh pty, so I just tried running the chroot under screen. So far so good!

This problem has gone away mysteriously on me before, so I'm not sure yet if this workaround actually works or not.

Here's my workaround in case anyone else wants to try this. It basically amounts to "copy screen out of your chroot and get it running in ChromeOS." It's a little bit annoying.

  1. Go into your chroot and install screen. Then, do "ldd which screen" to find out its library dependencies.
  2. Copy all of them to ~/Downloads/screen/ as well as the screen binary itself.
  3. Go back to crosh and copy ~/Downloads/screen to /usr/local/screen.
  4. Make a symlink for your ld-linux.so.3 in that directory if you need to.
  5. cd /usr/local/screen and then sudo -s
  6. LD_LIBRARY_PATH=/usr/local/screen ./ld-linux.so.3 ./screen
  7. Now run your chroot from there. As a bonus, you can detach and close crosh now.

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/155#issuecomment-25227966 .

DennyL@GMail

nadalle commented 11 years ago

Thanks for the link! Unfortunately, those appear to be for x86 chromebooks.

For an update, running under screen does not seem to be entirely effective, but it is a lot more stable. I did get the chroot UI freeze once last night, though. I attempted to debug it using strace, which definitely seems to point to a tty problem, but I that was as far as I got.

DennisLfromGA commented 11 years ago

Sorry, now looking at your 1st post I see that you're on the Samsung. It'd be nice to see something like those available on the ARM too.

On Fri, Sep 27, 2013 at 11:20 AM, nadalle notifications@github.com wrote:

Thanks for the link! Unfortunately, those appear to be for x86 chromebooks.

For an update, running under screen does not seem to be entirely effective, but it is a lot more stable. I did get the chroot UI freeze once last night, though. I attempted to debug it using strace, which definitely seems to point to a tty problem, but I that was as far as I got.

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/155#issuecomment-25252864 .

DennyL@GMail

excel4 commented 10 years ago

I was having the same problem on a C710 with precise / XFCE. I tried the Crosh Window app, but that did not help. I then tried trusty / unity. So far it has been running fine with no freezes. Although I prefer the lighter XFCE UI, stability is more important for my needs.

I also noticed that with precise / XFCE there were lots of errors/warnings on the console running crouton. Under trusty / unity there are no errors. Not sure if these issues are related...

dnschneid commented 9 years ago

Please try again with the latest crouton and re-open if this is still an issue.