X Server Access Denied, Fails to enter Chroot #524

Closed
thewes opened this Issue Dec 10, 2013 · 98 comments

Projects

None yet
@thewes
thewes commented Dec 10, 2013

Upon upgrading the Pixel this morning on Dev channel and after entering sudo startunity I receive this:

Loading extension GLX
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: Connection refused
/usr/bin/xinit: server error

Here's my version Info:

crouton: version 1-20131209181508~master:34ee7cf6
release: saucy
architecture: amd64
host: version 5062.1.0 (Official Build) dev-channel link

Chroot closes by itself and returns to command prompt.

@dnschneid
Owner

I can confirm that it's totally broken. Looking into it.

@dnschneid
Owner

Sean Paul is looking into it upstream, but I suspect dev channel will stay broken until the new year (unless someone comes up with a workaround). In the meantime, use xephyr or switch to beta channel (back up your chroot before switching).

@divx118
Contributor
divx118 commented Dec 21, 2013

I looked at the latest commits for the i915 driver in the kernel, but couldn't find anything obvious that would break starting X.
The one thing I noticed in the release info is that they now run X-server in chrome-os as user xorg and not as root anymore. Still need to dig some deeper into this if maybe this would be the cause somehow.
You can start the X-server by making a /etc/X11/xorg.conf file that uses fbdev driver instead of intel then your X-server will start. Off course this isn't a real workaround, no hardware acceleration. You however don't have to switch back to beta or use xephyr and can just wait for a fix.

xorg.conf:

Section "Device"
   Identifier  "fbdev Graphics"
   Driver      "fbdev"
EndSection
@andrewwippler

My Xorg already has the workaround (seen below). Moving xorg.conf to a backup and just placing the above in xorg.conf works.

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        #Option     "ShadowFB"                  # [<bool>]
        #Option     "Rotate"                    # <str>
        #Option     "fbdev"                     # <str>
        #Option     "debug"                     # [<bool>]
        Identifier  "Card2"
        Driver      "fbdev"
        BusID       "PCI:0:2:0"
EndSection
@rudolphpienaar

Isn't the root device read-only? How do you make edits to xorg.conf?

chronos@localhost /etc/X11 $ sudo cp xorg.conf xorg.conf.orig
cp: cannot create regular file ‘xorg.conf.orig’: Read-only file system

@andrewwippler

@rudolphpienaar Looks like you are editing the wrong file. You can find the file in /usr/local/chroots/NAME/etc/X11

@rudolphpienaar

Ah! That makes a lot more sense. And it worked -- although the crouton session is decidedly slow... Let's hope that this is fixed sometime soon.

@thewes
thewes commented Jan 3, 2014

Has this absolute destruction of crouton reared its ugly head in the beta channel yet? I can't imagine it not rendering crouton useless in the next few months on all channels.

@dnschneid
Owner

I doubt this will propagate to beta.

@johnrobertlawson

Just updated my Crouton, and I'm getting the "No screens found" error. I just updated my Pixel's beta channel... is this bad?

@divx118
Contributor
divx118 commented Jan 13, 2014

You can check if you have the same problem by entering the following command in cross shell.

chronos@localhost / $ cat /sbin/session_manager_setup.sh | grep USER

You get something like:

XUSER=root
xstart.sh ${XUSER} ${XTTY} ${XAUTH_FILE} &
export USER=chronos
export DATA_DIR=/home/${USER}
export LOGNAME=${USER}
"$(sudo -u ${USER} /bin/mktemp -d /tmp/.ibus-socket-XXXXXXXXXX)\
mkdir -p ${DATA_DIR} && chown ${USER}:${USER} ${DATA_DIR}
mkdir -p ${HOME} && chown ${USER}:${USER} ${HOME}
chown ${USER}:${USER} ${LOGIN_PROFILE_DIR}
USER_ID=$(id -u ${USER})
  CONSENT_USER_GROUP=$(stat -c %U:%G "$CONSENT_FILE")
  if [ "$CONSENT_USER_GROUP" = "root:root" ]; then
# Create the XAUTHORITY file so ${USER} can access the X server.
cp -f ${XAUTH_FILE} ${XAUTHORITY} && chown ${USER}:${USER} ${XAUTHORITY}
exec /sbin/session_manager --uid=${USER_ID} ${KILL_TIMEOUT_FLAG} \

If you get "XUSER=xorg" instead of "XUSER=root" then they start the X server as a normal user and you would have the same issue.
On my Falco they still start it as root with the newest update from 9 jan 2014.

Version 32.0.1700.95 beta
Platform 4920.71.0 (Official Build) beta-channel falco
Firmware Google_Falco.4389.78.0
@drinkcat
Collaborator

Not tested, but this issue may well have propagated to beta now (http://googlechromereleases.blogspot.sg/2014/01/beta-channel-update-for-chrome-os.html: platform version 5116.32.0).

The responsible commit was introduced somewhere between version 4982 and 5085 (see https://chromium.googlesource.com/chromiumos/platform/login_manager/+log/master/session_manager_setup.sh, commit 0bb5e82).

@AF9210
AF9210 commented Jan 17, 2014

can confirm issue has propagated to beta

Version 33.0.1750.29 beta
Platform 5116.32.0 (Official Build) beta-channel parrot
Firmware Google_Parrot.2685.37.0

@ehegnes
ehegnes commented Jan 17, 2014

I can also confirm this issue.

Version 33.0.1750.29 beta
Platform 5116.32.0 (Official Build) beta-channel peppy
Firmware Google_Peppy.4389.81.0

@drinkcat
Collaborator

Noted. Thanks. Switching back to the stable channel will fix the problem for the time being. AFAIK you can do that without a powerwash, so it should not be too painful (but backup your chroots first, just in case). (EDIT: No, apparently you need a powerwash. So backup your chroots and Downloads folder...)

Alternatives such as Xephyr and fbdev are also possible, but you would lose 3D acceleration.

Upstream issue is being tracked here: http://crbug.com/328115 , you can help by starring the issue (no need to comment).

@andrewwippler

As a workaround, you could do a sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification and edit /sbin/session_manager_setup.sh to run as root.... correct? What would the regressions be to that?

@drinkcat
Collaborator

As a workaround, you could do a sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification and edit /sbin/session_manager_setup.sh to run as root.... correct? What would the regressions be to that?

That should work yeah. There are conflicting reports about whether or not you would lose auto-updates (see #266), so we may not want to apply that automatically.

@AF9210
AF9210 commented Jan 17, 2014

powerwash is required on going back to stable ;(

@thewes
thewes commented Jan 17, 2014

Probably time to bounce to chrubuntu. I loved crouton, it made my pixel usable, but this issue has propagated over the last few months and will inevitably hit stable, rendering the whole project crippled. Thank you Schneider for all your hard work, tell Google to stop rendering their own products useless!

@jacklevy

confirmed broken on my pixel with beta channel as well.

Version 33.0.1750.29 beta
Platform 5116.32.0 (Official Build) beta-channel link
Firmware Google_Link.2695.1.133

this is the second time beta channel has completely broken crouton. guess i have to run stable from now on.

@thewes
thewes commented Jan 17, 2014

Drinkcat - we would lose auto updates to what? Chrome os? If that's the case I'm good with it- rather have working crouton then an up to date Chromebook

@drinkcat
Collaborator

At this stage, you have 4 options:

  1. Switch back to stable channel (that means powerwash, so backup your chroots first)
  2. Use the fbdev driver (see: #524 (comment), no 3D acceleration)
  3. Install the xephyr target and use that (no 3D acceleration)
  4. Remove rootfs verification and modify the init file (#524 (comment))

If you need 3D acceleration, I'd recommend option 1. If you don't, option 2 is the easiest to remove once the bug is fixed.

@andrewwippler

We may have a working chroot soon. There is code in review in the upstream: https://chromium-review.googlesource.com/#/c/183190/

@DennisLfromGA
Collaborator

In addition to @drinkcat's 4th option, some may want to add:

(5) Create the file '/mnt/stateful_partition/etc/lsb-release' that contains the following 2 lines:

  CHROMEOS_RELEASE_VERSION=9999.9999.9999.9999
  GOOGLE_RELEASE=9999.9999.9999.9999

to prevent ChromeOS updates from happening (until the fixes are in place at least)

@DennisLfromGA
Collaborator

Looks like they pulled the latest version from cros beta and reverted to the previous one...

os      channel current_version previous_version
cros    beta    32.0.1700.95    33.0.1750.29

Source: https://omahaproxy.appspot.com/

@drinkcat
Collaborator

Looks like they pulled the latest version from cros beta and reverted to the previous one...

This provides more details: http://cros-omahaproxy.appspot.com/ . For a short time beta was ahead of dev: that's clearly not supposed to happen... (scrap that, it happened in the past too, so it's probably normal)

But yes. It looks like the beta release has been pushed to dev, and beta reverted to the previous version.

to prevent ChromeOS updates from happening (until the fixes are in place at least)

Careful with that, you'll also lose security updates... Given that beta has been rolled back, that's really not necessary at this stage, especially if you are on the stable channel.

@DennisLfromGA
Collaborator

@drinkcat - Thanx for the warning about losing security updates, I'll try to keep a close eye on things until it's fixed.
I was on the dev chan. until it broke my chroots, then I painstakingly backed everything up and powerwashed my way back to beta. Once that broke, I invoked the XUSER=root method in /sbin/session_manager_setup.sh and got things working again. I plan to stay on the beta chan. for a while or until my chroots are broken again and I/we can't find a way around it.
I just stopped the updates as an experiment really just to see if it worked, I hadn't seen that method before so I wanted to try it; I'll probably start them up again soon.

@mpeaton
mpeaton commented Jan 20, 2014

Would be great if google were updating ChromeOS to allow display from a chroot to Aura.

@brando56894

Still happens on the beta channel of my (old) HP 14 running butterfly (?), I've been trying to get it to work for like the past 2 or 3 days, downloading new commits each time. I'm at work and don't have access to my chrombook but drinkcat linked me to here since I was having problems with chroagh and crouton.

(EE) intel(0): [drm] failed to set drm interface version: Permission denied [13].
(EE) intel(0): Failed to claim DRM device.
(EE) Screen(s) found, but none have a usable configuration.
(EE) no screens found(EE) 

@wjstarrsiii

I'm in stable channel on an Acer C720. Currently running 32.0.1700.95. I had 2 chroots that broke yesterday... debian wheezy (crunchbang-ified with openbox) and arch running xfce4. Both give the X-server issue upon enter-chroot. Wheezy however still works if I enter the chroot and just run bash instead of startx. Once at the bash prompt, I enter "startx" and voila, my desktop comes up. Still get failures however on the arch side.

One other question: I was trying to modify the xorg.conf as described above, but both of these distos use xorg.conf.d instead. I tried to create a file within that directory called 05-display.conf and put that info in there, but didn't seem to work on either distro. Should that have worked or am I missing something?

Thanks

@divx118
Contributor
divx118 commented Jan 22, 2014

Normally when starting X it first looks for xorg.conf then looks into xorg.conf.d . You should be able to see that when you look at the log file from Xorg. It should have worked when creating a file 05-display.conf in xorg.conf.d. However creating a xorg.conf in /etc/X11 should also work.
If it doesn't, post you /var/log/Xorg.1.log on for example pastebin.com

@wjstarrsiii

I put it in xorg.conf in arch. looks as if the fbdev was being pulled in correctly, X still doesn't start. Complains about there already being something on screen 0.

Xorg.1.log below as suggested. Thanks

http://pastebin.com/1shQ2R1G

@mpeaton
mpeaton commented Jan 23, 2014

Is this issue something that is expected to effect the stable channel as well? I there someone working a permanent solution?

@drinkcat
Collaborator

@wjstarrsiii: The specific problem discussed in this issue will not happen on your Chrome OS version (R32, 4920.71.0). Can you open a separate issue, and post logs and console output for wheezy to a gist (https://gist.github.com/)? You can post output with and without the extra xorg.conf file.

@mpeaton: Yes a solution has been found, and submitted upstream. It was reviewed and accepted, so should be included in Chromium OS soon. We'll do our best to make sure this is applied in the next beta.

@wjstarrsiii

So I went and did the first test without the extra xorg.conf and it ran flawlessly. No idea why it worked this time but it does, so there will be no new issue to post. I did capture stderr/stdout and have a log if you are interested but most likely not.

I did notice that for my arch install it is trying to open X on display 0, whereas the log indicates wheezy is starting on display 1. I'll address that issue in the croagh forum if a reinstall doesn't patch it up. My problems started after the installation of my new 128GB SSD and the restoration of chroot backups, so maybe that had something to do with it.

@aeroperf

I'm now having the same problem on my C720 after updating beta channel to 33.0.1750.51.

@drinkcat
Collaborator

I'm now having the same problem on my C720 after updating beta channel to 33.0.1750.51.

Yes, beta channel was updated again today. See #524 (comment) for your options (1: going back to stable channel, is recommended).

@Splaktar

Yep, issue is back in beta again with Version 33.0.1750.51 beta. Just got bit by this today on my Pixel. I guess that I need to backup and powerwash, dang. Glad to see that a patch has been submitted (Thanks Nicolas!), but it looks like it might take a while for that to get into the beta channel.

@dnschneid
Owner

Hopefully we'll get the patch merged by the next beta push or two, so it shouldn't be too long now.

@rawalk
rawalk commented Jan 27, 2014

Is there an update to this? I've been updating between xephyr and x11 targets to see when this gets fixed. Because xephyr runs too wonky for me (ie: dual monitors don't work, on laptop screen display switching between crouton and ubuntu is impossible.) If anyone has any advice to make xephyr a bit more tolerable that would be great.

@dnschneid dnschneid closed this in #602 Jan 27, 2014
@dnschneid
Owner

Re-opening until the fix is merged upstream

@dnschneid dnschneid reopened this Jan 27, 2014
@dnschneid
Owner

With the fix merged in crouton, the current state of upstream is this:
The next dev channel push for kernel 3.8 systems will have the fix.
A merge is pending for beta channel; assuming that gets approved in a timely manner the next beta channel push for 3.8 systems will have the fix as well.
We're still testing the fix for 3.4 systems, then that too will have to get merged to beta.

You can see which version of the kernel your device uses by running uname -r

@dnschneid dnschneid closed this Jan 27, 2014
@dnschneid
Owner

oops

@dnschneid dnschneid reopened this Jan 27, 2014
@steveg19710

any timetable for when the fix will be available for 3.4 systems?

@dnschneid
Owner

Fixes have been merged across the board; they should show up with the next beta and dev pushes.

@drinkcat
Collaborator

Thanks to Chromium OS devs who have been incredibly responsive and helpful (I can say it since I'm not one of them ,-)), fixes for both kernels 3.4 and 3.8 have now been merged, and will appear in dev channel sometimes in the future, once the platform versions catch up with 5283 (kernel 3.8) and 5331 (kernel 3.4).

In the mean time, both patches have also been merged into Release 33 (Platform 5116.X.Y), which is currently the beta release on all machines. The current beta channel (5116.45.0 or 5116.46.0) does not include the patches yet, but from the next update (or maybe the following one), they will be included.

That also means stable channel will include the patches once it is updated to Release 33 (currently, it is R32, platform 4920.71.0: not affected by this bug).

You can easily check if the fix is applied by running:
sudo ls -l /sys/kernel/debug/dri/drm_master_relax
If that file exists, all is good.

Finally, crouton has also been updated to activate the flag if it is present (so you can already update your chroots if you plan to switch back to beta channel once the fix is in).

@drinkcat
Collaborator

Latest beta channel push (5116.53/54.0) includes the patch, at least on kernel 3.8 (the 2 patches were merged at the same time so I don't expect problems on 3.4).

@rawalk
rawalk commented Jan 30, 2014

Um alright, sorry for the stupid question,

But I updated seconds ago, I'm on the beta channel.

ran this:
chronos@localhost / $ sudo ls -l /sys/kernel/debug/dri/drm_master_relax
-rw------- 1 root root 0 Jan 30 00:56 /sys/kernel/debug/dri/drm_master_rela

So that means that is fix is applied and running.

So I ran sudo sh -e ~/Downloads/crouton -u -n saucy -t x11 to return to the good ol' days, but it still shows a Fatal Server error with no screens found...

I must be doing something stupidly wrong. Any advice on what?

@dnschneid
Owner

Did you re-download crouton before running it with -u? What's the output of sudo enter-chroot croutonversion?

@rawalk
rawalk commented Jan 30, 2014

I did not re-download crouton. Yes and that did it, I knew I was doing something stupid. Thanks so much :) I can finally get my homework done now.

Here is the output just for the record:
Entering /usr/local/chroots/saucy...
crouton: version 1-20140129115028~master:caadc6ce
release: saucy
architecture: amd64
targets: x11,xephyr,xfce,xorg,gtk-extra,extension,core,audio,cli-extra
host: version 5116.53.0 (Official Build) beta-channel parrot
Unmounting /usr/local/chroots/saucy...

@dnschneid
Owner

Nothing's on fire! Yay!

@dnschneid dnschneid closed this Jan 30, 2014
@rudolphpienaar

Wait... Do we have to re-install 'crouton' again? I thought that once
the upstream mods trickle down everything will just start working again...

On 1/30/14, 04:10 , David Schneider wrote:

Did you re-download crouton before running it with -u? What's the
output of |sudo enter-chroot croutonversion|?


Reply to this email directly or view it on GitHub
#524 (comment).

@DennisLfromGA
Collaborator

A little OT but would it be worthwhile to incorporate some version checking mechanism in 'crouton' and throw a warning if it's not the latest and offer to update it?
I have a script I use to kick-off my chroots that checks and compares the latest version of 'crouton' with the one on the system and also the version in the chroot before it starts. I find it pretty handy.

@dnschneid
Owner

I'd rather do something like #351

@DennisLfromGA
Collaborator

Yep, sorry I forgot about that issue and thread - it was 5 months ago... :)

@Unixware

I have the same problem as OP, chromebook Acer AC710, currently on beta, crouton worked ok with beta till just yesterday... now I only get this darn message "(EE) no screens found(EE)" . Updating the chroot did nothing.

@DennisLfromGA
Collaborator

@Unixware, did you first download the latest version of 'crouton' before you updated your chroots? The latest version of crouton has the fix in it...

@Unixware

@DennisLfromGA , yea, I downloaded too the new version , that did not work. Anyway, after a powerwash the chroot works like before... so its ok now.

@steveg19710

i got the crouton working again(Hallelujah), and now i'm wondering if there
is a utility that could recover files that were lost on the xfce side?

On Fri, Jan 31, 2014 at 4:50 AM, Unixware notifications@github.com wrote:

@DennisLfromGA https://github.com/DennisLfromGA , yea, I downloaded too
the new version , that did not work. Anyway, after a powerwash the chroot
works like before... so its ok now.

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

@rudolphpienaar

Thanks... I did that, but am still getting the error. I'm on Chrome
34.0.1800.4 (Platform 5278.0.0-14.01.23)

On 1/30/14, 09:22 , drinkcat wrote:

@rudolphpienaar https://github.com/rudolphpienaar: You need to
update your chroots, see instructions here:
https://github.com/dnschneid/crouton#a-new-version-of-crouton-came-out-my-chroot-is-therefore-obsolete-and-sad


Reply to this email directly or view it on GitHub
#524 (comment).

@aeroperf

So if I need a solution to work immediately, I'm guessing going back to stable is still my best option?

@moline
moline commented Jan 31, 2014

HI there, still having problems.

I'm running on dev channel. Fix is active, and Here's what I have now:
Entering /usr/local/chroots/precise...
crouton: version 1-20131217183040~master:f4cd550d
release: precise
architecture: amd64
targets: touch,xfce
host: version 5116.53.0 (Official Build) beta-channel link
Unmounting /usr/local/chroots/precise...

I downloaded the new Crouton,
when I enter:: $ croutonversion -u -d -c ,
I get:: bash: croutonversion: command not found

When I enter:: sudo sh -e ~/Downloads/crouton -u -n chrootname
I get:: /usr/local/chroots/chrootname does not exist; cannot update.

Obviously I'm doing something wrong. Any suggestions?

@rawalk
rawalk commented Jan 31, 2014

@moline And anybody else having trouble getting their chroots setup again, Try this:

  1. Delete your crouton file from your downloads.

  2. http://goo.gl/fd3zc download the new crouton file from here.

  3. sudo ls -l /sys/kernel/debug/dri/drm_master_relax
    if the above spits out something like
    "-rw------- 1 root root 0 Jan 31 15:09 /sys/kernel/debug/dri/drm_master_relax"
    then that means the update is installed and theoretically you should not have problems, your problems stem from some silly mistake. And proceed to the following step.

  4. try running "sudo sh -e ~/Downloads/crouton -u -t x11 -n precise"

    -- NOTE: check the name of your chroot first by first running "sudo enter-chroot croutonversion"
    @moline's chroot name was "precise" as indicated by her post above. Yours might be different.

If you did not get something like the above in step 3, report it here, because it means the fix did not propagate to your system. And that's a global problem that can be addressed.

Oh PS: A general thing to @dnschneid and @drinkcat this "croutonversion -u -d -c" shortcut is legitly broken as I get "bash: croutonversion: command not found" as the output. Which is why I suggested manually downloading an update for the file.

I hope that this helps. Good luck :)

@dnschneid
Owner

croutonversion needs to be run from inside the chroot.

@rawalk
rawalk commented Jan 31, 2014

@dnschneid Ah gotcha, well apologies. That was not made clear on the README.md so running sudo enter-chroot , and then running croutonversion -u -d -c, works.

Awesome well, at least I learned something.

@DennisLfromGA
Collaborator

Cool, it's workin' on Canary -

(raring)denny@localhost:$ croutonversion
crouton: version 1-20140129115028
master:caadc6ce
release: raring
architecture: i386
targets: extension,chrome-beta,cli-extra,gtk-extra,cinnamon,gnome,kde,unity,xbmc,xfce
host: version 5395.0.0 (Official Build) canary-channel parrot

I'm running the canary channel on a usb stick made possible by Jay Lee's blog:
'Try Chrome OS Canary Without Risking Your Chromebook's Stability'

@jdashton
jdashton commented Feb 3, 2014

Yay! My CR-48 on the dev channel updated to kernel 5339 this weekend, and this problem #524 is now solved for me for both chroots (Precise and Saucy). Thank you!

@rudolphpienaar

Hi guys -- this thread is becoming rather long, and I hope I haven't missed a critical piece of info.

What is the current (as of today, 01-Feb-14) state of crouton on a dev pixel? I updated my crouton, turned off my chroot's custom xorg.conf (that used fbdev) and I'm getting the "X Server Access denied". I'm running whatever my pixel decided to update itself to over the weekend (I'm not on it right now, so can't confirm).

Just wondering if on pixels running dev chrome the upstream changes have trickled down, or if I should just be more patient. I've been somewhat surprised at how little I've been using the pixel since my crouton stopped working...

@drinkcat
Collaborator
drinkcat commented Feb 3, 2014

@rudolphpienaar: dev channel now includes the fix on all machines. Make sure to update your chroot (e.g. following @rawalk instructions: #524 (comment)).
If it is still not working, post the output of sudo enter-chroot croutonversion

@rudolphpienaar

Thanks for the quick reply! I'll check this evening...

Best
-=R

On 2/3/14, 10:51 , drinkcat wrote:

@rudolphpienaar https://github.com/rudolphpienaar: dev channel now
includes the fixes on all machines. Make sure to update your chroot
(e.g. following @rawalk https://github.com/rawalk instructions: #524
(comment)
#524 (comment)).
If it is still not working, post the output of |sudo enter-chroot
croutonversion|


Reply to this email directly or view it on GitHub
#524 (comment).

@rudolphpienaar

@drinkcat: Worked! Many thanks -- I have a working crouton again :-) Woohoo!

@moline
moline commented Feb 4, 2014

@rawalk Thanks for the help - all is working in the pixelworld again.

@juancferrer

So a new version (32.0.1700.103 - 4920.83.0) was released yesterday (Feb 4 2014) for STABLE.
Will updating to this release break X??.
I was already bitten by this bug on DEV, and then a few weeks later on BETA. It's not going to bite me again if I can help it.

@tedm
Contributor
tedm commented Feb 6, 2014

@juancferrer On the Samsung ARM, Crouton downloaded last Sunday, is working well with the stable channel Chrome OS update from yesterday, with a precise / xfce chroot. If you need to know exact version numbers, I can get those later today.

@rudolphpienaar

Hi (again) all --

In the wake of the fix to crouton and X etc, I've been slowly re-integrating my pixel into my workflow. I'm running the current dev of chromeos.

I by chance noticed today that on my crouton KDE desktop, OpenGL desktop effects weren't working -- for example Desktop Cube rotation when switching desktops. Curious, I tried some WebGL examples in a chromium browser running in the crouton session. No webgl support either (so the GL issue wasn't just some KDE thing, but seemed crouton-wide).These were all working prior to these recent X11 issue.

So, I'm wondering if this might be some artifact of all the X-server issues? As a stop gap while X wasn't working, I did use fbdev in a (crouton) /etc/X11/xorg.conf file, but I have removed this xorg.conf file since crouton started working again.

Does anyone have any ideas? OpenGL was working before the whole X debacle and I haven't changed anything on my crouton (other than run updates).

Best

@drinkcat
Collaborator

@rudolphpienaar: That's a different problem. Can you open a new issue?

In the new issue, from inside the chroot, please post:

  • The output of croutonversion (inside the chroot)
  • Create a gist (https://gist.github.com/), and post the output of glxinfo (you need to install the package mesa-utils), and the content of /var/log/Xorg.1.log.

Thanks.

@rudolphpienaar

Done. Many thanks.

@bradydowling

I am on the stable channel with Raring and Xfce. When I upgraded to Chrome OS I'm unable to start crouton, the same issues and output from the shell that are mentioned in this thread. I updated my targets after I upgraded Chrome and couldn't start Crouton. I actually did not have an xorg.conf file at all but once I added the fbdev fix it worked. Thank you so much for that fix. Here is my system information in case that will be useful:

Version 33.0.1750.124
Platform 5116.88.0 (Official Build) stable-channel falco
Firmware Google_Falco.4389.78.0

And here is my croutonversion output as well:

Entering /usr/local/chroots/raring...
crouton: version 1-20140114112909~master:7874dc04
release: raring
architecture: amd64
targets: keyboard,xfce,cinnamon
host: version 5116.88.0 (Official Build) stable-channel falco 
Unmounting /usr/local/chroots/raring...
@parthperygl

Can confirm bradydowling's report that this issue is now present on stable channel.

Version 33.0.1750.124
Platform 5116.88.0 (Official Build) stable-channel peppy
Firmware Google_Peppy.4389.81.0

crouton version output:

crouton: version 1-20140114112909~master:7874dc04
release: raring
architecture: amd64
targets: keyboard,xfce,cli-extra,chromium
host: version 5116.88.0 (Official Build) stable-channel peppy

@smibarber
Collaborator

@bradydowling, @parthperygl crouton needs to be updated on your machines. The drm fix was merged in on January 27, and your builds are a few weeks older than that.

Run croutonversion -u -d to download the latest version of crouton to Downloads, exit your chroot, then run sudo sh -e ~/Downloads/crouton -u -n chrootname to update your chroot(s).

@parthperygl

Thanks @smibarber! Should have thought of that...

@bradydowling

Awesome, I'll give this a shot tonight. I'm assuming I can just remove my
Xorg.conf file now and go from there and it'll be up and running again.

On Wed, Feb 26, 2014 at 4:25 PM, Parth notifications@github.com wrote:

Thanks @smibarber https://github.com/smibarber! Should have thought of
that...

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

@lanctot
lanctot commented Mar 1, 2014

I just applied the recent ChromeOS update (available a few days ago) and ran into the same problem (Xfce suddenly would not start). The upgrade of crouton fixed everything for me and seemed to update a lot of packages. Great to know; thanks @smibarber!

@spam10707

I am still seeing this issue on an Acer C720:

Version 33.0.1750.124
Platform 5116.88.0 (Official Build) stable-channel peppy
Firmware Google_Peppy.4389.81.0

crouton: version 1-20140301024303~master:06549cb2
release: saucy
architecture: amd64
targets: xfce,cli-extra
host: version 5116.88.0 (Official Build) stable-channel peppy

In addition to updating my existing chroot, I've tried creating a brand new one. Both show the same issue.

UPDATE: After rebooting the chromebook (not just sleeping it,) startxfce is working again. I hope that this may be helpful to someone else experiencing it.

@DennisLfromGA
Collaborator

Maybe we need to re-visit Auto-updates #351 again, it seems a lot of these problems are due to stale chroots.

@tejasmanohar

Is it safe to be on a dev, beta, or canary channel and use chroots now? This article still says it's not.

@smibarber
Collaborator

Said article is quite out of date. That issue's been fixed for a while.

@tejasmanohar

@smibarber Great, but other than that, the article's content still holds true right?

@smibarber
Collaborator

I think the graphics fixes section is no longer necessary. Aside from that, I can't say since I've never tried running elementary myself.

@tedm
Contributor
tedm commented Aug 30, 2014

The great part of that blog post is explaining how to apt-get purge unneeded packages. Not sure if it's up to date or not, does elementary run on the ARM?

@tejasmanohar

Probably but apt-get won't work for a lot of packages. I have intel cb anyways.

@dwploc
dwploc commented Dec 22, 2014

I am pulling out my hair on this same issue.

On a Pixel running:

Version 41.0.2252.3 dev (64-bit)
Platform 6592.2.0 (Official Build) dev-channel link_freon
Firmware Google_Link.2695.1.155
Check for and apply updates

Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20141208100324~master:7b8ffff0
release: trusty
architecture: amd64
targets: x11,keyboard,xfce
host: version 6592.2.0 (Official Build) dev-channel link_freon

Still seeing the X error:
Fatal server error:
(EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
(EE)

HELP Please. I KNEW I shouldn't move to DEV. Worked fine in BETA.

@dnschneid
Owner

This is not the same issue; freon has apparently propagated to link on dev. See #1265.

@bmoffitt

Is anyone else having this problem again in their chroots? I am on an Acer C710-2856 (with 10 GB ram and an SSD). I am currently on stable; I updated ChromeOS on Monday:

Version 42.0.2311.153 (64-bit)
Platform 6812.88.0 (Official Build) stable-channel parrot_ivb
Firmware Google_Parrot.2685.54.0

and my chroot stopped working. Here's the output from chrootversion:

crouton: version 1-20150519153807~master:30cf02c9
release: trusty
architecture: amd64
xmethod: xorg
targets: x11,xfce-desktop
host: version 6812.88.0 (Official Build) stable-channel parrot_ivb
kernel: Linux localhost 3.8.11 #1 SMP Fri May 8 13:50:13 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux
freon: no

If I just run startxfce4, it fails (exactly as if Chromeos had updated requiring a crouton update - Fatal server errors: (EE)no screens found (EE)). If I then update crouton and run startxfce4, the machine reboots.

I haven't changed the x.org config or anything else... I'm not sure what to do.

@torsava
torsava commented Mar 26, 2016

If anyone is still interested: The issue still persists when using the debian-sid chroot base. Recommended solution: Switch to an ubuntu chroot.

@tedm
Contributor
tedm commented Jan 6, 2017
@Yerffy
Yerffy commented Jan 15, 2017

@tedm Was trying to find if there was someone with the same issues and ended up responding on the wrong forum and deleted it after accidentally sending it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment