-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The extension corrupted after last update dev chanel(ASUS C302) #4078
Comments
Same issue as well: name: buster |
Same here Asus C302 on dev channel - Version 76.0.3807.0 (Official Build) dev (64-bit) Worked flawlessly for 6 months until the last update, now the extension corrupts when a chroot is launched. As a workaround, you can select 'repair extension' from the extensions menu in chrome, then click on the icon to select your chroot. |
Confirmed this works for me. it's just a pain to repair the extension over and over again to access the chroot. |
sudo startxfce4 -X xiwi _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root X.Org X Server 1.18.4
(xfsettingsd:5746): xfsettingsd-WARNING **: Unknown mode '1536x864 @ 59.5' for output default, aborting. (polkit-gnome-authentication-agent-1:5834): polkit-gnome-1-WARNING **: Unable to determine the session we are in: No session for pid 5834 |
sudo startxfce4 -X xiwi _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root X.Org X Server 1.18.4
(xfsettingsd:15825): xfsettingsd-WARNING **: Unknown mode '1536x864 @ 59.5' for output default, aborting. (polkit-gnome-authentication-agent-1:15873): polkit-gnome-1-WARNING **: Unable to determine the session we are in: No session for pid 15873 At this point the chroot is running, but the chrome extension has corrupted. |
I've just found the extension doesn't corrupt when using xorg. For example:- 'sudo startxfce4 -X xorg' I can then jump between windows using ctrl-alt-shift and the back or forward keys, and jump into the chroot using the extension. |
Is there a solution for this. Do we get xiwi back or not? |
No, a solution/fix has not yet been implemented/merged. But, one workaround was posted above, I'll provide it here also:
Another workaround is to use the 'xorg' xmethod instead, also posted above. I prefer 'xiwi' so I use the first workaround and repair the extension. Hope this helps, |
@DennisLfromGA Thank you for taking the time, Dennis. Xorg is still working as before. I was hoping to get my xiwi workflow back. The workarounds mention here, repairing the extension, either isn't working for me as it does for the person mentioning it, or just doesn't bring back single apps running in chrome windows as I knew it. Also, I am not on dev channel; on beta. I use xiwi windows and tabs daily to use apps like atom for programming - shifting to and fro with xorg inefficient, now also the keyboard mapping is different - I'll have to take the time at some stage to fix that or I dunno, just give up on chromeOS. Crouton chroots have been a good run, thought I had a nice machine to code on, but how reliable is it really? Just for hobbyists I see that now. |
@DennisLfromGA I really do appreciate you taking the time to advise me personally. Xiwi really is utterly broken for me. Since the last update on the Beta channel last week xiwi no longer successfully connects under any troubleshooting condition I have tried: with any app, either of my well functioning chroots, with any google account, all other extensions disabled, repairing repeating, repairing rebooting, etc. |
I fund a way to solve this problem. Just load the unpacked extension. |
I just came here to create an issue about this...I have same problem. As a 'solution', I have been repairing extension after running the command for the 1st time. It then runs on the second attempt. My chroot is buster. The following is the command I've been using to launch my chroot desktop: (I get 'timeouts' if I try to do sudo startgnome directly [with the extension connecting], which is another problem I've had. Works sometimes, most of the time not. But the below command always launches.)
I am on beta channel. |
I also have this issue on an Acer Chromebook 15 CB5-571 https://www.reddit.com/r/Crouton/comments/ccsyps/crouton_integration_crashing/ |
As one of probably many sidetracked for a while by this issue, I suggest that more be done to detect the problem and notify the user, eg by detecting the corrupt extension and posting a warning message with a link to this issue. Many will not notice the corrupt extension and try updating crouton (possibly spending a while, as I did, on a tangent fussing with the recent mounted-fs noexec situation). A warning in the updated crouton start scripts would save lots of people some substantial time, until the problem is actually fixed. That said, thanks very, very much for crouton, and the work everyone puts into it! I understand that Chrome OS is an especially active platform, and probably offers lots of challenges to maintaining an elaborate (but vital) add-on like this. |
+1 with ASUS C302 in dev mode, xenial and bionic. The "repair" workaround does the job but would be nice to get back to a non corrupted plugin. I'm joining kenmanheimer for the crouton great job, thanks a lot. Daniel |
Perhaps useful additional information: it's looking like my xiwi sessions are always gone after a system suspend. This makes the problem more serious, of course, since restarting is more frequently necessary. |
I just received 76.0.3809.77 on beta channel and haven't been seeing 'corruption' anymore. The crouton windows still disappear as soon as the laptop lid is closed (even for a second) but now when I select them from the crouton icon, the windows just immediately reopen. Way better than having to 'repair' and turn hidpi back on every time. Does this match other's experience with the latest beta? |
I'm seeing something a bit more complicated.
I can explicitly track down the residual processes (ps a) and send TERM signal to the enter-chroot process (sudo kill -TERM ), so I feel like this situation is better. It would be a lot better still, though, if the xiwi windows survived system sleep. Thanks, @danopia, for bring attention to the changed status! |
In response to what I wrote:
Looks like
|
Hmm, have you tried re-opening the windows from the crouton icon? Any time a xiwi window closes without being shut down, you should be able to re-open it from the extension's window. Like so: https://drive.google.com/file/d/1ivOagkOTCJWOLWgG6rujXuPVXfIGRcvP/view Though I definitely lost one of the 5 when recording that 😏 This is how I'm dealing with the sleep issue now, and it's okay. Obviously the windows surviving sleep would be better if we can figure out wtf these beta builds are doing. Maybe this ticket needs a rename - there's no corruption being reported for me anymore, the windows just close on lid close. |
As mentioned by @kenmanheimer above,
You can just list the processes if you're curious, I only have the
Hope this helps, |
Ah - that's very helpful! My browser Crouton extension icon was hidden in the overflow area, and the shelf icon disappears when the windows go away, so I didn't realize this was an option! I've moved the browser extension icon to a more prominent place, and it's a great avenue for getting back the windows, without costing any more resources. Thanks!
Same for me. The ability to get my xiwi window back intact relieves the pain of the problem, leaving it more as a complicating quirk. But I'm not sure how much attention this is getting from anyone actively working on Crouton, who might change the name of the thread? I do wonder whether some among Chrome OS developers might be aware of this thread, though. Maybe the beta alleviated the problem coincidentally, as part of addressing an issue noticed for other symptoms. Then again, maybe Crouton is among the Chrome OS developers and they addressed the Crouton issue directly? (If so, I wonder whether Crouton will become superfluous to them as Crostini advances...) Curious. |
Update: With the latest Chrome Dev - Version 77.0.3865.18 (Official Build) dev (64-bit) and the latest crouton I don't have to repair the extension anymore and things reconnect after locking the screen. It appears to be fixed. crouton: version 1-20190807171712~master:6f45f06a |
Great news that new build works I'm on Version 76.0.3809.102 (Official Build) (64-bit) and I'd rather stay out of dev I've tried to repair the extension, however, when I go to More Tools > Extensions (search for crouton) found it - I don't see a "repair" option ???? - there's "Load Unpacked" "Pack Extension" "Update" "Manage Kiosk Applications" ??? |
name: xenial
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/xenial...
crouton: version git
release: xenial
architecture: amd64
xmethod: xiwi
targets: extension,audio,xiwi,keyboard,kde-desktop,gtk-extra,xorg,touch,cli-extra
host: version 12236.0.0 (Official Build) dev-channel cave
kernel: Linux localhost 3.18.0-19671-g83419c049dc9 #1 SMP PREEMPT Wed May 29 14:04:09 PDT 2019 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Please describe your issue:
The extension corrupted after last update dev chanel(ASUS C302).
When the first time open xiwi is correct, but when close xiwi and open it agin is corrupted.
I open the extions dev model and find
WebSocket connection to 'ws://localhost:30011/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
Context
window.html?display=1&debug=0&hidpi=0&title=xenial%2Fpycharm%3A%20tdb%20%5B~%2FPycharmProjects%2Ftdb%5D%20-%20...%2Fsvd%2Fmodels.py%20%5Btdb%5D%20-%20PyCharm&mode=w
Stack Trace
window.html?display=1&debug=0&hidpi=0&title=xenial%2Fpycharm%3A%20tdb%20%5B~%2FPycharmProjects%2Ftdb%5D%20-%20...%2Fsvd%2Fmodels.py%20%5Btdb%5D%20-%20PyCharm&mode=w:0 (anonymous function)
The text was updated successfully, but these errors were encountered: